ming | Hi, I have a question about cloud-init working with ubuntu 22.04 QEMU image | 06:18 |
---|---|---|
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:19 |
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:21 |
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. | 06:22 |
=== ming is now known as ming33897 | ||
meena | ming33897: what does your log say? | 06:31 |
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:39 |
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:40 |
ming33897 | no change... as if the user-data.img never existed. | 06:41 |
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:50 |
meena | used Fallback data source | 06:51 |
meena | which data source were you expecting it to use? NoCloud? | 06:52 |
meena | what does data.img look like? | 06:52 |
ming33897 | sorry, a little new to IRC | 06:54 |
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:55 |
ming33897 | I just want to see the cloud-init get executed. | 06:56 |
meena | https://cloudinit.readthedocs.io/en/latest/reference/datasources/nocloud.html#file-formats | 06:57 |
ming33897 | I did not have meta-data | 06:57 |
ming33897 | cloud-localds user-data.img user-data | 06:58 |
ming33897 | I am using cloud-localds | 06:58 |
meena | that still tells you to create meta-data https://github.com/fred-vogt/cloud-utils/blob/master/bin/cloud-localds#L38 | 07:00 |
ming33897 | I tried the method from the link | 07:07 |
ming33897 | same result in /var/log/cloud-init-output.log | 07:07 |
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:08 |
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:09 |
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:10 |
ming33897 | no matter what I write into it. | 07:11 |
meena | ming33897: it needs user-data, meta-data, and it needs to be ISO or FAT, and have a label: ci-data | 07:12 |
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:13 |
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:16 |
meena | how are you attaching it? | 07:25 |
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:30 |
ming33897 | this time I am using ubuntu-22.04-server-cloudimg-amd64.vmdk | 07:31 |
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:35 |
ming33897 | image is coming from: https://cloud-images.ubuntu.com/releases/22.04/release/ubuntu-22.04-server-cloudimg-amd64.vmdk | 07:36 |
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? | 08:33 |
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:12 |
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. | 09:27 |
=== SirScott2 is now known as SirScott | ||
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:50 |
SDes91 | what would those regular places be? | 10:51 |
aciba | SDes91: Assuming the Nocloud datasource is going to be used: https://cloudinit.readthedocs.io/en/latest/reference/datasources/nocloud.html | 10:56 |
meena | in /var/lib/cloud/seed/nocloud/ user-data and meta-data | 11:07 |
SDes91 | ok thank you I'll have look into it | 11:28 |
=== jrm2 is now known as jrm | ||
=== frickler_ is now known as frickler | ||
=== `Nothing4You is now known as Nothing4You | ||
minimal | ming257897: what is "-H" option to cloud-localds support to mean? I don't see that option documented anywhere | 14:35 |
minimal | s/support/supposed/ | 14:38 |
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:42 |
minimal | ming35789: ^^^ | 14:44 |
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:42 |
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? | 17:44 |
minimal | holman: update-ca-trust would add certs there | 18:07 |
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:08 |
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:10 |
minimal | holman: the other point about deleting files (rather than somehow disabling certs) is that a subsequent package update could reinstall the files | 18:19 |
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 | 19:08 |
=== esv_ is now known as esv | ||
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:49 |
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:52 |
minimal | I can restore the previous RHEL behaviour, it doesn't affect me personally, I was just trying to "do the right thing" ;-) | 19:53 |
minimal | holman: I note the response you got to your Redhat ticket talked about deleting "locally" addeds CA certs, not the standard ones | 19:54 |
holman | minimal: +1 to restoring functionality, thanks for trying :) | 19:56 |
minimal | game over, next player please lol | 19:57 |
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...> | 19:59 |
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:01 |
holman | if that sounds like the "hard way".... it is | 20:02 |
minimal | don't have experience of gov IT but enterprise IT does tend to be "the most awkward way" :-( | 20:04 |
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:06 |
minimal | meena: kein problem ;-) | 20:07 |
holman | minimal: poking at FreeBSD subp test issue will have to wait, early EOD for me | 21:22 |
minimal | no problem | 22:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!