[14:08] <bdean> does anyone have an experience with growpart on Oracle Linux 7? when I run `growpart` myself interactively it works. but it never seems to run from cloud-init and I'm not sure how to tell what's going on. there's nothing in the logs, it goes right from write-files to resizefs and nothing from growpart
[14:10] <minimal> bdean: have you debugging enabled for cloud-init logs?
[14:10] <minimal> if so then there should be several lines written to /var/log/cloud-init.log by cc_growpart showing what is going on
[14:12] <minimal> also are there any entries relating to growpart in your user-data or in /etc/cloud/cloud.cfg or /etc/cloud/cloud.cfg.d/* ?
[14:12] <bdean> there are logs that say DEBUG, but I see nothing from cc_growpart
[14:12] <bdean> I have a file in cloud.cfg.d
[14:13] <minimal> what does it say about growpart?
[14:14] <bdean> not sure how to do multiline in irc, but it's `growpart: { mode: growpart, devices: ['/'], ignore_growroot_disabled: true }`
[14:14] <minimal> also what about:   grep "Running module growpart" /var/log/cloud-init.log ?
[14:15] <bdean> sure ...
[14:17] <bdean> just this:
[14:17] <bdean> 2023-05-18 14:06:26,086 - util.py[DEBUG]: Reading from /etc/cloud/cloud.cfg.d/06_growpart.cfg (quiet=False)
[14:17] <bdean> 2023-05-18 14:06:26,086 - util.py[DEBUG]: Read 97 bytes from /etc/cloud/cloud.cfg.d/06_growpart.cfg
[14:17] <bdean> and that's all
[14:18] <bdean> that's from `grep growpart /var/log/cloud-init.log`
[14:18] <minimal> so then it doesn't seem to be running the module
[14:18] <bdean> yeah, but why?
[14:19] <minimal> try:   grep "Skipping modules" /var/log/cloud-init.log
[14:19] <bdean> it's in the list in /etc/cloud/cloud.cfg too
[14:19] <bdean> cloud_init_modules:
[14:19] <bdean>  - disk_setup
[14:19] <bdean>  - migrator
[14:19] <bdean>  - bootcmd
[14:19] <bdean>  - write-files
[14:20] <bdean>  - growpart
[14:20] <bdean>  - resizefs
[14:20] <bdean>  - set_hostname
[14:20] <bdean>  - update_hostname
[14:20] <bdean>  - update_etc_hosts
[14:20] <bdean>  - rsyslog
[14:20] <bdean>  - users-groups
[14:20] <bdean>  - ssh
[14:21] <bdean> Skipping set-hostname, Skipping module named bootcmd, Skipping module named disable-ec2-metadata
[14:22] <minimal> does "cloud_init_modules" appear in any other file inside /etc/cloud/ ?
[14:22] <minimal> rgrep "cloud_init_modules" /etc/cloud/*
[14:32] <bdean> sorry, one second, was in a meeting
[14:34] <bdean> we've got a winner! /etc/cloud/cloud.cfg.d/99_oci_cloud.cfg
[14:35] <bdean> f-ing OCI
[14:35] <bdean> # The growpart module is disabled by default. To enable automatic boot volume resizing, uncomment
[14:35] <bdean> # the below entry for '- growpart' and reboot. All the dependent packages for the growpart
[14:35] <bdean> # module to work such as cloud-utils-growpart and gdisk are already included in the image.
[14:35] <bdean> #- growpart
[14:37] <bdean> that makes zero sense to me. Why would they make images where you have to do extra steps just to resize the root volume
[14:37] <minimal> bdean: and that 99_oci_cloud.cfg file has a "cloud_init_modules" section? assuming it does then that overrides the list in /etc/cloud.cfg
[14:37] <bdean> yeah
[14:37] <bdean> it's like a whole copy of /etc/cloud.cfg with various bits commented out
[14:39] <bdean> I'm already making a custom image (their version of an AMI) so I can just use sed on this to uncomment it, but it's just annoying
[14:39] <bdean> thanks for the help though
[14:41] <minimal> perhaps they want you to manually use oci-growfs?
[14:41] <bdean> I mean .. they certainly don't seem to mind requiring manual steps to get things going
[14:42] <minimal> yeah it makes no sense
[14:42] <bdean> I'm doing a diff to the standard cloud.cfg to see what else they changed, this one is fun:
[14:42] <bdean> #disable_vmware_customization: false
[14:42] <bdean> gotta comment out it being false
[14:43] <bdean> oh well
[14:43] <bdean> thanks again
[14:43] <minimal> why? aren't you using the Oracle datasource?
[14:43] <bdean> it adds that, yes
[14:43] <minimal> in why case why would a VMware datasource setting be relevant?
[14:44] <minimal> s/why/which/
[14:44] <bdean> maybe they don't know what they're doing
[14:48] <minimal> bdean: they're trying to save you from yourself ;-)
[14:48] <bdean> ;_;
[15:25] <minimal> any help to figure out why a single test is failing for #4128? I can't see what the problem actually is
[19:06] <falcojr> minimal: I'll take a look
[19:24] <minimal> Thanks. I found a few other places in testcases to correct modules names (though none of those affect testcase) so I'll be updating the PR shortly
[19:37] <falcojr> minimal: You can just remove this line https://github.com/canonical/cloud-init/blob/main/tests/integration_tests/modules/test_combined.py/#L228
[19:38] <falcojr> the test itself was wrong...it was expecting apt-pipelining to have been run even though it never should have
[19:38] <falcojr> but used the name apt_pipelining, which is why the test passed. Since you changed the name of the module, it failed as it now matched correctly
[19:40] <minimal> ah, that's why I didn't spot the issue, was staring intently at the code with my changes, not the original code, lol
[22:34] <meena> https://github.com/canonical/cloud-init/pull/4129
[22:34] -ubottu:#cloud-init- Pull 4129 in canonical/cloud-init "BSD: simplify finding MBR partitions" [Open]
[22:44] <meena> can soeone re-run tests here? https://github.com/canonical/cloud-init/pull/2146 — some of them have been cancelled, no idea why
[22:44] -ubottu:#cloud-init- Pull 2146 in canonical/cloud-init "FreeBSD fix parsing of mount and mount options" [Open]
[22:52] <meena> wow, i just realized: Python stuff gets installed without junk like tests.
[22:52] <meena> can somebody at NPM please cop on.