kairos
kairos copied to clipboard
booting stages are not running in the order as designed(documented)
Kairos version:
# kairos version
version: 2.6.4, compiled with: go1.21.7
CPU architecture, OS, and Version:
arch: amd64 os: ubuntu 22.04 Describe the bug
I encountered a strange issue where I found that the command code executed during the boot stage always runs after the runcmd and network stages.
To Reproduce
Here are my experiment results: cloud-config:
runcmd:
- echo "runCmd" >> /etc/tmp
stages:
initramfs:
- commands:
- echo "initCmd" >> /etc/tmp
name: "Init Stage"
boot:
- commands:
- echo "bootCmd" >> /etc/tmp
name: "Boot Stage"
network:
- commands:
- echo "networkCmd" >> /etc/tmp
name: "Network Stage"
After the system starts, the /tmp/tmp file looks like this:
# cat /etc/tmp
initCmd
networkCmd
runCmd
bootCmd
Expected behavior
According to document, expected order should be:
# cat /etc/tmp
initCmd
bootCmd
networkCmd
runCmd
Logs
Additional context
Hello, I'm a bot assisting in the triage process for the kairos project. Thank you for reporting this issue. However, we need more information to properly assess and resolve the issue.
Please provide the following details:
- What is the exact command you used to start the kairos instance?
- Which versions of kairos, cloud-config, and any other relevant artifacts are you using?
- Can you verify if this behavior is consistent across different instances or environments?
Once you provide this information, please add it to the issue description, and I'll be sure to update the labels accordingly. Thank you for your cooperation!
I am a bot, an experiment of @mudler and @jimmykarily helping with issue triage. If you have any questions, feel free to ask.
Network stage runs when network becomes available. Thus, it can happen before or after other stages. The problem in docs is this image: https://user-images.githubusercontent.com/2420543/195111193-3167eab8-8058-4676-a1a0-f64aea745646.png which implies that it always runs after boot stage.
Regarding runcmd, It's not documented when it runs (and as you see it run just before the boot stage). We need to document this too.
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days.