I’m using a Raspberry Pi with MicroOS and I wanted to force my already setup installation to re-run Ignition/Combustion.
In the docs it states that /boot/writable/firstboot_happened is created after the first successful boot. My system has rebooted many times and Ignition/Combustion did install some packages and created my user with my public key on its first boot. So it did run, but it did not leave the flag.
Combustion/Ignition also isn’t ran at every boot because of this missing flag, because otherwise my hostname would’ve changed. I changed my hostname in my config.ign.
I checked the source code of both the CoreOS upstream project on GitHub and the openSUSE additions on build.opensuse.org. I haven’t seen anything about a /boot/writable/firstboot_happened, maybe this is not implemented yet?
Based on the Ignition upstream code I did find a way to force Ignition to run again, but it’s not pretty.
In /etc/default/grub, add ignition.firstboot=1 to the GRUB_CMDLINE_LINUX_DEFAULT
Run sudo transactional-update grub.cfg
Reboot
However, this boot flag is persistent, it’s not cleaned up. But it’s better than re-image an SD card every time. This will help me test some stuff.
I’ll create a openSUSE Bugzilla issue later this week.
This is generator that checks kernel command line and arranges for the first boot to start if ignition.firstboot=1 is present. But looking at it - it runs before real root is mounted so you most certainly cannot use any flag file on root to do it.
You may consider adding grub boot menu entry with ignition.firstboot=1 and using grub2-reboot (or grub2-once) which will use it just for the next boot.
Thanks for the Grub suggestions, but the current workaround is fine to continue my testing. But the documentation seems to be wrong though. Will create a Bugzilla issue later.
Can you please elaborate again? If you mean that /ignition.firstboot is used as a boot flag, then that doesn’t account for MicroOS, since / is read-only. That’s why I suppose the /boot/writable directory was created. I did however use transactional-update run touch /ignition.firstboot. But that didn’t trigger Ignition again at boot. But if you don’t mean this with your hint, then please let’s not waste each other’s time
Your grub.cfg has to include this snippet and your kernel command line has to include $ignition_firstboot. I do not use ignition so I have no idea where the above code gets installed. I expect you can browse package files that are installed and figure it out. But if you spent a bit of your time reading ignition package changelog and browsing OBS history for this package and/or github history you would have seen that /boot/writablewas used by ignition in the past and then replaced by another method. To which extent this another method was adopted by MicroOS I do not know. ignition is not installed on my MicroOS image (actually, this is systemd-boot image so even grub2 is not used).
I’m not sure why you tell me this, I already found this mechanism. That indeed works to initiate the Ignition. But I created this topic because the documentation seems out of date or the openSUSE additions to Ignition are buggy.
Which changelog do you mean exactly? That of the upstream Ignition project? Or the openSUSE package? I’ve checked the changelog already. I did a recursive grep over the whole source code for keywords like firstboot, but I didn’t see anything that reflects with the documentation. Therefore this topic.
Which part exactly do you mean from the changelog? Please be specific. Because when I saw this, I didn’t read it as verbatim replacing the boot flag.
- Replace ignition-dracut-grub2 with combustion's firstboot.target:
* Add 0001-Order-ignition-disks.service-before-systemd-fsck-roo.patch
* Edit ignition-suse-generator
* Edit ignition-umount-initrd-fstab.service
* Edit module-setup.sh
* Drop 02_ignition_firstboot
* Drop ignition-firstboot-complete.service
* Adjust README.SUSE
Where can I see the git repo of Ignition? I did see the osc command, but then I still don’t get a git filesystem. If I can go to an older commit then I can see what exactly happened.
So by checking the changelog of the wiki and the changelog of git, I can confirm that the wiki is out of date. There are 2 ways of fixing this. One way is to rewrite the section about the firstboot, the other one is by just linking to the README section that explains the firstboot part. Then it will be linking to a part that’s always up to date and avoids confusion going forward.
However, by maybe enriching the README on Github with the info on the wiki, there would be no need to maintain stuff in 2 places either. Then there is no ‘split-brain’ possibility anymore. Everything would then be in one place, the Github project. The wiki can just redirect straight to it.
What does the community think? The easy fix is to just link the firstboot part in the wiki to the README on Github. Merging the wiki stuff into the README is another subject I suppose. It would also be more work, because I then have to check if nothing else is out of date.
