Closed ehuelsmann closed 9 months ago
The error is:
Errors were encountered while processing:
grub-pc
which comes from the --update
option which runs a bunch of apt commands.
I guess they fail because grub is trying to install a bootloader in the virt-builder appliance environment which probably doesn't have the same drives / layout as the real VM.
An alternative is to do the update later, eg:
virt-builder ... --firstboot-command 'apt-get -y update'
Or you could exclude grub-pc from the update, which would be some variation of:
virt-builder ... --run-command 'apt-mark hold grub-pc' --update
I guess they fail because grub is trying to install a bootloader in the virt-builder appliance environment which probably doesn't have the same drives / layout as the real VM.
That's correct. The virt-builder
environment uses an sda
device while the template image builder uses the vda
device. Aligning between the two would solve this issue; I'd propose to change the build parameters for the template to install on a scsi device while creating the template image instead of on a virtio-blk device, since the former is the default for virt-builder
.
I don't think this will solve the whole issue. There are many ways that the virt-builder environment is different from a VM. eg. BIOS drive names and geometry will be different (which matters for BIOS bootloaders). The real solution here is to not run grub from virt-builder.
Hmm. Marking grub-pc
on hold won't quite work either: many things can cause the initramfs-s to be regenerated, at which point grub is being updated too which means it will go look for its installation drive. Running the upgrade on first boot only works when the layout of the VM agrees with the template builder, because if not, the upgrade will get stuck on the required user-interaction (to select the new installation device) as well.
Seems that at least the "out-of-the-box" experience can be improved by aligning between the build system and virt-builder's defaults. The user can't really change those. When firing up an image with a virtio-blk device, they can adjust the setup to use scsi instead through libvirt, if/when required to successfully boot.
Did you actually try it? Rebuilding the initramfs should not invoke grub, and indeed we rebuild the initramfs in virt-v2v under similar circumstances and it works fine.
When running
virt-builder --size 20G --format qcow2 -o vm.qcow2 --arch amd64 --update debian-11
fails to build an image.Running the same command for
debian-10
(virt-builder --size 20G --format qcow2 -o vm.qcow2 --arch amd64 --update debian-10
) results in:I'm expecting the same for
debian-11
(virt-builder --size 20G --format qcow2 -o vm.qcow2 --arch amd64 --update debian-11
) to produce the same result, but instead it results in:Please find the build log from
$ virt-builder -v -x --size 20G --format qcow2 -o vm.qcow2 --arch amd64 --update debian-11 1>build.log 2>&1
attached:build.log