Purging grub-pc package deletes /etc/default/grub file owned by grub-efi-amd64

[Daniel Richard G.]

This concerns grub-pc 2.04-1ubuntu26 in Ubuntu focal.

I have the following packages installed. Note that grub-pc has been removed but not yet purged:

root@xubuntu:/# dpkg -l | grep grub
ii grub-common 2.04-1ubuntu26 amd64 GRand Unified Bootloader (common files)
ii grub-efi-amd64 2.04-1ubuntu26 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 version)
ii grub-efi-amd64-bin 2.04-1ubuntu26 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 modules)
ii grub-efi-amd64-signed 1.142+2.04-1ubuntu26 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 version, signed)
rc grub-pc 2.04-1ubuntu26 amd64 GRand Unified Bootloader, version 2 (PC/BIOS version)
ii grub-pc-bin 2.04-1ubuntu26 amd64 GRand Unified Bootloader, version 2 (PC/BIOS modules)
ii grub2-common 2.04-1ubuntu26 amd64 GRand Unified Bootloader (common files for version 2)

The /etc/default/grub file is owned by grub-efi-amd64, which is correct:

root@xubuntu:/# ucfq /etc/default/grub
Configuration file Package Exists Changed
/etc/default/grub grub-efi-amd64 Yes Yes

I then purge the grub-pc package, saying no to the "Remove GRUB 2 files?" debconf question:

root@xubuntu:/# apt-get purge grub-pc
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following package was automatically installed and is no longer required:
  grub-pc-bin
Use 'sudo apt autoremove' to remove it.
The following packages will be REMOVED:
  grub-pc*
0 upgraded, 0 newly installed, 1 to remove and 4 not upgraded.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such device)
(Reading database ... 254919 files and directories currently installed.)
Purging configuration files for grub-pc (2.04-1ubuntu26) ...
ucfr: Association belongs to grub-efi-amd64, not grub-pc
ucfr: Aborting
ucfr: Association belongs to grub-efi-amd64, not grub-pc
ucfr: Aborting

And then...

root@xubuntu:/# ls -l /etc/default/grub
ls: cannot access '/etc/default/grub': No such file or directory

The purging of grub-pc deleted a config file belonging to a different package, which is not only incorrect behavior, it could potentially leave the system unbootable after the next update-grub(8) invocation.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel Richard G. (skunk)]

This issue persists in Ubuntu jammy (grub-pc 2.06-2ubuntu7.2).

[Julian Andres Klode (juliank)]

Yes, that seems the expected behavior given that

    rm -f /etc/default/grub

is literally the first line of the postrm for the purge action.

There doesn't appear to be a way to solve this because we do need to remove the package and grub-pc and grub-efi-amd64 own this.

However this is a low priority issue in any case, as you need to forcefully switch the metapackage on the system which is both unnecessary and hard to do.

[Daniel Richard G. (skunk)]

Note that while switching the metapackage is not a typical operation on a regular installed system---PCs tend to be either BIOS or UEFI without switching from one to the other---it does come up when you are installing a standard OS image that has the "wrong" GRUB type installed and needs to change over to the other one.

Beyond the issue with /etc/default/grub, the ideal solution would be to allow both grub-pc and grub-efi-amd64 to be installed simultaneously. Not only would that eliminate the need to switch metapackages at all, it would allow for installing a dual-mode BIOS+UEFI bootloader setup (e.g. for a Linux system running off a portable USB hard drive). See https://bugs.debian.org/904062

[Julian Andres Klode (juliank)]

The way dual-mode works is by co-installing grub-efi-amd64*-signed* and grub-pc, this has been the default on desktop for ages, but is not yet supported by the new desktop installer.

[Julian Andres Klode (juliank)]

With regards to /etc/default/grub, the consensus in Debian maintainer group seems to be to move it to grub-common. Sadly you cannot have multiple owners for a ucf file and have a sensible transition between packages being purged and new ones installed, but moving the file to common would fix that.

It will also enable co-installing grub-efi-amd64, but to be fair this might not be much of a topic anymore if we decide to remove unsigned grub binaries altogether and only grub-efi-amd64-signed remains.

[Daniel Richard G. (skunk)]

> The way dual-mode works is by co-installing grub-efi-amd64*-signed* and grub-pc

Okay, I see that the -signed package has the grub-install logic in its postinst as well. Thanks for the pointer.

Having /etc/default/grub owned by grub-common seems eminently reasonable, much more so than sharing/passing it between multiple grub-* packages. I hope to see that implemented soon.

Re: grub-pc + grub-efi-amd64, the Conflicts: would still need to be addressed. These are currently written to allow only one GRUB metapackage, instead of taking into account combinations that make sense.

[Mate Kukri (mkukri)]

See https://salsa.debian.org/grub-team/grub/-/merge_requests/62

But ideally we should just move /etc/default/grub to grub-common

[Daniel Richard G. (skunk)]

Looks like a reasonable solution. But why not just move the file instead, if that's the end goal?