regression: ks.cfg can't be fetched from any non-first partition of installation media (ESP, OEMDRV, etc.)

[bam80]

Original report:
https://bugzilla.redhat.com/show_bug.cgi?id=2346192

Proposed solution:

1. apply fix fetching kickstarts from OEMDRV rhinstaller/anaconda#6222
2. as discussed, change inst.stage2 option from:
   inst.stage2=hd:LABEL=<ISO label>
   to:
   inst.stage2=hd:/dev/disk/by-partlabel/ISO9660
   Or introduce ${isopartlabel} expansion in the template and use it here instead of the hardcoded ISO9660.

The inst.stage2 option is apparently declared here:

lorax/share/templates.d/99-generic/efi.tmpl

Line 47 in 1d685c9

replace @ROOT@ 'inst.stage2=hd:LABEL=${isolabel|udev}' ${eficonf}

I didn't find where the ISO9660 PARTLABEL comes from, but it seems stable.

@poncovka @bcl

[bcl]

I don't think that it's safe to lock that into ISO9660, especially without knowing where it comes from.

Also, I see from the linked bugzilla that this is related to you adding a kickstart file to the iso -- FWIW you can use the mkksiso tool from lorax to recreate the iso with the kickstart placed inside the iso insead of the manual method you are using to add it to the EFI partition.

[bam80]

I don't think that it's safe to lock that into ISO9660, especially without knowing where it comes from.

I hoped you know where it comes from and can suggest better placeholder. But I can investigate it if you don't.

Using mkksiso is overkill for this task, as when you burn the .ISO to SD or USB disk (most real use-cases), the embedded writable ESP partition gets accessible without any special tools, so it's most natural way of providing the ks.cfg.

Can we reopen the issue?

[bcl]

No. I'm not going to hardcode ISO9660. Your best bet is to either use mkksiso or work with anaconda to figure out how to mount the partition.

[bam80]

Again, there is no need to hardcode ISO9660.
We just need to find a way to get PARTLABEL of the ISO partition and set it in the placeholder.
Do you have an idea maybe?

I'll provide the patch for anaconda but the second part should be addressed here, as said in the OP.

[bam80]

Anaconda's part of the fix:
rhinstaller/anaconda#6222

[bam80]

Also, I see from the linked bugzilla that this is related to you adding a kickstart file to the iso

@bcl
To be more precise, I added a kickstart file not to the iso, but to ESP partition of the installation media burnt with the ISO.
But as the same bug applies to any non-ISO partition of the installation media, OEMDRV including, Anaconda Kickstart Documentation you wrote is currently broken too:

Automatically load the Kickstart file

If you need to load Kickstart file automatically you can store your Kickstart file as /ks.cfg into the storage device which is accessible during the boot process and is labeled as OEMDRV. Such a device is automatically discovered during boot and the Kickstart file will be used.

As a possible solution, could we think of adding expansion of ${isopartlabel} along with the ${isolabel} to a template here?