Description of problem: Ubuntu Zesty images are GPT BIOS/UEFI bootable with a BIOS boot partition After resizing sda1 (ext4) the image is not BIOS bootable https://cloud-images.ubuntu.com/releases/17.04/release/ubuntu-17.04-server-cloudimg-amd64.img Version-Release number of selected component (if applicable): libguestfs-tools-1.36.5-1.fc26.noarch How reproducible: Always Steps to Reproduce: 1. Zesty cloud image 2. virt-resize --extend /dev/sda1 zesty.img output.img 3. Actual results: 1. Image is UEFI bootable (KVM OVMF) 2. Images is BIOS bootable Expected results: Image is BIOS and UEFI bootable Additional info: virt-resize seems to renumber the partitions; that doesn't seem to matter though so not sure why that would cause trouble. ## this is the original image root@cloud-98af:~# parted -s /dev/sdb u s print Model: QEMU QEMU HARDDISK (scsi) Disk /dev/sdb: 4612096s Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 14 2048s 10239s 8192s bios_grub 15 10240s 227327s 217088s fat32 boot, esp 1 227328s 4612062s 4384735s ext4 ## after virt-resize to a 20G qcow2 image root@cloud-98af:~# parted -s /dev/sdc u s print Model: QEMU QEMU HARDDISK (scsi) Disk /dev/sdc: 41943040s Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 2048s 10239s 8192s primary bios_grub 2 10240s 227327s 217088s fat32 primary boot, esp 3 227328s 41940479s 41713152s ext4 primary ## this growpart image works without using virt-resize: the image was grown using qemu-img; and the root partition was enlarged into the free space using growpart in initramfs; i.e order of partitions was preserved root@cloud-98af:~# parted -s /dev/sdd u s print Model: QEMU QEMU HARDDISK (scsi) Disk /dev/sdd: 41943040s Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 14 2048s 10239s 8192s bios_grub 15 10240s 227327s 217088s fat32 boot, esp 1 227328s 4612062s 4384735s ext4
..should read... Actual results: 2. Image is not BIOS bootable 1. Image remains UEFI bootable (KVM OVMF)
When booting the virt-resize image: Booting from Hard Disk... error: unknown filesystem. Entering rescue mode... grub rescue> The renumbering of the partitions (1,14,15) -> (3,1,2) seems to confuse grub. The system can be manually recovered: set prefix=(hd0,gpt3)/boot/grub set root=(hd0,gpt3) insmod linux linux /boot/vmlinuz-4.10.0-24-generic ro root=/dev/sda3 initrd /boot/initrd.img-4.10.0-24-generic boot This works to boot the system. Since ubuntu cloud images seems to be moving this way: BIOS/UEFI images sda14/sda15/sda1 <--- rootfs It might be useful not to renumber partitions?
After booting the system in BIOS, grub CLI recovery, and reinstalling grub, the system will now boot root@ubuntu:~# parted -s /dev/sda u s print Model: QEMU QEMU HARDDISK (scsi) Disk /dev/sda: 41943040s Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 2048s 10239s 8192s primary bios_grub 2 10240s 227327s 217088s fat32 primary boot, esp 3 227328s 41940479s 41713152s ext4 primary
The sdd comment #1 is incomplete; this is before the partition was grown to fill the free space using cloud-initramfs-growroot: # qemu-img resize zesty.img zesty20G.img root@cloud-98af:~# parted -s /dev/sdd u s print Model: QEMU QEMU HARDDISK (scsi) Disk /dev/sdd: 41943040s Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 14 2048s 10239s 8192s bios_grub 15 10240s 227327s 217088s fat32 boot, esp 1 227328s 4612062s 4384735s ext4 This is after growpart was run in the image: root@ubuntu:~# parted -s /dev/sda u s print Model: QEMU QEMU HARDDISK (scsi) Disk /dev/sda: 41943040s Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 14 2048s 10239s 8192s bios_grub 15 10240s 227327s 217088s fat32 boot, esp 1 227328s 41943006s 41715679s ext4 This image (without the partition renumbering) remains bootable.
virt-resize run: virt-resize --expand=/dev/sda1 zesty-server-cloudimg-amd64.img zesty20b.img [ 0.0] Examining zesty-server-cloudimg-amd64.img ********** Summary of changes: /dev/sda14: This partition will be left alone. /dev/sda15: This partition will be left alone. /dev/sda1: This partition will be resized from 2.1G to 19.9G. The filesystem ext4 on /dev/sda1 will be expanded using the 'resize2fs' method. ********** [ 2.4] Setting up initial partition table on zesty20b.img [ 9.6] Copying /dev/sda14 [ 9.6] Copying /dev/sda15 [ 10.1] Copying /dev/sda1 100% ⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧ 00:00 [ 17.1] Expanding /dev/sda1 (now /dev/sda3) using the 'resize2fs' method Resize operation completed with no errors. Before deleting the old disk, carefully check that the resized disk boots and works correctly.
The virt-resize'd image runs find under OVMF: root@ubuntu:~# parted -s /dev/sda u s print Model: QEMU QEMU HARDDISK (scsi) Disk /dev/sda: 41943040s Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 2048s 10239s 8192s primary bios_grub 2 10240s 227327s 217088s fat32 primary boot, esp 3 227328s 41940479s 41713152s ext4 primary
Yup, it's the crazy partition numbering. On the plus side at least Ubuntu is using GPT now instead of extended partitions. On the minus side, wtf non-monotonic partition numbering?
Yeah — for sure I thought the image was corrupted when I saw sda14 and sda15, like what just happened!? Downloaded it twice more and did a hexdump... :-(
This continues to be a problem with 20.04 focal.