| Author |
Message |
sunburnt
Joined: 08 Jun 2005
Posts: 4016
Location: Arizona, U.S.A.
|
 Posted: Sat 10 Apr 2010, 02:35 Post_subject:
 Running another script at boot from init fail? [ Solved ] |
|
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: | ##############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.
Edited_times_total
|
|
Back to top
|
|
 |
amigo
Joined: 02 Apr 2007
Posts: 1776
|
| Posted: Sat 10 Apr 2010, 02:49 Post_subject:
|
|
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.
|
|
Back to top
|
|
|
sunburnt
Joined: 08 Jun 2005
Posts: 4016
Location: Arizona, U.S.A.
|
| Posted: Sat 10 Apr 2010, 03:04 Post_subject:
|
|
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: | | 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.
|
|
Back to top
|
|
|
amigo
Joined: 02 Apr 2007
Posts: 1776
|
| Posted: Sat 10 Apr 2010, 15:20 Post_subject:
|
|
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.
|
|
Back to top
|
|
|
sunburnt
Joined: 08 Jun 2005
Posts: 4016
Location: Arizona, U.S.A.
|
| Posted: Sat 10 Apr 2010, 16:00 Post_subject:
|
|
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
|
|
Back to top
|
|
|
DMcCunney
Joined: 02 Feb 2009
Posts: 894
|
| Posted: Sun 11 Apr 2010, 14:45 Post_subject:
|
|
| 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
|
|
Back to top
|
|
|
sunburnt
Joined: 08 Jun 2005
Posts: 4016
Location: Arizona, U.S.A.
|
| Posted: Sun 11 Apr 2010, 17:46 Post_subject:
|
|
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...
|
|
Back to top
|
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index » Off-Topic Area » Programming
