5 ms·

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

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?
- mehrdadn 6y ago
  > You can just boot into the UEFI Interaractive Shell (think of it as a BIOS terminal/cmd.exe) > What's hard about that? That you had to explain what the UEFI interactive shell even is yourself is I think quite a clear answer to your question.
- Sebb767 6y ago
  > What's hard about that? Try booting from an encrypted drive identified by an UUID in a machine with a lot of disks
  - microcolonel 6y ago
    What does encryption have to do with you not having a label?
    - Sebb767 6y ago
      In some cases, the fstab needs specific volume names, which you also need to get right.
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?

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?
mehrdadn 6y ago
> You can just boot into the UEFI Interaractive Shell (think of it as a BIOS terminal/cmd.exe) > What's hard about that? That you had to explain what the UEFI interactive shell even is yourself is I think quite a clear answer to your question.
Sebb767 6y ago
> What's hard about that? Try booting from an encrypted drive identified by an UUID in a machine with a lot of disks
- microcolonel 6y ago
  What does encryption have to do with you not having a label?
  - Sebb767 6y ago
    In some cases, the fstab needs specific volume names, which you also need to get right.

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?