/srv/irclogs.ubuntu.com/2022/02/24/#cloud-init.txt

=== arif-ali_ is now known as arif-ali
cpaelzerblackboxsw: falcojr: FYI related to the lp issues that I pointed you to yesterday https://github.com/virt-manager/virt-manager/issues/35906:43
ubottuIssue 359 in virt-manager/virt-manager "`--cloud-init` with Ubuntu 20.04 also requires `--sysinfo system.serial='ds=nocloud'`" [Open]06:43
cpaelzerph I see it is even mentioned inth e description, so I guess you are aware06:43
=== arif-ali_ is now known as arif-ali
=== arif-ali_ is now known as arif-ali
falcojrthanks!14:16
blackboxswfalcojr: holmanb this PR is related to the recent changes that we landed for the /run/cloud-init/cloud-id-<cloud> file. https://github.com/canonical/cloud-init/pull/1281 16:50
ubottuPull 1281 in canonical/cloud-init "Check for existing symlink while force creating symlink" [Open]16:50
blackboxswI'm concerned that this failure path may be likely worth another release and/or worth adding a fix for this issue to the SRU. I'll look through this PR now in earnest.16:51
falcojryeah, if a datasource ever changes, this will fail17:00
paridefalcojr, blackboxsw, I'm EOD so I can't really check, but I saw a couple of cloud-init-daily recipe build failures 18:12
paridewell I guess you also received those emails given that we sorted out the mailing list thing18:13
blackboxswparide: +1 I see that's a ubuntu/daily merge problem, should be able to fix that now21:58
blackboxswfalcojr: I was able to reproduce the error with virt-install with ds-id not detecting datasource during early boot on kvm.21:58
blackboxswchecking failure path now to see if it is also reflected in https://bugs.launchpad.net/cloud-images/+bug/194079121:59
ubottuLaunchpad bug 1940791 in cloud-init "sr0 not available causes cloud-init.target not run on focal cloud image" [Undecided, Incomplete]21:59
blackboxswwhich I think it is. If it's the same failure path it's likely likely a duplicate. Though I'll try seeing if there is anything else we need to do from ds-id standpoint to better understand the race that ds-id loses on kvm for this device type22:00
falcojrblackboxsw: does the device have the cidata label?22:01
blackboxswfalcojr: yep /dev/disk/by-label/cidata22:02
blackboxswlrwxrwxrwx 1 root root 9 Feb 24 21:56 /dev/disk/by-label/cidata -> ../../sr022:02
blackboxswjust not seen during generator22:03
blackboxswjust not seen during generator timeframe for some reason22:03
blackboxswchecking journalctl timing for mounts of sr022:03
falcojrblackboxsw: gotcha. Using the virt-installer reproduction, I don't get a cidata label on the device22:04
blackboxswfalcojr: does running DI_LOG=stderr /usr/lib/cloud-init/ds-identify --force  on your system show ISO9660_DEVS=/dev/sr0=cidata22:06
blackboxswafter boot completes22:06
falcojrblackboxsw: no, it's empty22:06
blackboxswahh interesting ok different failure modes22:07
blackboxswmy boot doesn't see it at /run/cloud-init/ds-identify.log timeframe but running on the system later the mount is up and we can properly detect it.22:07
falcojryep, that sounds like what other people are seeing too, so glad you see it22:09

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!