Comment 42 for bug 2009141

------- Comment From <email address hidden> 2023-04-19 08:20 EDT-------
(In reply to comment #41)
> 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.

> 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.

> 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.

> 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]

> 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)

> 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

> 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