Run a script upon entering runlevel 2

[lapidu]

Hi Capricorny!

Interesting points. Is what you call the main filesystem the large KNOPPIX file? This appears to be the first thing that the init script mounts, hence Bash ought to be available prior to knoppix.sh execution, if what you think is correct.

I retrieved one of my original attempts, upon which I made the claim that some code worked in Bash but not at boot, and tested it again; it works correctly in a Bash terminal, likewise in root console post-boot (that is to say, after INIT enters runlevel 2), but is improperly implemented at boottime execution of knoppix.sh. Quite peculiar. If you are interested let me know and I'll post it.

Running /bin/busybox will list the functions defined in the BusyBox version installed on that workstation. As you say, these functions might not be shared by all versions of that program, and this is especially the case given the openness of GNU/Linux and associated software. Best practice entails specifying versions!

Now, a related question has emerged, and I'll post it next.

[Capricorny]

Is what you call the main filesystem the large KNOPPIX file? This appears to be the first thing that the init script mounts, hence Bash ought to be available prior to knoppix.sh execution, if what you think is correct.

You may unzip and look at the minirt.gz init script to see what is going on at the initial stages of booting.

The KNOPPIX image is cloop-mounted (or squashfs-mounted if it has been compressed that way, other schemes are also possible), and there may be several overlays mounted the same way, to be unionfs-mounted with persistent store(s). If you have updated any system programs, the new versions will reside in the persistent store (or overlays, if you compress stuff iteratively).

The knoppix-autoconfig script uses several system programs, so I would think they are all accessible, and the invocation of knoppix.sh is at the end of this script. Maybe there is some kind of "call frame"
here, making that run under busybox if the calling script does? I don't know much about this, you see .

As for busybox components, you may roll your own. For example, you may need more commands during minirt init, or you come across some incompatibility. Important uses of busybox are in phones and embedded devices, where there may never be full version core utilities available.

PS:

 grep -s -w -i "no_script" /proc/cmdline && exit

might be an even shorter way to implement that cheatcode? (Haven't tried, may also be busybox limitations for grep.)

[lapidu]

...might be an even shorter way to implement that cheatcode? (Haven't tried, may also be busybox limitations for grep.)...

That works, and the grep -w switch is especially recommended to anyone using a non-distinct assigned keyword that could be unintentionally matched by parts of other boot option words/phrases.