6 ms·

Frood, an Alpine Initramfs NAS

97 points by pabs3 2y ago

Zopieux 2y ago
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.
- pabs3 2y ago
  Just use standard chroot creation tools (like mmdebstrap for Debian) and stuff the results into an initramfs?
aim4min 2y ago
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 https://github.com/midzelis/zquickinit
blueflow 2y ago
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.
DCKing 2y ago
I wish other distros documented ways to make it easy to customize the initramfs like this. I'd love to build a setup like this, but I don't want to use Alpine as I don't like musl for compatibility reasons or RC scripts for managing services. 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.
- rollcat 2y ago
  > 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.
seiferteric 2y ago
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.
- zhengyi13 2y ago
  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.
- benlivengood 2y ago
  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.
- yjftsjthsd-h 2y ago
  > 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.
budwight 2y ago
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.
dmwilcox 2y ago
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)
pabs3 2y ago
Debian used to have a package called 'debirf' that let you do this too. https://tracker.debian.org/pkg/debirf https://tracker.debian.org/pkg/debirf https://web.archive.org/web/20181231232620/http://cmrg.fifthhorseman.net/wiki/debirf https://web.archive.org/web/20181231232620/http://cmrg.fifth...

97 points by pabs3 2y ago

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.

pabs3 2y ago
Just use standard chroot creation tools (like mmdebstrap for Debian) and stuff the results into an initramfs?

aim4min 2y ago

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 https://github.com/midzelis/zquickinit

blueflow 2y ago

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.

DCKing 2y ago

I wish other distros documented ways to make it easy to customize the initramfs like this. I'd love to build a setup like this, but I don't want to use Alpine as I don't like musl for compatibility reasons or RC scripts for managing services. 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.

rollcat 2y ago
> 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.

seiferteric 2y ago

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.

zhengyi13 2y ago
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.
benlivengood 2y ago
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.
yjftsjthsd-h 2y ago
> 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.

budwight 2y ago

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.

dmwilcox 2y ago

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)

pabs3 2y ago

Debian used to have a package called 'debirf' that let you do this too. https://tracker.debian.org/pkg/debirf https://tracker.debian.org/pkg/debirf https://web.archive.org/web/20181231232620/http://cmrg.fifthhorseman.net/wiki/debirf https://web.archive.org/web/20181231232620/http://cmrg.fifth...