> > You mentioned that wiping out older or addditional LUNs is not an option.
> > And I think it's not needed, only thought about wiping the LUNs for the OS

> > itself and only enable this OS LUN during installaltion. 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 ...)

> That would require disabling zfcp auto lun scan during installation
> [zfcp.allow_lun_scan=0]. I intentionally did not suggest this as
> changing the host-mapping of volumes on the storage is cleaner and does
> not change the scanning behavior of Linux. That said, it would be an
> option.
ok, I see and agree

> > And make sure the parm file is in the correct encoding (fix length "F 80" or
> > variable, "Trunc=80"):
> > PARMFILE UBUNTU   O1  F 80  Trunc=80 Size=4 Line=0 Col=1 Alt=0

> I'm not sure it needs fixed record length under z/VM. I use variable record > length for parm files successfully in my z/VM guests.
> In contrast to that, the binaries for kernel and initrd must indeed be fixed > record length 80.
Does not need to be fix 80 (like I wrote variable is also fine).
I just transfer it similar to kernel and initrd - and just switch from bin to ascii ...

> > The 3 dashes (" --- ") are to separate installer from kernel arguments.
> > "<installer> --- <kernel>"

> As stated recently, the kernel documentation says the separator is a
> double dash and kernel parameters go before the separator and user space
> stuff after it. I'm confused.
The three dashes are in/for Debian and Ubuntu.

> > At the early boot stage it's about "interactive netboot" and asks for
> > network information only
> > and all network devices are qeth (of course except RoCE) - so don't specify
> > any other devices here (like HBAs or LUNS)'or whatever).

> good info, I wasn't aware; then it should explicitly state so [see
> earlier comments from today]
Ok, thought it's obvious, since it states netboot (but I may have been blind...) - we'll consider changing the text ...

> > I believe that the content of the kernel parameter with all the "@" is more
> > a representaton issue (nevertheless, not very nice though ...), but since it
> > works for me on my system - and even with much more kernel args that are
> > needed in case of a fully non-interactive "autoinstall".

> ok, but this can confuse users (or even init/systemd) so it would be
> good to find the root cause and fix that as well (with lower prio than
> the actual installation issue)
I totally agree, I am pretty sure that this is an upstream issue, maybe introduced with the recent extention of the kernel arg space.
So I need to discuss this with IBM/Boris ..

> > What I noticed in the crash file is the following snippet:
> > "
> > 2023-04-06 19:17:21,139 DEBUG subiquitycore.utils:77 run_command ['udevadm',
> > 'settle', '-t', '0'] exited with code 0

> > 2023-04-06 19:17:21,143 INFO subiquity.common.errorreport:406 saving crash
> > report 'unknown error crashed with OSError' to

> yes, I've been pointing to this multiple times and it even occurs early
> for settling after the network interface (IP address) setup and before
> any zfcp device config
Since it's python the error is propagated up, hence I 'assume' it might not be udev related rather than asyncio - but just a wild guess here.

> > That could be a problem with asyncio (I remember that there was an issue
> > with asyncio in the past) or a race condition.
> > I'll ask my installer colleague to have a look at this ...

> looking forward
+1