no grub2 update?

[Faris Raouf]

This is relating to PVE 6.2

I update my nodes relatively frequently and obviously keep an ear open for important updates that might mean an update needs to be done sooner rather than later.

Today I had expected to need to install a grub2 update along with the associated bits and bobs, but although there were several Debian packages needing an update, grub2 wasn't one of them when I checked via the GUI (node > Updates) just now.

The only reason I can think of is because there is some pve-specific package that needs to be updated and released first, to be installed alongside the updated grub2, and therefore preventing grub2 from being updated immediately.

Is that the case, or has something gone horribly wrong for me somehow?

Starting system upgrade: apt-get dist-upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following package was automatically installed and is no longer required:
  pve-kernel-5.4.41-1-pve
Use 'apt autoremove' to remove it.
The following packages will be upgraded:
  base-files dbus libdbus-1-3 libgnutls-openssl27 libgnutls30 libgnutlsxx28 libperl5.28
  libpython3.7 libpython3.7-minimal libpython3.7-stdlib libunwind8 linux-libc-dev
  nfs-common nmap nmap-common perl perl-base perl-modules-5.28 postfix postfix-sqlite
  proxmox-backup-client python3.7 python3.7-minimal
23 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 28.1 MB of archives.
After this operation, 130 kB of additional disk space will be used.
Do you want to continue? [Y/n]

 

[H4R0]

If your node uses zfs on rpool it will use systemd not grub.

Debian stable repo had the upgrade available since thursday and pushed a second upgrade yesterday. grub2-common 2.02+dfsg1-20+deb10u2

Not sure if the grub2 package is bundled with pve or comes directly from debian repo, if its the former it will take some time for proxmox team to test it. In that case enterprise repo will be the last one to receive the upgrade.

Anyway the exploit requires someone to aquire root, so its not really a problem.

 

[Faris Raouf]

Thanks @H4R0 - no ZFS here - local storage only with ext4 (and on Enterprise repo). And no UEFI either.

I'm not actually looking forward to installing this, as I'm always worried when something significantly changes in terms of boot code.

 

[Faris Raouf]

I woke up this morning to read reports of updated grub2/shim causing severe problems for Centos (certainly 8, possibly 7) and some Ubuntu versions. I'm guessing the updated Debian version @H4R0 mentioned may indicate there is/was an issue with Debian too.

This is exactly what I was afraid of.

Having tested installing the Grub2 update on a "disposable" Centos 7 VM and had no issues on reboot, I happened to have gone ahead and updated all my Centos 7 VMs overnight. Luckily not a single problem. But if I'd read the reports first, I wouldn't have done it.

And of course now I'm going to be terrified of updating my PVE nodes whenever the updated grub2 makes an appearance.

 

[H4R0]

Where did you read that reports ?

I upgraded all my systems already and had no issues, but im only using debian and freebsd.

Im also only using zfs with autosnapshots enabled, this way i can rollback any change to the fileysystem. So no worries to break anything.

 

[Faris Raouf]

Here: https://arstechnica.com/gadgets/202...ystems-arent-booting-due-to-boothole-patches/
See also https://bugzilla.redhat.com/show_bug.cgi?id=1861977

zfs with autosnapshots within the VM, I take it? It sounds very interesting, but beyond my technological capability at present. I'm still on ext4 (not even xfs) and only recently started using LVM (and wondering why I bothered because it prevents easy attachment of a backup to a running VM due to the UUID/Name conflict, which I find infuriating!!!)

[EDIT: It seems the issue only affects systems where UEFI is used, as far as I can tell]

 

[H4R0]

Oh wow thats unfortunate. Yeah the second upgrade on debian fixed that bug with efi.

ZFS on the host, if every vm would run zfs there would be quite some overhead. The vm will use a simple filesystem like ext4 for linux. As every vm has its own vdev you can rollback them as well on the host tho.

ZFS takes some time to learn its not a simple filesystem. But if you know what you are doing its really powerfull, e.g. lz4 compression, deduplication, encryption, raidz (better raid5/6), snapshots, data integrity using checksums and automatic scrub, cache options (slog/l2arc) etc.

 

[fabian]

PVE does not support secure boot/signed kernels yet, so we don't need to urgently fix bugs related to that functionality. The patches in our Grub packages are mainly for improved ZFS support, although we switched to using systemd-boot without Grub for the default UEFI install quite a while ago and only keep that around for legacy/upgraded systems.