After some checkings, using a known failing qcow2, instead of booting the default 6.0.3 kernel, I installed and booted a 5.10.149-2 kernel. The resizefs operation didn't fail, so I guess we have an ext4 issue in the kernel 6.0 . F. On Thu, 20 Oct 2022 15:33:53 +0200 Frédéric Bonnard <frederic@fr.ibm.com> wrote: > Hi everybody, > [I am not subscribed to the list] > I test the cloud images from unstable and since 2 days, the tests fail > to resize the qcow2 files : > > example using https://cloud.debian.org/images/cloud/sid/daily/latest/debian-sid-nocloud-amd64-daily.qcow2 : > > --- > host $ qemu-img info debian-sid-nocloud-amd64-daily.qcow2 > image: debian-sid-nocloud-amd64-daily.qcow2 > file format: qcow2 > virtual size: 2 GiB (2147483648 bytes) > disk size: 378 MiB > cluster_size: 65536 > Format specific information: > compat: 1.1 > compression type: zlib > lazy refcounts: false > refcount bits: 16 > corrupt: false > extended l2: false > host $ qemu-img resize debian-sid-nocloud-amd64-daily.qcow2 +18G > Image resized. > host $ qemu-img info debian-sid-nocloud-amd64-daily.qcow2 > image: debian-sid-nocloud-amd64-daily.qcow2 > file format: qcow2 > virtual size: 20 GiB (21474836480 bytes) > disk size: 378 MiB > cluster_size: 65536 > Format specific information: > compat: 1.1 > compression type: zlib > lazy refcounts: false > refcount bits: 16 > corrupt: false > extended l2: false > --- > > Now booting that resized qcow2 in a guest : > > --- > guest# dmesg -T |grep -i sda > [Thu Oct 20 13:21:07 2022] sd 0:0:0:0: [sda] 41943040 512-byte logical blocks: (21.5 GB/20.0 GiB) > [Thu Oct 20 13:21:07 2022] sd 0:0:0:0: [sda] Write Protect is off > [Thu Oct 20 13:21:07 2022] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 > [Thu Oct 20 13:21:07 2022] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA > [Thu Oct 20 13:21:07 2022] sd 0:0:0:0: [sda] Preferred minimum I/O size 512 bytes > [Thu Oct 20 13:21:07 2022] sda: sda1 sda14 sda15 > [Thu Oct 20 13:21:07 2022] sd 0:0:0:0: [sda] Attached SCSI disk > [Thu Oct 20 13:21:08 2022] EXT4-fs (sda1): mounted filesystem with ordered data mode. Quota mode: none. > [Thu Oct 20 13:21:09 2022] EXT4-fs (sda1): re-mounted. Quota mode: none. > [Thu Oct 20 13:21:09 2022] EXT4-fs (sda1): resizing filesystem from 491515 to 491515 blocks > guest# lsblk > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS > sda 8:0 0 20G 0 disk > ├─sda1 8:1 0 1.9G 0 part / > ├─sda14 8:14 0 3M 0 part > └─sda15 8:15 0 124M 0 part /boot/efi > sr0 11:0 1 1024M 0 rom > guest# growpart /dev/sda 1 > CHANGED: partition=1 start=262144 old: size=3932127 end=4194270 new: size=41680863 end=41943006 > guest# resize2fs /dev/sda1 > resize2fs 1.46.6-rc1 (12-Sep-2022) > Filesystem at /dev/sda1 is mounted on /; on-line resizing required > old_desc_blocks = 1, new_desc_blocks = 3 > [ 89.416761] EXT4-fs (sda1): resizing filesystem from 491515 to 5210107 blocks > [ 90.120506] EXT4-fs (sda1): resized filesystem to 5210107 > [ 91.493798] EXT4-fs (sda1): Invalid checksum for backup superblock 32768 > [ 91.493798] > [ 91.496160] EXT4-fs error (device sda1) in ext4_update_backup_sb:174: Filesystem failed CRC > [ 91.498819] Aborting journal on device sda1-8. > [ 91.500255] EXT4-fs error (device sda1): ext4_journal_check_start:83: comm systemd-journal: Detected aborted journal > [ 91.542867] EXT4-fs (sda1): Remounting filesystem read-only > [ 91.544748] EXT4-fs error (device sda1) in ext4_update_backup_sb:174: Journal has aborted > resize2fs: Read-only file system While checking for on-line resizing support > guest# lsblk > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS > sda 8:0 0 20G 0 disk > ├─sda1 8:1 0 19.9G 0 part / > ├─sda14 8:14 0 3M 0 part > └─sda15 8:15 0 124M 0 part /boot/efi > sr0 11:0 1 1024M 0 rom > guest# mount|grep sda1 > /dev/sda1 on / type ext4 (ro,relatime,discard,errors=remount-ro,mb_optimize_scan=0) > /dev/sda15 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro) > --- > > Any idea what's happening ? > This used to work and still works on testing/bullseye cloud images. > unstable cloud image 3days ago with kernel 5.19.0-2 worked. > unstable cloud image 2days ago with kernel 6.0.0-1 did not work and fails since then. > I don't know about the intrinsics of cloud image generation. Something could have > change there as well. > Regards, > > F.
Attachment:
signature.asc
Description: PGP signature