[Bug 868184] New: Cloud-init not fully called on first boot up
https://bugzilla.novell.com/show_bug.cgi?id=868184 https://bugzilla.novell.com/show_bug.cgi?id=868184#c0 Summary: Cloud-init not fully called on first boot up Classification: openSUSE Product: openSUSE Factory Version: 13.2 Milestone 0 Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: Basesystem AssignedTo: rschweikert@suse.com ReportedBy: aj@suse.com QAContact: qa-bugs@suse.de Found By: Customer Blocker: --- When running a fresh image from susestudio with cloud-init support added, it seems that several modules are not executed. As far as i could debug, this is because the first boot of the instance only calls the "init" stage, config and final are missing/not executed. According to this bug report: https://bugzilla.novell.com/show_bug.cgi?id=823024#c0 Its fixed in Cloud:Tools. So I upgraded the package to this one: http://ftp5.gwdg.de/pub/opensuse/repositories/Cloud:/Tools/openSUSE_Factory/... But the problem seems not to be fixed. This is easy to check because all the modules for other stages are not executed at all. Funny side note: if you reboot the instance, it works fine. So I debugged a bit more and found the issue: the cloud-init stages Init-local, config and final are not called at first boot, because the generated first-boot-init-script from suse studio does only call the init and enables the boot scripts for the rest. But at this stage the boot scripts will not be executed anymore. So adding three more calls to the first boot script fixes this. ###################################################################### Next one: grub config seems to be ignored Affects: grub2/boot When booting an image for the first time, there was no console output, thus We where unable to get output for the openstack dashboard. I added the following String inside the kiwi scripts, to get console back to work: console=ttyS0,115200 console=tty0 So, by now, at first boot up I get some output which is shown inside the Dashboard, which is nice. But when I reboot the instance, the log disappears. After some checking I found that the grub.cfg seems to be ignored: # grep console /boot/grub2/grub.cfg linux /boot/vmlinuz-3.11.6-4-default root=UUID=ea5211a7-9e96-4060-ab8d-aae7010e5e80 root=/dev/vda1 disk=/dev/vda resume=swap quiet splash=silent console=ttyS0,115200 console=tty0 # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.11.6-4-default root=UUID=ea5211a7-9e96-4060-ab8d-aae7010e5e80 root=/dev/vda1 disk=/dev/vda resume=swap quiet splash=silent Console part is missing and no output is given. Is there any other part taking care about whats booted up and how beside the normal boot loader stuff? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=868184 https://bugzilla.novell.com/show_bug.cgi?id=868184#c1 --- Comment #1 from Robert Schweikert <rschweikert@suse.com> 2014-03-13 15:30:19 UTC --- The cloud-init package does not insert itself into the boot sequence when installed. This is a packaging decision, mine in this case. We can argue about whether or not the behavior of the package should be changed and I can probably convinced, with a sufficiently well presented argument, that cloud-init should force itself into the boot process upon installation. As such this is not a bug but a feature ;) I'll leave the bug open to provide a forum to discuss the "whether or not cloud-init should insert itself into the boot process" point. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=868184 https://bugzilla.novell.com/show_bug.cgi?id=868184#c Robert Schweikert <rschweikert@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Major |Minor -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=868184 https://bugzilla.novell.com/show_bug.cgi?id=868184#c2 --- Comment #2 from Robert Schweikert <rschweikert@suse.com> 2014-03-13 15:31:42 UTC --- There is also a simple fix in Studio, add suseInsertService cloud-init-local suseInsertService cloud-init suseInsertService cloud-config suseInsertService cloud-final into the config script editor. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=868184 https://bugzilla.novell.com/show_bug.cgi?id=868184#c3 Sven Michels <s.michels@external.telekom.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |s.michels@external.telekom. | |de --- Comment #3 from Sven Michels <s.michels@external.telekom.de> 2014-03-17 12:58:16 UTC --- Hi, i was the inital reporter of the problem. Let me give you some background why this popped up at all: We want to use SLES/SUSE Images on our OpenStack Service. When we first started using images from suse studio, we noticed that the growpart/resize filesystem feature doesn't work. So if you create an image with a 2GB partition and start it on a flavor with 10GB root disk, the root disk stays at 2GB. You can, of course, try to reclaim the space by yourself later, but thats not what we intent to have. We want to have the same feature of "auto growing" across all images. When playing around with a latest version of SUSE Images, the problem was still there. So i tried to fix it by myself adding the necessary stuff to the image (using overlaying archives or modify scripts afterwards). After adding the growpart stuff and run some tests it looked fine so far. But when i ported that one back to the base image, it stopped working. Reason was as described: the stages of cloud init where not executed. I'll try to rebuild an image with your "fixes", but it leaves me at the stage that i think this should work without such modifications. At all its a bit disappointing that suse studio does have an option/state like "the partition will grow to the full size of the disk later" when it simply doesn't work at all (nor has the feature at all.). So, i'll come back to this after some more tests. Best regards, Sven -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=868184 https://bugzilla.novell.com/show_bug.cgi?id=868184#c4 --- Comment #4 from Robert Schweikert <rschweikert@suse.com> 2014-03-17 13:38:33 UTC --- There are a number of things being intermingled here that are at best tangentially related. 1.) growpart (Growing of the root partition in a cloud image) This feature is currently not implemented in SUSE, period. I am actively investigating this and trying to figure out an approach that is sustainable and supportable. 2.) inserting cloud-init into the boot process cloud-init today can be inserted manually into the boot process of SUSE images. The package itself does not insert the boot code upon installation. This is a package design decision and can be changed, so far I have not seen any convincing arguments why it should be changed. 3.) Studio feature of "partition growing/image expansion" This feature is integrated into the initrd that is created by KIWI, the image builder and only applies to OEM images. Thsi si completely disconnected from the way cloud images are built. For the growpart problem we already have a bug: 861473 (most of the comments are private) This bug is titeled about integration of cloud-init into the boot process. If you only care about growpart, I'll mark it as a duplicate of the other bug. If you would like to present arguments why cloud-init should insert itself into the boot process I am willing to listen. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=868184 https://bugzilla.novell.com/show_bug.cgi?id=868184#c5 --- Comment #5 from Sven Michels <s.michels@external.telekom.de> 2014-03-17 15:27:50 UTC --- Hi, 1.) ok. 2.) i tried it via. studio and put it into "run script at the end of the build". Since i had some other stuff to check, i checked the result... and remembered why that didn't work for me: if [ "$bios" != 'SUSE Studio Testdrive' ]; then # cloud-init retrieves the keypair from SUSE Cloud/OpenStack chkconfig cloud-config on chkconfig cloud-init-local on chkconfig cloud-init on chkconfig cloud-final on # Workaround. The chkconfig calls are not starting cloud init right now. # This makes sure that cloud-init is running on first boot and creates # the required ssh credentials cloud-init init - see the workaround. Even if i enable it via the script it won't get started at the first boot this way. Ok, i can add the same calls also for config, init-local and final that way, should have the same effect as your workaround. 3.) So no expansion for normal cloud images. Can we build OEMs then? Regards, Sven -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=868184 https://bugzilla.novell.com/show_bug.cgi?id=868184#c6 --- Comment #6 from Robert Schweikert <rschweikert@suse.com> 2014-03-17 15:51:00 UTC --- 1.) The good news is that I have settled on an approach to solve the resizing problem. Thus, we will soon have a growpart package that will provide the growpart script. 2.) What you did doesn't look right, but I am double checking with the Studio team. First you want to use the kiwi provided function as outlined in comment #2. The guard against test drive is immaterial as the script as far as I know is run at build time, i.e. the service is enabled/inserted before you would be able to run it in test drive. Once cloud-init is enabled I am not certain the image will work in test drive. 3.) You cannot use OEM images. OEM images have a completely different layout. I suppose you can build an OEM image and then download and disassemble it and use the "inner" image, but that's not really all that pleasant either. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com