← Back to team overview

cloud-init team mailing list archive

questions as I read - boot phases


I know AIX. AIX does not use systemd (and internally it seems to be called sysv (aka sys5) the "ancient" AT&T "new" method rather than /etc/inittab. (And AIX, of course uses the UNIXv6/UNIXv7/'bsd' inittab approach.

So, there are few terms that are confusing:

Reading https://cloudinit.readthedocs.io/en/latest/topics/boot.html

* generator: what is a generator? What is cloud-init.target? (I suspect a systemd construct).

* local: in sysv terms this starts /etc/rc.d/rcX.d/SXX/cloud-init-local start

Saving me the hassle of reading all the code - what does this actually do. From the doc I conclude it is after the "root volume group has been mounted" - in AIX terms it is rather late in the game (e.g., /etc/rc.tcpip has already run). If it needs to be earlier then "I need to be thinking about changes to /sbin/rc.boot" because this is when AIX is still very early in the boot process (aka AIX boot phase 2, boot phase 3 is when programs start getting called via /etc/inittab entries (that - towards the end, call "/etc/rc.d/rc 2" (default run-level is 2).

I have never read any (official) documentation - but apparantly, to get it to work at all with AIX (and cloud-init-0.7.5) a configuration setting was added (there are two - related, but very different sys0 attributes: clouddev and ghostdev)

I am thinking "maybe" it is better to have cloud-init-local closer to AIX phase 2, rather than some magic in the background changing things as some vague time. All I can read is:

michael@x071:[/home/michael]lsattr -El sys0 | grep dev
clouddev 0 Recreate ODM devices on next boot True ghostdev 0 Recreate devices in ODM on system change True

Rumors say: ghostdev is to support the now defunct "Activation Engine" and clouddev is to support "cloud-init". I have, obviously, not looked hard enough for the documentation of these variables.

So much for my grief re: AIX documentation - my core-question is: Is this when the /var/lib/cloud area gets populated? And I am trying to (guess) find how the system knows on subsequent boots that the "first-boot" datasource - is no more. (Or is it considered "good practice" to modify /etc/cloud/cloud.cfg and add 'network: {config: disabled}'

From the docs:

"If this is an instance’s first boot, then the selected network configuration is rendered. This includes clearing of all previous (stale) configuration including persistent device naming with old mac addresses.

This stage must block network bring-up or any stale configuration might already have been applied. That could have negative effects such as DHCP hooks or broadcast of an old hostname. It would also put the system in an odd state to recover from as it may then have to restart network devices."

As we are in phase 3 - either the 'clouddev' entry above has stopped them from being activated (better, unconfigured then rediscovered) - then the 'rendering' can occur unhindered.

So, "when does /var/lib/cloud" get copied?

* network

docs say:

 * *runs*: After local stage and configured networking is up.
 * *blocks*: As much of remaining boot as possible.
 * *modules*: |init_modules|

|Thus, I conclude 'local' brings network up (while I was thinking - originally - local meant 'without IP support" ('local' DataOcean datasource permits (I read needs) network support even before networking is 'rendered'.

docs say: |
|This stage runs the |disk_setup| and |mounts| modules which may partition

So, except for the 'bootcmd' thre is probably nothing to do here (for AIX) as this has all be done during "phase 2" of /sbin/rc.boot

* config

docs: |
This stage runs config modules only. Modules that do not really have an effect on other stages of boot are run here.

|This is basically - what AIX boot phase 3 is: If this was NIM - I would call it "firstboot" scripts.
Question: this is the cc_* "stuff" in the ./config directory?

* final
This stage runs as late in boot as possible. Any scripts that a user is accustomed to running after logging into a system should run correctly here. Things that run here include

     * package installations
     * configuration management plugins (puppet, chef, salt-minion)
     * user-scripts (including |runcmd|).

|Again - lucky me: not really any different from the "config" stage, as far as the AIX boot process is concerned. For now - (on AIX) it is the phase that calls "runcmd", and will call 'reboot' (I expect it is this part that does that) when requested.

Anyway - thank you for your attention. I would appreciate feedback - where I got it wrong.
Once this flow is clear to me I will be better able to organize my effort.


Follow ups