I've done it recently on my work laptop. Some notes for whoever walks this path.

I'd add /opt to that list, where I install non-apt software .e.g. Jetbrains, Joplin, eclipse, ...

Some stuff under $HOME breaks even if it shouldn't. firefox got an upgrade from LTS to mozilla, and refused to pickup or even import its profile and passwords. libreoffice never got past the splash screen . The corporate VPN tool just completely broke for no apparant reason. Deleting and rewriting all their .config 'fixed' it. Also, .cache was not copied over.

I started maintaining an ansible script to manage my laptop, but that was more to learn ansible. Even so, it did well rebuilding /etc. I have a copy but don't seem to need it..

I look at utmp to book my work hours, so I had to guestimate failover day. A next upgrade will copy it too.

Renaming the home directory due to sssd broke a lot of paths that really should have been relative to ~. I made a symlink from my old home as lazy workaround.

All in all, I was back running fast, but mainly because everything was scripted or in a decent location. My days of perfectly tuning every nook and cranny are long past.

Also I should clarify that I'm not trying to say this is your fault. But I also understand why the maintainers acted the way they did. I think it's not unreasonable to expect that a configuration change distributed as part of a new version of a program won't be installed by itself.

>isn't guaranteed to work

Nothing's guaranteed, but it is good when an OS which is properly installed to be bootable by BIOS, behaves like it should and will naturally also be bootable by UEFI according to what the firmware finds in an accessible EFI folder somewhere.

Or if nothing else what you can type in on the UEFI shell.

One of the inconsistencies I see between different distributions is the location of the full set of Grub boot files.

Sometimes the EFI (Fat32) partition will only contain the minimal handful of files barely needed to boot, with the remaining bulk of the files still needed to follow through, plus service & update Grub, residing on the EXTx volume. This is descended from the legacy way of having Grub2's "barely needed" boot code reside in a small number of traditional boot sectors (back before UEFI displaced MBR), while the remaining bulk of Grub was similarly in files & folders in the main Linux EXTx volume. In these cases a grub.cfg file may exist in both the fat32 EFI as well as within the EXTx fileset. And they will often, if not usually, be different.

Experience has shown this to be nonideal compared to the established alternative:

Other distros will have the full config and service files & folders, including initrd & vmlinuz, right there on the EFI volume in the distro's own designated folder.

This is really the way it should be going forward. With UEFI now standardized at having a required fat32 boot volume, the more complete boot files finally have the perfect place they have been needing since the BIOS days.

Now the distros that already have this are actually compatible with what they had in the past because once booted they find Grub on the EFI partitiion and mount the working Grub folders virtually on the EXTx filesystem into their previously expected locations.

That way either alternative for the physical location of Grub support files in common use today is intended to be handled by the same grub service & update scripts.

So it is no longer as sensible to have any of the Grub support files on the EXTx volume at all, or the performance is poorer than Windows.

Since today's Windows NT6 takes full advantage of the dedicated EFI partition, so its boot files in \EFI\Microsoft are more-than-complete as needed. That way you can change everything on the NTFS volume alone and it changes nothing about NT6 booting whatsoever.

IOW with Windows you can format and recover your NTFS volume alone, choosing from any number of backup dates, without touching the EFI volume at all. This quite reliably boots the Windows that it finds on your main NTFS volume, regardless if is actually the same version or year as the NT6 bootfiles.

The possibility of equivalent Linux backup/recovery workflow is broken when Grub is not physically stored on the EFI partition, which is the kind of thing that particular partition is there for to begin with.

Recovery may never be fast, but even with some bloat it's not so slow any more either.

What's really good is having better confidence than ever that Windows will immediately boot the first time after full recovery, with no further ado, delays, or grub-installs. And no further Windows "installs" either. Yikes, let's be honest. The Windows installation process writes an appropriate EFI folder when there's nothing on your SSD at all. It may or may not be your friend at other times. Especially if you dual boot, the UEFI default-generically-named \EFI\boot\bootx64.efi file is actually OS-specific so whatever OS you install the most recently is the one that puts its own version of this file into the \EFI\boot folder, overwriting whatever the previous one was.

Once you've got a reliable EFI whether you are multibooting or not, it's nice not to need any more attention over the long run. The \EFI\ folder is made to be shared by \EFI\Microsoft, \EFI\fedora, \EFI\debian, etc.

Those OS's that have enough of their bootloader files physically located on the EFI volume can have those files updated independently from any respective OS or OS updates.

This can increase the chances that it will go well, and definitely make it easier to recover in case there is a breaking change like the author had.

Edit: Also forgot to add, without much trouble you can back up the full EFI folder from either Linux or Windows, but not very helpful if parts of Grub are also on EXTx. The distros having Grub on EXTx are also scattered in more than one folder. Which is one reason I don't think many people have gotten in the habit of backing them up.

Correct, no value meant defaulting to 0.

> One of the settings that was set to zero was the timeout to connect to the remote SMTP server. Some experimentation established that on this particular machine with its typical load, a zero timeout would abort a connect call in slightly over three milliseconds.