How do I trigger oem-resize on first boot of an imported disk?

[Raphael Traviss]

Hi all,

I am using the following image config to build a resizable OEM image:

  <preferences profiles="vmware">
    <type
      image="oem"
      filesystem="btrfs"
      format="vmdk"
      firmware="uefi"
      efipartsize="33"
      kernelcmdline="plymouth.enable=0 console=ttyS0="
      bootpartition="false"
      bootkernel="custom"
      devicepersistency="by-uuid"
      btrfs_quota_groups="true"
      btrfs_root_is_snapshot="true"
      btrfs_root_is_subvolume="true"
    >
      <bootloader name="grub2" timeout="0" console="serial"/>

      <systemdisk>
        <volume name="home"/>
        <volume name="root"/>
        <volume name="tmp"/>
        <volume name="opt"/>
        <volume name="srv"/>
        <volume name="boot/grub2/arm64-efi" mountpoint="boot/grub2/arm64-efi" />
        <volume name="usr/local"/>
        <volume name="var" copy_on_write="false"/>
      </systemdisk>

      <oemconfig>
        <oem-resize>true</oem-resize>
        <oem-unattended>true</oem-unattended>
      </oemconfig>
    </type>

  </preferences>

But when I import the disk into VMWare fusion using a 12GB simulated disk, it doesn't automatically resize on first boot (attached image)

After the VM boots, I can log in and manually resize with the following commands:

  parted /dev/nvme0n1 resize part 2 100%
  btrfs filesystem resize max /

Is there any way to get oem-resize to trigger automatically on first boot?

Regards,

Raphael

[Marcus Schäfer]

Hi Raphael,

> But when I import the disk into VMWare fusion using a 12GB simulated
> disk, it doesn't automatically resize on first boot (attached image)

According to your setup it should have done that as part of
an action inside of the initrd prior the mount of the rootfs

If it did not happen we need logging information to find out why.
You can get this log file as follows:

- Repeat the import of the image into a test disk on VMWare
- On first boot pass the following parameter to the kernel cmdline via
the bootloader console:

rd.kiwi.debug

- Once you can login to the system you will find a log file in

/run/initramfs/log/boot.kiwi

Check the log for any data you would be concerned to send. If ok
send us the file and we can double check what's going on

Thanks

Regards,
Marcus
--
Public Key available via: https://keybase.io/marcus_schaefer/key.asc
keybase search marcus_schaefer
-------------------------------------------------------
Marcus Schäfer Brunnenweg 18
Tel: +49 7562 905437 D-88260 Argenbühl
Germany
-------------------------------------------------------

[Raphael Traviss]

Hi Marcus,

> According to your setup it should have done that as part of
> an action inside of the initrd prior the mount of the rootfs

> If it did not happen we need logging information to find out why.

Attached is the log file, which says that the resize was skipped because

the disk geometry did not change--could this be because of

btrfs_root_is_subvolume ?

Attached lsblk output says the drive is 12G, but p2 is only 1GB since the

resize was skipped--I'd expect p2 to be resized to fill the unallocated space.

Using KIWI-NG 10.0.10 package from

https://build.opensuse.org/package/show/Virtualization:Appliances:Builder/python-kiwi

building on an openSUSE Tumbleweed (6.x kernel) aarch64 VM hosted via VMWare on macOS;

creating images for openSUSE LEAP (5.x kernel) aarch64 VMs also intended for VMWare on macOS.

Regards,

Raphael

[Marcus Schäfer]

Hi,

> Attached is the log file

Thanks

ok, so on a GPT partitioned disk, there is a backup table at the
end of the disk. If you dump an image to a larger disk this backup
table is now no longer at the end of the disk and this is the
condition we check to identify that the disk geometry has changed.
The tool we use to check this is this:

sudo sgdisk --verify /dev/nvme0n1

Can you please call this on your system directly after deployment
without you having done any manual changes and send us the output.
Thanks much

I can imagine some possible reasons for the issue:

1. The sgdisk utility was not added to the initrd. This would happen
if your image doesn't install the gptfdisk package. Can you double
check if you install this package ? It is set as a requires to the
dracut-kiwi-lib which you surely have installed, but better check.
Please also call:

sudo lsinitrd /boot/initrd | grep sgdisk

2. The sgdisk verification sends unexpected results. We will
know from the above output

3. The way you deployed the image to that VMware disk has already
moved the backup table to the end of the disk. Actually I doubt
that your image file is 12GB of size, is that true, it looks
pretty big. Your image <type> definition does not specify a fixed
size, thus it gets just as big as needed to store the data.
As your rootfs is ~1GB I would assume your original image is ~1G
Can you therefore also call:

gdisk -l your-image-file.raw

of if you only have the .vmdk at hand:

qemu-img convert -f vmdk -O raw your-image-file.vmdk foo.raw
gdisk -l foo.raw

Such that we can see the original partition table before you
used it inside of VMWare

[Raphael Traviss]

Hi,

> 3. The way you deployed the image to that VMware disk has already
moved the backup table to the end of the disk.

Yes, this is exactly what was happened when I did the resize through the

VMWare Fusion resize wizard.  To test OEM resize, I have to resize the disk

image manually, using the Linux build host:

cp path/to/image.raw testing.raw
dd if=/dev/zero of=testing.raw bs=1 count=1 seek=$((12*1024*1024*1024-1))
qemu-img convert -f raw -O vmdk testing.raw /path/to/output.vmdk

Using the dd workflow, KIWI now catches the disk geometry change, and

resizes as I'd expect.

Thanks--that backup table hint was the key.

Regards,

Raphael

[Marcus Schäfer]

Hi Raphael,

> > 3. The way you deployed the image to that VMware disk has already
> moved the backup table to the end of the disk.
>
> Yes, this is exactly what was happened when I did the resize through
> the
>
> VMWare Fusion resize wizard. To test OEM resize, I have to resize the
> disk

Ahh ok, great that we found it

> Using the dd workflow, KIWI now catches the disk geometry change, and
>
> resizes as I'd expect.
>
> Thanks--that backup table hint was the key.

Great, thanks for the feedback.

Happy we sorted it out

Cheers,