| jnamdar | Hey everyone, is there anything planned to support adding DNF repositories from cloud-init config ? I saw in the doc there was a module to add YUM ones, but since RHEL 8 I think the default package manager is dnf. | 00:28 |
|---|---|---|
| holmanb | jnamdar: Just use the yum config module. It should work for dnf too. | 05:32 |
| holmanb | jnamdar: dnf still just uses repo files in /etc/yum.repos.d/, so unless they changed the format or something that module should continue to work | 05:33 |
| holmanb | I guess they left, but if anyone feels like verifying dnf support and updating docs to mention support, that would be a easy task for someone's first cloud-init contribution. | 05:42 |
| * holmanb looks forward to a future with github issues to categorize issues like this for new contributors | 05:43 | |
| === esv_ is now known as esv | ||
| emma14 | hi, I'm trying to use cloud-init to configure my kvm-based VM. I'm mounting an ISO with a `user-data.txt` file in it, and it doesn't appear to be getting picked up when the VM boots after running `virt-sysprep` against the VM's disk - any suggestions? | 15:37 |
| minimal | emma: did you also create a meta-data file in the ISO? it is required | 15:57 |
| minimal | emma14: https://cloudinit.readthedocs.io/en/latest/reference/datasources/nocloud.html#file-formats | 15:58 |
| minimal | "Both files must be present for it to be considered a valid seed ISO." | 15:58 |
| emma14 | Ah, right on, will give that a try | 15:58 |
| emma14 | Doesn't seem to actually run anything I've specified. I'm generating a file `seed.iso` containing 3 files: `meta-data`, `user-data`, `network-config` which is a valid netplan schema. Mounting it through virt-manager as `SATA CDROM 1` with raw storage format. In-between each attempt I'm running `cloud-init clean --logs` to reset the | 16:24 |
| emma14 | `/var/lib/cloud/`-directory | 16:24 |
| emma14 | If I mount the ISO and run `$ cloud-init schema --config-file /mnt/cidata/user-data` it says it's valid as well | 16:25 |
| minimal | nothing related appeared in /var/log/cloud-init.log? | 16:26 |
| emma14 | Hmm, I don't see anything particularly relevant. E.g. I don't see any mention of my user-data script or | 16:32 |
| emma14 | This is just ubuntu20.04 server | 16:32 |
| emma14 | Checking this ~ https://cloudinit.readthedocs.io/en/latest/reference/faq.html#where-are-the-logs ~ looks like /run/cloud-init/status.json indicates that the datasource is DataSourceNone | 16:38 |
| emma14 | Do I need to manually specify the datasource somewhere? | 16:38 |
| minimal | there is a default list, that basically includes all the DataSources, with 'None' as the last one | 16:39 |
| emma14 | I see | 16:39 |
| minimal | unless a specific DS or list of DS has been set somehow in /etc/cloud/cloud.cfg or in /etc/cloud/cloud.cfg.d/ | 16:39 |
| minimal | look for a "datasource_list" entry | 16:40 |
| minimal | is the ISO labelled correctly? | 16:41 |
| zaphod_b | hiya lads; I'm trying to enable cloud-init on a regular ubuntu18 live-server image; my first attempts are failing, and I take it the presence of `/etc/cloud/cloud-init.disabled` is the culprit here | 16:42 |
| zaphod_b | so my question is, is there a way to override this with an option on the kernel command line for example ? | 16:42 |
| minimal | zaphod_b: why not use a Ubuntu cloud image? | 16:43 |
| zaphod_b | well this is for booting off metal; I had considered that at first, but could not find a way to get the hardware boot off any of the cloud images that I'd found | 16:44 |
| zaphod_b | but would love to learn otherwise :) | 16:44 |
| minimal | I *think* Live Server is using Subiquity | 16:44 |
| minimal | which then uses cloud-init | 16:45 |
| zaphod_b | well as far as I've understood, subiquity is a recent thing and probably was not yet around in 2018 | 16:45 |
| zaphod_b | not quite sure about that | 16:45 |
| zaphod_b | how would subiquity be helpful ? | 16:45 |
| minimal | Ubuntu Server 18.04 uses Subiquity | 16:46 |
| emma14 | > is the ISO labelled correctly? ~ from isoinfo - Volume id: cidata | 16:46 |
| minimal | well what I mean is that using Subquity (which uses cloud-init) is not exactly the same as using cloud-init "proper", | 16:47 |
| zaphod_b | yes indeed; the scripts have written so far work fine with u20.04 and u22.04 | 16:47 |
| minimal | emma14: the DS selection doesn't show much, if anything, in cloud-init.log unless you enable debug, then it shows exactly what is going on | 16:48 |
| emma14 | Ah that's super helpful | 16:48 |
| emma14 | I'll try that | 16:48 |
| minimal | emma14: then it will log the list of DSes it will check, you should see it looking for a fs labelled cidata, etc | 16:48 |
| minimal | zaphod_b: my point was that Live Server appears to use Subiquity for installing. So are you trying to install Ubuntu? | 16:51 |
| emma14 | Following this ~ https://gist.github.com/RagedUnicorn/a70f8540c68e0a41e3e097a2e29130f1#logs | 16:51 |
| zaphod_b | not installing, running live | 16:52 |
| zaphod_b | and using cloud-init for setting ssh keys | 16:52 |
| minimal | zaphod_b: I don't think Live Server is designed for that | 16:53 |
| zaphod_b | well, clearly not, but with a little help the 20 and 22 versions have been willing to comply ;-) | 16:55 |
| zaphod_b | plus, that's called liver server, right ? | 16:55 |
| zaphod_b | plus, that's called live server, right ? | 16:55 |
| minimal | but does the cloud-init services run in sequence when you boot Live Server? | 17:05 |
| minimal | I'd expect not and that subiquity would run instead | 17:05 |
| zaphod_b | with u20 and u22, yes | 17:05 |
| minimal | hmm? you said you have a cloud-init.disabled file so then how can the c-i services run? | 17:06 |
| minimal | emma14: that guide does not mention increasing loglevel, only moving where the logfile is placed | 17:08 |
| zaphod_b | that file is present on the u18 image only | 17:08 |
| minimal | zaphod_b: right, seems things were changed in Ubunto 20: https://discourse.ubuntu.com/t/cloud-init-and-the-live-server-installer/14597 | 17:10 |
| zaphod_b | minimal: thanks, this is helpful | 17:17 |
| blackboxsw | zaphod_b: minimal right. Just a drive by comment from me. The live server installer is subiquity-based for the installation dialogs etc. I just launched the bionic live server iso the installer. Ubuntu 18 was a special case that does disable cloud-init intentionally within the ephemeral/installed environment. What I think this means is that you won't be able to provide any custom cmdline options to 'enable' cloud-init because most of | 17:18 |
| blackboxsw | what I'd tell you would be something akin to ... | 17:18 |
| minimal | blackboxsw: yeah I wasn't sure what would happen if "cloud-init=enabled" was passed on cmdline | 17:20 |
| blackboxsw | manipulating the kernel params to send something like autoinstall ds=nocloud-net;s=http://SOME_IP:8000/' where you host a user-data/meta-data file to remove said /etc/cloud/cloud-init.disabled file. But, chicken and egg problem here. cloud-init is disabled in this stage on bionic 18.04 so it doesn't receive those directies to override and remove the disable flag file | 17:20 |
| zaphod_b | yeah that's what I'm about to conclude too despite several attempts | 17:20 |
| blackboxsw | I recall that the live installer puts in layers of files in the ephemeral environment, I'll see if there is a kernel param switch that can be provided to disalllow disabling cloud-init (I think it unlikely but i'll poke around) | 17:21 |
| zaphod_b | blackboxsw: thank you that would be very helpful indeed | 17:22 |
| minimal | blackboxsw: isn't that the cmdline value I posted? | 17:24 |
| zaphod_b | I'm already messing with the grub options; I guess my next option along that pass would be to override the squashfs to remove the disabling file, but that's another step further and I was really hoping I would be able to avoid that... | 17:24 |
| minimal | zaphod_b: trying to install bare metal from a cloud/vm image would depend on whether that image happened to include drivers and firmware for your bare metal host's network, storage, etc devices | 17:25 |
| minimal | I'm not familiar with the Ubunut cloud images so not sure, but assume the NoCloud VM tailored images must have at least some physical devices drivers | 17:26 |
| zaphod_b | yes, and that's the reason why I'd discarded that idea at first as it does not souond quite right | 17:27 |
| emma14 | Okay I think I may see why I wasn't getting the results I expected. When I ran `cloud-id` it said `none`, so I checked the contents of /etc/cloud/cloud.cfg.d/* and sure enough, it specified `none`. Led me to this answer - https://bugs.launchpad.net/subiquity/+bug/1958377/comments/11 - which led me to download a cloud image from - | 17:28 |
| emma14 | https://cloud-images.ubuntu.com/ - and now I'm seeing debuggable output in `/var/log/cloud-init-*` and `cloud-id` is showing nocloud. Makes sense | 17:28 |
| -ubottu:#cloud-init- Launchpad bug 1958377 in cloud-init (Ubuntu) "cloud-init does not apply network configuration from NoCloud resource" [High, Incomplete] | 17:28 | |
| blackboxsw | minimal nice on `cloud-init=enabled` Yeah. zaphod_b minimal looks like providing the extended kernel params after --- cloud-init=enabled will enable cloud-init in BIonic's ephemeral boot stage I can see it camping out trying to discover a datasource in the KVM console | 17:40 |
| blackboxsw | s/camping out/spinning/ | 17:40 |
| blackboxsw | this is with stock 18.04.6 bionic live server ISO | 17:41 |
| NightMonkey | Howdy. I'm having a heck of a time getting cloud-init clean to have its expected effect on Ubuntu 22.04. What is the proper way to prep a "golden image" template. | 17:48 |
| NightMonkey | ? | 17:48 |
| zaphod_b | blackboxsw: indeed, this is awesome ! | 17:48 |
| zaphod_b | thank you blackboxsw minimal for all the help ! | 17:49 |
| meena | NightMonkey: which of your expectations aren't met? | 17:49 |
| NightMonkey | meena: I would like cloud-init to run on the next boot after the os image is cloned. | 17:51 |
| jnamdar | Hi all, is there any doc to add dnf repositories ? I found the doc for yum repos, but those are outdated on Fedora/RHEL 8 | 17:51 |
| meena | jnamdar: dnf uses rpm repositories, so the yum module should just work | 17:52 |
| NightMonkey | What I'm seeing, however, is that cloud-init doesnt even run. | 17:52 |
| meena | NightMonkey: anything in the logs as to why? | 17:52 |
| blackboxsw | NightMonkey `cloud-init status --long` may tell you what gives (also could check /run/cloud-init/ds-identify.log) | 17:52 |
| minimal | NightMonkey: which version of Ubuntu is this with? cloud image? Ubuntu server? | 17:52 |
| jnamdar | meena yeah but i'm afraid if the module writed in /etc/yum.repos.d/, the dnf command will probably not pick them up | 17:53 |
| jnamdar | writes* | 17:53 |
| blackboxsw | zaphod_b: just cofirmed I can run `python3 -m http.server 8000` with a directory containing `user-data` file with my #cloud-config and an empty meta-data file and I can 'install ubuntu' on the live server 18.04 image passing the following kernel cmdline params: `--- cloud-init=enabled ds=nocloud-net;s=http://_gateway:8000/' and it honors my #cloud-config | 17:54 |
| meena | try it out and tell us about it, if it doesn't work, we'll fix it | 17:54 |
| blackboxsw | zaphod_b: note as well that the #cloud-config user-data provided is manipulating the ephemeral boot stage, not the target system across reboot | 17:55 |
| zaphod_b | blackboxsw that's fine as I only intend to run in live mode, so not leaving the ephemeral boot stage | 17:57 |
| blackboxsw | zaphod_b: For what it's worth we're working on getting a architecture diagram and examples together as this is a big pain point and confusion for lots of people (ephemeral interaction vs target system interaction) given that cloud-init is active in both boots | 17:59 |
| zaphod_b | indeed the whole business can be a headache ;-) | 18:05 |
| NightMonkey | meena: That's part of the problem. I see no logs from cloud-init. | 18:08 |
| meena | is it enabled? is logging enabled? | 18:09 |
| NightMonkey | In case it is a local misconfiguration, I'll ask this: does anyone here make golden images with Ubuntu 22.04 and see cloud-init run after running "cloud-init clean"? :) | 18:09 |
| NightMonkey | meena: I see it as a unit in systemd, but it is "inactive/dead". | 18:10 |
| NightMonkey | I also see a file in /etc/rsyslog.d/ that disables cloud-init logging, but I disabled that file. :/ | 18:11 |
| blackboxsw | NightMonkey: yes, but what platform are you trying to launch that golden image in after creating it? cloud-init status --long should tell you why cloud-init is disabled. | 18:11 |
| NightMonkey | @blackboxsw: Ah, I'll try that on Monday. Thank you. | 18:12 |
| blackboxsw | NightMonkey: +1 cloud-init status --long and read /run/cloud-init/ds-identify.log | 18:12 |
| blackboxsw | ds-identify.log is the first entry point for cloud-init and decides whether the platform looks compatible with cloud-init | 18:13 |
| blackboxsw | ds-identify will deactivate all systemd units if it doesn't look like a viable datasource for cloud-init exists | 18:13 |
| blackboxsw | ok ... I really need to file my taxes. catch you all later. thanks! | 18:13 |
| NightMonkey | Oh, awesome, thanks a bunch! | 18:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!