Grub2 updates for Red Hat systems are making some unbootable
Posted Jul 30, 2020 16:55 UTC (Thu)
by cesarb (subscriber, #6266)
[Link] (2 responses)
Posted Jul 30, 2020 21:54 UTC (Thu)
by hmh (subscriber, #3838)
[Link] (1 responses)
Debian had a regression related to dual-booting Microsoft Windows. It has already been fixed, the regression-fixing packages are ready, and the Debian security team tells me the regression-fixing update is already going through the EFI-signature-and-final-upload pipeline (no idea how long that takes, though).
Hopefully all distros will converge on the regression-fixes very fast...
I am not rebooting my EFI systems for a few days if I can help it, though :-P
Posted Jul 31, 2020 1:53 UTC (Fri)
by geuder (subscriber, #62854)
[Link]
Posted Jul 30, 2020 17:28 UTC (Thu)
by Smon (guest, #104795)
[Link] (17 responses)
Posted Jul 30, 2020 17:34 UTC (Thu)
by zlynx (guest, #2285)
[Link] (16 responses)
Posted Jul 30, 2020 20:02 UTC (Thu)
by leromarinvit (subscriber, #56850)
[Link] (6 responses)
Posted Jul 30, 2020 21:43 UTC (Thu)
by hmh (subscriber, #3838)
[Link] (5 responses)
I have no idea where that /dev/sda in the wiki came from. It is never right for an EFI install, hopefully grub-install will ignore it, because if it doesn't, well, the result won't be pretty.
Heck, you don't tell anyone to grub-install /dev/sda *even* for grub-pc (the "PC BIOS" edition), you say something like /dev/<boot device>...
Posted Jul 30, 2020 21:46 UTC (Thu)
by hmh (subscriber, #3838)
[Link]
Posted Jul 30, 2020 22:56 UTC (Thu)
by leromarinvit (subscriber, #56850)
[Link] (3 responses)
Good to know, thanks.
> I have no idea where that /dev/sda in the wiki came from. It is never right for an EFI install, hopefully grub-install will ignore it, because if it doesn't, well, the result won't be pretty.
What would it do? Treat the GPT partition table as MBR and corrupt it? While definitely not pretty, that should be recoverable as GPT has a backup table hopefully not located in the first few sectors.
> Heck, you don't tell anyone to grub-install /dev/sda *even* for grub-pc (the "PC BIOS" edition), you say something like /dev/<boot device>...
That's definitely a useful clarification. While it's probably obvious to the average LWN reader that a bootloader needs to be installed on whatever drive the system wants to boot from, people blindly following instructions might run into trouble here.
Posted Jul 31, 2020 20:58 UTC (Fri)
by kreijack (guest, #43513)
[Link] (2 responses)
> What would it do? Treat the GPT partition table as MBR and corrupt it? While definitely not pretty, that should be recoverable as GPT has a backup table hopefully not located in the first few sectors.
Apart the fact that boot device could not be /dev/sda, the GPT table would be not affected. In fact both GPT and MBR partition can co-exist together (and say the same thing or different thing ! more often the latter).
I think that the real risk is that some bios doesn't start in UEFI mode if a MBR partition table is available. My BIOS (which is quite old) didn't show any UEFI related option until I removed all MBR partition table.
Posted Jul 31, 2020 21:23 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (1 responses)
Theoretically, GPT-partitioned disks have a fake MBR with one huge untouchable “partition” that covers all the space within the GPT partitions. (This only gets you so far if your disk is bigger than MBR will support.)
Posted Aug 2, 2020 6:05 UTC (Sun)
by kreijack (guest, #43513)
[Link]
Correct.
To complete the answer, I have to point out that below of the "MBR" label there are two kind if information:
Both are stored in the first sector. Grub-install change only the latter. So in any case grub-installer can't change nor damage the GPT table. However installing a MBR boot loader, could start the bios in legacy mode (and not uefi one).
Posted Jul 30, 2020 21:28 UTC (Thu)
by cjwatson (subscriber, #7322)
[Link] (3 responses)
Posted Jul 30, 2020 21:53 UTC (Thu)
by zlynx (guest, #2285)
[Link]
As I remember things it did not always do that check for UEFI. Or perhaps it was someone booting an OS that didn't understand UEFI and it did it.
That kind of thing is what leads people to get upset with Windows because it will repeatedly repair the corrupted boot records. Which is not Windows' fault when it is the Linux users doing it wrong.
Posted Jul 31, 2020 8:55 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (1 responses)
When I tried to install SUSE on this laptop, it quite happily installed - UEFI - pointing to the UEFI partition it created on sdb. Of course, the laptop boots Windows off sda, so SUSE-install (presumably grub) put it in the wrong place and the laptop doesn't even realise SUSE is there :-(
Cheers,
Posted Aug 1, 2020 5:36 UTC (Sat)
by gfernandes (subscriber, #119910)
[Link]
I later realised that all OSs should _add_ to the same UEFI partition, that should already be there if you got an off the shelf laptop with WhineDoze preinstalled.
So I now first increase the size of the UEFI partition, and then install Fedora on another disk with /boot/efi pointing to the same UEFI partition. And since then, dual boot works fine and can be driven from the grub menu.
Posted Jul 30, 2020 23:19 UTC (Thu)
by dmoulding (subscriber, #95171)
[Link] (3 responses)
There should be nothing wrong with doing "grub-install /dev/sda", assuming /dev/sda is the disk that contains the ESP. And, in fact, if you're running grub-install from a rescue system (which is UEFI) against another UEFI system's disk (such that the system currently has *two* disks attached to it, each one containing an ESP), then specifying the disk should be *mandatory* because otherwise grub-install has to choose which of the two it should install to, and it's almost certainly not going to guess that correctly every time. I would think the same would apply if you've got a rescue USB stick plugged into the system, which also contains an ESP.
Posted Jul 31, 2020 2:20 UTC (Fri)
by nivedita76 (subscriber, #121790)
[Link] (2 responses)
Posted Jul 31, 2020 3:16 UTC (Fri)
by dmoulding (subscriber, #95171)
[Link] (1 responses)
I suppose it's still got to know which file system has the contents of /boot so that it knows where to put its modules, and the other things it wants to put in /boot/grub. That's a little harder since there isn't a designated type UUID for the partition containing /boot (and it could be on an LVM volume or something else that's not a GPT partition). So you might have to in some cases give it the --boot-directory option, as well (or mount the desired file system at /boot in advance).
Nevertheless, I still don't see how specifying a disk (as long as it's not wrong), could be more harmful than not specifying a disk.
Posted Jul 31, 2020 15:38 UTC (Fri)
by nivedita76 (subscriber, #121790)
[Link]
Posted Jul 31, 2020 12:29 UTC (Fri)
by cortana (subscriber, #24596)
[Link]
Someone should update the GRUB manual then!
Posted Jul 30, 2020 23:38 UTC (Thu)
by cesarb (subscriber, #6266)
[Link]
Excerpt:
"Red Hat is aware of this bug and is working on a fix.
DO NOT apply the affected Errata RHSA-2020:3217 for RHEL 7.
For Red Hat Satellite exclude this Errata from your Content Views"
Posted Jul 31, 2020 6:56 UTC (Fri)
by madhatter (subscriber, #4665)
[Link]
Posted Jul 31, 2020 10:47 UTC (Fri)
by purslow (guest, #8716)
[Link] (6 responses)
Posted Jul 31, 2020 12:38 UTC (Fri)
by anselm (subscriber, #2796)
[Link]
How does LILO cope with things like encrypted disks?
Posted Jul 31, 2020 14:14 UTC (Fri)
by nescafe (subscriber, #45063)
[Link]
Posted Jul 31, 2020 19:13 UTC (Fri)
by ajmacleod (guest, #1729)
[Link]
I wish I'd read this article before updating practically all my grub booting servers (CentOS 7 and Debian 10)! Here's hoping there's a fix that can be applied before any reboots are required...
Posted Aug 1, 2020 18:04 UTC (Sat)
by xnox (guest, #63320)
[Link]
Posted Aug 7, 2020 9:50 UTC (Fri)
by flussence (guest, #85566)
[Link] (1 responses)
Posted Sep 14, 2020 17:04 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Posted Jul 31, 2020 15:52 UTC (Fri)
by jhhaller (guest, #56103)
[Link] (2 responses)
Also check your BIOS vendor, at least HP (not to be confused with HPE) has reported that a BIOS update is required for some of their models before installing the new revocation list.
Posted Jul 31, 2020 21:06 UTC (Fri)
by amacater (subscriber, #790)
[Link]
Posted Aug 1, 2020 15:08 UTC (Sat)
by xnox (guest, #63320)
[Link]
Ubuntu is making 20.04 LTS, 18.04 LTS, 16.04 LTS point releases for that reason. Once they are out dbx update will be pushed out.
Posted Aug 3, 2020 19:16 UTC (Mon)
by cesarb (subscriber, #6266)
[Link]
The only thing I have found so far is https://git.centos.org/rpms/shim-unsigned-x64/c/834e5a0c4... ("[PATCH] hexdump.h: fix arithmetic error") which mentions fixing rhbz#1861977 (https://bugzilla.redhat.com/show_bug.cgi?id=1861977).
Grub2 updates for Red Hat systems are making some unbootable
Grub2 updates for Red Hat systems are making some unbootable
Grub2 updates for Red Hat systems are making some unbootable
Also on Debian based systems
For me, chrooting into the broken system (or doing it while the system is still running), `grub-install /dev/sda` solved it for me.
Also on Debian based systems
Interesting. Both the Debian wiki and the Arch wiki suggest using exactly this command. What does it break, and what should be used instead to (re-)install GRUB on UEFI systems?
Also on Debian based systems
Also on Debian based systems
Also on Debian based systems
Also on Debian based systems
Also on Debian based systems
Also on Debian based systems
In fact both GPT and MBR partition can co-exist together (and say the same thing or different thing ! more often the latter).
Also on Debian based systems
> partitions. (This only gets you so far if your disk is bigger than MBR will support.)
- the partition table
- the boot loader
Also on Debian based systems
Also on Debian based systems
Also on Debian based systems
Wol
Also on Debian based systems
Also on Debian based systems
Also on Debian based systems
Also on Debian based systems
Also on Debian based systems
Also on Debian based systems
23 Invoking grub-install
************************
The program 'grub-install' generates a GRUB core image using
'grub-mkimage' and installs it on your system. You must specify the
device name on which you want to install GRUB, like this:
grub-install INSTALL_DEVICE
The device name INSTALL_DEVICE is an OS device name or a GRUB device
name.
Grub2 updates for Red Hat systems are making some unbootable
DO NOT apply the affected Errata RHSA-2020:3216 for RHEL 8.
Grub2 updates for Red Hat systems are making some unbootable
Grub2 updates for Red Hat systems are making some unbootable
I've never used anything else in 20 years of Linux, including 17 years of Gentoo.
Grub2 updates for Red Hat systems are making some unbootable
Grub2 updates for Red Hat systems are making some unbootable
Grub2 updates for Red Hat systems are making some unbootable
Grub2 updates for Red Hat systems are making some unbootable
Grub2 updates for Red Hat systems are making some unbootable
Grub2 updates for Red Hat systems are making some unbootable
Grub2 updates for Red Hat systems are making some unbootable
Grub2 updates for Red Hat systems are making some unbootable
Grub2 updates for Red Hat systems are making some unbootable
Grub2 updates for Red Hat systems are making some unbootable