| === cpaelzer_ is now known as cpaelzer | ||
| SDes91 | Hi all. I have a rather weird thing happening. I have mentioned explicitly `python3-pip` in the packages list and then the `ansible` section according to the examples. But the error states that `pip` is not installed. Image is Ubuntu 24.04 LTS cloud-init 24.1.6 | 14:36 |
|---|---|---|
| SDes91 | also when I create a couple of users the user IDs seems to be okay but the Group IDs are always one ahead value ahead of the user id. e.g. userid 1000 but groupid 1001 | 14:42 |
| minimal | SDes91: why would the UIDs and GIDs necessarily be in sync? | 15:12 |
| minimal | typically the next available UID and GID are chosen | 15:13 |
| minimal | as for the ansible issue, did you check /var/log/cloud-init.log to see what is happening? | 15:16 |
| SDes91 | minimal it explicitly mentioned that the ansible module failed. upon inspecting the logs in `results.json` it mentions that pip is not installed | 15:20 |
| minimal | did the logs show whether cc_oackage_update_upgrade_install actually installed python3-pip? | 15:21 |
| minimal | by "I have mentioned explicitly `python3-pip` in the packages list" you mean you listed python3-pip in user-data: "packages:\n - python3-pip\n" ? | 15:22 |
| SDes91 | yes. | 15:24 |
| SDes91 | I am checking the logs again to check the cc_package_update_upgrade_install logs. | 15:25 |
| minimal | then that means you are using the *distro* packaging of pip and therefore for your cc_ansible configuration you should be specifying "install_method: distro" | 15:26 |
| SDes91 | I really have a weird thing going on here. I luckily had a backup `user-data` file that works like a charm when installing the packages. Ironically I have only ever added a few more packages to the `packages` list and suddenly it skips it. I might have misconfigured something. | 15:31 |
| minimal | SDes91: does your user-data specify "install_method: distro" ? | 15:32 |
| minimal | sounds like whatever additional entries you added to the "packages:" list might have created some sort of package conflict. I'd expect that to result in some form of output in cloud-init.log | 15:33 |
| SDes91 | yes I am able to log into the qcow2 image and I have the logs on the machine. Strangely I cannot find any logs for `cc_package_...` and it somehow skips or overrides the `packages_upgrade: true` set with another subprocess. | 15:35 |
| SDes91 | I guess I will have to check the packages as you mentioned. If I find something I will post it here on the chat. But I fear it might be some apt package that I was previously using for 20.04 LTS and may have to be verified for 24.04 LTS. The packages I added in posterity are: `bc`, `bison`, `flex`, `gcc`, `jq`, `libelf-dev`, `make`, `mc`, | 15:40 |
| SDes91 | `pciutils`, `unzip`, `zip` which are pretty standard. | 15:40 |
| minimal | SDes91: search for "Running module package_update_upgrade_install" | 15:40 |
| SDes91 | very strange. upon `cat cloud-init.log | grep -i "running module"` I do not find the module execution at all in the log. | 15:42 |
| SDes91 | there are other modules that ran. not the package_update_upgrade_install | 15:43 |
| minimal | then check for "Skipping modules" ? | 15:44 |
| SDes91 | this was also rather visible on my end. I was building the image using QEMU and Packer. Previously I could see the logs for `while [ ! -f /var/lib/cloud/instance/boot-finished ]; do echo 'Waiting for Cloud-Init...'; sleep 1; done` in packer that cloud-init was wrapping up correctly. Upon the change it literally skipped this provisioning step. | 15:45 |
| SDes91 | skipping modules does not mention anything about `package`. It skips all other modules which I have not configured. But no explicit mention of packages. | 15:48 |
| SDes91 | the image I made with the previous configuration has been built successfully and in that image I can see the logs for `package_update_upgrade_install` very clearly. | 15:50 |
| minimal | then is "package_update_upgrade_install" missing from the "cloud_final_modules" list in the /etc/cloud/cloud.cfg file and /etc/cloud/cloud.cfg.d/* files? | 15:50 |
| SDes91 | it exists in the `cloud_final_modules` in cloud.cfg but there is no explicit file under `/etc/cloud/cloud.cfg.d/` directory. | 15:55 |
| minimal | then it should be run and appear in cloud-init.log | 15:56 |
| minimal | are you using Ubuntu or Ubuntu Server? | 15:56 |
| SDes91 | albeit in the `99-installer.cfg` the the raw userdata configuration has the list of `packages` in it and I can see `python3-pip` | 15:56 |
| blackboxsw | minimal: > doesn't cc_growpart only grow the rootfs partition? .... By default is down attempt only to resize devices: ["/"] but in user-data additional device paths can be provided https://cloudinit.readthedocs.io/en/latest/reference/modules.html#growpart | 15:56 |
| SDes91 | Ubuntu Live Server AMD64 image. | 15:56 |
| minimal | SDes91: isn't Ubuntu Server using Subiquity (which makes use of cloud-init behind the scenes) ? | 15:57 |
| minimal | blackboxsw: the growpart tool (from cloud-utils) can only grow (extend) the last partition on a device... | 15:57 |
| SDes91 | yes. I use autoinstall which as the subpart of cloud-init configuration in it. | 15:57 |
| minimal | SDes91: so are you running subiquity or cloud-init? | 15:58 |
| blackboxsw | SDes91: .. per using your while loop on presence of /var/lib/cloud/instance/boot-finished, why wouldn't you use the blocking `cloud-init status --wait` command? | 15:58 |
| minimal | sounds like this is a Subiquity issues rather than a "native" cloud-init issue | 15:59 |
| SDes91 | umm... if i understand if the `user-data` starts with `autoinstall` it might be subiquity? | 15:59 |
| blackboxsw | SDes91: maybe not wanting to invoke python from within a shell script... | 15:59 |
| SDes91 | sorry you are correct this might be a subiquity problem. | 16:00 |
| minimal | yes, "autoinstall" is Subiquity | 16:00 |
| blackboxsw | SDes91: yes any cloud-config user-data beginning with autoinstall "has to" be subiquity as cloud-init doesn't really do anything with that key besides check that it contains a version: 1 value | 16:00 |
| SDes91 | blackboxsw I will take that into consideration for using `status --wait` | 16:00 |
| blackboxsw | +1 on cloud-init status --wait. Also subiquity invokes that too https://github.com/canonical/subiquity/blob/main/subiquity/cloudinit.py#L117 | 16:01 |
| SDes91 | appreciate your help here. Thanks again. i have reverted back to my original config and I will try to see if I can reproduce it. | 16:02 |
| minimal | blackboxsw: To clarify, from the c-i cc_growpart docs: "Note that this only works if the partition to be resized is the last one on a disk with classic partitioning scheme (MBR, BSD, GPT). LVM, Btrfs and ZFS have no such restrictions." | 16:02 |
| minimal | blackboxsw: so yeah you're right in the context of ZFS | 16:02 |
| minimal | BTW the reference to "LVM" should probably be removed as cc_growpart does not *currently* support LVM, it's on my list once I fix LUKS handling | 16:03 |
| blackboxsw | SDes91: so also your ansible config issue. I thought you didn't have to provide a separate packages: [python3-pip] when providing config with `ansible: {install_method: pip}` I thought cloud-init just did the right thing and installed if it was unable to import pip. https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cc_ansible.py#L99-L101 | 16:04 |
| === kuraudo1 is now known as kuraudo | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!