[HN Gopher] Backward-incompatible GRUB2 change causing BIOS setu...
___________________________________________________________________
Backward-incompatible GRUB2 change causing BIOS setup bootloop
Author : ge0rg
Score : 47 points
Date : 2024-12-16 17:11 UTC (5 hours ago)
(HTM) web link (op-co.de)
(TXT) w3m dump (op-co.de)
| alexjplant wrote:
| Wasn't the 500 mile email [1] caused by something similar, i.e.
| software loading a config file made for a newer version loading
| it and behaving in an undesirable fashion?
|
| [1] https://www.ibiblio.org/harris/500milemail.html
| OptionOfT wrote:
| 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.
| Netch wrote:
| Nice work! Perseverance to find the root cause in such an
| unfriendly environment as any bootstrap is what saves all us from
| the civilization crash...
| bean-weevil wrote:
| > This was caused by installing Debian, then restoring a full
| backup from the old laptop, which didn't use EFI yet, over the
| root filesystem.
|
| This really isn't guaranteed to work. I'm surprised nothing else
| broke! This is why my laptop migration process looks something
| more like this:
|
| 1. Restore home directory 2. Restore /etc (taking care not to
| overwrite anything hardware-specific) 3. Install the same list of
| packages that were installed on old machine
| bean-weevil wrote:
| 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.
| hyperman1 wrote:
| 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.
| fuzzfactor wrote:
| >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.
| o11c wrote:
| I had a different GRUB2 upgrade breakage a couple years ago. Mine
| related to a hybrid ISO/MBR disk (extremely common for distro
| install disks); previously grub had silently just used the
| obvious partition table, but the new grub insisted on erroring
| out due to ambiguity. I had to do some really hairy "dd to back
| up the MBR; wipefs; dd to restore the MBR" to get a working
| system again; luckily I didn't lose power.
|
| (note that many distros normally don't upgrade grub after the
| first install to avoid exactly this kind of breakage, but there
| was some "important security crap" at the time)
___________________________________________________________________
(page generated 2024-12-16 23:00 UTC)