[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
