Run a script upon entering runlevel 2

[lapidu]

Yes, your code above works at boot, and is more elegant.

My initial attempt with grep used a different syntax which worked in Bash but returned an error at boot, hence my incorrect statement that "grep will not work" in a post above; grep function is included in BusyBox and will indeed work at boottime.

[Capricorny]

Yes, your code above works at boot, and is more elegant.

My initial attempt with grep used a different syntax which worked in Bash but returned an error at boot, hence my incorrect statement that "grep will not work" in a post above; grep function is included in BusyBox and will indeed work at boottime.

Sure it is elegant! As regards busybox, I'm not so sure: As soon as main file system is mounted, I would think bash is available. So, Klaus K's reason for explicitly using /bin/busybox may, for example, be to have the same semantics during the whole init process. During minirt init, he has made only busybox available (other booting procedures stuff lots of core utilities into that image), and busybox does its things somewhat differently from standard gnu coreutils.

Also, what commands busybox contains and not depends on the compilation. You may find that other versions can have more or fewer commands than this one, which I think may be the standard Debian version.

[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.