[HN Gopher] Mkinitcpio v31 and UEFI Stubs
       ___________________________________________________________________
        
       Mkinitcpio v31 and UEFI Stubs
        
       Author : Foxboron
       Score  : 40 points
       Date   : 2021-08-23 07:36 UTC (1 days ago)
        
 (HTM) web link (linderud.dev)
 (TXT) w3m dump (linderud.dev)
        
       | throwaway4857 wrote:
       | A similar option is to boot a kernel using the built-in EFI stub
       | (CONFIG_EFI_STUB=y), embed the initramfs if you use one
       | (CONFIG_INITRAMFS_SOURCE), and set the default command line with
       | CONFIG_CMDLINE if configuring it via UEFI is too unpleasant. I
       | boot like this.
       | 
       | Advantage: less complex than adding another layer (and
       | dependency) with the gummiboot stub.
       | 
       | Disadvantage: relinking the kernel is more expensive than
       | rebundling with objcopy, if you change initramfs with the same
       | kernel often.
       | 
       | Disadvantage: it's not an option if you use a distribution kernel
       | binary instead of building your own.
        
         | elFarto wrote:
         | I actually wrote a UEFI boot loader a few weeks ago that loads
         | the kernel, initramfs and command line directly from a file on
         | the root fs. It uses the efifs project to let it load directly
         | off of an ext4 file system.
         | 
         | It's nice to use compared with grub, just edit a file and
         | reboot. I've struggled to understand exactly how the fedora
         | boot system is configured, and which command I need to run or
         | file to edit to get it reconfigured.
        
           | zamadatix wrote:
           | The extra step of running the command to generate the final
           | output file has saved my ass many times since it checks for
           | errors as well. Other than that command it's the same process
           | isn't it? Edit /etc/default/grub, run command to validate and
           | apply, reboot?
        
         | zokier wrote:
         | This method is also documented at kernel.org:
         | 
         | https://www.kernel.org/doc/html/latest/filesystems/ramfs-roo...
         | 
         | https://www.kernel.org/doc/html/latest/driver-api/early-user...
        
       | dathinab wrote:
       | If the author reads this:
       | 
       | Thanks a lot.
       | 
       | I have been using some package manager hooks to do roughly the
       | same thing mkinitcpio no natively supports ;=)
        
       | LukeShu wrote:
       | Not related to this change in particular, but: mkinitcpio is neat
       | to me because it is one of the last pieces of bespoke distro-
       | specific software that's stayed on my radar.
       | 
       | It used to be that distros had to come up with huge piles of
       | distro-specific scripting to build a complete system, but the
       | trend has been to create independent projects so that each distro
       | doesn't need to reinvent things. Distros used to have a lot of
       | custom bootup scripts, which have been largely replaced by
       | modular components of systemd. For many distros, the scripts for
       | creating the init ramdisk have been replaced by Dracut; but not
       | on Arch Linux and derivatives, Dave Reisner's mkinitcpio is still
       | going strong. And it's interesting that Arch is being a holdout
       | with Dracut, when they were one of the first adopters of systemd.
        
         | throwmkinit wrote:
         | Is there a good reason for this? The last I read [0], Dave
         | didn't think that mkinitcpio was the way forward. I've since
         | migrated my setup to use dracut and haven't looked back. Is it
         | just inertia that's kept mkinitcpio alive?
         | 
         | [0]: https://lists.archlinux.org/pipermail/arch-dev-
         | public/2019-M...
        
           | random53 wrote:
           | How was the migration? Any potential pitfalls?
        
             | throwmkinit wrote:
             | Relatively straight-forward once you read up on alpm hooks
             | [0] to make sure you're rebuilding the init at the right
             | times. The wiki [1] has working examples that are drop-in
             | dracut replacements for
             | /usr/share/libalpm/scripts/mkinitcpio-{install,remove}.
             | Dracut also makes it easy to build unified kernel images
             | that can be signed for secure boot, which I never figured
             | out how to do with mkinitcpio.
             | 
             | [0] https://man.archlinux.org/man/alpm-hooks.5
             | 
             | [1] https://wiki.archlinux.org/title/Dracut
        
         | Teknoman117 wrote:
         | Another one is genkernel from Gentoo (although you can use
         | dracut as well).
        
       | binarybanana wrote:
       | I do create my own "EFI stub" by embedding the kernel and initrd
       | in a GRUB image as memdisk using grub-mkimage. Then I sign that
       | using my own keys and copy it over to the EFI partition. One cool
       | thing about it is that I can still adjust kernel boot parameters,
       | or load entirely different kernels by mounting the encrypted LVM
       | volume of I really need to. Using the kernel's own stub support
       | this isn't possible, but at the end the grub image still a single
       | self-contained bootable EFI executable file, just like the Linux
       | stub.
        
       ___________________________________________________________________
       (page generated 2021-08-24 23:02 UTC)