(old)Puppy Linux Discussion Forum

Posted: **Sat 10 Apr 2010, 06:35**

I wanted to be able to develop boot code without having to rebuild the initrd.gz file all the time.
So I put "jump points" in the init file that execute another file "init_ALT" in the same shell.
Starting at line 375 in the init file:

Code: Select all

##############END MODULE LOADING TO ACCESS DRIVES####################

if [ "$palt" ];then
  if [ "$pdev" -a "$psubdir" ];then
    echo -n "###   Mount Puppy home device." >/dev/console
    mkdir -p /initrd/mnt/dev_save
    mount /dev/$pdev /initrd/mnt/dev_save                                # mount home device
    mount |grep $pdev |sed 's/ type.*$//' >/dev/console
    echo '###   Mount Error:   '$? >/dev/console
    echo -n "###   Jump #1 to alternate init file." >/dev/console
    . /initrd/mnt/dev_save/$psubdir/init_ALT alt1                       # jump to alt. init file
  fi
fi
if [ ! "$findPfiles" ];then                                                            # skip or run this section

#######################FINDING PUPPY FILES##########################

I made a new boot argument: $palt to trigger the jump.
Then it checks for the boot arguments: $pdev and $psubdir
If they exist then it makes the proper mount point and mounts the Save device $pdev.
Then it runs the external file ( external to the initrd.gz file ).

As you might suspect, it loads the inital modules and then kernal panic ... tried to kill init!
I don`t see any of my code causing a problem except for the execution of the external file.

Posted: **Sat 10 Apr 2010, 06:49**

If you want the alternate file to be run and not return to the original script, then you need to use 'exec':
exec /initrd/mnt/dev_save/$psubdir/init_ALT alt1

Another possible problem, the shell being used by the initrd is probably not bash. In that case, 'sourcing' your alternate script with an argument like this:
. /initrd/mnt/dev_save/$psubdir/init_ALT alt1
may not be working (the 'alt1' may be ignored). If that is the case, you'd need to use soemthing like:
MYALT=alt1 . /initrd/mnt/dev_save/$psubdir/init_ALT
and include code in init_ALT which 'picks up' the MYALT variable value.

Posted: **Sat 10 Apr 2010, 07:04**

Hi amigo; I do want the init_ALT script to return to init. It sets the variable $findPfiles
This test in init then runs the next block of code or not depending on how init_ALT set $findPfiles

Code: Select all

if [ ! "$findPfiles" ];then

You may be right about just setting a variable and letting init_ALT pick it up.
But I`d think that the argument would have a better chance, variables can die in the boot process.

Posted: **Sat 10 Apr 2010, 19:20**

What I'm getting at is that bash when 'sourcing' another script (the '.'), it will pass the $1 argument along. ash and other shells do not pass any positional args when *sourcing* another script, so you have to pass any args as environmental variables as shown before, or use 'exec' or simply 'running' the script like this:
/initrd/mnt/dev_save/$psubdir/init_ALT alt1

Put some echoes in your script fragment to debug it, or replace key command swith echos/dummy commands, then open a terminal, run the shell which is being used by the initrd and see if sourcing the file is working as expected.

Posted: **Sat 10 Apr 2010, 20:00**

I get what you`re saying, The argument "alt1" isn`t critical to getting the external script to run.
It may ( probably ) won`t pass the argument, but that`s not the reason it goes into kernel panic.
It panics immediately after the: echo -n "### Jump #1 to alternate init file." >/dev/console
I have "echo" in init_ALT and they never show up.
It seems that it doesn`t want to leave the init script at all.

I modded the code lines ( shown above ) and this line produces no output:
mount |grep $pdev |sed 's/ type.*$//' >/dev/console

Posted: **Sun 11 Apr 2010, 18:45**

sunburnt wrote: I modded the code lines ( shown above ) and this line produces no output:
mount |grep $pdev |sed 's/ type.*$//' >/dev/console

Is there in fact output to display?

What is $pdev set to? How do you know?

You might want to check the exit status of grep: it normally returns 0 if matches are found, 1 if no matches, or 2 if an error occurred.
______
Dennis

Posted: **Sun 11 Apr 2010, 21:46**

Success! It ran the init_ALT file, returned to the init file, and booted to the desktop!
So now I have some small external control over how Puppy boots and the code that`s run.
Now if I can just wade through all the boot variables that control all the possible ways to boot...

(old)Puppy Linux Discussion Forum

Running another script at boot from init fail? [ Solved ]

Running another script at boot from init fail? [ Solved ]