| falcojr | You shouldn't see that warning on 24.4. The warning is telling you that something outside of the init system is calling cloud-init which is not how cloud-init is usually intended to run. That warning has no effect on whether later stages run or not unless there's something besides systemd invoking cloud-init and checking return codes before running | 01:24 |
|---|---|---|
| falcojr | later stages | 01:24 |
| ananke | falcojr: unfortunately, I am seeing that on 24.4, when I invoke cloud-init status manually. I'm not sure what's happening under the hood, I still haven't been able to dissect it enough. one thing for sure, I can reliably repeat it all the time. | 02:47 |
| ananke | now, I'm using kali linux for this, and their repos are based on debian testing. I haven't tried it with plain debian, I will see if they have an AMI for debian testing that I can use for that | 02:48 |
| ananke | I do see that debian folks have been tinkering with init related stuff for cloud-init, when I inspect contents of those packages: https://ftp.debian.org/debian/pool/main/c/cloud-init/ | 02:49 |
| ananke | between 22.4 and 24.4 versions systemd service files were moved from /lib/systemd to /usr/lib/systemd, and there's a new/additional cloud-init-main.service file | 02:52 |
| === kuraudo1 is now known as kuraudo | ||
| === kuraudo1 is now known as kuraudo | ||
| falcojr | ananke: what does "cloud-init --version" show? | 14:59 |
| falcojr | afaik, the Kali version is using the Debian version, and the Debian version also removed the warning | 15:01 |
| ananke | /usr/bin/cloud-init 24.4 | 15:05 |
| ananke | you are right, the exact error message has changed, now it errors out with a more generic 'ailed due to systemd unit failure. Ensure all cloud-init services are enabled, and check 'systemctl' or 'journalctl' for more information.' | 15:05 |
| ananke | there are no messages with the word 'error' in /var/log/cloud* , and I'm not sure which of the services it's complaining about. https://dpaste.com/54KQFQCSP.txt has more output | 15:08 |
| ananke | and yes, Kali uses those packages. I've tried even using directly debian packages, same issue. two out of three stages do not seem to run, last one to be executed is ssh module from the config stage | 15:12 |
| falcojr | ananke: thanks, that pastebin helps a lot. Can you run "cloud-init collect-logs" and attach the resulting tarball to a new bug at https://github.com/canonical/cloud-init/issues ? The full logs would be really helpful here | 15:12 |
| ananke | certainly, thank you for your time and help with this | 15:13 |
| ananke | https://github.com/canonical/cloud-init/issues/5928 submitted | 16:00 |
| -ubottu:#cloud-init- Issue 5928 in canonical/cloud-init "cloud-init status complains about systemd unit failures, only init stage modules are executed - Debian Testing/Unstable/Kali" [Open] | 16:00 | |
| falcojr | ananke: not even sure if this is possible, but are you on a system with sysvinit and systemd coexisting? | 16:42 |
| falcojr | cloud-init 24.3 should have brought in a new service called "cloud-init-main.service", but I'm not seeing it anywhere in your logs other than the upgrade part you posted | 16:43 |
| falcojr | update-rc.d: We have no instructions for the cloud-init-main init script. | 16:44 |
| ananke | falcojr: if I am, that's certainly not intentional, it would be a result of the upstream | 16:44 |
| ananke | ○ cloud-init-main.service - Cloud-init: Single Process | 16:44 |
| ananke | Loaded: loaded (/usr/lib/systemd/system/cloud-init-main.service; disabled; preset: disabled) | 16:44 |
| ananke | Active: inactive (dead) | 16:44 |
| ananke | and the package certainly has that file | 16:45 |
| ananke | there's certainly one possibility: package maintainers made something that in theory would work on a fresh install, but is lacking critical steps on an upgrade | 16:46 |
| falcojr | yeah, I'm wondering if there was an upgrade step missing here | 16:46 |
| ananke | I can certainly attempt to enable this service manually, and see what happens | 16:47 |
| falcojr | yeah, it should have been enabled but your logs don't show anything about it running | 16:48 |
| ananke | yep! that was it! | 16:48 |
| falcojr | interesting... | 16:48 |
| ananke | enabled it, rebooted, and now cloud-init status shows 'done', and I see traces of the per-boot scripts running | 16:49 |
| falcojr | glad it worked! | 16:49 |
| ananke | which means I'll have to open an issue with debian. it would seem both of their 24.3-1 and 24.4-1 packages are affected by it, and as a result the downstream kali is | 16:50 |
| ananke | I don't know enough about deb package structure and conventions regarding how they enable new service units for existing packages during an upgrade, but I imagine many people would be impacted by this | 16:52 |
| ananke | and wouldn't know about it. we rely on cloud-init for those systems on subsequent boots, not just during provisioning, so we noticed | 16:52 |
| falcojr | total guess here based on the "update-rc.d" message in your upgrade output, but I'm wondering if apt is somehow misidentifying your init system as sysvinit rather than systemd and so applied the upgrade there rather than to systemd | 16:55 |
| falcojr | cause your journal also had an odd message | 16:55 |
| falcojr | Dec 13 15:28:55.523890 terminal.example.com systemd-sysv-generator[225]: SysV service '/etc/init.d/cloud-init' lacks a native systemd unit file, automatically generating a unit file for compatibility. | 16:56 |
| ananke | there's 'sysvinit-utils/kali-rolling,now 3.11-1 amd64 [installed]', which may be some backwards compatibility layer | 16:56 |
| ananke | https://packages.debian.org/testing/sysvinit-utils talks about "This package contains the important System-V-like utilities. | 16:58 |
| ananke | Specifically, this package includes: init-d-script, fstab-decode, killall5, pidof" | 16:58 |
| ananke | while the cloud-init package comes with both /etc/init.d/cloud-init and /usr/lib/systemd/system/cloud-init-main.service | 16:59 |
| ananke | I'll fire up debian 12 ami and see if they include sysvinit-utils there too | 17:00 |
| ananke | I was suspecting that this service might be implicated, but I could not figure it out from the logs at all, so I didn't want to guess | 17:01 |
| ananke | yep, that package also exists on debian 12 stable | 17:06 |
| === esv_ is now known as esv | ||
| ananke | performing update on debian 12 stable to this latest package works fine, it shows that new systemd symlinks are created, so either something on debian testing or kali is causing this. fun | 17:10 |
| dilfridge | 21:45 | |
| dilfridge | https://distfiles.gentoo.org/releases/amd64/autobuilds/20241213T133324Z/di-amd64-cloudinit-20241213T133324Z.qcow2 | 21:46 |
| dilfridge | in case anyone is interested in testing, ^ bootable (EFI) Gentoo disk image running cloud-init on boot | 21:46 |
| dilfridge | (first ever build) | 21:46 |
| dilfridge | other files including hash checksums and gpg signature with gentoo releng key are in the same directory | 21:47 |
| holmanb | dilfridge: nice :) | 22:12 |
| holmanb | dilfridge: do you have any other contributions planned in the near future? | 22:13 |
| holmanb | dilfridge: we still need to get pep517 sorted out, and I know gentoo is keen on getting that resolved sooner than later | 22:13 |
| holmanb | dilfridge: I think we know what needs to happen there, just haven't gotten to it yet | 22:14 |
| holmanb | dilfridge: debian doesn't appear to be in a rush to drop existing support so it hasn't been as urgent for us - I'm guessing the same is true for rhel-family | 22:14 |
| dilfridge | in principle yes, but I'm more on the release engineering and less on the python side | 22:16 |
| dilfridge | so I will definitely try | 22:17 |
| * dilfridge is learning python by adding features to existing programs :D | 22:18 | |
| dilfridge | I'd like to figure out now which gentoo-specific features are still missing (mostly for gentoo+systemd which I see as more future-proof than gentoo+openrc) | 22:23 |
| dilfridge | objective being, make gentoo more attractive for cloud / hosting providers | 22:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!