DietPi Update to v8.22.3 fails on Native PC (x86_64)

Troubleshooting
1

I’m unable to upgrade DietPi to v8.22.3 on a Native PC (a HP 600 G2 Mini PC with an i5 6600T, 8 GB, and a 256 GB SSD) image.
Prior updates went fine with no errors or issues. The original dietpi image was installed in May 2023.

Where might I start looking at logs and troubleshooting?

Thank you.

Creating a bug report/issue

Required Information

  • Date | Tue Oct 10 16:52:15 EDT 2023
  • DietPi version | v8.21.1 (MichaIng/master)
  • Image creator |
  • Pre-image |
  • Hardware | Native PC (x86_64) (ID=21)
  • Kernel version | Linux DietPi 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29) x86_64 GNU/Linux
  • Distro | bullseye (ID=6)
  • Command | apt-get -y --with-new-pkgs upgrade
  • Exit code | 100
  • Software title | DietPi-Update

Additional logs:

Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following package was automatically installed and is no longer required:
  linux-image-5.10.0-25-amd64
Use 'sudo apt autoremove' to remove it.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up grub-pc (2.06-3~deb11u6) ...
Installing for i386-pc platform.
grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
grub-install: error: embedding is not possible, but this is required for cross-disk install.
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
Errors were encountered while processing:
 grub-pc
E: Sub-process /usr/bin/dpkg returned an error code (1)


#### Additional Information (if applicable)
- Software title | dietpi_update
- Was the software title installed freshly or updated/migrated? Updated


#### Steps to reproduce
Tried to update several times from v8.21.1 to v8.22.3 over past two days. 
Same error message in console each time. Rebooted each time before trying dietpi_update again.


#### Extra details
Initial DietPi image installed in May 2023 on HP 600 G2 mini PC. All prior dietpi updates were successful with no issues or console errors during updates. 
System appears to operate fine after unsuccessful update and reboot. Primary use is for Nextcloud.
- ...
2

UPDATE:
Searching more on the error messages (i.e., grub-pc, grub-install, etc.), I found a solution - - and maybe the cause – in this closed issue from December 2022:

Update to 8.12.1 fails on UEFI x86_64 #5998

I used
dpkg --configure grub-pc
to start the grub-pc configuration process to tell it which drive is the root drive.
My HP Mini PC has a SATA SSD, which is labeled /dev/nvme0n1p1. I also have an external USB HD for all data.
I didn’t actually change any of the settings during the prompts and then closed out of the config.

The dietpi-update to v8.22.3 then worked correctly and a reboot was successful.

Welcome any comments/corrections and will close this in a few days.

Cheers.

1 Like
3

Right, in the meantime we set this automatically on first boot of DietPi, but for images installed prior to this, it needs to be done manually once: https://github.com/MichaIng/DietPi/blob/fb0db339f63275d8924b80db7bca2d8d0410e6a0/rootfs/var/lib/dietpi/services/dietpi-firstboot.bash#L330-L335

It is actually strange that the issue was named “UEFI” and that the error message says “GPT partition label”, since this issue explicitly only applies for the BIOS/CSM images with MBR partition table. The grub-pc package is the best indicator, as for UEFI, there is another grub-efi-amd64 package, which does not “flash” GRUB somewhere (which is why it needs to know where) but installs the EFI binary to the EFI partition mounted to /boot/efi.

EDIT: Ah, your external USB HDD will be /dev/sda and was formatted with GPT partition table, then the error message makes sense. We use /dev/sda as default GRUB target drive entry when generating the images, as best guess until it is (now) corrected on first boot.