PXE initrd is bound to image

Jellyfrog commented 4 years ago

Problem description

When using the installpxe option, the pxe initd it generates is bound to the image its created with.
the file /.profile contains image "unique" data:

kiwi_align='1048576'
kiwi_bootloader='grub2'
kiwi_cmdline='splash'
kiwi_displayname='JeOS-test'
kiwi_firmware='uefi'
kiwi_iname='JeOS-test'
kiwi_initrd_system='dracut'
kiwi_install_volid='INSTALL'
kiwi_iversion='5.0.0'
kiwi_keytable='sv-latin1.map.gz'
kiwi_language='en_US'
kiwi_loader_theme='SLE'
kiwi_oemdevicefilter='/dev/ram'
kiwi_oemunattended='true'
kiwi_revision='db0ce8552c94bf5c11799c50edd4cc9ab17b9e65'
kiwi_sectorsize='512'
kiwi_startsector='2048'
kiwi_timezone='UTC'
kiwi_type='oem'

Which comes directly from my oemconfig:

<oemconfig>
  <oem-unattended>true</oem-unattended>
  <oem-swap>true</oem-swap>
  <oem-device-filter>/dev/ram</oem-device-filter>
  <oem-multipath-scan>false</oem-multipath-scan>
</oemconfig>

the file /config.bootoptions also contains "unique" data:

splash root=UUID=516ef94d-127c-4e61-bc2d-c34ac25fd389 rw

This means that the pxe initrd can't (sometimes) be used to boot another image than the one it was created with, also the oemconfig is bound to one specific image.

Expected behaviour

The PXE initrd shouldn't contain any image unique data

Steps to reproduce the behaviour

Create image with installpxe=true

OS and Software information

KIWI version: 9.19.6
Operating system: SLES12-SP4
OBS version: 2.9

schaefi commented 4 years ago

I'm currently looking into this. One thing I noted is that the information from the oemconfig section is not image specific but basically deployment specific. In a PXE environment the oemconfig setup specifies the scope of the deployment, e.g add swap, or ignore ramdisk devices, etc etc. Those settings control the behavior of the initrd for the deployment process and are optional anyway. This means it's in your hands at this point how it should behave. I'm not going to change that part unless there are objections.

The other issue concerning the fixed cmdline parameter list that gets stored in the initrd really makes it image specific which I'm going to find a better solution. However I'm not sure if it can be done without a behavior change... still thinking

schaefi commented 4 years ago

My current idea is

to allow to read an optional config file that contains the boot options used for the kexec call that boots the dumped image. If that file is not present the built in defaults apply.
Alternatively we can drop config.bootoptions and create this as an extra config file which will be part of the result pxe archive. The boot code would then require this file to be present in order to boot the dumped image because it has to contain at least the root reference.

In the first case the initrd contains image specific information but they can be overwritten. In the second case the initrd does not contain any image specific information but requires those to be provided as a config file. We would create that config file for the connected image as part of the pxe tarball and would also need to update the documentation.

@davidcassany what do you think ?

schaefi commented 4 years ago

The open pull request implements variant b) I think with our commitment to a more generic use of the PXE case which is mostly a customer specific environment it doesn't make sense to have a fallback bootconfig still inside of the initrd. Let me know what you think. Thanks

davidcassany commented 4 years ago

Yes I am also in favor of option b. I like the idea of removing image and description specific configuration files form the initrd. I am just wondering how is this provided then, by downloaded from the PXE server? this is what I'd do, gonna check the PR in short.

schaefi commented 4 years ago

I am just wondering how is this provided then, by downloaded from the PXE server?

yes, see the PR that should make it clear, also from a doc perspective. Thanks much

OSInside / kiwi