Run a script upon entering runlevel 2

[zvivered]

Hello,

I'm booting Knoppix 6.7.1 from DOK.
The image on this media was created using a live CD.
Then I changed syslinux.cfg in 6.7.1 and now knoppix enters runlevel 2 (text mode) by default.

Upon entering this level I want to run my script.

So I added:
echo "My script"
in /etc/rc.local

But "My script" is not displayed.

According to another thread in this forum I tried putting my script in :
/opt/knx/knoppix/KNOPPIX/knoppix.sh

But this does not work also.

Can you help ?

Thanks,
Zvika.

[zvivered]

Dear members,

The script knoppix.sh should be put in the folder KNOPPIX (when the DOK is mounted under windows)

Thanks,
Zvika.

[lapidu]

Hi, Anyone know a way to inhibit execution of knoppix.sh with a boot command/cheatcode? This is useful when working on devices where you might not want your regular script to run.

[Werner P. Schulz]

You cannot inhibit the script knoppix.sh, but you can decide within this script what to do.

Append any cheatcode, for example
knoppix no_myscriptIn your script "knoppix.sh" test for existence of your cheatcode by
cat /proc/cmdlineIf the cheatcode is found, do nothing else; otherwise execute remaining of the script.

[lapidu]

Good idea Werner, thanks for the suggestion!

Here is my detailed explanation for novices, and a working code sample (tested on v6.7.1dvd), for those who wish to use this method:

knoppix.sh is executed during startup by a block of code that can be seen at the end of /etc/init.d/knoppix-autoconfig. If one wishes to undertake a deep remastering, it is possible to modify this code to build a script-inhibiting cheatcode into the system.

Alternatively, a conditional code block can be inserted at the start of knoppix.sh to parse /proc/cmdline, the kernel boot instructions, for a specified keyword, for example no_myscript. Use this keyword as you would a cheatcode, by typing knoppix no_myscript at the boot prompt, and the code shown below will suspend script execution; if the keyword is not entered, the script will execute as per normal.


string=$(cat /proc/cmdline); # Assign output of 'cat' to variable 'string'.

if [ "$string" != "${string/no_myscript}" ]; then # Check for presence of keyword.
echo "Stopping Script"
exit
else
echo "Running Script"
fiNote that knoppix.sh is not executed in Bash, but in a Bourne shell, so some more common Bash commands that check whether a variable contains certain text will not work properly; for instance, grep will not work, nor will [[ "$string" == *no_myscript* ]]. Hence my use of the clever method published by one ephemient on a thread at stackoverflow, and described by him as follows:


${var/search/replace} is $var with the first instance of search replaced by replace, if it's found (it doesn't change $var). If you try to replace [no_myscript] by nothing, and the string has changed, then obviously [no_myscript] was found.

[Werner P. Schulz]

Note that knoppix.sh is not executed in Bash, but in a Bourne shellIf you use within Knoppix the shebang-line
#!/bin/shyou'll get the Bash. '/bin/sh' is only a symlink to '/bin/bash'

[lapidu]

I see, and appreciate your input; as a novice myself I welcome and encourage criticism and instruction from others who know their stuff.

My comment was an inference based on the fact that certain alternative methods of checking for the presence of text in a string var worked in LXTerminal, but not in the lower runlevel root terminal at startup. Why is this the case?

I noticed that the shebang-line in /etc/init.d/knoppix-autoconfig invokes #!/bin/busybox sh. Does knoppix.sh therefore run in Busybox/Almquist shell, rather than Bash or sh?

[Werner P. Schulz]

While booting Knoppix only busybox is available (here '#!/bin/sh' is a symlink to busybox). After completion of bootprocess you can use Bash.

Within the init-script of minirt.gz you can see, how KK solved the problem using the function "checkbootparam()"

In the script knoppix.sh you can use a line like this:

cat /proc/cmdline | grep -q "no_myscript" && exit

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

Challenge: A user wants knoppix.sh to launch, or cause to be launched, a Leafpad window on his display. The window should be waiting for him once his graphical desktop loads. What code will allow him to do so?

Trying to run Leafpad, or any graphical program, from the root console results, of course, in a "Cannot open display" warning. I thought this challenge should have an obvious solution - the consoles and x-server are not totally insulated from one another, since they can all access the same filesystem, so there must be a simple command that can tell the console to make the x-server perform a job (e.g. launch a window) remotely, as it were. But so far my research and attempts have not found this 'simple command', if it even exists.

What do you think about the possibility of this challenge?

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

[Capricorny]

Challenge: A user wants knoppix.sh to launch, or cause to be launched, a Leafpad window on his display. The window should be waiting for him once his graphical desktop loads. What code will allow him to do so?

Trying to run Leafpad, or any graphical program, from the root console results, of course, in a "Cannot open display" warning. I thought this challenge should have an obvious solution - the consoles and x-server are not totally insulated from one another, since they can all access the same filesystem, so there must be a simple command that can tell the console to make the x-server perform a job (e.g. launch a window) remotely, as it were. But so far my research and attempts have not found this 'simple command', if it even exists.

What do you think about the possibility of this challenge?

Some 15 years ago, I could just have the script append the commands to my startx script, but since then X has developed from hack to complete kludge, and there is still some time before Wayland resques us from that. I tried with a local .xinitrc file - X initialized, but wouldn't stay up. So there are probably very good reasons for .xinitrc missing... I don't even remember when, along the way, I gave up on such things - but it seems to be a challenge today, and that tells us that something is basucally flawed.

[Capricorny]

I have found no universal way to do it, and several of the solutions on the net don't work with Knoppix/LXDE.

But, if you run LXDE, there is a relatively inelegant&hard-wired solution, documented on the LXDE Wiki: http://wiki.lxde.org/en/Autostart

Edit the file /etc/xdg/lxsession/LXDE/autostart and add the things you want to have run, prepended with an "@", like @leafpad, and add parameters as needed.
Then it worked for me, at least. Attempts at using only the user's .desktop file didn't succeed for me.

Thank you for the question, I'll need this myself to get virtualization set up automatically. :)

[lapidu]

Glad I asked, thanks for the response. Your solution does the job. Good idea looking up LXDE specifically.

The challenge remains open to a direct, universal solution.

The following command will enable any command-line console to launch graphical programs by allowing them to access the appropriate display via x, but the catch is that it must be executed within the graphical environment first; attempting to do so in a console gives a variant 'unable to open display' error. Hence it cannot be usefully included in knoppix.sh.


xhost +local:Once this is done, you can launch a graphical application from console by specifying the target display. For example, launch an instance of leafpad in default display :0 :


DISPLAY=:0 leafpadWhen you switch back to the desktop leafpad will open.

[Capricorny]

I'm afraid there is no universal solution at this time.
The main problem is that you may open displays as much as you like, but they are killed when X starts.

Therefore, the most universal solution tight now might be to setup LXDE to run something like "knoppix-x.sh" at start.