Package: autopkgtest Version: 5.32 X-Debbugs-Cc: Victor Westerhuis <[email protected]>
I am observing that autopkgtest-build-qemu started failing after upgrading it in a bookworm system. In diagnosing it I narrowed down the cause and eventually bisected it down to this commit: https://salsa.debian.org/ci-team/autopkgtest/-/commit/18a2f2e7c9e92b2ce386f4abb0581e1d1aa7529b The failing command is: autopkgtest-build-qemu --boot=efi unstable image If I take a bookworm installation, upgrade autopkgtest to 5.42 and revert that commit, it works. Without the revert, it fails. Running the same command on unstable with autopkgtest 5.42 succeeds. The failed log contains this: remembering /dev/mapper/loop0p1 as efi remembering /dev/mapper/loop0p2 as root Exec: ['/sbin/mkfs', '-t', 'ext4', '-O', '^large_dir', '-O', '^metadata_csum_seed', '-O', '^large_dir,^metadata_csum_seed,^orphan_file', '/dev/mapper/loop0p2'] Exec: ['blkid', '-c/dev/null', '-ovalue', '-sUUID', '/dev/mapper/loop0p2'] Exec: ['mount', '/dev/mapper/loop0p2', '/tmp/tmpdto6jb0k'] Exec: ['debootstrap', '--arch', 'arm64', '--variant', '-', '--components', 'main', '--keyring', '/etc/apt/trusted.gpg.d/freexian-archive-extended-lts.gpg', 'buster', '/tmp/tmpdto6jb0k', 'http://deb.freexian.com/extended-lts'] Exec: ['chroot', '/tmp/tmpdto6jb0k', 'apt-get', 'update'] Exec: ['chroot', '/tmp/tmpdto6jb0k', 'apt-get', '-y', '--no-show-progress', '', 'install', 'eatmydata'] Exec: ['chroot', '/tmp/tmpdto6jb0k', 'eatmydata', 'apt-get', 'update'] Exec: ['chroot', '/tmp/tmpdto6jb0k', 'eatmydata', 'apt-get', '-y', '--no-show-progress', '', 'install', 'linux-image-arm64'] Exec: ['chroot', '/tmp/tmpdto6jb0k', 'apt-get', 'clean'] Exec: ['/sbin/mkfs', '-t', 'vfat', '/dev/mapper/loop0p1'] Exec: ['blkid', '-c/dev/null', '-ovalue', '-sUUID', '/dev/mapper/loop0p1'] Exec: ['mount', '/dev/mapper/loop0p1', '/tmp/tmpdto6jb0k/./boot/efi'] Installing GRUB for UEFI Exec: ['mount', '--bind', '/dev', '/tmp/tmpdto6jb0k/dev'] Exec: ['mount', '--bind', '/sys', '/tmp/tmpdto6jb0k/sys'] Exec: ['mount', '--bind', '/proc', '/tmp/tmpdto6jb0k/proc'] Exec: ['parted', '-s', '/dev/loop0', 'set', '1', 'esp', 'on'] Exec: ['mount', '/dev/mapper/loop0p1', '/tmp/tmpdto6jb0k/boot/efi'] ERROR: Program failed: 32 When comparing this to a reverted run, the first mount of /boot/efi before "Installing GRUB for UEFI" goes away. The second mount fails, because it already is mounted and in dropping the earlier mount, the second mount no longer fails. When comparing this to a run on unstable, the second mount goes away and thus no longer fails. Why does it go away you ask? Because https://salsa.debian.org/debian/vmdb2/-/commit/a993ca34fe8a6e190b3216b34c2127f921315b1e So technically, autopkgtest should Suggests: vmdb2 (>= 0.28) as it depends on this behavior change. Unfortunately, that makes using autopkgtest from unstable on bookworm infeasible as vmdb2 had really lots of changes and backporting that looks infeasible. Now even in unstable, vmdb2's grub plugin still mounts efi. Do you think we could simply discard the mount on the autopkgtest-build-qemu side and rely on vmdb2 doing it to avoid bumping the versioned requirement on vmdb2? If that doesn't work, maybe the mount and the grub plugin can be swapped? Helmut
