Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Unattended upgrade of grub failed
106 views
Skip to first unread message
Jesper Dybdal
Oct 8, 2023, 5:20:06 AM10/8/23
to
I run Bullseye on an UEFI boot machine. The system originally ran
on BIOS boot hardware, but this summer I moved it to an UEFI machine
by installing the EFI version of grub.
This has worked fine since then, with unattended-upgrades succeeding in keeping it up-to-date, including kernel upgrades and reboots.
But this morning, unattended-upgrades failed:
It seems to have a problem with "grub-pc". But I thought that grub-pc was only for BIOS boot, and that by installing the UEFI version grub-pc would disappear or at least be disabled.
Do I need to do an uninstall of grub-pc? and will that not be dangerous for the EFI version?
I am now somewhat worried - can my system boot at all? And I expect that the point release will be installed tonight - will that mess things up further? Can I simply disable unattended-upgrades with systemctl in order to temporarily stop unattended upgrades?
This machine is also my router/firewall/server, so if it fails, everything becomes difficult.
Thanks for any help you can offer,
Jesper
The entire mail from unattended-upgrades:
This has worked fine since then, with unattended-upgrades succeeding in keeping it up-to-date, including kernel upgrades and reboots.
But this morning, unattended-upgrades failed:
(The entire mail from unattended-upgrades is quoted below.)Packages that attempted to upgrade: grub-common grub-efi-amd64-bin grub-efi-amd64-signed grub-pc grub-pc-bin grub2 grub2-common Packages with upgradable origin but kept back: Debian oldstable-security: grub2-common grub-common grub-pc-bin grub-efi-amd64-signed grub2 grub-pc grub-efi-amd64-bin
It seems to have a problem with "grub-pc". But I thought that grub-pc was only for BIOS boot, and that by installing the UEFI version grub-pc would disappear or at least be disabled.
Do I need to do an uninstall of grub-pc? and will that not be dangerous for the EFI version?
I am now somewhat worried - can my system boot at all? And I expect that the point release will be installed tonight - will that mess things up further? Can I simply disable unattended-upgrades with systemctl in order to temporarily stop unattended upgrades?
This machine is also my router/firewall/server, so if it fails, everything becomes difficult.
Thanks for any help you can offer,
Jesper
The entire mail from unattended-upgrades:
Unattended upgrade result: All upgrades installed Packages that attempted to upgrade: grub-common grub-efi-amd64-bin grub-efi-amd64-signed grub-pc grub-pc-bin grub2 grub2-common Packages with upgradable origin but kept back: Debian oldstable-security: grub2-common grub-common grub-pc-bin grub-efi-amd64-signed grub2 grub-pc grub-efi-amd64-bin Package installation log: Log started: 2023-10-08 06:47:58 apt-listchanges: Reading changelogs... Preconfiguring packages ... apt-listchanges: Reading changelogs... Preconfiguring packages ... Preparing to unpack .../0-grub2_2.06-3~deb11u6_amd64.deb ... Unpacking grub2 (2.06-3~deb11u6) over (2.06-3~deb11u5) ... Preparing to unpack .../1-grub2-common_2.06-3~deb11u6_amd64.deb ... Unpacking grub2-common (2.06-3~deb11u6) over (2.06-3~deb11u5) ... Preparing to unpack .../2-grub-pc_2.06-3~deb11u6_amd64.deb ... Unpacking grub-pc (2.06-3~deb11u6) over (2.06-3~deb11u5) ... Preparing to unpack .../3-grub-pc-bin_2.06-3~deb11u6_amd64.deb ... Unpacking grub-pc-bin (2.06-3~deb11u6) over (2.06-3~deb11u5) ... Preparing to unpack .../4-grub-efi-amd64-bin_2.06-3~deb11u6_amd64.deb ... Unpacking grub-efi-amd64-bin (2.06-3~deb11u6) over (2.06-3~deb11u5) ... Preparing to unpack .../5-grub-common_2.06-3~deb11u6_amd64.deb ... Unpacking grub-common (2.06-3~deb11u6) over (2.06-3~deb11u5) ... Setting up grub-common (2.06-3~deb11u6) ... Setting up grub-efi-amd64-bin (2.06-3~deb11u6) ... Setting up grub2-common (2.06-3~deb11u6) ... Setting up grub-pc-bin (2.06-3~deb11u6) ... Setting up grub-pc (2.06-3~deb11u6) ... /dev/disk/by-id/ata-ST2000DM001-1ER164_W4Z216NL does not exist, so cannot grub-install to it! You must correct your GRUB install devices before proceeding: DEBIAN_FRONTEND=dialog dpkg --configure grub-pc dpkg --configure -a dpkg: error processing package grub-pc (--configure): installed grub-pc package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent configuration of grub2: grub2 depends on grub-pc (= 2.06-3~deb11u6); however: Package grub-pc is not configured yet. dpkg: error processing package grub2 (--configure): dependency problems - leaving unconfigured Processing triggers for man-db (2.9.4-2) ... Processing triggers for install-info (6.7.0.dfsg.2-6) ... Errors were encountered while processing: grub-pc grub2 needrestart is being skipped since dpkg has failed Running kernel seems to be up-to-date. The processor microcode seems to be up-to-date. Restarting services... systemctl restart amavisd-milter.service Service restarts being deferred: /etc/needrestart/restart.d/dbus.service systemctl restart ge...@tty1.service systemctl restart systemd-logind.service systemctl restart unattended-upgrades.service No containers need to be restarted. No user sessions are running outdated binaries. E:Sub-process /usr/bin/dpkg returned an error code (1) Log ended: 2023-10-08 06:48:20 Unattended-upgrades log: Starting unattended upgrades script Allowed origins are: origin=Debian,codename=bullseye,label=Debian, origin=Debian,codename=bullseye,label=Debian-Security, origin=Debian,codename=bullseye-security,label=Debian-Security Initial blacklist: Initial whitelist (not strict): Packages that will be upgraded: grub-common grub-efi-amd64-bin grub-efi-amd64-signed grub-pc grub-pc-bin grub2 grub2-common Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log Installing the upgrades failed! error message: installArchives() failed dpkg returned a error! See /var/log/unattended-upgrades/unattended-upgrades-dpkg.log for details Package grub-common is kept back because a related package is kept back or due to local apt_preferences(5). Package grub-efi-amd64-bin is kept back because a related package is kept back or due to local apt_preferences(5). Package grub-efi-amd64-signed is kept back because a related package is kept back or due to local apt_preferences(5). Package grub-pc is kept back because a related package is kept back or due to local apt_preferences(5). Package grub-pc-bin is kept back because a related package is kept back or due to local apt_preferences(5). Package grub2 is kept back because a related package is kept back or due to local apt_preferences(5). Package grub2-common is kept back because a related package is kept back or due to local apt_preferences(5).
-- Jesper Dybdal https://www.dybdal.dk
Marco M.
Oct 8, 2023, 5:30:05 AM10/8/23
to
Am 08.10.2023 um 11:09:53 Uhr schrieb Jesper Dybdal:
> It seems to have a problem with "grub-pc". But I thought that
> grub-pc was only for BIOS boot, and that by installing the UEFI
> version grub-pc would disappear or at least be disabled.
Uninstall grub-pc if you are on an UEFI system.
> It seems to have a problem with "grub-pc". But I thought that
> grub-pc was only for BIOS boot, and that by installing the UEFI
> version grub-pc would disappear or at least be disabled.
You can still have the .deb in /var/cache/apt, so you can reinstall it
in a chroot environment of you fear.
Marco M.
Oct 8, 2023, 5:40:05 AM10/8/23
to
Am 08.10.2023 um 11:30:13 Uhr schrieb DdB:
> On issuing the update interactively, i could see, that grub was
> prompting for the place to write itself to, which needed interaction.
> After giving the info (like /dev/sda in my case), the upgrade
> succeded. Later, there came more updates, but this time, they could
> indeed install themselves automatically.
Specifying a block device for boot loader installation is only needed
for BIOS boot and not for UEFI boot, so in case of an UEFI system,
grub-pc isn't needed.
> On issuing the update interactively, i could see, that grub was
> prompting for the place to write itself to, which needed interaction.
> After giving the info (like /dev/sda in my case), the upgrade
> succeded. Later, there came more updates, but this time, they could
> indeed install themselves automatically.
Specifying a block device for boot loader installation is only needed
for BIOS boot and not for UEFI boot, so in case of an UEFI system,
grub-pc isn't needed.
Jesper Dybdal
Oct 8, 2023, 6:10:06 AM10/8/23
to
installation is still intact and working?
Would it make sense to do a grub-install after removing grub-pc, just to
ensure that it will work?
And many thanks to you and DdB for your responses.
Jesper Dybdal
Oct 8, 2023, 7:40:06 AM10/8/23
to
On 2023-10-08 12:07, Jesper Dybdal wrote:
> On 2023-10-08 11:25, Marco M. wrote:
>> Am 08.10.2023 um 11:09:53 Uhr schrieb Jesper Dybdal:
>>
>>> It seems to have a problem with "grub-pc". But I thought that
>>> grub-pc was only for BIOS boot, and that by installing the UEFI
>>> version grub-pc would disappear or at least be disabled.
>> Uninstall grub-pc if you are on an UEFI system.
>> You can still have the .deb in /var/cache/apt, so you can reinstall it
>> in a chroot environment of you fear.
>>
>
> Can I simply do an apt-get remove grub-pc and expect that the grub-efi
> installation is still intact and working?
>
> Would it make sense to do a grub-install after removing grub-pc, just
> to ensure that it will work?
I tried to simulate it with a "apt-get -s remove grub-pc". It then said:
> On 2023-10-08 11:25, Marco M. wrote:
>> Am 08.10.2023 um 11:09:53 Uhr schrieb Jesper Dybdal:
>>
>>> It seems to have a problem with "grub-pc". But I thought that
>>> grub-pc was only for BIOS boot, and that by installing the UEFI
>>> version grub-pc would disappear or at least be disabled.
>> Uninstall grub-pc if you are on an UEFI system.
>> You can still have the .deb in /var/cache/apt, so you can reinstall it
>> in a chroot environment of you fear.
>>
>
> Can I simply do an apt-get remove grub-pc and expect that the grub-efi
> installation is still intact and working?
>
> Would it make sense to do a grub-install after removing grub-pc, just
> to ensure that it will work?
The following packages will be REMOVED:
grub-pc grub2
Is removing grub2 not a problem? If I do an "aptitude why grub2", it says:
Manually installed, current version 2.06-3~deb11u6, priority optional
No dependencies require to install grub2
Marco M.
Oct 8, 2023, 8:30:06 AM10/8/23
to
Am 08.10.2023 um 13:37:45 Uhr schrieb Jesper Dybdal:
> I tried to simulate it with a "apt-get -s remove grub-pc". It then
> said:
>
> The following packages will be REMOVED:
> grub-pc grub2
>
> Is removing grub2 not a problem? If I do an "aptitude why grub2", it
> says:
That is my EFI system, no package "grub2" installed.
> I tried to simulate it with a "apt-get -s remove grub-pc". It then
> said:
>
> The following packages will be REMOVED:
> grub-pc grub2
>
> Is removing grub2 not a problem? If I do an "aptitude why grub2", it
> says:
m@ryz:~$ dpkg -l |grep grub
ii grub-common
2.12~rc1-11 amd64 GRand Unified
Bootloader (common files) ii grub-efi-amd64
2.12~rc1-11 amd64
GRand Unified Bootloader, version 2 (EFI-AMD64 version) ii
grub-efi-amd64-bin 2.12~rc1-11
amd64 GRand Unified Bootloader, version
2 (EFI-AMD64 modules) ii grub-efi-amd64-signed
1+2.12~rc1+11 amd64 GRand
Unified Bootloader, version 2 (amd64 UEFI signed by Debian) ii
grub2-common 2.12~rc1-11
amd64 GRand Unified Bootloader (common
files for version 2) m@ryz:~$
The package description is also clear:
|Description: GRand Unified Bootloader, version 2 (dummy package)
|This is a dummy transitional package to handle GRUB 2 upgrades. It
|can be safely removed.
So you can remove it.
Marco M.
Oct 8, 2023, 8:40:06 AM10/8/23
to
Am 08.10.2023 um 12:46:06 Uhr schrieb DdB:
> My understanding is, that it might be dangerous to uninstall grub-pc
> and its dependencies without further precautions.
If a system was installed in UEFI mode, no grub-pc is installed.
If a system is being migrated from BIOS boot to UEFI boot, care must be
taken.
> My understanding is, that it might be dangerous to uninstall grub-pc
> and its dependencies without further precautions.
If a system was installed in UEFI mode, no grub-pc is installed.
If a system is being migrated from BIOS boot to UEFI boot, care must be
taken.
Jesper Dybdal
Oct 8, 2023, 11:20:05 AM10/8/23
to
On 2023-10-08 11:25, Marco M. wrote:
release (11.8) before rebooting.
After the reboot, which went well, I noticed that the new kernel version
was "held back". An explicit install of the new kernel seemed to
succeed, and everything seems to work ok now.
Thank you!!
Jeffrey Walton
Oct 8, 2023, 1:20:05 PM10/8/23
to
ensure they are not auto-removed. For example, you need to perform
`apt-mark manual cryptsetup-initramfs` to ensure initramfs can mount
an encrypted root. See <https://wiki.debian.org/DebianUpgrade>.
I'm not saying that's happening here. I'm only saying that it happens
on occasion.
Jeff
Greg Wooledge
Oct 8, 2023, 8:40:06 PM10/8/23
to
On Sun, Oct 08, 2023 at 05:14:52PM +0200, Jesper Dybdal wrote:
> After the reboot, which went well, I noticed that the new kernel version was
> "held back". An explicit install of the new kernel seemed to succeed, and
> everything seems to work ok now.
Note the differences among "apt upgrade", "apt-get upgrade",
> After the reboot, which went well, I noticed that the new kernel version was
> "held back". An explicit install of the new kernel seemed to succeed, and
> everything seems to work ok now.
"apt-get upgrade --with-new-pkgs" and "apt-get dist-upgrade.
"apt-get upgrade" will not install new packages.
"apt upgrade" will.
"apt-get upgrade --with-new-pkgs" also will.
"apt-get dist-upgrade" will install new packages, and potentially
remove packages, if the situation requires it. For a simple point
release, it should be vanishingly rare that a package would be
removed, so this is hardly ever needed. But "dist-" is a lot easier to
type and to remember than "--with-new-pkgs", so people tend to use it
as a synonym.
0 new messages