Frood, an Alpine Initramfs NAS(words.filippo.io)
words.filippo.io
Frood, an Alpine Initramfs NAS
https://words.filippo.io/dispatches/frood/
13 comments
> I wish other distros documented ways to make it easy to customize the initramfs like this.
Well this is not exactly a documented or "official" way to do things, it's just that Alpine is so darn simple, that producing an elegant but crazy hack doesn't look all too different from wrangling Ubuntu to do a normal, sane thing (like installing Firefox without Snap).
In fact, building an initramfs completely from scratch, with just enough userspace to start doing useful things, is not that difficult. It's just a cpio archive with an arbitrary filesystem layout - you can drop a statically linked executable (name it "/init"), pass -kernel & -initrd to Qemu, and you've got yourself a "hello, world" of embedded/single-purpose Linux.
> I don't like musl for compatibility reasons or RC scripts for managing services
That's the point. You can afford hacks like this because you got rid of all that complexity. musl is simple. RC scripts are simple. NixOS is all but.
Well this is not exactly a documented or "official" way to do things, it's just that Alpine is so darn simple, that producing an elegant but crazy hack doesn't look all too different from wrangling Ubuntu to do a normal, sane thing (like installing Firefox without Snap).
In fact, building an initramfs completely from scratch, with just enough userspace to start doing useful things, is not that difficult. It's just a cpio archive with an arbitrary filesystem layout - you can drop a statically linked executable (name it "/init"), pass -kernel & -initrd to Qemu, and you've got yourself a "hello, world" of embedded/single-purpose Linux.
> I don't like musl for compatibility reasons or RC scripts for managing services
That's the point. You can afford hacks like this because you got rid of all that complexity. musl is simple. RC scripts are simple. NixOS is all but.
I've been thinking about the opposite on my gentoo desktop, eliminating the initramfs. My understanding is if you compile the essential drivers you need for boot in the kernel (not as modules), then you don't need the initramfs step. Should result in faster boot.
Depends on how fast your BIOS/UEFI is at loading sectors off the disk; some are really slow and it can be faster to load and boot a small kernel and then load all the modules.
Static kernels like that used to be a lot more common when the kernel was simpler. I semi-fondly remember trying to optimize my 2.x era kernels on my Slackware box to eliminate everything I didn't absolutely need.
> My understanding is if you compile the essential drivers you need for boot in the kernel (not as modules), then you don't need the initramfs step.
Correct. When I ran Funtoo I did that so I can tell you it works.
> Should result in faster boot.
Possibly, but you should test. I expect it to work so long as you only bake in drivers needed for boot; if you include more then it could theoretically slow things down vs lazy-loading later.
Correct. When I ran Funtoo I did that so I can tell you it works.
> Should result in faster boot.
Possibly, but you should test. I expect it to work so long as you only bake in drivers needed for boot; if you include more then it could theoretically slow things down vs lazy-loading later.
Cool idea. Very simple. I like it.
> There are of course many alternatives for declarative systems: from NixOS (which just doesn’t sound fun)
The linked drama in the NixOS discourse forum is sad to see. I'm a happy NixOS user and committer, but never find need to browse the forum.
> There are of course many alternatives for declarative systems: from NixOS (which just doesn’t sound fun)
The linked drama in the NixOS discourse forum is sad to see. I'm a happy NixOS user and committer, but never find need to browse the forum.
I have created something "almost the same" but different.
I call it zquickinit - it's basically a bash script that generates initramfs - but adds in things like ZFSBootMenu, a proxmox installer, etc. I patched ZFSBootMenu so that I can securely boot/unlock the ZFS root boot, which holds the unlock key for the 2nd stage ZFS data pool.
I did this so that my ZFS install can have 0 keys in it. I use tailscale or ssh to access it in pre-boot mode, enter my key, and continue-on with boot.
Just sharing - Let me know what you think!
https://github.com/midzelis/zquickinit
I call it zquickinit - it's basically a bash script that generates initramfs - but adds in things like ZFSBootMenu, a proxmox installer, etc. I patched ZFSBootMenu so that I can securely boot/unlock the ZFS root boot, which holds the unlock key for the 2nd stage ZFS data pool.
I did this so that my ZFS install can have 0 keys in it. I use tailscale or ssh to access it in pre-boot mode, enter my key, and continue-on with boot.
Just sharing - Let me know what you think!
https://github.com/midzelis/zquickinit
I did the same, but the setup.sh is the weak point of the whole setup, as it needs to reproduce (and you need to update that) the behavior of the setup-* (alpine-conf) scripts.
Also apkovl's are dumb tarballs, you can generate them without using lbu.
Also apkovl's are dumb tarballs, you can generate them without using lbu.
Debian used to have a package called 'debirf' that let you do this too.
https://tracker.debian.org/pkg/debirf https://web.archive.org/web/20181231232620/http://cmrg.fifth...
https://tracker.debian.org/pkg/debirf https://web.archive.org/web/20181231232620/http://cmrg.fifth...
Do this but with systemd as the init and you've got yourself a new user. No, I don't mind the glibc dependency.
I ended up using Buildroot (with systemd) for some headless in-memory Raspberry Pi project because I was loathing writing init scripts with zero dependency management in Alpine land. But also because, as this blog mentions, Alpine's current "diskless" options are, confusingly, anything but what I (and the author) want: reproducible, build-once-and-forget, fully standalone images with no moving parts. What Alpine gives you instead is an awkward overlay system with some intermediate runtime steps.
I ended up using Buildroot (with systemd) for some headless in-memory Raspberry Pi project because I was loathing writing init scripts with zero dependency management in Alpine land. But also because, as this blog mentions, Alpine's current "diskless" options are, confusingly, anything but what I (and the author) want: reproducible, build-once-and-forget, fully standalone images with no moving parts. What Alpine gives you instead is an awkward overlay system with some intermediate runtime steps.
Just use standard chroot creation tools (like mmdebstrap for Debian) and stuff the results into an initramfs?
Love it. Very similar to mine which I embarrassingly have not written about (other than a readme) for the going on 3 years I've been using it daily.
But I think the point of these type of systems (small, immutable, simple) is that they are so simple that aside from introducing people to the concept there isn't much else needed. Anyway, go forth and build, these type of systems are fast, fun, and teach you a lot (even for a grump using Linux for 20 years like me)
But I think the point of these type of systems (small, immutable, simple) is that they are so simple that aside from introducing people to the concept there isn't much else needed. Anyway, go forth and build, these type of systems are fast, fun, and teach you a lot (even for a grump using Linux for 20 years like me)
There are other options, but they have considerable barriers to entry as well, like NixOS which requires learning their specific DSL. I like the idea of `bootc` but that doesn't support running from RAM best I can tell. Other distros really only document customizations to the initramfs as a means to provide an installer for a stateful system, which makes running a server like this a bit of uncharted territory.