3 ms·

By not using Grub you lose the ability to fallback on a safe kernel. That may be quite dangerous depending on how reliable kernel update is for you. I have been

By not using Grub you lose the ability to fallback on a safe kernel. That may be quite dangerous depending on how reliable kernel update is for you. I have been saved by kernel fallbacks before. Double that for laptops whose ACPI drivers randomly break from version to version, as evidenced by your note on 5.17.x kernels. Regardless I sympathize, as I recently had a good deal of trouble updating from BIOS to UEFI. The 4K issue seems to also affect Dell XPS15 and leads to a kernel panic on the latest Canonical Live CD [1] [1] https://cenains.blog/2022/05/01/converting-boot-mode-from-bios-to-uefi-in-ubuntu-with-xps15-9550/ https://cenains.blog/2022/05/01/converting-boot-mode-from-bi...

smoldesu 4y ago
I mean, that's not entirely true. You can chroot into your box and change your kernel if something goes horrifically wrong, the situation isn't as unsalvageable as you paint it out to be.
- Sakos 4y ago
  It's possible but it's more inconvenient than it needs to be. I'd rather be able to select a previous kernel from a list instead of trying to remember how to change the kernel through chroot on a broken system.
  - csdvrx 4y ago
    You can totally select a different kernel if it's packaged in its own EFI payload. You can even enroll this EFI payloads from within the BIOS by just selecting the file from the EFI partition if you forgot to add them into your UEFI (ie if they don't show in your F12 boot options)
csdvrx 4y ago
> By not using Grub you lose the ability to fallback on a safe kernel That is factually wrong: if you create other EFI entries with different kernel payloads, then enroll them in your UEFI bios, you can select them at boot time in a menu. This is how I test cmdline options (same kernel packaged in different .EFI) If you forgot to do that before a problem, but still have the old payloads around, you can even use the UEFI to add EFI payloads by selecting their files from your EFI partition.
- ptsneves 4y ago
  Hmm seems we disagree so it is not factually wrong, but a matter of where you draw the line at fallback. I am not an expert in uefi but my uefi system does not give me the ability to pass command line arguments to the kernel. I actually went to check and took a picture[1]. According to your statement that means you need a working system to repack your kernel if you do not use grub. That kind of proves the opposite of what you write. With grub you can set kernel arguments in an ephemeral way by just interrupting the boot. In the past, when testing failing kernels it was mighty useful to add a magic argument to the kernel. [1] https://ibb.co/6vS1VX9 https://ibb.co/6vS1VX9
orangepurple 4y ago
I keep a USB key around with the Arch Linux ISO to boot an OS, mount my filesystem, and fix whatever is busted. I never needed to do this yet.
arminiusreturns 4y ago
This got me looking around at how one would load a luks or dm-crypt encrypted drive from efi without grub. I didn't find anything solid but I've used initram shims for stuff like that before so that might be an approach but at that point you might as well use grub which has some nice features built-in. I guess I'm really curious what there is to gain by bypassing grub if anything?
- smoldesu 4y ago
  I don't use GRUB on any of my systems anymore, here's a couple loose answers to your questions. > This got me looking around at how one would load a luks or dm-crypt encrypted drive from efi without grub. systemd-boot lets you define an encrypted drive at installation, which is what I do for my LUKS devices. Whole thing works pretty flawlessly, in my experience. > I guess I'm really curious what there is to gain by bypassing grub if anything? I mean, you're not "bypassing" anything; Linux has molecularity at it's core, it's perfectly normal to swap out it's surrounding components to personalize your system. Personally, I pass on GRUB because systemd-boot is fast. Booting with GRUB takes 10-45 seconds depending on your hardware and encryption setup: I've never seen systemd-boot take longer than 15. If you're not dual-booting or doing any fancy baremetal stuff, I think most people would be perfectly happy with it. GRUB certainly still has it's place though, and I'm glad it exists.

smoldesu 4y ago

I mean, that's not entirely true. You can chroot into your box and change your kernel if something goes horrifically wrong, the situation isn't as unsalvageable as you paint it out to be.

Sakos 4y ago
It's possible but it's more inconvenient than it needs to be. I'd rather be able to select a previous kernel from a list instead of trying to remember how to change the kernel through chroot on a broken system.
- csdvrx 4y ago
  You can totally select a different kernel if it's packaged in its own EFI payload. You can even enroll this EFI payloads from within the BIOS by just selecting the file from the EFI partition if you forgot to add them into your UEFI (ie if they don't show in your F12 boot options)

csdvrx 4y ago

> By not using Grub you lose the ability to fallback on a safe kernel That is factually wrong: if you create other EFI entries with different kernel payloads, then enroll them in your UEFI bios, you can select them at boot time in a menu. This is how I test cmdline options (same kernel packaged in different .EFI) If you forgot to do that before a problem, but still have the old payloads around, you can even use the UEFI to add EFI payloads by selecting their files from your EFI partition.

ptsneves 4y ago
Hmm seems we disagree so it is not factually wrong, but a matter of where you draw the line at fallback. I am not an expert in uefi but my uefi system does not give me the ability to pass command line arguments to the kernel. I actually went to check and took a picture[1]. According to your statement that means you need a working system to repack your kernel if you do not use grub. That kind of proves the opposite of what you write. With grub you can set kernel arguments in an ephemeral way by just interrupting the boot. In the past, when testing failing kernels it was mighty useful to add a magic argument to the kernel. [1] https://ibb.co/6vS1VX9 https://ibb.co/6vS1VX9

orangepurple 4y ago

I keep a USB key around with the Arch Linux ISO to boot an OS, mount my filesystem, and fix whatever is busted. I never needed to do this yet.

arminiusreturns 4y ago

This got me looking around at how one would load a luks or dm-crypt encrypted drive from efi without grub. I didn't find anything solid but I've used initram shims for stuff like that before so that might be an approach but at that point you might as well use grub which has some nice features built-in. I guess I'm really curious what there is to gain by bypassing grub if anything?

smoldesu 4y ago
I don't use GRUB on any of my systems anymore, here's a couple loose answers to your questions. > This got me looking around at how one would load a luks or dm-crypt encrypted drive from efi without grub. systemd-boot lets you define an encrypted drive at installation, which is what I do for my LUKS devices. Whole thing works pretty flawlessly, in my experience. > I guess I'm really curious what there is to gain by bypassing grub if anything? I mean, you're not "bypassing" anything; Linux has molecularity at it's core, it's perfectly normal to swap out it's surrounding components to personalize your system. Personally, I pass on GRUB because systemd-boot is fast. Booting with GRUB takes 10-45 seconds depending on your hardware and encryption setup: I've never seen systemd-boot take longer than 15. If you're not dual-booting or doing any fancy baremetal stuff, I think most people would be perfectly happy with it. GRUB certainly still has it's place though, and I'm glad it exists.