[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: grub update and reinstallation



hmh@debian.org - Henrique de Moraes Holschuh posted this on LWN.net earlier. It's about as clear as it gets so I'm cheating and copying this direct into debian-cd so that others see it: thanks for the clarity, Henrique

>>

For Debian, most of the issues reported with the security update were linked to bad configuration at package update time, and an extremely annoying shortcoming of the package: it cannot rollback when it fails to install to the boot media, and it doesn't crash and burn the update run either, so it will not be noticed if you are not reading the update run output.

Run dpkg-reconfigure on your grub2 variant, so that it asks for your boot devices. Ensure it is correct, and let it update the bootloader on disk. Watch to ensure no errors are reported (i.e. do it from the terminal, not some GUI). This will sync everything.

Examples:
dpkg-reconfigure grub-efi-amd64
dpkg-reconfigure grub-pc

The other issue was a chain loader breackage on EFI, already fixed in the current packages.

<<

[The second issue affected chainloading EFI  for, say, a Debian / Windows 10 dual boot]

The fixed packages are all there now

ZFS on Debian - strictly, it's off-topic here since it's not supported in Debian at the moment.

On Mon, Aug 3, 2020 at 4:18 PM D. R. Evans <doc.evans@gmail.com> wrote:
Tom Dial wrote on 8/1/20 9:31 PM:

>
> My experience, now on eight machines, indicates that it should be if the
> installed, configured, and used versions of grub components is
>
> 2.02+dfsg1-20+deb10u2.
>
> I could be wrong, but here it has been the case for both UEFI (and root
> on ZFS) and legacy boot setups, on both i386 and amd64. The only
> exception is one root-on-ZFS VM that was slightly broken beforehand and
> declines to boot for reasons I am fairly sure are unrelated to grub
> installation.
>

So if one has two bootable drives (call them A and B), will this update update
the MBR on both A and B, not just the one that happened to have been used for
the most recent boot?

I ask because I have a couple of root-on-ZFS BIOS-boot machines that are both
configured as two-disk mirrors and I want to be sure that, following this
upgrade, I can still boot off either of the two disks (as I can at the moment)
without having to perform any manual changes.

The use case is, if it's not obvious, that if under normal circumstances disk
A is used for booting, but then at some point A fails (so ZFS is running in a
degraded state) I can still boot from drive B if necessary.

  Doc

--
Web:  http://enginehousebooks.com/drevans


Reply to: