OEM not resizing

[Gavin Lambert]

I previously had OEM resizing working (as far as I recall) but lately it seems to be more inconsistent or not working at all, and I'm not sure what I changed to break it or if there's another issue.

I do not have <oem-resize> specified in the <oemconfig> (which according to the docs means it should be enabled by default?).  I've tried both using the installiso to boot and install onto a disk and also directly burning the .raw file to a USB drive.  In most cases it seems to not be resizing the disk at all.  In one case it did resize the partition successfully but didn't resize the filesystem to match.

Here's one example where it didn't resize anything and I'm not sure why not:

$ lsblk

NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sr0          11:0    1 1024M  0 rom  
nvme0n1     259:0    0   30G  0 disk
├─nvme0n1p1 259:4    0    2M  0 part
├─nvme0n1p2 259:5    0   20M  0 part /boot/efi
└─nvme0n1p3 259:6    0  9.4G  0 part /
$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p3  9.2G  6.8G  2.0G  78% /

Related boot logs:

[    6.493426] dracut-pre-mount[711]: ///lib/dracut/hooks/pre-mount/20-kiwi-repart-disk.sh@270(source): resize_wanted /dev/disk/by-uuid/e916bbc0-f338-4986-8c7e-bd73ad8e221d /dev/nvme0n1
[    6.493491] dracut-pre-mount[711]: //lib/kiwi-partitions-lib.sh@413(resize_wanted): declare kiwi_oemresizeonce=
[    6.493547] dracut-pre-mount[711]: //lib/kiwi-partitions-lib.sh@414(resize_wanted): declare kiwi_rootpartuuid=60777a5f-b245-4d26-aae1-a2ad80f3d7b9
[    6.493607] dracut-pre-mount[711]: //lib/kiwi-partitions-lib.sh@415(resize_wanted): local current_rootpart_uuid
[    6.493660] dracut-pre-mount[711]: //lib/kiwi-partitions-lib.sh@416(resize_wanted): local root_device=/dev/disk/by-uuid/e916bbc0-f338-4986-8c7e-bd73ad8e221d
[    6.493711] dracut-pre-mount[711]: //lib/kiwi-partitions-lib.sh@417(resize_wanted): local disk_device=/dev/nvme0n1
[    6.494747] dracut-pre-mount[1054]: ///lib/kiwi-partitions-lib.sh@418(resize_wanted): bool ''
[    6.494911] dracut-pre-mount[1054]: ///lib/kiwi-lib.sh@185(bool): local value=
[    6.494986] dracut-pre-mount[1054]: ///lib/kiwi-lib.sh@186(bool): '[' -n '' ']'
[    6.495033] dracut-pre-mount[1054]: ///lib/kiwi-lib.sh@189(bool): echo false

[    6.495332] dracut-pre-mount[711]: //lib/kiwi-partitions-lib.sh@418(resize_wanted): kiwi_oemresizeonce=false
[    6.495542] dracut-pre-mount[711]: //lib/kiwi-partitions-lib.sh@419(resize_wanted): getargbool 0 rd.kiwi.oem.force_resize
[    6.495620] dracut-pre-mount[711]: //lib/dracut-lib.sh@247(getargbool): local _b
[    6.495667] dracut-pre-mount[711]: //lib/dracut-lib.sh@248(getargbool): unset _b
[    6.495720] dracut-pre-mount[711]: //lib/dracut-lib.sh@249(getargbool): local _default
[    6.495770] dracut-pre-mount[711]: //lib/dracut-lib.sh@250(getargbool): _default=0
[    6.495893] dracut-pre-mount[711]: //lib/dracut-lib.sh@251(getargbool): shift
[    6.496778] dracut-pre-mount[1055]: ///lib/dracut-lib.sh@252(getargbool): getarg rd.kiwi.oem.force_resize
[    6.496883] dracut-pre-mount[1055]: ///lib/dracut-lib.sh@173(getarg): debug_off
[    6.496934] dracut-pre-mount[1055]: ///lib/dracut-lib.sh@23(debug_off): set +x
[    6.500509] dracut-pre-mount[1055]: ///lib/dracut-lib.sh@236(getarg): return 1
[    6.500855] dracut-pre-mount[711]: //lib/dracut-lib.sh@252(getargbool): _b=
[    6.500920] dracut-pre-mount[711]: //lib/dracut-lib.sh@252(getargbool): _b=0
[    6.500956] dracut-pre-mount[711]: //lib/dracut-lib.sh@253(getargbool): '[' -n 0 ']'
[    6.500979] dracut-pre-mount[711]: //lib/dracut-lib.sh@254(getargbool): '[' 0 = 0 ']'
[    6.501002] dracut-pre-mount[711]: //lib/dracut-lib.sh@254(getargbool): return 1
[    6.501031] dracut-pre-mount[711]: //lib/kiwi-partitions-lib.sh@424(resize_wanted): '[' false = true ']'

[    6.501063] dracut-pre-mount[711]: //lib/kiwi-partitions-lib.sh@434(resize_wanted): info 'System resize is active on every reboot'
[    6.501086] dracut-pre-mount[711]: //lib/dracut-lib.sh@89(info): echo 'System resize is active on every reboot'
[    6.501109] dracut-pre-mount[711]: //lib/kiwi-partitions-lib.sh@436(resize_wanted): disk_has_unallocated_space /dev/nvme0n1
[    6.501131] dracut-pre-mount[711]: //lib/kiwi-partitions-lib.sh@328(disk_has_unallocated_space): local disk_device=/dev/nvme0n1
[    6.501154] dracut-pre-mount[711]: //lib/kiwi-partitions-lib.sh@329(disk_has_unallocated_space): local pt_table_type
[    6.501747] dracut-pre-mount[1058]: ///lib/kiwi-partitions-lib.sh@330(disk_has_unallocated_space): get_partition_table_type /dev/nvme0n1
[    6.501814] dracut-pre-mount[1058]: ///lib/kiwi-partitions-lib.sh@295(get_partition_table_type): local disk_device=/dev/nvme0n1
[    6.501848] dracut-pre-mount[1058]: ///lib/kiwi-partitions-lib.sh@296(get_partition_table_type): local table_type
[    6.502286] dracut-pre-mount[1059]: ////lib/kiwi-partitions-lib.sh@300(get_partition_table_type): uname -m
[    6.503422] dracut-pre-mount[1058]: ///lib/kiwi-partitions-lib.sh@300(get_partition_table_type): [[ x86_64 =~ s390 ]]
[    6.503452] dracut-pre-mount[1058]: ///lib/kiwi-partitions-lib.sh@313(get_partition_table_type): blkid -s PTTYPE -o value /dev/nvme0n1
[    6.514529] dracut-pre-mount[711]: //lib/kiwi-partitions-lib.sh@330(disk_has_unallocated_space): pt_table_type=gpt
[    6.514604] dracut-pre-mount[711]: //lib/kiwi-partitions-lib.sh@331(disk_has_unallocated_space): '[' gpt = gpt ']'
[    6.515101] dracut-pre-mount[1062]: //lib/kiwi-partitions-lib.sh@338(disk_has_unallocated_space): sgdisk --verify /dev/nvme0n1
[    6.515251] dracut-pre-mount[1063]: //lib/kiwi-partitions-lib.sh@338(disk_has_unallocated_space): grep -q 'end of the disk'
[    6.523069] dracut-pre-mount[711]: //lib/kiwi-partitions-lib.sh@440(resize_wanted): info 'Disk geometry did not change'
[    6.523114] dracut-pre-mount[711]: //lib/dracut-lib.sh@89(info): echo 'Disk geometry did not change'
[    6.523137] dracut-pre-mount[711]: //lib/kiwi-partitions-lib.sh@441(resize_wanted): info 'Skipping resize operation'
[    6.523153] dracut-pre-mount[711]: //lib/dracut-lib.sh@89(info): echo 'Skipping resize operation'

[    6.523169] dracut-pre-mount[711]: //lib/kiwi-partitions-lib.sh@442(resize_wanted): return 1
[    6.523214] dracut-pre-mount[711]: ///lib/dracut/hooks/pre-mount/20-kiwi-repart-disk.sh@271(source): return

It looks like maybe it's expecting some output of sgdisk that is not there?

$ sudo sgdisk --verify /dev/nvme0n1

No problems found. 43091934 free sectors (20.5 GiB) available in 2
segments, the largest of which is 43089920 (20.5 GiB) in size.

Possibly of significance is that my target system is currently OpenSUSE Leap 15.5 but I'm running kiwi-ng from 15.6 (and also using Virtualization:/Appliances:/Builder/openSUSE_Leap_15.6 in the config.xml so that it pulls the matching version of dracut-kiwi-oem-repart).

[Gavin Lambert]

On Friday, July 4, 2025 at 1:51:24 PM UTC+12 I wrote:

I previously had OEM resizing working (as far as I recall) but lately it seems to be more inconsistent or not working at all, and I'm not sure what I changed to break it or if there's another issue.

Another possibly interesting snippet from the boot logs:

++++ lsblk -p -l -o NAME,TYPE,START -x START /dev/nvme0n1
++++ cut -f1 -d ' '
++++ grep -E 'part|md$'
lsblk: unknown column: START
Try 'lsblk --help' for more information.
+++ return 1

[Gavin Lambert]

On Friday, July 4, 2025 at 1:51:24 PM UTC+12 I wrote:

In one case it did resize the partition successfully but didn't resize the filesystem to match.

I've managed to reproduce this.  The first case was with burning the .raw[.xz] file directly to a larger disk using Rufus; it appears that leaves it in a state where it doesn't think it wants to resize anything.

The following is the log from running the install .iso; in this case it did resize the partition but not the filesystem:

+++ local device=/dev/disk/by-uuid/69dd81aa-afe2-4baf-b7d8-5dd64a3c8d7d
+++ '[' '!' -e /dev/disk/by-uuid/69dd81aa-afe2-4baf-b7d8-5dd64a3c8d7d ']'
++++ blockdev --getsize64 /dev/disk/by-uuid/69dd81aa-afe2-4baf-b7d8-5dd64a3c8d7d
+++ echo 9890799
++ storage_size=9890799
++ '[' 9890799 -gt 0 ']'
++ sleep 1
++ return 0
++ resize_wanted /dev/disk/by-uuid/69dd81aa-afe2-4baf-b7d8-5dd64a3c8d7d /dev/nvme0n1
++ declare kiwi_oemresizeonce=
++ declare kiwi_rootpartuuid=b564d9f9-51a5-49de-b0b3-5b15b1736872
++ local current_rootpart_uuid
++ local root_device=/dev/disk/by-uuid/69dd81aa-afe2-4baf-b7d8-5dd64a3c8d7d
++ local disk_device=/dev/nvme0n1
+++ bool ''
+++ local value=
+++ '[' -n '' ']'
+++ echo false
++ kiwi_oemresizeonce=false
++ getargbool 0 rd.kiwi.oem.force_resize
++ local _b
++ unset _b
++ local _default
++ _default=0
++ shift
+++ getarg rd.kiwi.oem.force_resize
+++ debug_off
+++ set +x
++ _b=
++ _b=0
++ '[' -n 0 ']'
++ '[' 0 = 0 ']'
++ return 1
++ '[' false = true ']'
++ info 'System resize is active on every reboot'
++ echo 'System resize is active on every reboot'

System resize is active on every reboot

++ disk_has_unallocated_space /dev/nvme0n1
++ local disk_device=/dev/nvme0n1
++ local pt_table_type
+++ get_partition_table_type /dev/nvme0n1
+++ local disk_device=/dev/nvme0n1
+++ local table_type
++++ uname -m
+++ [[ x86_64 =~ s390 ]]
+++ blkid -s PTTYPE -o value /dev/nvme0n1
++ pt_table_type=gpt
++ '[' gpt = gpt ']'
++ sgdisk --verify /dev/nvme0n1
++ grep -q 'end of the disk'
++ info 'Activating resize operation'
++ echo 'Activating resize operation'
Activating resize operation
++ return 0
+++ get_partition_table_type /dev/nvme0n1
+++ local disk_device=/dev/nvme0n1
+++ local table_type
++++ uname -m
+++ [[ x86_64 =~ s390 ]]
+++ blkid -s PTTYPE -o value /dev/nvme0n1
++ '[' gpt = gpt ']'
++ relocate_gpt_at_end_of_disk /dev/nvme0n1
++ sgdisk -e /dev/nvme0n1
The operation has completed successfully.
++ lvm_system
++ declare kiwi_lvm=
++ '[' '' = true ']'
++ return 1
++ repart_standard_disk
++ declare kiwi_oemrootMB=
++ declare kiwi_RootPart=3

++ '[' -z '' ']'
++ local disk_have_root_system_mbytes=30697
++ local min_additional_mbytes=10
++ '[' 10 -lt 10 ']'
++ check_repart_possible 9658 21039 10
++ declare kiwi_oemrootMB=
++ local disk_root_mbytes=9658
++ local disk_free_mbytes=21039
++ local min_additional_mbytes=10
++ '[' -n '' ']'
++ '[' 10 -gt 21039 ']'
++ return 0
++ deactivate_device_mappings
++ lvm_system
++ declare kiwi_lvm=
++ '[' '' = true ']'
++ return 1
++ mdraid_system
++ declare kiwi_RaidDev=
++ '[' -n '' ']'
++ return 1
++ luks_system /dev/nvme0n1
++ declare kiwi_RootPart=3
++ local disk=/dev/nvme0n1
++ local device
+++ get_partition_node_name /dev/nvme0n1 3
+++ local disk=/dev/nvme0n1
+++ local partid=3
+++ local index=1
+++ local part
+++ udev_pending
+++ declare DEVICE_TIMEOUT=
+++ local limit=30
+++ [[ '' =~ ^[0-9]+$ ]]

+++ udevadm settle --timeout=30

++++ lsblk -p -l -o NAME,TYPE,START -x START /dev/nvme0n1
++++ cut -f1 -d ' '
++++ grep -E 'part|md$'
lsblk: unknown column: START
Try 'lsblk --help' for more information.
+++ return 1

++ device=
++ cryptsetup isLuks ''
++ return 1
++ local command_query
++ local root_part_size=+30697M
++ '[' -z '' ']'
++ root_part_size=.
++ command_query='
        d 3
        n p:lxroot 3 . .
    '
++ create_partitions /dev/nvme0n1 '
        d 3
        n p:lxroot 3 . .
    '
++ local disk_device=/dev/nvme0n1
++ local 'partition_setup=
        d 3
        n p:lxroot 3 . .
    '
++ local pt_table_type
+++ get_partition_table_type /dev/nvme0n1
+++ local disk_device=/dev/nvme0n1
+++ local table_type
++++ uname -m
+++ [[ x86_64 =~ s390 ]]
+++ blkid -s PTTYPE -o value /dev/nvme0n1

++ pt_table_type=gpt
++ case ${pt_table_type} in
++ create_gpt_partitions /dev/nvme0n1 '
        d 3
        n p:lxroot 3 . .
    '
++ local disk_device=/dev/nvme0n1
++ local 'partition_setup=
        d 3
        n p:lxroot 3 . .
    '
++ local partid
++ local part_name
++ local part_size_start
++ local part_size_end
++ local cmd_list
++ local cmd
++ for cmd in ${partition_setup}
+++ echo d
+++ tr . 0
++ cmd=d
++ cmd_list[$index]=d
++ index=1
++ for cmd in ${partition_setup}
+++ echo 3
+++ tr . 0
++ cmd=3
++ cmd_list[$index]=3
++ index=2
++ for cmd in ${partition_setup}
+++ echo n
+++ tr . 0
++ cmd=n
++ cmd_list[$index]=n
++ index=3
++ for cmd in ${partition_setup}
+++ echo p:lxroot

++ for cmd in ${partition_setup}
+++ echo p:lxroot
+++ tr . 0
++ cmd=p:lxroot
++ cmd_list[$index]=p:lxroot
++ index=4
++ for cmd in ${partition_setup}
+++ echo 3
+++ tr . 0
++ cmd=3
++ cmd_list[$index]=3
++ index=5
++ for cmd in ${partition_setup}
+++ echo .
+++ tr . 0
++ cmd=0
++ cmd_list[$index]=0
++ index=6
++ for cmd in ${partition_setup}
+++ echo .
+++ tr . 0
++ cmd=0
++ cmd_list[$index]=0
++ index=7
++ index=0
++ for cmd in ${cmd_list[*]}
++ case ${cmd} in
++ partid=3
++ sgdisk --delete 3 /dev/nvme0n1
The operation has completed successfully.
++ index=1
++ for cmd in ${cmd_list[*]}
++ case ${cmd} in
++ index=2
++ for cmd in ${cmd_list[*]}
++ case ${cmd} in

+++ tr : .
+++ echo p:lxroot
++ part_name=p.lxroot
++ partid=3
++ part_size_start=0
++ part_size_end=0
++ sgdisk --new 3:0:0 /dev/nvme0n1
The operation has completed successfully.
++ sgdisk --change-name 3:p.lxroot /dev/nvme0n1
Setting name!
partNum is 2
The operation has completed successfully.
++ index=3
++ for cmd in ${cmd_list[*]}
++ case ${cmd} in
++ index=4
++ for cmd in ${cmd_list[*]}
++ case ${cmd} in
++ index=5
++ for cmd in ${cmd_list[*]}
++ case ${cmd} in
++ index=6
++ for cmd in ${cmd_list[*]}
++ case ${cmd} in
++ index=7
++ type partprobe
++ partx -u /dev/nvme0n1
++ finalize_disk_repart
++ declare kiwi_RootPart=3
++ finalize_partition_table /dev/nvme0n1
++ declare kiwi_BootPart=3
++ declare kiwi_gpt_hybrid_mbr=
++ local disk_device=/dev/nvme0n1
++ '[' -n 3 ']'
++ activate_boot_partition /dev/nvme0n1 3

++ local disk_device=/dev/nvme0n1
++ local boot_partition_id=3
++ local pt_table_type
+++ get_partition_table_type /dev/nvme0n1
+++ local disk_device=/dev/nvme0n1
+++ local table_type
++++ uname -m
+++ [[ x86_64 =~ s390 ]]
+++ blkid -s PTTYPE -o value /dev/nvme0n1
++ pt_table_type=gpt
+++ uname -m
++ [[ x86_64 =~ i.86|x86_64 ]]
++ '[' gpt = dos ']'
++ '[' '' = true ']'
+++ get_partition_node_name /dev/nvme0n1 3
+++ local disk=/dev/nvme0n1
+++ local partid=3
+++ local index=1
+++ local part
+++ udev_pending
+++ declare DEVICE_TIMEOUT=
+++ local limit=30
+++ [[ '' =~ ^[0-9]+$ ]]
+++ udevadm settle --timeout=30

++++ lsblk -p -l -o NAME,TYPE,START -x START /dev/nvme0n1
++++ cut -f1 -d ' '
++++ grep -E 'part|md$'
lsblk: unknown column: START
Try 'lsblk --help' for more information.
+++ return 1

++ set_root_map ''
++ root_map=
++ export root_map
++ luks_system /dev/nvme0n1
++ declare kiwi_RootPart=3

++ local disk=/dev/nvme0n1
++ local device
+++ get_partition_node_name /dev/nvme0n1 3
+++ local disk=/dev/nvme0n1
+++ local partid=3
+++ local index=1
+++ local part
+++ udev_pending
+++ declare DEVICE_TIMEOUT=
+++ local limit=30
+++ [[ '' =~ ^[0-9]+$ ]]
+++ udevadm settle --timeout=30

++++ lsblk -p -l -o NAME,TYPE,START -x START /dev/nvme0n1
++++ cut -f1 -d ' '
++++ grep -E 'part|md$'
lsblk: unknown column: START
Try 'lsblk --help' for more information.
+++ return 1

++ device=
++ cryptsetup isLuks ''
++ return 1
++ mdraid_system
++ declare kiwi_RaidDev=
++ '[' -n '' ']'
++ return 1
++ lvm_system
++ declare kiwi_lvm=
++ '[' '' = true ']'
++ return 1
+++ get_root_map
+++ echo ''
++ resize_filesystem ''
++ local device=
++ test -n ''
++ return

I'm assuming that the lsblk error is the main culprit here.  But I'd like for the first case to be detected properly too.

[Gavin Lambert]

On Friday, July 4, 2025 at 1:51:24 PM UTC+12 I wrote:

It looks like maybe it's expecting some output of sgdisk that is not there?

$ sudo sgdisk --verify /dev/nvme0n1

No problems found. 43091934 free sectors (20.5 GiB) available in 2
segments, the largest of which is 43089920 (20.5 GiB) in size.

Perhaps it could compare that free sectors value against some minimum threshold to decide that it's worth resizing?  Another way to see it is (this is from a different build, so the numbers don't match exactly):

$ sudo sgdisk --print /dev/nvme0n1 | grep '^Total free space' | cut -d' ' -f5
43087838

 

Though not sure if that's safe vs. localisation.

[Raphael Traviss]

On GPT disks, there is a backup table at the end of the disk--and this is what `sgdisk` is actually checking to determine if disk geometry has changed (versus scanning the sectors themselves).

The problem is that Rufus and other tools "correctly" resize the disks--resizing geometry, and then placing the GPT backup table at the end of the disk--and then that `sgdisk` command says "Looks good" and assumes that the disk geometry hasn't changed: when in fact, the disk geometry could be very different than the size of your image.

The solution is to "incorrectly resize" your disk image, by writing an empty byte at your desired (enlarged) hard disk size, as an offset (12GB example shown):

```
dd if=/dev/zero of=/path/to/existing/image.raw bs=1 count=1 seek=$((12*1024*1024*1024-1))

``` 

That image file will now extend out to the desired size, and no GPT backup table will exist at the last byte--therefore, the `sgdisk` command will now identify the geometry as having changed, and start the resize logic.

Regards,

Raphael

[Gavin Lambert]

On Sunday, July 6, 2025 at 6:55:45 AM UTC+12 skyleaf...@gmail.com wrote:

On GPT disks, there is a backup table at the end of the disk--and this is what `sgdisk` is actually checking to determine if disk geometry has changed (versus scanning the sectors themselves).

I'm aware.  My point is that this seems unreliable and it should probably check for the number of free sectors instead.  (Which may be misleading if it's a gap in the middle of the disk, but at least the ordinary partition layout won't do that.)  Or perhaps another method.

 

The problem is that Rufus and other tools "correctly" resize the disks--resizing geometry, and then placing the GPT backup table at the end of the disk--and then that `sgdisk` command says "Looks good" and assumes that the disk geometry hasn't changed: when in fact, the disk geometry could be very different than the size of your image.

The solution is to "incorrectly resize" your disk image, by writing an empty byte at your desired (enlarged) hard disk size, as an offset (12GB example shown):

```
dd if=/dev/zero of=/path/to/existing/image.raw bs=1 count=1 seek=$((12*1024*1024*1024-1))

``` 

That image file will now extend out to the desired size, and no GPT backup table will exist at the last byte--therefore, the `sgdisk` command will now identify the geometry as having changed, and start the resize logic.

I don't see how this would help; as you say, burning this with Rufus would still write the GPT backup table correctly.  Or if you're suggesting creating new image files for each target disk size (so that there's no room for the backup table), that completely defeats the entire point of the resize on boot.

This also doesn't help with the lsblk error, which seems like a recently introduced bug.

[Marcus Schäfer]

Hi,

> I previously had OEM resizing working (as far as I recall) but
> lately it seems to be more inconsistent or not working at all, and
> I'm not sure what I changed to break it or if there's another issue.
>
> Another possibly interesting snippet from the boot logs:
> ++++ lsblk -p -l -o NAME,TYPE,START -x START /dev/nvme0n1
> ++++ cut -f1 -d ' '
> ++++ grep -E 'part|md$'
> lsblk: unknown column: START
> Try 'lsblk --help' for more information.
> +++ return 1

You opened a patch to fix this regression. Thanks much.
I was not able to reproduce this behavior on any of the NVME
devices I have here though ? Can you provide the partition
table for this device ?

sfdisk -d /dev/nvme0n1 > table

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
-------------------------------------------------------

[Marcus Schäfer]

Hi,

> The problem is that Rufus and other tools "correctly" resize the
> disks--resizing geometry, and then placing the GPT backup table at the
> end of the disk--and then that `sgdisk` command says "Looks good" and
> assumes that the disk geometry hasn't changed: when in fact, the disk
> geometry could be very different than the size of your image.

Yes, the check done in the kiwi code assumes that the original image
produced by kiwi hasn't changed by something else prior the first boot.
In this case the only action that has happened on the target was the
byte dump of the original kiwi produced image to the target device.
In this condition any geometry information still represents the image and
a comparision with the real geometry of the target disk allows to
identify this state.

If there is anything in between that "works" with the image, all
assumptions about the origin might be wrong. For such a condition you
can switch off kiwi's checks via the kernel cmdline option:

rd.kiwi.oem.force_resize

[Gavin Lambert]

On Monday, July 7, 2025 at 7:21:01 PM UTC+12 Marcus wrote:

I was not able to reproduce this behavior on any of the NVME
devices I have here though ? Can you provide the partition
table for this device ?

sfdisk -d /dev/nvme0n1 > table

I don't have access to the real device I was reproducing this on at the moment, but I get the same behaviour from taking the .raw disk file, converting to .vmdk, using VMware to expand the disk to 30GB, then booting -- it does not detect the disk size change and does not resize anything.  The same thing occurs when using Rufus to directly burn the .raw file to a larger USB drive (not an NVME drive, but still GPT).

$ sudo sgdisk --verify /dev/nvme0n1

No problems found. 43087838 free sectors (20.5 GiB) available in 2
segments, the largest of which is 43085824 (20.5 GiB) in size.

$ sudo sfdisk -d /dev/nvme0n1

GPT PMBR size mismatch (19828735 != 62914559) will be corrected by write.
label: gpt
label-id: CD759FEF-9BCC-4C8C-B0B7-D644A9363C45
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 62914526
sector-size: 512

/dev/nvme0n1p1 : start=        2048, size=        4096, type=21686148-6449-6E6F-744E-656564454649, uuid=89A0ABE3-587E-45B1-8FB2-0639FF42DC76, name="p.legacy"
/dev/nvme0n1p2 : start=        6144, size=       40960, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=0C8F6BF2-DF28-44A7-BC7D-656229849F65, name="p.UEFI"
/dev/nvme0n1p3 : start=       47104, size=    19781599, type=4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709, uuid=B564D9F9-51A5-49DE-B0B3-5B15B1736872, name="p.lxroot"

> rd.kiwi.oem.force_resize

I noticed that setting, but the docs say that this will make it resize (and change partition UUIDs) on every boot, and I'd prefer these were more stable.

Also, currently (due to the lsblk regression presumably), specifying this makes it resize the partition but not the filesystem.  Output after reboot:

$ sudo sfdisk -d /dev/nvme0n1

GPT PMBR size mismatch (19828735 != 62914559) will be corrected by write.
label: gpt
label-id: CD759FEF-9BCC-4C8C-B0B7-D644A9363C45
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 62914526
sector-size: 512

/dev/nvme0n1p1 : start=        2048, size=        4096, type=21686148-6449-6E6F-744E-656564454649, uuid=89A0ABE3-587E-45B1-8FB2-0639FF42DC76, name="p.legacy"
/dev/nvme0n1p2 : start=        6144, size=       40960, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=0C8F6BF2-DF28-44A7-BC7D-656229849F65, name="p.UEFI"
/dev/nvme0n1p3 : start=       47104, size=    62867423, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=321AD0E0-FEAE-46BC-BC6A-0BB28B1F510C, name="p.lxroot"

Contrary to what the docs seemed to be saying, after yet another reboot the output (and uuid) stayed the same.  So maybe keeping that set permanently is ok, once the lsblk issue is fixed.

One other thing that I noticed and am not sure if it's intended: if I run sudo dracut -f in the installed OS, it does not include any of the kiwi modules by default, so on subsequent reboots they're completely ignored.  When the resizing works I guess this might be ok to have it essentially single-shot, but given that it logs "System resize is active on every reboot", I thought it was intended to keep running.  Shouldn't it drop something into /etc/dracut.conf.d/ or are we expected to do that ourselves?

[Marcus Schäfer]

Hi,

> I don't have access to the real device I was reproducing this on at the
> moment, but I get the same behaviour from taking the .raw disk file,
> converting to .vmdk, using VMware to expand the disk to 30GB, then
> booting -- it does not detect the disk size change and does not resize
> anything. The same thing occurs when using Rufus to directly burn the
> .raw file to a larger USB drive (not an NVME drive, but still GPT).
> $ sudo sgdisk --verify /dev/nvme0n1
> No problems found. 43087838 free sectors (20.5 GiB) available in 2
> segments, the largest of which is 43085824 (20.5 GiB) in size.

Yeah the tools used in this procedure corrects the "mistake" :)

> $ sudo sfdisk -d /dev/nvme0n1
> GPT PMBR size mismatch (19828735 != 62914559) will be corrected by

Yes same, here

> > rd.kiwi.oem.force_resize
>
> I noticed that setting, but the docs say that this will make it resize
> (and change partition UUIDs) on every boot, and I'd prefer these were
> more stable.

This is correct, we try to resize with every boot, the tools called
in this procedure find out in a row that there is nothing to do if
the geometry hasn't changed and completes very fast without performing
a change. I consider it safe but I also wanted to have a safe and simple
check that allows us to know that we don't have to even call them.

So I also aim for a stable solution but so far I'm running out of ideas.
Before I coded that "trick" with checking on the location of the backup
GPT, we had code that checks if there is a gap between the address of
the last partition in the table and the end of disk. But this check
can be misleading too because I remember users who wanted a gap there
and complained that the resize code "fixes" it.

However, I believe it's better to improve the check for unallocated_space
and maybe add another option to skip parts of it when needed.

I'm very happy to discuss other ideas

Thoughts ?

> One other thing that I noticed and am not sure if it's intended: if I
> run sudo dracut -f in the installed OS, it does not include any of the
> kiwi modules by default, so on subsequent reboots they're completely
> ignored.

Yes this is an intentional behavior. in general the kiwi intrd code
is setup to do the job when needed and then can be dropped.
When producing a host-only initrd via either "dracut -f" or by a
package that calls it, usally no extra kiwi code is required anymore.

The resize code forms an exception in a way that it can also be
useful during the lifetime of the image but you need to express
that this is wanted. You can stick with the module by adding an
overlay file in your image description like this:

root/etc/dracut.conf.d/kiwi-resize.conf

with the content:

add_dracutmodules+=" kiwi-repart "

There are so many different tools and ways to resize the system,
kiwi is just one opportunity and we wanted that users who requests
it need to do it explicitly, such that debugging shows it as a
setup for dracut. We also don't wanted the kiwi initrd code to be
in conflict with others. Hope this makes sense to you too

[Gavin Lambert]

On Tuesday, July 8, 2025 at 8:30:41 PM UTC+12 Marcus wrote:

> $ sudo sfdisk -d /dev/nvme0n1
> GPT PMBR size mismatch (19828735 != 62914559) will be corrected by

Yes same, here

Interestingly, this warning remained after the kiwi-repart successfully resized the partition (as shown above).  Possibly a difference between sfdisk and whatever tool kiwi is using internally?

However, I believe it's better to improve the check for unallocated_space
and maybe add another option to skip parts of it when needed.

Yes, that'd be good.  Using the force_resize option works for me for now since it appears that it will later fail the "check_repart_possible" check and not actually change anything, but I think it would be better to have an explicit unallocated space check (probably with some kind of "minimum unallocated space required to repart" setting, to account for small and/or deliberate gaps).  The check for misplaced backup table is a good indicator but not quite sufficient by itself.

Yes this is an intentional behavior. in general the kiwi intrd code
is setup to do the job when needed and then can be dropped.
When producing a host-only initrd via either "dracut -f" or by a
package that calls it, usally no extra kiwi code is required anymore.

Makes sense in retrospect, but perhaps worth mentioning in the docs?  I wasted a bit of time wondering why rd.kiwi.debug mysteriously stopped generating the log file (because the modules were no longer loaded).

 

root/etc/dracut.conf.d/kiwi-resize.conf

with the content:

add_dracutmodules+=" kiwi-repart "

FWIW that's not quite sufficient by itself.  I'm not sure if both of these are needed but copying from the command that kiwi itself uses during the build I ended up with this:

add_dracutmodules+=" kiwi-repart "
install_optional_items+=" /.profile /config.partids "

[Marcus Schäfer]

Hi,

> Yes, that'd be good. Using the force_resize option works for me for
> now since it appears that it will later fail the
> "check_repart_possible" check and not actually change anything

right

>, but I
> think it would be better to have an explicit unallocated space check
> (probably with some kind of "minimum unallocated space required to
> repart" setting, to account for small and/or deliberate gaps). The
> check for misplaced backup table is a good indicator but not quite
> sufficient by itself.

agreed and on my list of things to look at

> Makes sense in retrospect, but perhaps worth mentioning in the docs?

The docs can really need some love :) Would you mind to come up
with a PR that adds this information as you would expect it ?
I'm asking because you are right now facing the issue and that
is usually the best condition for a doc change.

> FWIW that's not quite sufficient by itself. I'm not sure if both of
> these are needed but copying from the command that kiwi itself uses
> during the build I ended up with this:
> add_dracutmodules+=" kiwi-repart "
> install_optional_items+=" /.profile /config.partids "

That problem we fixed some time ago. See.

https://github.com/OSInside/kiwi/pull/2604

Seems like you are on an older code base with this ?

[Marcus Schäfer]

Hi Gavin,

> >, but I
> > think it would be better to have an explicit unallocated space check
> > (probably with some kind of "minimum unallocated space required to
> > repart" setting, to account for small and/or deliberate gaps). The
> > check for misplaced backup table is a good indicator but not quite
> > sufficient by itself.
>
> agreed and on my list of things to look at

I made a first patch to address this here:

https://github.com/OSInside/kiwi/pull/2851

Would you mind to review the code or give it a test ?

Thanks much

[Gavin Lambert]

On Wednesday, July 9, 2025 at 8:25:25 PM UTC+12 Marcus wrote:

That problem we fixed some time ago. See.

https://github.com/OSInside/kiwi/pull/2604

Seems like you are on an older code base with this ?

I'm on the latest release in the 15.6 download repo (otherwise I wouldn't have hit the lsblk issue, since that was triggered by a recent change).

I don't recall the exact text, but I had a call to dracut -f in my config.sh and that (after adding the dracut.conf.d file) triggered a warning/error that a file was missing and that it would not install kiwi-repart.  The build continued after that and the module did actually get installed due to kiwi running dracut again itself later.  Adding the extra line to the conf file fixed that.  I've since removed the line from my config.sh as it was redundant, so I'm not getting the error any more anyway.

> I made a first patch to address this here:

> 
> https://github.com/OSInside/kiwi/pull/2851
> 
> Would you mind to review the code or give it a test ?

Since I'm mostly using release builds I probably won't be able to test it until that gets released, but a look at the code suggests it might not behave as intended.  As previously mentioned the warning about "GPT PMBR size mismatch" does not disappear after resizing, so this will always skip the subsequent check and basically behave as if the force_resize flag had been used.  Which is still perhaps an improvement on not resizing at all, but I doubt this was intended.

Also I'm not sure a test for 0 unallocated sectors is ideal; while that did succeed in my default-partition-layout test (after successful resize) there might be people with deliberate gaps or other oddities that would like to specify a minimum size.  Though perhaps this doesn't matter too much as this is just an early filter prior to the check_repart_possible check.