6 ms·

Looks nice. I personally don't use Bootloaders anymore , using UEFI directly to boot my kernel. Edit: It doesn't require any manual tinkering/maintainance eve

Looks nice. I personally don't use Bootloaders anymore , using UEFI directly to boot my kernel. Edit: It doesn't require any manual tinkering/maintainance even when updating. Also it boots fast. https://wiki.archlinux.org/index.php/EFISTUB https://wiki.archlinux.org/index.php/EFISTUB

bestouff 6y ago
How do you do that ? I didn't know you could compile a kernel directly to an UEFI payload. Edit: Indeed it's possible with CONFIG_EFI_STUB=y : https://wiki.archlinux.org/index.php/EFISTUB https://wiki.archlinux.org/index.php/EFISTUB - thanks for the hint !
- mehrdadn 6y ago
  Note that just because you can, it doesn't mean you should. How much maintenance this needs depends on your distro, your machine and firmware's own quirks (if any), and your own usage/update/maintenance patterns/quirks.
  - deleted 6y ago
    [deleted]
  - bleepblorp 6y ago
    Also: directly booting the kernel as a UEFI module makes it much more difficult to set kernel parameters temporarily on boot. If you need to boot into runlevel 3 (or use init=/bin/bash) for maintenance, it's going to be much more complicated to make this happen than it is when booting through Grub.
    - josteink 6y ago
      Is it really? You can just boot into the UEFI Interaractive Shell (think of it as a BIOS terminal/cmd.exe), which most BIOSes have, and launch your kernel with those parameters, as regular arguments to a regular command, right? What's hard about that?
      - chabad360 6y ago
        Not really, the EFISTUB has the kernel arguments baked into it, and to my knowledge, you can't just execute it with arguments and expect it to use them.
        vladvasiliu 6y ago
        According to the Arch Wiki [0] that can be done by using an `.efi` file but it is not necessarily the case. The UEFI can directly load the linux kernel and add parameters. However, it's not particularly practical. Of course, as with all things UEFI, YMMV. This worked for me on an HP EliteDesk 800 G2 before I got around to setting up the keys for secure boot. [0] https://wiki.archlinux.org/index.php/EFISTUB#Using_UEFI_directly https://wiki.archlinux.org/index.php/EFISTUB#Using_UEFI_dire...
        josteink 6y ago
        From the very same wiki you linked, and just like I claimed, you can do this directly: > fs0: > \vmlinuz-linux root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 rw initrd=\initramfs-linux.img Again: how is this hard?
        vladvasiliu 6y ago
        I never said it was hard, just not as practical as modifying a command line, for example in Grub, that already has the UUID setup. Also, not sure how many people have the UUID lying around ready to be copied. If you have encryption setup, there's even more parameters to add. Again, it's not hard, but a bootloader with an editable command line is just much simpler.
        bleepblorp 6y ago
        Why go to the trouble of typing a UUID (from memory?) when Grub just works?
        mehrdadn 6y ago
        > \vmlinuz-linux root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 rw initrd=\initramfs-linux.img > Again: how is this hard? Is this a joke? Is this something you do yourself with any frequency? Do you realize how utterly painful just typing the correct UUID is? I've had to rescue non-booting systems like this many dozens of times and it makes me absolutely hate my life that on top of having to fix the actual boot problem, I also have to scramble to find a paper and pencil or grab a phone or whatever (or flip back and forth between two screens approximately 51,295,183 times) just to copy 32 random hexadecimal digits from another screen just to test other parameters from a screen I really shouldn't have to bring up in the first place. Especially given the inevitable transcription mistakes that will force you through another reboot cycle. It's such an utter frustration and waste of time to have to go through this nonsense to test a fix to a boot issue. And that's based on the ridiculous assumption that the process is somehow intuitive for people—what fraction of Linux users do you think even know there's both a PARTUUID and a volume UUID? What fraction do you think even know what to type when they face a GRUB screen, and also know what kernel parameters they need to pass? What fraction of those do you think know (and remember!) how to do all this in the UEFI shell?
    - BenjiWiebe 6y ago
      Just have two UEFI boot entries: one booting the EFI stuff directly, and one booting GRUB, which then boots the same kernel. Then you can use GRUB to change kernel command line.
      - mehrdadn 6y ago
        What tangible benefit do you get from booting directly if you're going to have to maintain the GRUB entries anyway? Some ε > 0 improvement in boot time?
        marta_morena_25 6y ago
        It makes you feel cool? I guess.
    - therein 6y ago
      You can boot into the EFI shell or use your firmware setup (likely DEL upon boot) to reconfigure your boot records and entries.
      - bleepblorp 6y ago
        How common are those features? None of my systems have the UEFI shell in firmware or provide that level of control over boot records from the firmware setup interface.
    - tinus_hn 6y ago
      Just in case you absolutely cannot boot from the rescue USB stick?
alias_neo 6y ago
Does that make kernel updates a more manual process? Are you building your own? Are you signing and using secure boot? I'd be interested in giving this a try.
- profsnuggles 6y ago
  That is what I am doing as well. I'm building my own kernel but not using secure boot. Kernel upgrades are just copying .config from the old kernel to the new kernel. sudo make olddefconfig && sudo make && sudo make modules_install && install_kernel The contents of install_kernel KERNEL=`readlink /usr/src/linux` NUMBER=${KERNEL##linux-} NUMBER=${NUMBER%%-gentoo} sudo cp arch/x86_64/boot/bzImage /boot/EFI/Gentoo/vmlinuz-${NUMBER}-gentoo.efi sudo efi bootmgr -c -L "Gentoo ${NUMBER}" -l "\\EFI\\Gentoo\\vmlinuz-${NUMBER}-gentoo.efi" -d /dev/nvme0n1
  - alias_neo 6y ago
    Amazing thanks for the explanation, I'll have to give this a go!
  - mshook 6y ago
    Don't compile as root, there's no need for that. You should only elevate your privileges when needed. The only thing you need root for are modules_install and your install_kernel script.
    - londons_explore 6y ago
      People always say this, but if a project is malicious, it can take your SSH keys and get persistence even without root. It can alias sudo in your bashrc to get root if it wants too. Yet if you don't use sudo, some make/compiles fail with random permissions errors. I mean I see the reasoning, but in 2020 I think the Linux desktop security model is sufficiently broken that it doesn't matter.
- deleted 6y ago
  [deleted]
- 6y ago

bestouff 6y ago

How do you do that ? I didn't know you could compile a kernel directly to an UEFI payload. Edit: Indeed it's possible with CONFIG_EFI_STUB=y : https://wiki.archlinux.org/index.php/EFISTUB https://wiki.archlinux.org/index.php/EFISTUB - thanks for the hint !

mehrdadn 6y ago
Note that just because you can, it doesn't mean you should. How much maintenance this needs depends on your distro, your machine and firmware's own quirks (if any), and your own usage/update/maintenance patterns/quirks.
- deleted 6y ago
  [deleted]
- bleepblorp 6y ago
  Also: directly booting the kernel as a UEFI module makes it much more difficult to set kernel parameters temporarily on boot. If you need to boot into runlevel 3 (or use init=/bin/bash) for maintenance, it's going to be much more complicated to make this happen than it is when booting through Grub.
  - josteink 6y ago
    Is it really? You can just boot into the UEFI Interaractive Shell (think of it as a BIOS terminal/cmd.exe), which most BIOSes have, and launch your kernel with those parameters, as regular arguments to a regular command, right? What's hard about that?
    - chabad360 6y ago
      Not really, the EFISTUB has the kernel arguments baked into it, and to my knowledge, you can't just execute it with arguments and expect it to use them.
      - vladvasiliu 6y ago
        According to the Arch Wiki [0] that can be done by using an `.efi` file but it is not necessarily the case. The UEFI can directly load the linux kernel and add parameters. However, it's not particularly practical. Of course, as with all things UEFI, YMMV. This worked for me on an HP EliteDesk 800 G2 before I got around to setting up the keys for secure boot. [0] https://wiki.archlinux.org/index.php/EFISTUB#Using_UEFI_directly https://wiki.archlinux.org/index.php/EFISTUB#Using_UEFI_dire...
        josteink 6y ago
        From the very same wiki you linked, and just like I claimed, you can do this directly: > fs0: > \vmlinuz-linux root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 rw initrd=\initramfs-linux.img Again: how is this hard?
        vladvasiliu 6y ago
        I never said it was hard, just not as practical as modifying a command line, for example in Grub, that already has the UUID setup. Also, not sure how many people have the UUID lying around ready to be copied. If you have encryption setup, there's even more parameters to add. Again, it's not hard, but a bootloader with an editable command line is just much simpler.
        bleepblorp 6y ago
        Why go to the trouble of typing a UUID (from memory?) when Grub just works?
        mehrdadn 6y ago
        > \vmlinuz-linux root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 rw initrd=\initramfs-linux.img > Again: how is this hard? Is this a joke? Is this something you do yourself with any frequency? Do you realize how utterly painful just typing the correct UUID is? I've had to rescue non-booting systems like this many dozens of times and it makes me absolutely hate my life that on top of having to fix the actual boot problem, I also have to scramble to find a paper and pencil or grab a phone or whatever (or flip back and forth between two screens approximately 51,295,183 times) just to copy 32 random hexadecimal digits from another screen just to test other parameters from a screen I really shouldn't have to bring up in the first place. Especially given the inevitable transcription mistakes that will force you through another reboot cycle. It's such an utter frustration and waste of time to have to go through this nonsense to test a fix to a boot issue. And that's based on the ridiculous assumption that the process is somehow intuitive for people—what fraction of Linux users do you think even know there's both a PARTUUID and a volume UUID? What fraction do you think even know what to type when they face a GRUB screen, and also know what kernel parameters they need to pass? What fraction of those do you think know (and remember!) how to do all this in the UEFI shell?
  - BenjiWiebe 6y ago
    Just have two UEFI boot entries: one booting the EFI stuff directly, and one booting GRUB, which then boots the same kernel. Then you can use GRUB to change kernel command line.
    - mehrdadn 6y ago
      What tangible benefit do you get from booting directly if you're going to have to maintain the GRUB entries anyway? Some ε > 0 improvement in boot time?
      - marta_morena_25 6y ago
        It makes you feel cool? I guess.
  - therein 6y ago
    You can boot into the EFI shell or use your firmware setup (likely DEL upon boot) to reconfigure your boot records and entries.
    - bleepblorp 6y ago
      How common are those features? None of my systems have the UEFI shell in firmware or provide that level of control over boot records from the firmware setup interface.
  - tinus_hn 6y ago
    Just in case you absolutely cannot boot from the rescue USB stick?

alias_neo 6y ago

Does that make kernel updates a more manual process? Are you building your own? Are you signing and using secure boot? I'd be interested in giving this a try.

profsnuggles 6y ago
That is what I am doing as well. I'm building my own kernel but not using secure boot. Kernel upgrades are just copying .config from the old kernel to the new kernel. sudo make olddefconfig && sudo make && sudo make modules_install && install_kernel The contents of install_kernel KERNEL=`readlink /usr/src/linux` NUMBER=${KERNEL##linux-} NUMBER=${NUMBER%%-gentoo} sudo cp arch/x86_64/boot/bzImage /boot/EFI/Gentoo/vmlinuz-${NUMBER}-gentoo.efi sudo efi bootmgr -c -L "Gentoo ${NUMBER}" -l "\\EFI\\Gentoo\\vmlinuz-${NUMBER}-gentoo.efi" -d /dev/nvme0n1
- alias_neo 6y ago
  Amazing thanks for the explanation, I'll have to give this a go!
- mshook 6y ago
  Don't compile as root, there's no need for that. You should only elevate your privileges when needed. The only thing you need root for are modules_install and your install_kernel script.
  - londons_explore 6y ago
    People always say this, but if a project is malicious, it can take your SSH keys and get persistence even without root. It can alias sudo in your bashrc to get root if it wants too. Yet if you don't use sudo, some make/compiles fail with random permissions errors. I mean I see the reasoning, but in 2020 I think the Linux desktop security model is sufficiently broken that it doesn't matter.
deleted 6y ago
[deleted]
6y ago