[06:18] <ming> Hi, I have a question about cloud-init working with ubuntu 22.04 QEMU image
[06:19] <ming> created a simple user-data
[06:19] <ming> #cloud-config
[06:19] <ming> runcmd:
[06:19] <ming>  - [ sh, -c, 'echo ==== $(date) ====; echo HI WORLD; echo =======' ]
[06:19] <ming> cloud-localds -H  user-data.img basic
[06:21] <ming> qemu-system-x86_64 -smp 8 -m 6G -nographic -net nic -net user,hostfwd=tcp::2222-:22 -drive file=./ubuntu-2204.qcow2,if=virtio -drive file=./user-data.img,if=virtio,media=cdrom
[06:21] <ming> however, cloud-init script seems not executed at all
[06:22] <ming> when I login to the VM and cat /var/log/cloud-init-output.log
[06:22] <ming> I cannot get this "HI WORLD" string
[06:22] <ming> may I know what I am missing?
[06:22] <ming> I tried many other things within the user-data. Nothing works for me.
=== ming is now known as ming33897
[06:31] <meena> ming33897: what does your log say?
[06:39] <ming33897> at login, I noticed this 4 lines:
[06:39] <ming33897> cloud-init[912]: Cloud-init v. 22.3.4-0ubuntu1~22.04.1 running 'modules:config' at Tue, 2.
[06:39] <ming33897> [   77.022613] cloud-init[924]: Cloud-init v. 22.3.4-0ubuntu1~22.04.1 running 'modules:final' at Tue, 24 Jan 2023 06:38:40 +.
[06:39] <ming33897> [   77.794753] cloud-init[924]: Cloud-init v. 22.3.4-0ubuntu1~22.04.1 finished at Tue, 24 Jan 2023 06:38:42 +0000. Datasourcs
[06:39] <ming33897> [   77.800064] cloud-init[924]: 2023-01-24 06:38:42,126 - cc_final_message.py[WARNING]: Used fallback datasource
[06:40] <ming33897> Cloud-init v. 22.3.4-0ubuntu1~22.04.1 running 'init-local' at Tue, 24 Jan 2023 06:38:09 +0000. Up 44.78 seconds.
[06:40] <ming33897> Cloud-init v. 22.3.4-0ubuntu1~22.04.1 running 'init' at Tue, 24 Jan 2023 06:38:12 +0000. Up 48.48 seconds.
[06:40] <ming33897> ci-info: ++++++++++++++++++++++++++++++++++++++Net device info++++++++++++++++++++++++++++++++++++++
[06:40] <ming33897> ci-info: +--------+------+----------------------------+---------------+--------+-------------------+
[06:40] <ming33897> ci-info: | Device |  Up  |          Address           |      Mask     | Scope  |     Hw-Address    |
[06:40] <ming33897> ci-info: +--------+------+----------------------------+---------------+--------+-------------------+
[06:40] <ming33897> ci-info: |  ens3  | True |         10.1.10.9          | 255.255.255.0 | global | 52:54:00:12:34:56 |
[06:40] <ming33897> ci-info: |  ens3  | True | fe80::5054:ff:fe12:3456/64 |       .       |  link  | 52:54:00:12:34:56 |
[06:40] <ming33897> ci-info: |   lo   | True |         127.0.0.1          |   255.0.0.0   |  host  |         .         |
[06:40] <ming33897> ci-info: |   lo   | True |          ::1/128           |       .       |  host  |         .         |
[06:40] <ming33897> ci-info: +--------+------+----------------------------+---------------+--------+-------------------+
[06:40] <ming33897> ci-info: ++++++++++++++++++++++++++++Route IPv4 info++++++++++++++++++++++++++++
[06:40] <ming33897> ci-info: +-------+-------------+-----------+---------------+-----------+-------+
[06:40] <ming33897> ci-info: | Route | Destination |  Gateway  |    Genmask    | Interface | Flags |
[06:40] <ming33897> ci-info: +-------+-------------+-----------+---------------+-----------+-------+
[06:40] <ming33897> ci-info: |   0   |   0.0.0.0   | 10.1.10.1 |    0.0.0.0    |    ens3   |   UG  |
[06:40] <ming33897> ci-info: |   1   |  10.1.10.0  |  0.0.0.0  | 255.255.255.0 |    ens3   |   U   |
[06:40] <ming33897> ci-info: +-------+-------------+-----------+---------------+-----------+-------+
[06:41] <ming33897> no change... as if the user-data.img never existed.
[06:50] <meena> ming33897: that's a lot of stuff to just dump into a chat. Next time, please use a paste service like GitHub's gist 
[06:51] <meena> used Fallback data source
[06:52] <meena> which data source were you expecting it to use? NoCloud?
[06:52] <meena> what does data.img look like?
[06:54] <ming33897> sorry, a little new to IRC
[06:55] <ming33897> [10:19:36 PM] <ming> #cloud-config
[06:55] <ming33897> [10:19:36 PM] <ming> runcmd:
[06:55] <ming33897> [10:19:36 PM] <ming>  - [ sh, -c, 'echo ==== $(date) ====; echo HI WORLD; echo =======' ]
[06:55] <ming33897> the above the content of user-data.img
[06:55] <ming33897> my iso file
[06:55] <ming33897> I have no idea of the data source I am expecting to use
[06:56] <ming33897> I just want to see the cloud-init get executed.
[06:57] <meena> https://cloudinit.readthedocs.io/en/latest/reference/datasources/nocloud.html#file-formats
[06:57] <ming33897> I did not have meta-data
[06:58] <ming33897> cloud-localds user-data.img user-data
[06:58] <ming33897> I am using cloud-localds
[07:00] <meena> that still tells you to create meta-data https://github.com/fred-vogt/cloud-utils/blob/master/bin/cloud-localds#L38
[07:07] <ming33897> I tried the method from the link
[07:07] <ming33897> same result in /var/log/cloud-init-output.log
[07:08] <ming33897> Cloud-init v. 22.3.4-0ubuntu1~22.04.1 running 'modules:config' at Tue, 24 Jan 2023 07:01:49 +0000. Up 38.30 seconds.
[07:08] <ming33897> Cloud-init v. 22.3.4-0ubuntu1~22.04.1 running 'modules:final' at Tue, 24 Jan 2023 07:02:05 +0000. Up 53.75 seconds.
[07:08] <ming33897> Cloud-init v. 22.3.4-0ubuntu1~22.04.1 finished at Tue, 24 Jan 2023 07:02:06 +0000. Datasource DataSourceNone.  Up 55.33 secos
[07:08] <ming33897> 2023-01-24 07:02:06,947 - cc_final_message.py[WARNING]: Used fallback datasource
[07:08] <meena> despite valid meta-data??
[07:08] <ming33897> yeah
[07:09] <meena> you sure it is a different image?
[07:09] <ming33897> I am using cloud-init schema --config-file user-data
[07:09] <ming33897> to validate the format, and it shows the file is valid
[07:09] <meena> shutdown the machine fully, then write the image, then start it again
[07:10] <ming33897> I tried many times, by shutdown the VM. I killed QEMU and also tried shutdown now
[07:10] <ming33897> I feel that the user-data.img just never get touched for some reason.
[07:11] <ming33897> no matter what I write into it.
[07:12] <meena> ming33897: it needs user-data, meta-data, and it needs to be ISO or FAT, and have a label: ci-data
[07:13] <ming33897> I tried generating different user-data.img and nothing changed.
[07:13] <ming33897> the file is ISO
[07:13] <meena> only then will it be considered valid, and be actually mounted
[07:13] <ming33897> I can use: file user-data.img
[07:13] <ming33897> user-data.img: ISO 9660 CD-ROM filesystem data 'cidata'
[07:16] <ming33897> hmm, but I am not sure if my user-data.img is mounted
[07:16] <ming33897> tried this inside VM: mount /dev/sr0 /mnt/cdrom
[07:16] <ming33897> mount: /mnt/cdrom: no medium found on /dev/sr0.
[07:25] <meena> how are you attaching it?
[07:30] <ming33897> -drive file=./user-data.img,if=virtio,media=cdrom
[07:30] <ming33897> the above qemu option
[07:30] <ming33897> hmm, I tried another ubuntu 22.04 image
[07:31] <ming33897> this time I am using ubuntu-22.04-server-cloudimg-amd64.vmdk
[07:35] <ming33897> I see cloud-init crashes
[07:35] <ming33897> ubuntu login: [   49.137150] cloud-init[1109]: Traceback (most recent call last):
[07:35] <ming33897> [   49.138385] cloud-init[1109]:   File "/usr/bin/cloud-init", line 33, in <module>
[07:35] <ming33897> [   49.139678] cloud-init[1109]:     sys.exit(load_entry_point('cloud-init==22.4.2', 'console_scripts', 'cloud-init')())
[07:35] <ming33897> [   49.140759] cloud-init[1109]:   File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 1086, in main
[07:35] <ming33897> [   49.142424] cloud-init[1109]:     retval = util.log_time(
[07:35] <ming33897> [   49.143333] cloud-init[1109]:   File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2680, in log_time
[07:35] <ming33897> [   49.147206] cloud-init[1109]:     ret = func(*args, **kwargs)
[07:35] <ming33897> [   49.148375] cloud-init[1109]:   File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 702, in status_wrapper
[07:35] <ming33897> [   49.151119] cloud-init[1109]:     util.ensure_dirs(
[07:35] <ming33897> [   49.152145] cloud-init[1109]:   File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 1754, in ensure_dirs
[07:35] <ming33897> [   49.155948] cloud-init[1109]:     ensure_dir(d, mode)
[07:35] <ming33897> [   49.156988] cloud-init[1109]:   File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 1791, in ensure_dir
[07:35] <ming33897> [   49.160509] cloud-init[1109]:     os.makedirs(path)
[07:35] <ming33897> [   49.161602] cloud-init[1109]:   File "/usr/lib/python3.10/os.py", line 215, in makedirs
[07:35] <ming33897> [   49.163219] cloud-init[1109]:     makedirs(head, exist_ok=exist_ok)
[07:35] <ming33897> [   49.164317] cloud-init[1109]:   File "/usr/lib/python3.10/os.py", line 225, in makedirs
[07:35] <ming33897> [   49.165858] cloud-init[1109]:     mkdir(name, mode)
[07:35] <ming33897> [   49.167235] cloud-init[1109]: OSError: [Errno 30] Read-only file system: '/var/lib/cloud'
[07:36] <ming33897> image is coming from: https://cloud-images.ubuntu.com/releases/22.04/release/ubuntu-22.04-server-cloudimg-amd64.vmdk
[08:33] <meena> ming35789: first off, again: please stop pasting so much stuff into the chat. put it on a paste service
[08:33] <meena> second: where are you getting these images from?
[09:12] <aciba> ming35789: it looks like the rootfs is somehow readonly. have you tried to follow the QEMU tutorial under https://cloudinit.readthedocs.io/en/latest/tutorial/index.html?
[09:27] <SDes91> Has someone tried configuring an image from Xilinx Ubuntu with cloud-init? I cannot find documentation on whether the `user-data` file should exist in the `/boot/firmware` partition or should it be somewhere else. The image does have `cloud-init` installed on it.
=== SirScott2 is now known as SirScott
[10:50] <meena> SDes91: if it has cloud-init, and that cloud-init isn't heavily modified, then it'll expect user-data in the regular place(s)
[10:51] <SDes91> what would those regular places be?
[10:56] <aciba> SDes91: Assuming the Nocloud datasource is going to be used: https://cloudinit.readthedocs.io/en/latest/reference/datasources/nocloud.html
[11:07] <meena> in /var/lib/cloud/seed/nocloud/ user-data and meta-data
[11:28] <SDes91> ok thank you I'll have look into it
=== jrm2 is now known as jrm
=== frickler_ is now known as frickler
=== `Nothing4You is now known as Nothing4You
[14:35] <minimal> ming257897: what is "-H" option to cloud-localds support to mean? I don't see that option documented anywhere
[14:38] <minimal> s/support/supposed/
[14:42] <minimal> ming257897: I believe your problem is you are specifying "if=virtio" which means use a virtio-blk device - virtio-blk does NOT support a CDROM AFAIK, instead specify "-drive file=./user-data.img,id=CD0,if=scsi -device scsi-cd,drive=CD0"
[14:44] <minimal> ming35789: ^^^
[17:42] <holman> minimal: Probably a dumb question related to the certs PR: What makes deleting the files from /etc/pki/ca-trust/ and /usr/share/pki/ca-trust-source/ in the RHEL/Fedora case wrong?
[17:44] <holman> minimal: I see a comment in update-ca-trust(8) about not manually modifying contents of java/uefi/etc directories, but the reasoning given is that update-ca-trust itself will modify those directories. As far as I'm aware this isn't used on RHEL/Fedora, so that shouldn't be a concern there. Is there some other reason?
[18:07] <minimal> holman: update-ca-trust would add certs there
[18:08] <minimal> my concern about simply deleting files from the cert locations was the presence of java and edk/uefi related stuff - i.e. could delete edk2 related files then break secure boot?
[18:10] <minimal> I didn't find any docs describing how all the certificate-related stuff is supposed to work on RHEL-derived distros and so was being cautious
[18:19] <minimal> holman: the other point about deleting files (rather than somehow disabling certs) is that a subsequent package update could reinstall the files
[19:08] <meena> minimal: jdk'd trust store is a single binary file (i forget the exact format), so it wouldn't make any difference if you delete files until the store is regenerated
=== esv_ is now known as esv
[19:49] <holman> minimal: I think this is enough justification to not add a new feature to a distro, but I'm not sure if we have enough justification to remove an existing feature from a distro. It is still usable as is, though it probably deserves some extra caution tape.
[19:52] <minimal> holman: I guess I was just hoping to find some "official" doc like "How to disable/delete standard CAs on RHEL/Fedora" but failed to find any clear info
[19:53] <minimal> I can restore the previous RHEL behaviour, it doesn't affect me personally, I was just trying to "do the right thing" ;-)
[19:54] <minimal> holman: I note the response you got to your Redhat ticket talked about deleting "locally" addeds CA certs, not the standard ones
[19:56] <holman> minimal: +1 to restoring functionality, thanks for trying :)
[19:57] <minimal> game over, next player please lol
[19:59] <holman> heh
[19:59] <minimal> ok, that still leaves the FreeBSD subp tests issue, any ideas?
[19:59] <holman> minimal: Agreed, sounds a bit like RHEL/Fedora aren't trying to support this, but maybe we (or esposem) could put in a request for something a bit more dynamic like alpine/debian/ubuntu
[19:59] <holman> err, I didn't look at the subp test issues, can poke it now
[19:59] <minimal> <I'm assuming RHEL must have some enterprise/gov customers who want to disable certain "standard" CAs, i.e. gov customer doesn't trust CAs from certain other countries, wonder what they do...>
[20:01] <holman> my primary experience with gvmt orgs on RHEL involved spinning their own distro derivative of RHEL -  which involved rebuilding everything and managing their own repos
[20:02] <holman> if that sounds like the "hard way".... it is
[20:04] <minimal> don't have experience of gov IT but enterprise IT does tend to be "the most awkward way" :-(
[20:06] <meena> minimal, sorry about not getting back to you about the tests, I was in Germany, and now I'm back and uh busy
[20:07] <minimal> meena: kein problem ;-)
[21:22] <holman> minimal: poking at FreeBSD subp test issue will have to wait, early EOD for me
[22:17] <minimal> no problem