Date: Mon, 01 Jun 2015 23:58:46 +0200 From: John Spencer <maillist-musl@...fooze.de> To: sabotage@...ts.openwall.com CC: br1.rdgz@...il.com Subject: Re: Introduction and some (little) problems (already solved :P ) bruno wrote: > Hello!! > > My name is Bruno, and I got information about this distro thanks to > suckless.org... And I liked the idea, so I started installing it in a VM > (to check if I could do the same to bare metal). Yes, I know I could have > used an image, use the staged stuff or whatever... But the idea was > starting from scratch. that's the right spirit. > > My first problem was finding a suitable live-cd-dvd-usb-something with a > somehow useful gcc version able to compile a stage0. Finally I'm using > knoppix DVD, because of: > > a) It's the only one I found with a usable git, gcc, and some more stuff > (screen, sshd), > b) it's got i686 and x86_64 kernels/libs and > c) starting it with "knoppix 2" or "knoppix64 2" in single user mode is > fast enough > > My second problem: the "butch install core" part didn't work, because of > libressl. The errors (sorry, I didn't keep the logs) were a bunch of > undefined references to stuff, like this > > undefined reference to `__stack_chk_fail_local' interesting, i wasn't aware that this happens with current libressl on i386. > > I know, this is a well known problem with " -fstack-protection-all " option > and linking to the SSP library. So, even if there is a patch for that in > gcc474, I had to add -lssp_nonshared to CFLAGS in the pkg file. After that > it worked > > CFLAGS="-lssp_nonshared $optcflags" > > I also had a little problem with git installation, the LDFLAGS there should > be set to: > > LDFLAGS="$optldflags -static-libgcc" why ? > > BTW, I changed the package file to install git 2.4.0, is there anybody > interested in "new packages" ? I normally use arch linux, and I love AUR, > but I also know it requires resources, a community and lots of effort. sure, updated packages are always welcome (as long as they don't break other packages or pull in a mountain of new dependencies) > > Finally, the default kernel configuration is not that cool when it comes > about having a filesystem in ext4. It looks like a normal mkfs.ext4 sets > the option huge_files to the filesystem, and that needs the option "Enable > the block layer ---> Support for large (2TB+) block devices and files" > activated in the kernel. I read something about that here: seems nobody used sabotage i386 (32bit) yet with huge harddisks (the kernel option depends on !64bit so it's probably a non-issue on x86_64) I guess it would be safe to enable CONFIG_LBDAF in the default kernel. > > http://kuttler.eu/post/filesystem-with-huge-files-cannot-be-mounted-read-write-without-config_lbdaf/ > > So I had to boot again chrooting from knoppix and execute that > > tune2fs -O ^huge_file /dev/sda2; fsck /dev/sda2 > > And after that everything booted OK. If you are reading this and you think > this message was sort of "a noob saying s*it", I'm sorry, but since a > gentoo from stage 0 and an LFS (following the guide step by step), > installing a distribution from scratch is something I'm not doing every day. > > Thank you !!! > thank you as well for your report! btw, you can open issues and pull requests on github as well (prefered). --JS
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.