https://bugzilla.suse.com/show_bug.cgi?id=1198457 https://bugzilla.suse.com/show_bug.cgi?id=1198457#c28 --- Comment #28 from Lee Duncan --- (In reply to Fabian Vogt from comment #27)

Looking at this bug and its internal sibling (bsc#1194903) I'm a bit lost what the current state is. Did After=local-fs.target work?

That other bug turned out not to be an issue once updated code was tested. We never did try adding "After=local-fs.target". Trying to chase which systemd unit(s) must be or not be waited for is like playing whack-a-mole -- it's a never-ending battle. So I'm loath to change those settings. I'm more likely to do away with this silly "create the initiator name file if it doesn't exist" service, which was created upstream. We should not need it.

It's possible that this is the usual btrfs filesystem-wide read-only race which can make /var (needed for /etc) read-only temporarily during boot. I couldn't find any evidence for that in the journal though.

(In reply to Lee Duncan from comment #24)

...

I have an RPM bundle for x86_64 Factory (same code as Leap 15.3), if you would like to try it. Just let me know.

I have submitted an update to Factory that restores earlier behavior of setting the initiatorname file on RPM installation.

Once accepted in Factory I will submit to SLE-15-SP3 and SLE-15-SP4.

This means that all systems deployed with the image will have the same initiator name. That sounds like it will cause issues at some point.

No, it does not mean that. The initiator name is generated using a random seed, so theoretically each and every IQN will be different. It's the exact same mechanism that iscsi-init.service uses to create an IQN (initiator name) if one is not present. Note that an updated open-iscsi package has been submitted to SLE-15-SP3. See https://build.suse.de/request/show/273085 -- You are receiving this mail because: You are on the CC list for the bug.