Support install disk overwrite per cmdline

[schaefi]

Allow install disk overwrite from cmdline

Add rd.kiwi.oem.installdevice=DEVICE. Configures the disk device that should be used in an OEM installation. This oerwrites any other oem device setting, e.g device filter or maxdisk and just continues the installation on the given device. However, the device must exist and must be a block special.

[schaefi]

cool, thanks for the review. As this is initrd code I'm always a bit concerned and therefore I also like to have two people approving. @davidcassany could you have a short look if you see something problematic ? I think we are good though. Thanks

[davidcassany]

Looks good to me.

Just a comment regarding the current logic. From lines

kiwi/dracut/modules.d/90kiwi-dump/kiwi-dump-image.sh

Lines 138 to 152 in 488be00

	if [ -z "${kiwi_oemunattended_id}" ];then
	# unattended mode requested but no target specifier,
	# thus use first device from list
	echo "${device_array[0]}"
	else
	# unattended mode requested with target specifier
	# use this device if present
	local device
	for device in ${device_array[*]}; do
	if [[ ${device} =~ ${kiwi_oemunattended_id} ]];then
	echo "${device}"
	return
	fi
	done
	fi

I understand that oem-unattended-id element from the XML will always have precedence over rd.kiwi.oem.installdevice , I am not sure this is intended. In general, my expectation as a user would be that runtime choices in kernel command parameters overwrite buildtime choices coming from the XML, so that the same image build turns to be usable in a wider range of use cases.

Note this is arguable, as setting oem-unattended-id in XML already assumes a great knowledge of the deployment environment before.

[davidcassany]

Looks great 👍

[schaefi]

I'm going to submit a Staging kiwi including this change. Our integration testing will rebuild and we can do some in depth tests with the image from here:

• https://build.opensuse.org/package/show/Virtualization:Appliances:Images:Testing_x86:tumbleweed/test-image-disk

[schaefi]

my tests were successful. I tested:

• normal operation, no regression found
• with rd.kiwi.oem.installdevice=/dev/foo ends with expected error message on the console
• with rd.kiwi.oem.installdevice=/dev/sda installs like in normal case because my qemu disk appears as /dev/sda
• with rd.kiwi.oem.installdevice=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001 installs like in normal case because ata-QEMU_HARDDISK_QM00001 -> ../../sda

If you have more specific tests in my mind just try them with the proposed integration test. Thanks

[e-minguez]

my tests were successful. I tested:

• normal operation, no regression found
• with rd.kiwi.oem.installdevice=/dev/foo ends with expected error message on the console
• with rd.kiwi.oem.installdevice=/dev/sda installs like in normal case because my qemu disk appears as /dev/sda
• with rd.kiwi.oem.installdevice=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001 installs like in normal case because ata-QEMU_HARDDISK_QM00001 -> ../../sda

If you have more specific tests in my mind just try them with the proposed integration test. Thanks

Just in case it would be nice to test installing it into a 'second' hard disk such as /dev/sdb to verify that it doesn't use the default one :) Thanks!

[schaefi]

Just in case it would be nice to test installing it into a 'second' hard disk such as /dev/sdb to verify that it doesn't use the default one :) Thanks!

yep good idea. I did this as follows

qemu-img create mydisk_a 20g
qemu-img create mydisk_b 20g

kvm -cdrom kiwi-test-image-disk.x86_64-1.42.1-Build62.13.install.iso -hda mydisk_a -hdb mydisk_b -boot d

and on the cmdline:

rd.kiwi.oem.installdevice=/dev/sdb

then after halt

kvm -hda mydisk_b

• and it boots with the system deployed to the second disk
• the device switch via hda and hdb does not impact the system boot as the UUID of the deployed root device did not change, so it's still safe to deploy a target using its unix node name even if that is not a persistent device name

So I think it does what we wanted it to do :)