Hacker News Reader

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.

You almost certainly only need to run two or three efibootmgr commands to accomplish this. For most people that means only the "Using UEFI directly" section is relevant.

https://wiki.archlinux.org/title/EFISTUB

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

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

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

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.

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.

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.

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

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.

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.

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

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)

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

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.

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

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.

Yes, people who tell you that you can blindly buy any Lenovo laptop for Linux are lying. You have to do some googling first. Or check the inofficial Thinkpad Wiki. But other than that, if you pick a device that's recommended for use with Linux, it's as good as it gets regarding Linux on laptops if you ask me. Saying that your next Laptop isn't a Lenovo because your random purchase sucked is a little :rolleyes:

Oh and yes, avoid nvidia if you do Linux. Some people say it "works for them", but I for one would recommend just completely staying away from Linux if you want nvidia.

The truth is, and will probably always be, that you have to do some research before buying HW if you're using Linux and don't feel lucky.

> Yes, people who tell you that you can blindly buy any Lenovo laptop for Linux are lying.

I wouldn't say they're lying, per se, just that it's not 100% true. If you use PopOS with an X1 Extreme then almost all of those features work out of the box. On another OS they may not though. A good portion of what OP is describing require some applications present (and configured) in the userland, just having drivers isn't enough. The bit about grub I'm not sure about, but I believe it; that said grub is always a YMMV situation in my experience.

Ubuntu for me just works. I use it on an X1 Gen 5. Also used on XPS13.

I agree. I got a Lenovo Thinkpad L13 and I got lucky that there were no major issues running Linux on it. Although, this will be my last Lenovo laptop and also running Linux on a laptop.

I use Linux entirely for programming, and I already do that on VM's, on a server that I have. I basically just need to SSH and start Vim to do whatever I need to.

I have decided to move to using a Macbook Air with OS X. I like iTerm2 more and can just SSH into my Linux VM's. I am waiting to see if the new Air's launched this year will have dual monitor support, otherwise will just get an Intel based Macbook Air from 2019 or 2020.

Not lying if you talk about Thinkpads. Thry have been very good at Linux support for most of the thinkpad line up.

Have you used it without the dock? Because my experience with daily driving Linux at work for 10+ years with Thinkpads has been the complete opposite, with the exception of NVidia's driver garbage (which is just a problem with NVidia generally).

My current work system is a P53 that has an Nvidia GPU though and it's been working very very well for me through updates and the like via dkms.

The only other problem on that list I've encountered was within the first month or so after buying my T14s suspend support was a problem.

A bad dock can introduce a lot of problems.

> A bad dock can introduce a lot of problems.

That's why I bought the $400 official Lenovo dock.

Unfortunately, I can't do my daily work without the dock. (at least not without having to introduce numerous dongles and USB hubs, which may cause more issues)

I was unable to make the official dock work with my Lenovo (Fedora), but a usb-c dongle has been working without issues.

Same here, my $400 dock is completely non-functional with Fedora 35. I have read some reports it works with Arch, so maybe Fedora 36 will work.

I think most of the praise on Thinkpads comes from older versions, from IBM and the first Lenovos. I have an X220, and even though it's quite outdated hardware for today's world, it is still a very capable machine.

The most recent laptops are very good, but their support of linux is lacking compared with the older ones. As a rule of thumb, I try to find the model page in arch wiki before any purchase, it should list most of the common problems and how to fix them (if they are fixable at all, your X1-Extreme page for example[1]).

[1]: https://wiki.archlinux.org/title/Lenovo_ThinkPad_X1_Extreme

The last ThinkPad I owned disintegrated in under a year. The chassis was so poorly made that it just crumbled with normal use.

I have been buying Asus ever since. Not the prettiest machines but durable and reliable.

I have a Zephyrus G15 with 5800u/RTX3080/40GB/3TB and with the 5.15 kernel it works flawlessly on Linux Mint. I use it more often than MBP these days. The only drawback is no DisplayPort for VR.

Last time I got a new laptop, I simply ordered a Lenovo Thinkpad (X1 Carbon, not Extreme) with Linux pre-installed. I am past where I want to tinker to get the hardware and software working together, but do prefer Linux as my daily driver. I haven't had any issues with it, but I also got a relatively simple setup. I've ordered a Linux pre-installed Dell in the past with similar fine results.

Same for me, both my X1 Carbon and Precision Pro (2013 with Ubuntu pre-installed) worked flawlessly.

ThinkPad battery life could be a bit better, but that's my fault for choosing the 4k one.

Thank you for sharing; these comments make me pause.

At work, RHEL on Thinkpad is one of the standard offerings, and has continued to be across many generations. EVERYTHING works. I've had a work-provided RHEL Thinkpad (T450) which was smooth and seamless, as have my colleagues (most of them chose X1 variations, some T480, some with the newer T14).

I have a large number of Thinkpads at home and I want to install Linux on some of them, but comments like these make me wonder how much extra work and special juice our IT department had to commit in order to make it happen - and what my own experience would be in real world.

Older (1/2 years) models will generally have good support. In my experience you start running into issues when you purchase the latest gen and kernel support hasn’t yet caught up (e.g. 12th gen Intel processors)

The largest stumbling block is typically when the machine has 2 GPUs.

If it is just a normal Intel with integrated graphics / ultra-book it will work out of the box with distros like Ubuntu.

I cannot confirm any of this, and I am a complete noob regarding Linux. I don't have a 4k screen, and the Intel GPU is deactivated since day one anyway, so I can't say anything about using both GPUs in parallel. Sleep and power saving works just fine, firmware updates work without interference from my side. I use Nvidia proprietary drivers. Thunderbolt and external screens work without trouble. And battery life is good, maybe a little worse then under Windows, but that rather feels like minutes and not hours. Max I get out is just a little over 4 hours of Civ VI. Leaving it in sleep depletes the battery in the course of 3 days, more or less.

> Maybe I could solve some of this stuff if I'd spend some time on it, I don't know. I do know that as long as I run Linux as my daily driver, my next laptop won't be a Lenovo.

Could not agree more. I was using mac's for a decade prior to buying thinkpad X1E a couple years ago. It's been an absolute disaster and I now loath them. Multiple years after purchase, the only distro I could find that even half works is Fedora.

Docking is worse, even under windows. So the dock was working under linux for a while but as a last week it's completely non-functional, no usb, no display. Under windows, probably 25% of the time the USB devices don't function on startup, and have to be unplugged and plugged back in. I was trying to run a monitor with hdmi and it would half the time not wake up. Switched to display port and it's a little better but still problematic. And if your computer goes to sleep, it's 5-10 minutes of trying to wake and often requires hard power cycle to come back. I had to set the computer to sleep only after 2 hour or so. This is with all firmware and os updates applied.

In the future, will be be selling these hot messes, and moving to a framework laptop. Doubtful I every buy another thinkpad, I have many fond memories of my first couple of IBM based thinkpads those were awesome machines.

> ACPI, power management, and UEFI are consistently causing problems.

> Suspend on lid close is unpredictable.

Yeah, same experience here. The worst part is I can't even figure out how to debug this stuff. No idea where things are going wrong. I've gotten as far as dumping ACPI tables and disassembling some of its code but I can't find anything relevant.

What is Windows doing that Linux isn't? It can't be so insanely difficult, can it?

> The dual-GPU (Intel and nVidia) situation is unworkable under Linux.

Yup. Gotta choose one of them, can't use hybrid graphics.

> The battery life under Linux is about half of what you can expect from Windows.

I think it's due to power management issues, especially the dGPU which can't be turned off due to lack of hybrid graphics. On my laptop I got great battery life after disabling the GPU in the firmware settings.

Also, pretty much everything is GPU accelerated nowadays. Even terminal emulators. Kitty for example will cause massive power usage spikes.

I have run into issues when the hardware is very recent, but usually have a “works out of the box” experience if the model has been out more than 6-12mo. This often coincides with good deals on those models since Lenovo refreshes every 6-12mo and has sales to clear out the prior year’s inventory.

I’ll second you on the grub stuff, and the nvidia stuff.

I wish I could switch to an intel gpu. I’ve considered buying a thunderbolt dock just so I can not use nvidia when at home.

> Grub has an issue with the 4K display, causing it to render at about 1 FPS.

Just lower the resolution in grub's config file.