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:08 |
---|---|---|
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:10 |
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:12 |
minimal | what does it say about growpart? | 14:13 |
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:14 |
bdean | sure ... | 14:15 |
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:17 |
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:18 |
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:19 |
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:20 |
bdean | Skipping set-hostname, Skipping module named bootcmd, Skipping module named disable-ec2-metadata | 14:21 |
minimal | does "cloud_init_modules" appear in any other file inside /etc/cloud/ ? | 14:22 |
minimal | rgrep "cloud_init_modules" /etc/cloud/* | 14:22 |
bdean | sorry, one second, was in a meeting | 14:32 |
bdean | we've got a winner! /etc/cloud/cloud.cfg.d/99_oci_cloud.cfg | 14:34 |
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:35 |
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:37 |
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:39 |
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:41 |
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:42 |
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:43 |
minimal | s/why/which/ | 14:44 |
bdean | maybe they don't know what they're doing | 14:44 |
minimal | bdean: they're trying to save you from yourself ;-) | 14:48 |
bdean | ;_; | 14:48 |
minimal | any help to figure out why a single test is failing for #4128? I can't see what the problem actually is | 15:25 |
falcojr | minimal: I'll take a look | 19:06 |
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:24 |
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:37 |
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:38 |
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 | 19:40 |
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:34 | |
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:44 | |
meena | wow, i just realized: Python stuff gets installed without junk like tests. | 22:52 |
meena | can somebody at NPM please cop on. | 22:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!