Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ