I did some more investigations anyway, and discovered: "It is not a bug, it is a feature"!
__________________ Steps to reproduce: ================== - In Virutalbox, start a new test machine - Install a fresh 20.04 (minimal install is enough, and I did it in my 20GB RAM disk, it's faster!) - sudo update/upgrade - stop the VM Now on the network configuration of you VM which defaults to NAT, go to advance and "unplug" the cable. That will create (don't ask me why!) a 7.5 sec delay on network start, simulating almost what I have on my real network. - Start the VM - Look at the systemd-analyze plot (file attached) - "Replug" the cable (you can do it without restarting) - Install open-isci - Create a node (discover, or what I did is copy my nodes configuration to the VM) - Stop the VM - "Unplug" the cable - Start again - Look again at systemd-analyze plot (file attached) What you see is that in the first case "Network-manager-online-wait and "Plymouth-quit-wait" clearly overlap, allowing a lot of the session services to start without waiting for the network. On the second graph you see that they do NOT overlap and Plymouth-quit-wait waits until the end of the 7.5 seconds timeout to kick in, with the rest of the session services. The total difference is not 7.5 sec in this case because due to VirtualBox, it benefits from the "7.5 sec" wait to launch some VM related services. So the end difference is rather about 3 or 4 seconds for no iscsi mounts (since none are automatic) So I guess there is indeed a relation that I don't see when you have iscsi WITH some nodes (without any nodes, indeed systemd does not even try to start iscsi) that instructs Plymouth to be run only after some successor of iscsid. I guess this is "work as design" because the expectation is that since you have some nodes (although none are marked as "automatic"!) they are supposed to be needed by the user-session so there must be somewhere an instruction to "wait"... This assumption is wrong in my case, so I don't need the "work as designed" behaviour. Since there is no "fancy configuration" to say to iscsi that he got the wrong assumption, I guess my workaround is also the simplest way to tell it! QED ** Attachment added: "VM Clean 20.04 startup with iscsi DISABLED" https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1882986/+attachment/5384542/+files/startup_iscsi2.svg -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1882986 Title: open-iscsi is slowing down the boot process To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1882986/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
