Resize_device fails

Hi Folks,

== tl;dr:
cloud-config: resize_device: /dev/vda
=>
growpart fails with: ‘Start sector 0 out of range’.

== Long Version:
We use the RancherOS Version 1.0.
In the cloud-config we configured the following so that the first partition grows to volume size:

-------------------- >8 --------------------
rancher:
  resize_device: /dev/vda
-------------------- >8 --------------------

It is an Openstack environment. The instance has one 70GB Volume:
-------------------- >8 --------------------
Disk /dev/vda: 70 GiB, 75161927680 bytes, 146800640 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
Disklabel type: dos
Disk identifier: 0x3452b8fc

Device     Boot Start    End Sectors Size Id Type
/dev/vda1  *        0 176127  176128  86M 17 Hidden HPFS/NTFS
-------------------- >8 --------------------

As you can see, the first partition (vda1) was not resized (only 86MB).
When we look into the ‘cloud-init-execute’-Container logs, we can see the Problem:

-------------------- >8 --------------------
attempt to resize /dev/vda failed. sfdisk output below:
| Backup files:
|          MBR (offset     0, size   512): /tmp/growpart.gUvcEQ/orig.save-vda-0x00000000.bak
| 
| Disk /dev/vda: 70 GiB, 75161927680 bytes, 146800640 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
| Disklabel type: dos
| Disk identifier: 0x3452b8fc
| 
| Old situation:
| 
| Device     Boot Start    End Sectors Size Id Type
| /dev/vda1  *        0 176127  176128  86M 17 Hidden HPFS/NTFS
| 
| >>> Script header accepted.
| >>> Script header accepted.
| >>> Script header accepted.
| >>> Script header accepted.
| >>> Created a new DOS disklabel with disk identifier 0x3452b8fc.
| Start sector 0 out of range.
| Failed to add partition: Numerical result out of range
| Leaving.
| 
FAILED: failed to resize
***** WARNING: Resize failed, attempting to revert ******
512+0 records in
512+0 records out
***** Appears to have gone OK ****
-------------------- >8 --------------------

Is it a Bug in the “growpart” Script or a Bug in sfdisk or am I doing something completely wrong?

Thanks and kind regards,
larsux

I’ll need to test - it worked when I tried it for something last month.

@larsux frustratingly, its working for me:

[rancher@rancher-dev ~]$ sudo fdisk -l /dev/vda
Disk /dev/vda: 70 GiB, 75161927680 bytes, 146800640 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
Disklabel type: dos
Disk identifier: 0xd3973182

Device     Boot Start       End   Sectors Size Id Type
/dev/vda1  *     2048 146800606 146798559  70G 83 Linux

I’m using the following in my cloud-init file:

sven@i7:~/go/src/github.com/rancher/os$ cat resize.yml
#cloud-config
rancher:
  resize_device: /dev/vda

most often I’m testing with ./scripts/run --fresh --openstack --cloud-config resize.yml - the qemu based script in the rancher/os repo.

I wonder if you have any other customisations, and if they’re causing some conflict that I need to fix.

Hi Sven,

thanks for your testing.
As I can see your partition starts at sector 2048.
In my Openstack instance the partition starts at 0, which causes the problem.

I have to look, who creates the partition table. Openstack while provisioning or the dapper-tool while building the RancherOS Image.

Thanks and kind regards,
larsux

Okay, the issue appear, when we rebuild the rancherOS-ISO (https://docs.rancher.com/os/custom-builds/custom-rancheros-iso) in order to use the metadataservice from openstack (so we don’t need the configdrive):
------------------------ >8 -------------------------
$ git clone https://github.com/rancher/os.git
$ cd os
$ sed -i ‘s#configdrive:/media/config-2#url:http://169.254.169.254/latest/user-data#’ os-config.tpl.yml
$ make
------------------------ >8 -------------------------

When we use the standard-ISO (https://releases.rancher.com/os/latest/rancheros-openstack.img) the partition starts at 2048.

For now we now use a workaround in that way, that we append an additional ephemeral disk and use it completely as mount point for ‘/var/lib/docker’. But I don’t know if this is the best way to do.

Best regards,
larsux