> Don't use Grub or any bootloader if you can avoid it. I haven't used Grub in 10 years. Load Linux directly as an EFI executable via the EFISTUB approach.

I run Windows dual boot, since I need (native) Windows for certain work related tasks.

> S3 suspend was removed as a default option by many hardware manufacturers. You will likely need to enter the BIOS to change this.

It's on, S3 is not the problem

> There is a bug in 5.17.x kernels where suspend doesn't work with bluetooth enabled. It will be fixed soon.

I'm not running 5.17.

But frankly, I don't want to care about all this "oh, but you just have to do [insanely_technical_thing]"

Sure, if I invest $LOTS_OF_TIME in it, I might be able to fix most of the issues. But this is a $3000 professional laptop, which is supposed to have good Linux support. This machine is my work equipment and I chose this expensive machine so I don't have to tinker with this stuff. It should just work.

> I run Windows dual boot, since I need (native) Windows for certain work related tasks.

If your firmware has a "boot from" hotkey (usually F12), then you use that as your dual-boot menu.

>But this is a $3000 professional laptop, which is supposed to have good Linux support. //

That's a big fail by Lenovo then, so why didn't you return it? When the support guys logged in to your computer to fix it, what did they do -- just go "yeah, or product is crap" and usher you away?

> so why didn't you return it?

Mostly because I had more important things to do at the time. Though not perfect, the computer does work, it does get the job done.

And also, I wouldn't know which other brand/model to get. I made my decision to buy the X1E based on the HN community recommending Lenovo as having one of the best support for Linux. So if I switch to a different brand, I might end up with an even worse Linux experience, so it wasn't worth the risk to me.

It's not that everything branded Lenovo runs linux flawlessly.

There are know models and model lines that do so (like the T line). Usually they were / are even offered in variants with Linux preinstalled from Lenovo web site.

Other models may have and do have problems, unsupported hardware, etc.

My X1 carbon works flawlessly aside from the fingerprint scanner (never tried it) and the builtin 4G modem which requires Windows drivers to initialize on Verizon with some shady proprietary blob that is downloaded over the air.

Yeah for the most part it's a "Linux on laptops works if you <list of steps to configure things>...". At least that has been my experience. Although I have not run Linux on a laptop in years so maybe it's time to revisit that.

There isn't much configuration to do if you have an X1 carbon installed with EFISTUB booting if you have the full KDE suite installed. KDE makes your interaction with any peripherals utterly seamless. If you don't want to tweak your Linux machine much, you need to go all-in on KDE.

It's highly dependent on the specific hardware. On some everything works out of the box, others you're stuck with very little working (think Apple M1). Just like any OS you always need to ensure hardware compatibility before purchase.

> I run Windows dual boot, since I need (native) Windows for certain work related tasks.

Windows also supports EFI boot.

>> Don't use Grub or any bootloader if you can avoid it. I haven't used Grub in 10 years. Load Linux directly as an EFI executable via the EFISTUB approach.

> I run Windows dual boot, since I need (native) Windows for certain work related tasks.

The windows/efi boot menu can handle dual boot.

But, assuming you want/need secure boot and bitlocker - I'm not sure if there is an easy way to avoid having to type in recovery key on kernel updates :/

Perhaps efi > direct windows and efi > grub > Linux might work? Probably still needs recovery key for bitlocker after grub update? Maybe this is solved now - I don't dual boot any machines w bitlocker right now.

>But frankly, I don't want to care about all this "oh, but you just have to do [insanely_technical_thing]"

>It should just work.

Then you should buy a laptop that ships with Linux and has official support from the vendor. Like the Dell XPS Developer edition, or anything from System76.

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-bi...

> 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.

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

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.

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?

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.

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.

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.

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)

I have used EFISTUB for 10 years but I wouldn't recommend it for the next install. The bootloader is the one arcane place that you don't want to be clever with and get reminded of its presence daily, because once it fails for some reason, it wastes much more time to find and read docs and diagnose than the time saved in boot speedup, because the knowledge to debug it is not something you would remember everyday. And this setup is even rarer than Grub, so any failure cases will not have help from cached knowledge and thus require much more research from first principle. Some backup options here would help in case, even if they impose some tax in boot speed. (If Grub takes a tax of 3 seconds per boot, and if a failure in EFISTUB takes 1 hour to resolve, it takes 1200 boots for EFISTUB to be worth the risk, which is 3 years if it's a laptop booting once per day, and much longer for a desktop.)

Once my desktop using the EFISTUB setup had a kernel that failed to boot, stuck at some filesystem error. Then I had to come up with a rescue plan at the spot, because there was no other way to boot into the desktop and there was no tutorial to help with this at the time.

The issues of EFISTUB:

- It doesn't interact with kernel updates nicely. I used a script in /etc/kernel/postinst.d to copy /vmlinuz to \EFI\debian\vmlinuz.efi. There is no rollback, and no multiple kernels.

- It doesn't work well with kernel parameters. The parameters are encoded in UEFI NVRAM. You have to create separate entries for different kernel parameters, or manipulate the NVRAM back and forth with efibootmgr, which is another gun that easily shoots the foot (you can easily mess up the bootorder variable).

- It doesn't play nicely with Windows and Secure Boot.

I use EFTSTUB with Arch Linux and I agree about it taking up more of your time. However, for me, this was all the very start to first set it up. Since then, it’s been smooth sailing.

I also use multiple kernels and I have had issues with kernel updates, and no issues with kernel parameters. However, there is friction with creating separate entries and so I created a very simple shell script to save my commands.

I’ve had no issues dual booting with Windows using BitLocker. I do not use secure boot (yet).

If you’re willing to spend an hour to set it up, I’d go for it. However, that’s an hour of your life you can save with Grub.

Sure, it's common to have it working for a long time, because breaking changes and interactions between different systems occur very infrequently at the level of bootloader and firmware, but when it happens it can easily get into very difficult support situation. Logistically speaking, firmware is not a nice place to play around. It's not well coded, not well tested, and rarely "used" by an end user.

For one I wouldn't put great confidence in a script to manipulate UEFI boot entries, because it is not idempotent and there are precedents to brick the UEFI with unexpected sequence of interaction. Also Windows' reboot options and its annual upgrade tend to mess with the boot variables. I had to help repair colleagues' laptops that had Grub's boot entries erased by Windows upgrades.

> Also Windows' reboot options and its annual upgrade tend to mess with the boot variables. I had to help repair colleagues' laptops that had Grub's boot entries erased by Windows upgrades.

I'm mostly a Windows user, and this has never happened in my experience: at worst Windows might reorder the UEFI boot options, or change the default boot option, but it has never overwritten or erased an entry.

At worst they are still available in the F12 boot menu.

> The parameters are encoded in UEFI NVRAM.

You can embed the parameters in the EFISTUB, this is explained in the arch wiki.

I use that to test different parameters with the same kernel packaged in different EFI payload, which I can select from the F12 boot menu if I don't want to use the commands to specify "use this payload only for the next boot"

It's completely seamless after initial setup on Arch Linux. No scripts, copying, or anything. It just works for years. I almost forgot it exists.

I see that you can use systemd as a boot loader (UEFI only). I've never tried it, but would like to set it up. The Arch wiki (of course) has info on it: https://wiki.archlinux.org/title/systemd-boot

I highly recommend that option, even if you use an Ubuntu based distribution: in 2022, there's no reason to still use grub on a UEFI system.