I figured it out myself: somehow PVE cached the Cloudinit.pm (The "Regenerate Image" button still works even if I moved away the file; I don't speak Perl but I think it's working as intended). I restarted pvedaemon.service and the iso generation is working as intended.
-- Zhuoyun Wei On Wed, Feb 13, 2019, at 02:09, Zhuoyun Wei wrote: > I did my little experiemnt: > > root@inf-vmh-3:~# for i in /dev/pve/*cloudinit; do grep package_upgrade $i; > done > Binary file /dev/pve/vm-104-cloudinit matches > Binary file /dev/pve/vm-110-cloudinit matches > > Look, there are two VM (104 and 110) that have "package_upgrade" > options in their cloud-init drive. > > - Click on "Regenerate Image" button while the VMs are powered on - the > config is still there; > - Power off the VMs - the config is still there; > - Clicking on "Regenerate Image" button while the VMs are powered off - > the entire LV is wiped (cat or strings shows nothing); > - Start the VMs - the config is still there. > > I am befuddled. I am sure that in "Cloudinit.pm" file, the relevant > code is commented out, so why does regenerated images still have that > option hard-coded? > > -- > Zhuoyun Wei > > On Wed, Feb 13, 2019, at 01:34, Zhuoyun Wei wrote: > > Hi again, > > > > sorry for bringing this up. I have commented out the code that > > generates hard-coded "package_upgrade: true" config in cloud-init drive > > two weeks ago. And all worked well, until today. > > > > Today I modified the hardware (CPU and memory) of a VM thru the Web UI, > > and rebooted the VM. After rebooting, the VM did a full system upgrade. > > I checked its /dev/sr0 and found "package_upgrade: true" was all there > > again. (But the Cloudinit.pm file I modified was okay) > > > > I am confused. Could someone explain to me how does the cloud-init iso > > generation work? What should I do to prevent the unsolicited iso > > re-generation? > > > > > > With regards. > > > > -- > > Zhuoyun Wei > > > > On Mon, Jan 28, 2019, at 10:45, Zhuoyun Wei wrote: > > > Thanks. I have filed a bug. [1] > > > > > > I am aware that cloud-init 0.7.9 is quite an old version. The good news > > > is, CentOS Team has rebased its cloud-init source to upstream version > > > 18.2 as of 2018-10 [2]. The new cloud-init package is already in the > > > repo (could be yum updated). But the latest pre-built cloud image is > > > 1809, so it is stuck at 0.7.9 for now. Highly likely cloud-init 18.2 > > > would be available in the next pre-built cloud image release. > > > > > > > > > Links: > > > [1] https://bugzilla.proxmox.com/show_bug.cgi?id=2068 > > > [2] > > > https://git.centos.org/blobdiff/rpms!cloud-init.git/c60dcdee662fa585e0ef611c5cd5c48078259a68/SPECS!cloud-init.spec > > > > > > -- > > > Zhuoyun Wei > > > > > > On Mon, Jan 28, 2019, at 23:28, David Limbeck wrote: > > > > Yes, that's currently the only way to disable package upgrades. Feel > > > > free to open an enhancement in our bugtracker. > > > > (https://bugzilla.proxmox.com/) > > > > > > > > Just a quick note, the cloud-init version in CentOS is old and some > > > > features don't work correctly or at all. > > > > > > > > On 1/28/19 3:47 PM, Zhuoyun Wei wrote: > > > > > Hi, > > > > > > > > > > I am trying to set up our first Proxmox server. I am using the > > > > > GenericCloud pre-built image by CentOS [1]. We use the exact same > > > > > image already in a public cloud provider. By re-using the same image, > > > > > we could replicate our production VMs in our office. > > > > > > > > > > After importing and starting the first VM in Proxmox, I found that > > > > > something was not quite right: the packages in the Proxmox VM were > > > > > newer than the packages in the cloud provider VM. After checking > > > > > logs, it turned out that cloud-init did a full system upgrade on > > > > > first boot (it upgraded CentOS 7.5 to CentOS 7.6). > > > > > > > > > > A further inspection revealed the roots of the issue: there was a > > > > > hard-coded "package_upgrade: true" config key in the generated > > > > > cloud-init config iso [2]. > > > > > > > > > > There was no way to override this config key as of cloud-init 0.7.9 > > > > > [3], which was used in the latest CentOS GenericCloud image. Could > > > > > Proxmox make a little improvement here and allow user to opt out the > > > > > full system upgrade after the first boot of the VM? The only > > > > > workaround I could see now is edit the CloudInit.pm file and comment > > > > > out that line. > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > Links: > > > > > > > > > > [1] https://cloud.centos.org/centos/7/images/ > > > > > [2] > > > > > https://git.proxmox.com/?p=qemu-server.git;a=blob;f=PVE/QemuServer/Cloudinit.pm;h=5be820c22d58b0cc0014e7dab6412f8d2db9132d;hb=refs/heads/master#l135 > > > > > [3] > > > > > https://cloudinit.readthedocs.io/en/0.7.9/topics/modules.html#package-update-upgrade-install > > > > > > > > > > > > > _______________________________________________ > > > > pve-user mailing list > > > > [email protected] > > > > https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-user > > > > _______________________________________________ pve-user mailing list [email protected] https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-user
