resizefs failure with raring

[Robert Collins]

Deploying a raring cloud image with a 2.7G filesystem to 2TB hard disk crashes in resizefs

[ 143.673885] 0000000000000800 ffff880bd4b87f60 ffff880bca8b7d00 ffffffff8125b
e47
[ 143.673945] Call Trace:
[ 143.673970] [<ffffffff8125be47>] ext4_flex_group_add+0x1317/0x1490
[ 143.674001] [<ffffffff8125d00a>] ext4_resize_fs+0x74a/0xdc0
[ 143.674030] [<ffffffff8123ae31>] ext4_ioctl+0x971/0xb60
[ 143.674060] [<ffffffff811a4091>] ? do_filp_open+0x41/0xa0
[ 143.674089] [<ffffffff811a61a9>] do_vfs_ioctl+0x99/0x570
[ 143.674119] [<ffffffff8117d00f>] ? kmem_cache_free+0x2f/0x130
[ 143.674148] [<ffffffff811a36b2>] ? final_putname+0x22/0x50
[ 143.674177] [<ffffffff811a38b9>] ? putname+0x29/0x40
[ 143.674204] [<ffffffff811a6711>] sys_ioctl+0x91/0xb0
[ 143.674233] [<ffffffff816d59dd>] system_call_fastpath+0x1a/0x1f
[ 143.674261] Code: 0f 85 f2 fe ff ff 31 c0 48 83 c4 28 5b 41 5c 41 5d 41 5e 41
 5f 5d c3 48 83 c4 28 b8 f4 ff ff ff 5b 41 5c 41 5d 41 5e 41 5f 5d c3 <0f> 0b 90
 66 66 66 66 90 55 48 89 e5 48 83 ec 18 4c 89 65 f0 49
[ 143.674584] RIP [<ffffffff8125a5cd>] set_flexbg_block_bitmap+0x17d/0x180
[ 143.674618] RSP <ffff880bca8b7bb0>
[ 143.674643] ---[ end trace 5fa931e218cd3ae5 ]---
2013-09-30 10:07:44,273 - util.py[WARNING]: Failed to resize filesystem (cmd=('r
esize2fs', '/dev/disk/by-uuid/420927c3-abd7-4b7d-972c-a8b6969d7d53'))
2013-09-30 10:07:44,293 - util.py[WARNING]: Running resizefs (<module 'cloudinit
.config.cc_resizefs' from '/usr/lib/python2.7/dist-packages/cloudinit/config/cc_
resizefs.pyc'>) failed

Is all the diagnostics I have so far.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1233075

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Stefan Bader (smb)]

So as of IRC feedback this seems to work on a current Quantal kernel. Which means the next steps should be to verify on one side whether for example the originally released Raring kernel (3.8.0-19.29) already showed that problem and on the other side whether a current Saucy (3.11.0-9.16) kernel still has the same issue.

[Stefan Bader (smb)]

As Robert also pointed out on IRC this seems to have been noted before:
https://lkml.org/lkml/2013/3/19/554

There does not seem to be a follow-up or answer, though.

[Robert Collins (lifeless)]

interestingly quantal didn't resize, but it didn't lockup either. Definitely more investigation warranted.

[Robert Collins (lifeless)]

huh,
root@undercloud-notcompute-jws3awlsb2kh:/home/heat-admin# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 1.8T 0 disk
��sda1 8:1 0 20G 0 part /
��sda2 8:2 0 7.9M 0 part
root@undercloud-notcompute-jws3awlsb2kh:/home/heat-admin# fdisk /dev/sda

Command (m for help): p

Disk /dev/sda: 2000.4 GB, 2000365379584 bytes
255 heads, 63 sectors/track, 243197 cylinders, total 3906963632 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
Disk identifier: 0x000233a6

   Device Boot Start End Blocks Id System
/dev/sda1 1 41945714 20972857 83 Linux
/dev/sda2 41945715 41961779 8032+ 82 Linux swap / Solaris

This would have been the same for the raring image, so a mere 20G partition size was enough to trigger the failure. That should be reproducable in virt.

[Robert Collins (lifeless)]

We may have found some more data on the situation: bug 1233024 reports on a failure to resize with the same images..

[Robert Collins (lifeless)]

Nuts, wrong reference...

We may have found some more data on the situation: bug 1233008 reports on a failure to resize with the same images..

[Stefan Bader (smb)]

This appears to be fixed actually (reference in other bug)

[Stefan Bader (smb)]

Correct status is a bit hard to say as the problem was the journal which was defined too small given the image size on creation. There may or may not be a better way to detect this and bail early.

[Steven DuChene (steven-a-duchene)]

Got exact same error from a current devtest.sh run

[Robert Collins (lifeless)]

I've reproduced this recently with saucy, without the --max-resize option, but only resizing to 20-30G from a 2G base, which is well within the heuristics ext4 has.

[Robert Collins (lifeless)]

Steven's report is with saucy as well.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1233075

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]