| === arif-ali_ is now known as arif-ali | ||
| cpaelzer | blackboxsw: falcojr: FYI related to the lp issues that I pointed you to yesterday https://github.com/virt-manager/virt-manager/issues/359 | 06:43 |
|---|---|---|
| ubottu | Issue 359 in virt-manager/virt-manager "`--cloud-init` with Ubuntu 20.04 also requires `--sysinfo system.serial='ds=nocloud'`" [Open] | 06:43 |
| cpaelzer | ph I see it is even mentioned inth e description, so I guess you are aware | 06:43 |
| === arif-ali_ is now known as arif-ali | ||
| === arif-ali_ is now known as arif-ali | ||
| falcojr | thanks! | 14:16 |
| blackboxsw | falcojr: 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 |
| ubottu | Pull 1281 in canonical/cloud-init "Check for existing symlink while force creating symlink" [Open] | 16:50 |
| blackboxsw | I'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 |
| falcojr | yeah, if a datasource ever changes, this will fail | 17:00 |
| paride | falcojr, blackboxsw, I'm EOD so I can't really check, but I saw a couple of cloud-init-daily recipe build failures | 18:12 |
| paride | well I guess you also received those emails given that we sorted out the mailing list thing | 18:13 |
| blackboxsw | paride: +1 I see that's a ubuntu/daily merge problem, should be able to fix that now | 21:58 |
| blackboxsw | falcojr: I was able to reproduce the error with virt-install with ds-id not detecting datasource during early boot on kvm. | 21:58 |
| blackboxsw | checking failure path now to see if it is also reflected in https://bugs.launchpad.net/cloud-images/+bug/1940791 | 21:59 |
| ubottu | Launchpad bug 1940791 in cloud-init "sr0 not available causes cloud-init.target not run on focal cloud image" [Undecided, Incomplete] | 21:59 |
| blackboxsw | which 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 type | 22:00 |
| falcojr | blackboxsw: does the device have the cidata label? | 22:01 |
| blackboxsw | falcojr: yep /dev/disk/by-label/cidata | 22:02 |
| blackboxsw | lrwxrwxrwx 1 root root 9 Feb 24 21:56 /dev/disk/by-label/cidata -> ../../sr0 | 22:02 |
| blackboxsw | just not seen during generator | 22:03 |
| blackboxsw | just not seen during generator timeframe for some reason | 22:03 |
| blackboxsw | checking journalctl timing for mounts of sr0 | 22:03 |
| falcojr | blackboxsw: gotcha. Using the virt-installer reproduction, I don't get a cidata label on the device | 22:04 |
| blackboxsw | falcojr: does running DI_LOG=stderr /usr/lib/cloud-init/ds-identify --force on your system show ISO9660_DEVS=/dev/sr0=cidata | 22:06 |
| blackboxsw | after boot completes | 22:06 |
| falcojr | blackboxsw: no, it's empty | 22:06 |
| blackboxsw | ahh interesting ok different failure modes | 22:07 |
| blackboxsw | my 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 |
| falcojr | yep, that sounds like what other people are seeing too, so glad you see it | 22:09 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!