[HN Gopher] Frood, an Alpine Initramfs NAS
       ___________________________________________________________________
        
       Frood, an Alpine Initramfs NAS
        
       Author : pabs3
       Score  : 71 points
       Date   : 2024-12-16 07:13 UTC (15 hours ago)
        
 (HTM) web link (words.filippo.io)
 (TXT) w3m dump (words.filippo.io)
        
       | blueflow wrote:
       | 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 wrote:
       | 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 wrote:
         | > 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 wrote:
       | 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 wrote:
         | 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 wrote:
         | 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.
        
       | budwight wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2024-12-16 23:01 UTC)