On Fri, Sep 9, 2016 at 9:28 PM, Dusty Mabe <dusty@xxxxxxxxxxxxx> wrote: Stderr: "attempt to resize /dev/sda failed. sfdisk output below:\n| Backup files:\n| MBR (offset 0, size 512): /tmp/growpart.PO8wWI/backup-sda-0x00000000.bak\n| \n| Disk /dev/sda: 10 GiB, 10737418240 bytes, 20971520 sectors\n| Units: sectors of 1 * 512 = 512 bytes\n| Sector size (logical/physical): 512 bytes / 512 bytes\n| I/O size (minimum/optimal): 512 bytes / 512 bytes\n| Disklabel type: dos\n| Disk identifier: 0x1ef30347\n| \n| Old situation:\n| \n| Device Boot Start End Sectors Size Id Type\n| /dev/sda1 * 2048 6291455 6289408 3G 83 Linux\n| Ok so it starts out as 6289408/2048= 3071MiB (or 3G) >Created a new partition 1 of type 'Linux' and of size 10 GiB.\n| /dev/sda2: \n| New situation:\n| \n| Device Boot Start End Sectors Size Id Type\n| /dev/sda1 * 2048 20971519 20969472 10G 83 Linux\n| \n| New size. But what about sda2? It said it was creating a new partition sda2, but not specifying its size, only specifying the new size of sda1. > The partition table has been altered.\n| Calling ioctl() to re-read partition table.\n| Re-reading the partition table failed.: Device or resource busy\n| The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).\n Something isn't calling partprobe? Or there's a kernel error in re-reading the device? dmesg would help, maybe. ***** WARNING: Resize failed, attempting to revert ******\n512+0 records in\n512+0 records out\n512 bytes copied, 0.000400551 s, 1.3 MB/s\n***** Appears to have gone OK ****\n" And if we are to believe this, it changed the partition table back to the Old Situation. > Sep 10 03:13:17 cloudhost.localdomain cloud-init[645]: [CLOUDINIT] util.py[DEBUG]: resize_devices took 0.127 seconds > Sep 10 03:13:17 cloudhost.localdomain cloud-init[645]: [CLOUDINIT] cc_growpart.py[DEBUG]: '/' FAILED: failed to resize: disk=/dev/sda, ptnum=1: Unexpected error while running command. > Command: ['growpart', '/dev/sda', '1'] > Exit code: 2 > Reason: - > Stdout: 'FAILED: failed to resize\n' > Stderr: "attempt to resize /dev/sda failed. sfdisk output below:\n| Backup files:\n| MBR (offset 0, size 512): /tmp/growpart.PO8wWI/backup-sda-0x00000000.bak\n| \n| Disk /dev/sda: 10 GiB, 10737418240 bytes, 20971520 sectors\n| Units: sectors of 1 * 512 = 512 bytes\n| Sector size (logical/physical): 512 bytes / 512 bytes\n| I/O size (minimum/optimal): 512 bytes / 512 bytes\n| Disklabel type: dos\n| Disk identifier: 0x1ef30347\n| \n| Old situation:\n| \n| Device Boot Start End Sectors Size Id Type\n| /dev/sda1 * 2048 6291455 6289408 3G 83 Linux\n| \n| >>> Script header accepted.\n| >>> Script header accepted.\n| >>> Script header accepted.\n| >>> Script header accepted.\n| >>> Created a new DOS disklabel with disk identifier 0x1ef30347.\n| Created a new partition 1 of type 'Linux' and of size 10 GiB.\n| /dev/sda2: \n| New situation:\n| \n| Device Boot Start End Sectors Size Id Type\n| /dev/sda1 * 2048 20971519 20969472 10G 83 Linux\n| \n| The partition table has been altered.\n| Calling ioctl() to re-read partition table.\n| Re-reading the partition table failed.: Device or resource busy\n| The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).\n***** WARNING: Resize failed, attempting to revert ******\n512+0 records in\n512+0 records out\n512 bytes copied, 0.000400551 s, 1.3 MB/s\n***** Appears to have gone OK ****\n" > And that just looks like a 2nd attempt which also fails. > > > Should I open a bug for this? Can we get someone to look at it/work on it? Yes, and I think it needs a dmesg in case partprobe was called but that failed for some reason. And then need to look at the cloud-init code and see if partprobe is being called. This is not the best log, it doesn't report the actual commands its using and the exit code for each command. So we're left wondering if partprobe was called or not. Maybe it's being called but is missing in the image? -- Chris Murphy _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/cloud@xxxxxxxxxxxxxxxxxxxxxxx
