Terrific, I think. These are the upgrades I’ve been waiting for since January! All the NVidia stuff, all the “sutton” stuff (which is code for nvidia OEM packages).
I click install now:
I don’t understand what the message is trying to tell me. Isn’t 2.12 >= 2.02? What is the issue here?
Well, there is a little more information here about GRUB:
After looking at the bug that this update was designed to fix, which Software Updater pointed me at, I decided I did not need it since it effects Secure Boot installations and I’ve disabled Secure Boot.
I installed the rest of the updates, the stuff I really wanted, and it works fine. I don’t see any great improvements yet, but no problems either.
Still, I would like to understand the original error message.
If you read the bug description completely you will find that secure boot fixes ( which had piled up for some time) were only a minor portion of the fix, the actual issue the bug fixed was a kernel crash due to repeatedly loading of kernel modules which can be either exploited or cause a kernel hang due to an integer overflow of a reference counter…
Yes, I did read that. And perhaps this bug is the source of the multiple problems my system has been suffering since January, for which I have been developing workarounds like hibernate instead of suspend. But I determined that installing all the updates but this one was unlikely to make things any worse, and that appears to have been the case.
So maybe I need to chime in on that bug and ask what needs to be done to get this important update to install.
Nah, I only meant to point out that it isn’t that easy, you can’t just say “oh, there is only sec-boot stuff in it and I don’t use sec-boot”, I doubt the bug has any functional impact on your system, but you leave an attack point open when not updating grub (you got to load and unload a module quite often to actually trigger an overflow to exploit it, so the vulnerability is rather theoretical, but that update has simply more than some secure boot fixes in it)
Well, it still seems like a bug of some sort that advertised updates are uninstallable. If the update is phased, shouldn’t the notification be held back until the package is installable?
Well, that’s apt … you could file a wishlist bug against it for sure, but the feature works as advertised, apt shows that the package is phased in your output and phasing does cause held packages for dependencies, I think the actual bug here is that the GUI does not talk about phasing at all, that would have made it clearer (apt does inform you about phasing on the commandline when it finds such a situation)
$ sudo apt install grub-efi-amd64-signed
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following package was automatically installed and is no longer required:
nvidia-firmware-535-535.183.01
Use 'sudo apt autoremove' to remove it.
The following additional packages will be installed:
grub-efi-amd64 grub-efi-amd64-bin
The following packages will be upgraded:
grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed
3 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
Need to get 3,084 kB of archives.
After this operation, 51.2 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://us.archive.ubuntu.com/ubuntu noble-updates/main amd64 grub-efi-amd64 amd64 2.12-1ubuntu7.3 [52.8 kB]
Get:2 http://us.archive.ubuntu.com/ubuntu noble-updates/main amd64 grub-efi-amd64-signed amd64 1.202.5+2.12-1ubuntu7.3 [1,393 kB]
Get:3 http://us.archive.ubuntu.com/ubuntu noble-updates/main amd64 grub-efi-amd64-bin amd64 2.12-1ubuntu7.3 [1,638 kB]
Fetched 3,084 kB in 1s (2,959 kB/s)
Preconfiguring packages ...
(Reading database ... 318761 files and directories currently installed.)
Preparing to unpack .../grub-efi-amd64_2.12-1ubuntu7.3_amd64.deb ...
Unpacking grub-efi-amd64 (2.12-1ubuntu7.3) over (2.12-1ubuntu7.1) ...
Preparing to unpack .../grub-efi-amd64-signed_1.202.5+2.12-1ubuntu7.3_amd64.deb
...
Unpacking grub-efi-amd64-signed (1.202.5+2.12-1ubuntu7.3) over (1.202.2+2.12-1ub
untu7.1) ...
Preparing to unpack .../grub-efi-amd64-bin_2.12-1ubuntu7.3_amd64.deb ...
Unpacking grub-efi-amd64-bin (2.12-1ubuntu7.3) over (2.12-1ubuntu7.1) ...
Setting up grub-efi-amd64-bin (2.12-1ubuntu7.3) ...
Setting up grub-efi-amd64 (2.12-1ubuntu7.3) ...
Installing grub to /boot/efi.
Installing for x86_64-efi platform.
Installation finished. No error reported.
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/oem-flavour.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-59-generic
Found initrd image: /boot/initrd.img-6.8.0-59-generic
Found linux image: /boot/vmlinuz-6.8.0-58-generic
Found initrd image: /boot/initrd.img-6.8.0-58-generic
Found linux image: /boot/vmlinuz-6.8.0-57-generic
Found initrd image: /boot/initrd.img-6.8.0-57-generic
Found memtest86+ 64bit EFI image: /boot/memtest86+x64.efi
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
Generating 'Restore Ubuntu 22.04 to factory state' entry ...
done
Setting up grub-efi-amd64-signed (1.202.5+2.12-1ubuntu7.3) ...
Installing grub to /boot/efi.
Installing for x86_64-efi platform.
Installation finished. No error reported.
Processing triggers for shim-signed (1.58+15.8-0ubuntu1) ...
Secure Boot not enabled on this system.
This looks to me like the command-line apt did install the package.
shoot! I’ve been living on the bleeding edge since I bought this Lenovo laptop with a nvidia GPU four months ago. Nothing has worked the way it should. Everything has been a struggle. Yet, here I am.
If Software Updates is going to use phasing, it shouldn’t advertise upgrades that haven’t been phased. That seems like a bug to me.
And if apt install is going to ignore phasing, it should provide a warning message and chance to abort.
That’s my two cents.
But thanks for the explanation!
Well, phasing doesn’t necessarily mean beta testing, the packages have been tested in the proposed repo for a while before they go to the archive and into phasing, phasing is more a “hold the line in an easier manner if unexpected problems show up”, i.e. less people have to roll back in case something unexpected happens…
What you do by running apt install is just simply skipping the line, you’d get that same update anyway, just a day or half a day later would you wait…
Between a day and a few (usually under a week) … and indeed it depends when/how often you check, if you do it once a week chances are good you hit phasing rarely or even never …
