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]

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 leafpad

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