Comment 47 for bug 2009141

At '<email address hidden>' - nah, that's not what I'm saying, things are (historically) a bit more complex:

So there is '--' vs '---', whereas Kernel uses everything until '--' and userspace uses everything.

Back in the early Debian-Installer days, d-i used '--' to separate things (for use in installed & installer system vs use in the installer only). When systemd & kernel had a spat, and kernel started to use '--' separator, Debian was forced to change to something else and started to use '---'. So both '--' and '---' have their use case today.
Notice this example:
debug -- systemd.log_level=info --- systems.log_level=debug
Which will have all three on for installer system, propagate the first two to the installed system, with kernel itself only considering the first option.
Because of historical usage of '--' and the conflict that Debian had to yield '--' to kernel.
Depending on the age of the docs one may find in the documentation, info might be outdated or wrong, hence confusing.

Some more references:

https://docs.kernel.org/admin-guide/kernel-parameters.html
The kernel parses parameters from the kernel command line up to “--“; if it doesn’t recognize a parameter and it doesn’t contain a ‘.’, the parameter gets passed to init: parameters with ‘=’ go into init’s environment, others are passed as command line arguments to init. Everything after “--” is passed as an argument to init.

https://d-i.debian.org/manual/en.s390x/install.en.pdf
A “---” in the boot options has special meaning. Kernel parameters that appear after the last “---” may be copied
into the bootloader configuration for the installed system (if supported by the installer for the bootloader).
The installer will automatically filter out any options (like preconfiguration options) that it recognizes.

https://man7.org/linux/man-pages/man1/init.1.html

(kudos to xnox)

At <email address hidden>:

I barely remember that there were changes in the LVM meta data in the past, hence a relatively new installer (22.04.x) might have trouble with an somewhat older 20.04.5 - so 'could'be ...
(Hence my suggestion to wipe an old LUN with potentially old data - which is in your multi-LUN, multi-OS setup not what you want.)

And yes the 'No space' left is due to the amount of crash files.

"The expectation is to not have to unmap other OS luns with LVM configs from a host, in order for a single OS lun be discovered for an install to be successful."

Sure, just note that I'm currently trying to find a workaround to unblock you in the first instance ...

"
Reducing config to having a single OS lun discovered at install, seems to be a take away in functionality

>Any additional LUNs can be easily added post-install and should not be enabled at >install time (here, for testing and to be on the safe side).
> (I think that's easier compared to disabling them on the SAN side ...)

This adds an additional step, while also requiring to update the initramfs and reboot, if the updated configuration needs to be persistent across follow-on reboots
"

I don't think that is is too bad, since it only means shifting the enablement of the LUNs that you don't want to touch and only integrate, from install time to post install.
And post install it's only a chzdev command, which (since a couple of Ubuntu releases, via a hook) automatically triggers a rebuild of the initramfs, so makes your changes persistent - so no need to do that manually or reboot.