Hacker News Reader

Comment by giancarlostoro | Hacker News Reader

I've been wanting to do this but with a Pi or any SBC board with Linux from Scratch, but not sure how I would even approach LFS on a Pi.

View on HN

I'm in extremely early stages of writing up some documentation for how to build a Linux distro for a Raspberry Pi 3, gauging interest and figuring out pain points. Shoot me an email [my username]@gmail if you've got ideas or requests!

That sounds interesting. I think your guide would be extra helpful if it focused on building a distro that has as much of the system loaded into memory as possible to minimize amount of reads from the SD card, and which is configured with a read-only file system and never even tries to write to the SD card. That would be very useful. SD card corruption is a pain!

Maybe we can somehow refer to each other? I wrote a guide for a custom board I made running Linux, but it's very low level up to tge stage of getting the kernel running with a minimal user land.

I would be happy to refer to you at the end of mine: brainyv2.hak8or.com

What do you mean by building a distro? Have you looked at Yocto/poky/angstrom? It's kind of a distro-generator.

Might be worth doing the CLFS (Cross Linux From Scratch)[1] path since it'll be a LOT faster to compile things like the kernel and gcc on your deskop computer.

I did this and wrote a bunch of scripts to automate the process. CLFS uses busybox and DropBear to keep things really small (~42MB binary for the entire OS, including the Raspberry Pi blobs) - but you'll learn enough to be able to swap out components of your choosing.

[1] http://clfs.org/view/clfs-embedded/arm/

I'm not sure why you'd expect the approach for RPi needing to be significantly different from that of any other computer. Bootloader would be the biggest difference I foresee, but that is fairly small part of the whole LFS.

I've not done LFS, but have worked a bit with Linux on arm devices, and I would avoid choosing an arm device for this purpose because the state of upstream kernel support for many devices that arm manufacturers use is, well, shit. You'll almost certainly have to use some old, unmaintained manufacturer kernel to get all of the devices working (e.g. graphics).

Edit: It actually doesn't seem that bad for some(?) rpi devices: https://elinux.org/RPi_Upstreaming

Not sure if that list includes all devices found on even the newer ones too.

I'm fine with older kernels / older devices. My goal is to see how it all comes together and learn more about the internals. I like SBC's because they're usually cheap and can be replaced quickly and easily enough.

Older devices is fine, but you can start to run into trouble with older kernels. For example, newer glibc versions are notorious for requiring newer kernels [0].

So then you're stuck with an old glibc for your kernel. Not all applications (especially newer ones) will successfully link against that, so then you're looking for replacements or older versions that do (if there are any). What about other libc implementations, like musl? There are differences between musl and glibc[1] that will drive you nuts trying to find things that will link in musl that were originally written to link against glibc.

0. https://mirrors.edge.kernel.org/pub/software/libs/glibc/hjl/...

1. https://wiki.musl-libc.org/functional-differences-from-glibc...

My problems with LFS are:

1. The documentation is always in flux. You may get lucky and it's accurate, or you may not, and spend hours looking for tarballs that no longer exist online, or worse find them and they are no longer compatible with LFS - They don't host the required source archives along with the LFS book, and a lot of links to parts you need end up going nowhere.

2. As a step-by-step it does do what it says on the tin, but as a learning tool, there's a lot missing. When I was less knowledgeable about Linux I found myself following the LFS book with little to no idea about what I was actually doing and why. It would say things like 'chroot in the build folder' without actually explaining why, and what chroot actually did.

3. The whole thing can fail at any point, leaving you with a broken build, that more often than not, you'd have to wipe and start over. As most of the steps involve compiling, that's a lot of lost hours.

Reply on news.ycombinator.com