4

I'm upgrading a Debian server running on DigitalOcean from Bullseye to Bookworm, and cannot figure out how to get past this error that came during apt upgrade --without-new-pkgs

When I tried to continue the failed upgrade, the error keeps appearing:

Setting up initramfs-tools (0.142+deb12u1) ...
update-initramfs: deferring update (trigger activated)
Setting up linux-image-6.1.0-28-amd64 (6.1.119-1) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-6.1.0-28-amd64
E: /usr/share/initramfs-tools/hooks/growroot failed with return 1.
update-initramfs: failed for /boot/initrd.img-6.1.0-28-amd64 with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: error processing package linux-image-6.1.0-28-amd64 (--configure):
 installed linux-image-6.1.0-28-amd64 package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-image-amd64:
 linux-image-amd64 depends on linux-image-6.1.0-28-amd64 (= 6.1.119-1); however:
  Package linux-image-6.1.0-28-amd64 is not configured yet.

dpkg: error processing package linux-image-amd64 (--configure):
 dependency problems - leaving unconfigured
Processing triggers for initramfs-tools (0.142+deb12u1) ...
update-initramfs: Generating /boot/initrd.img-5.10.0-33-amd64
E: /usr/share/initramfs-tools/hooks/growroot failed with return 1.
update-initramfs: failed for /boot/initrd.img-5.10.0-33-amd64 with 1.
dpkg: error processing package initramfs-tools (--configure):
 installed initramfs-tools package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 linux-image-6.1.0-28-amd64
 linux-image-amd64
 initramfs-tools
root@anaximander1:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            1.9G     0  1.9G   0% /dev
tmpfs           392M  864K  392M   1% /run
/dev/vda1       118G   82G   31G  74% /
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           392M  4.0K  392M   1% /run/user/0

Since it's growpart failing, I've tried checking disk usage, but I don't see any problems.

Filesystem      Size  Used Avail Use% Mounted on
udev            1.9G     0  1.9G   0% /dev
tmpfs           392M  864K  392M   1% /run
/dev/vda1       118G   82G   31G  74% /
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           392M  4.0K  392M   1% /run/user/0

And I've checked fdisk

Disk /dev/vda: 120 GiB, 128849018880 bytes, 251658240 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 66776602-A740-4B6D-8F30-6CC8AA66C962

Device     Start       End   Sectors  Size Type
/dev/vda1   4096 251656191 251652096  120G Linux filesystem
/dev/vda15  2048      4095      2048    1M BIOS boot


Partition table entries are not in disk order.

How can I resolve this error?

balleyne
  • 225

2 Answers2

4

I figured out a workaround, but be very careful that your system does NOT need growpart. My DigitalOcean server is one partition that had plenty of space. So, I disabled the growpart hook, completed the upgrade, re-enable it, and it seems to be working fine.

# Set aside the hook
mv /usr/share/initramfs-tools/hooks/growroot /root/growroot

Run update-initramfs


update-initramfs -u


Continue the upgrade


dpkg --configure -a
apt upgrade --without-new-pkgs
apt full-upgrade


Return hook to its rightful place


mv /root/growroot /usr/share/initramfs-tools/hooks/growroot


Run update-initramfs again to make sure it's still working


update-initramfs -u

I welcome a better answer. This seemed to work on my system without causing any problems, but it doesn't feel like the proper answer.

balleyne
  • 225
0

Disable the growroot hook, at least temporarily. Its not that well documented, but reading the script source shows if certain files exist, in the root file system, the growroot hook will quit early.

  touch /etc/growroot-disabled

Proceed with the apt upgrade.

As to when you might need it, this hook only matters if you extend the disk containing the root file system in a partition, and want that partition to use all the available space after it.

Disks are so easy to extend these days. If using partitions, those tables cannot be safely edited with the device open. Including file systems, which would need to be unmounted. This causes a problem for the root file system in particular, which is always mounted.

Except extremely early in boot, in the initramfs. growroot guesses at what the root partition is and run growpart program on it. If growpart --dry-run "${rootdisk}" "${partnum}" prints CHANGE: indicating that it would do something, the script unmounts root to do it for real, then mounts it back.

I am unsure as to how and why this hook gets called as a part of kernel package install. Clearly a lot of scripts happen.

This hook is fragile in how it guesses at the root partition based on trailing numbers of the device name. And if it tries to unmount root while the system is booted, that is not going to work. If you care, you could manually run the hook as a shell script, and debug if it guesses the partition correctly, and if it is attempting to extend a partition.

John Mahowald
  • 36,071