init development

Under development: PCMCIA, wireless, etc.
Message
Author
User avatar
Crash
Posts: 453
Joined: Fri 09 Dec 2005, 06:34
Location: Melbourne, FL

init development

#1 Post by Crash »

This post describes a modification to the init file within initrd.gz that allows the puppy save file to be specified by the boot loader. This is useful if you have several pup_save files, and want to just boot into one of them without having the Kernel stop to ask you which one you want.

The modification consists of only five lines of code. In the section of initrd that chooses the pup_save file, the lines between the comments are added:

Code: Select all

...
PUPMODE=0
#choose which pup_save.2fs to use...
if [ -f /tmp/MULTIFOLDERS ];then #multisession cd/dvd.
 if [ "$PRAMONLY" = "yes" ];then #v3.97 fix 'pfix=ram' for multisession dvd.
  PUPSAVE=""
 else
  PUPMODE=72 #77 v3.01 64+8, will become 77.
  PUPSAVE="`cat /tmp/MULTIFOLDERS | cut -f 1-3 -d ' ' | tr ' ' ','`" #only record 1st folder.
 fi
else
 #Added PUPSAVE code
 [ $psave ] && PSAVE=$psave #Explicit pup save file. ex: pup_save.2fs pup_save2.2fs
 if [ $PSAVE ]; then
   grep "$PSAVE" /tmp/PUPSAVE2FSS > /tmp/PUPSAVTMP
   mv -f /tmp/PUPSAVTMP /tmp/PUPSAVE2FSS
 fi  
 # End added code
 NUMPUPSAVES=`wc -l /tmp/PUPSAVE2FSS | tr -s ' ' | cut -f 2 -d ' '`
 [ "$PRAMONLY" = "yes" ] && NUMPUPSAVES=0 #pfix=ram is a boot param.
 case $NUMPUPSAVES in
 ...
A new parameter, psave, is passed from the boot loader to the Kernel. With linld, typical boot loader code would be:

boot code:

Code: Select all

LINLD.COM image=D:\linux\puppy\p412\vmlinuz initrd=D:\linux\puppy\p412\initrd.gz cl=@D:\PUPPY.LIN
contents of puppy.lin:

Code: Select all

root=/dev/ram0
pmedia=idehd
acpi=on
psubok=TRUE
psubdir=linux/puppy/p412
psave=pup_save2.2fs
At first, I just used the pupsave parameter, but it has a rather long set of parameters that must be specified:

Typical pupsave parameter:

hda3,ext2,/pup220/pup_save.2fs

The psave parameter actually can contain the same type of format as pupsave, or can contain abbreviated forms:

psave=sda2,vfat,/linux/puppy/p412/pup_save2.2fs
psave=pup_save2.2fs
psave=2.2fs
psave=2.2

They all have the same effect, since all available save files have been identified by this time in the init code; then grep does all the work.

If you have save files of the same name but in different partitions, you can simply specify the partition:

psave=sda2

There are all sorts of combinations that can work for your specific situation.

The code is not elegant (hey, I've only been doing shell scripts for a month, give me a break), but is very robust. If there is a match, the appropriate save file is loaded. If there are still multiple matches, the original menu comes up to give your choices. If there is no match, Puppy still boots, just with no save file.

All this description for five lines of code. Actually, its all the other neat code in init that these five lines take advantage of that makes this feature really cool.

Note: This version of init is from Puppy V4.12 initrd.zg, and also contains the modifications discussed in a previous post
http://www.murga-linux.com/puppy/viewtopic.php?t=36703

Contents of the init file:
Attachments
init.gz
Modified init file from Puppy V4.12 initrd.gz
(16.87 KiB) Downloaded 998 times

User avatar
WhoDo
Posts: 4428
Joined: Wed 12 Jul 2006, 01:58
Location: Lake Macquarie NSW Australia

Re: init development

#2 Post by WhoDo »

Crash wrote:This post describes a modification to the init file within initrd.gz that allows the puppy save file to be specified by the boot loader. ...[snip]...
A new parameter, psave, is passed from the boot loader to the Kernel. ...[snip]...
The psave parameter actually can contain the same type of format as pupsave, or can contain abbreviated forms:

psave=sda2,vfat,/linux/puppy/p412/pup_save2.2fs
psave=pup_save2.2fs
psave=2.2fs
psave=2.2

They all have the same effect, since all available save files have been identified by this time in the init code; then grep does all the work.

If you have save files of the same name but in different partitions, you can simply specify the partition:

psave=sda2

...[snip]...
Note: This version of init is from Puppy V4.12 initrd.zg, and also contains the modifications discussed in a previous post
http://www.murga-linux.com/puppy/viewtopic.php?t=36703
Thanks, Crash. Much appreciated. 8) I have downloaded your update for inclusion in Puppy-4.2a3 or b1 - a2 is pretty much fixed at the moment, ready to be uploaded PM tomorrow 26 January.

It sounds like a very useful inclusion. Thank you. If you feel like tackling anything else, take a look at the Developer's ToDo List on the puppylinux.org wiki. There are a couple of challenges there for a script debugger. :wink:

Cheers
[i]Actions speak louder than words ... and they usually work when words don't![/i]
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#3 Post by Pizzasgood »

Just a thought: if you look nearer to the top of the file, you'll see where the other parameters are handled. It would be good to also add some kind of mention up there about it. Like a comment before or following the block of other ones explaining which variable is set and what it's used for. That way we can look in that one spot and know exactly which extra parameters Puppy can handle.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

User avatar
Crash
Posts: 453
Joined: Fri 09 Dec 2005, 06:34
Location: Melbourne, FL

#4 Post by Crash »

WhoDo-

Thanks for the positive response. The more I look at the way Puppy Linux is put together, the more I learn and the more interesting things get. Anything that I can pass on to the community is small payback in comparison to the benefit that I receive.

Looking at the todo list, there are some things I will explore. If any look like things that I think I am capable of addressing, I'll let you know. Most of the roots of my experience are in assembly language and hardware/software interaction. I'm not too good at things like apps and GUIs, but the boot process fascinates me. Thus the concentration in things like Wakepup, boot methods, and now, the Kernel startup process.

Pizzasgood-

I was flipping a coin between including the first statement of the added code in the area at the front of the init file or keeping it with the body of the added code. From a clarity viewpoint of explaining it, I kept it attached to the added code. But in a final version, all the references should be in one place for the reasons you stated. Thus the two lines:

[ $psubok ] && PSUBOK=$psubok #All puppy files in PSUBDIR. ex: TRUE

and

[ $psave ] && PSAVE=$psave #Explicit pup save file. ex: pup_save.2fs pup_save2.2fs

should be able to be moved to the code at the start like this:

Code:
[ $pmedia ] && PMEDIA=$pmedia #boot parameter, broad category of boot media. ex: cd.
[ $pdev1 ] && PDEV1=$pdev1 #boot parameter, partition have booted off. ex: hda3
[ $psubdir ] && PSUBDIR=$psubdir #boot parameter, directory for puppy files. ex: puppy220
[ $psubok ] && PSUBOK=$psubok #boot parameter, all puppy files in PSUBDIR. ex: TRUE
[ $psave ] && PSAVE=$psave #boot, explicit pup save file. ex: pup_save.2fs pup_save2.2fs

I'll make this change and verify that it works OK. I have no reason to believe it won't, but I learned long ago that the last minor change that I do to a program is usually the one that breaks it.

... Another thing that I didn't mention in this post: The psave parameter can be used in conjunction with the psubdir/psubok parameters, but its function is independent and it can be used stand-alone. Any combination can be used, which gives a lot of flexibility. A lot of times I even set the pmedia parameter to null, which gives even more opportunity to get interesting combinations for testing.

/// Edited Jan 27

Attached is an updated init file with the two definitions moved up front. As expected, it works the same as the original post, just is a little more self-documenting.

P.S. One ToDo that catches my eye is "Missing pup_save.2fs file error dialog - what to do next". I'll take a look and see if there is anything I can do with it. Also, the "Investigate problem with PUI and Grub not installing properly" is another good one. I'm not real fast, so don't hold your breath. But there are some definite possibilities.
Attachments
init.gz
Modified init file from Puppy V4.12 initrd.gz
(16.87 KiB) Downloaded 966 times

vg1
Posts: 142
Joined: Sun 02 Dec 2007, 18:56

#5 Post by vg1 »

Crash,

thanks for this, exactly what was need.
Both psave & psub work on the 4 and 3 series. So all my 3 and 4 series puplets are now in subfolders, and have their dedicated grub entries for different flavours of the same puplet. The 2 series init search code is too different to implement this. At least for me.

I nice refinement in psave is that I need only specify the actual diff in file name, 1.2 or new.2 etc.

A side note, I haven't noticed any decrease in boot time with the new init. I suppose this is because I always specified all params in grub so the search was never extensive.

vg

big_bass
Posts: 1740
Joined: Mon 13 Aug 2007, 12:21

#6 Post by big_bass »

crash
P.S. One ToDo that catches my eye is "Missing pup_save.2fs file error dialog - what to do next". I'll take a look and see if there is anything I can do with it. Also, the "Investigate problem with PUI and Grub not installing properly" is another good one. I'm not real fast, so don't hold your breath. But there are some definite possibilities.

Hey crash

nice thread thanks for starting it

the missing pup_save2fs error ???

that is a blessing

I never use a pup_save :D

which allows me multiple puppy installs
some as a change root environment
and others installed on different drives

and I can test any live CD version of puppy without fear
of an auto update borking my carefully configured setup

there are many ways to come to a solution which is the best ?
the one that works for you

I by passed the initrd.gz I dont even use the one for puppy at all
I use a very simple basic one
but I do use the init so that all is detected correctly *that is needed
the kernel takes care of the rest

you'll notice that many modules are not included
in the default puppy * one issue is my monitor
and my box not powering off
which I finally resolved

this is not a complaint
puppy has worked well on many
other machines I used
except my main box
had those glitches
*just in case Barry reads this :D

btw I dont use the puppy kernel either
I boot puppy off a full slackware kernel

please crash
if you have the time remove the

auto update to the newer puppy version
that will make a lot of people happy

yank that part out please, please, please

big_bass

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#7 Post by Pizzasgood »

please crash
if you have the time remove the

auto update to the newer puppy version
that will make a lot of people happy

yank that part out please, please, please
I've already done that with the init script that was used in the Puppy 4.2 alphas.
http://www.murga-linux.com/puppy/viewto ... 117#267117

I provided a patch (which are just the output of diff) so it should be pretty easy for you to add that to your modified version, or for anybody to add it to any version of the init script that isn't drastically different from the one in 4.1.2.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

big_bass
Posts: 1740
Joined: Mon 13 Aug 2007, 12:21

#8 Post by big_bass »

Pizzasgood

you hit that in the Bulls-eye

with the no update pup save

I am really shocked you didnt get a big
response there?

I missed that post
to my loss


thats great work
and long awaited

thanks for the link
Pizzasgood


big_bass

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

Re: init development

#9 Post by Dougal »

Crash wrote:At first, I just used the pupsave parameter, but it has a rather long set of parameters that must be specified:

Typical pupsave parameter:

hda3,ext2,/pup220/pup_save.2fs

The psave parameter actually can contain the same type of format as pupsave, or can contain abbreviated forms:

psave=sda2,vfat,/linux/puppy/p412/pup_save2.2fs
psave=pup_save2.2fs
psave=2.2fs
psave=2.2

They all have the same effect, since all available save files have been identified by this time in the init code; then grep does all the work.

If you have save files of the same name but in different partitions, you can simply specify the partition:

psave=sda2

There are all sorts of combinations that can work for your specific situation.
I'm not sure if it's very responsible to allow any string to be given, as it opens the door for confusion and possibly errors (though you can take care of that, to a certain degree, by using grep -m1).
When I implemented this feature in my init script, I used the PUPSAVE format intentionally, as it makes it much easier to remember what the format should be, plus you just need to copy it from /etc/rc.d/PUPSTATE -- either by hand, or if you want to make the installer add it to grub.conf.

Note also that if you get it in the PUPSAVE format, you could bypass searching the HD for files altogether, thus speeding up boot-time considerably.
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

User avatar
WhoDo
Posts: 4428
Joined: Wed 12 Jul 2006, 01:58
Location: Lake Macquarie NSW Australia

Re: init development

#10 Post by WhoDo »

Dougal wrote:I'm not sure if it's very responsible to allow any string to be given, as it opens the door for confusion and possibly errors
Hi Dougal. Speaking as someone who is perpetually confused and open to errors, would it be possible for you to take a look at the init from Alpha4 and blend in both PG and Crash's changes in a way that you would consider a safer, less error prone way? Please hear my pleas and pleasure me with a "yes", Dougal, buddy ... pal ... mate ... :P
[i]Actions speak louder than words ... and they usually work when words don't![/i]
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com

User avatar
Crash
Posts: 453
Joined: Fri 09 Dec 2005, 06:34
Location: Melbourne, FL

#11 Post by Crash »

I thought this thread died a while ago. It's good to see some more comments. A lot of times, I have absolutely no idea if what I say is useful or not. So I appreciate the feedback.

Bear with me - my original software background is in embedded systems, where "we don't need no stinkin' operating system", where you have complete control over the entire software set, 'cause you wrote every bit of it and can only blame yourself if it doesn't work. I lost interest as the Microsoft products became more and more impenetrable. Puppy Linux is refreshing, as the open source lets me get back to my roots.
responsible
First I'm told to drink responsibly, now I've got to code responsibly! You're asking a lot...

I thought it was OK, because the search process is undisturbed - all the psave parameter does is further filter the results. I tried using the pupsave parameter directly, but if I had a typo, the boot process would choke and dump me to the shell prompt - probably the most common boot complaint that I see on the Forum. If I make a typo using the psave parameter, the worst that happens is the the boot process finishes without a save file being loaded. Leaving out the parameter entirely makes the original code execute unaltered. I thought this is pretty safe.

I tried the -m1 parameter, but was getting conflicting results between tests I did in Rxvt vs. when inserting it in the actual init file. Maybe different behavior in two different shells? This is where my relative lack of experience is showing. At any rate, after messing with the code as it is now, it started to grow on me. I would have liked to simply differentiate between "save" and "save2", without having to add the dot, but I couldn't figure out how to do that. Thus the form that I finally presented.
Missing pup_save.2fs file error
Actually, I haven't seen this problem for a while and was thinking of concentrating on the "pup_xxx.sfs file not found" issue instead. But I get too confused if I mix up my comments about this issue vs. the one I originally brought up here, so I'll leave it for a different post.
remove the auto update
I applaud Pizzasgood's work on this issue. I find it to be an irritant. I also find the automatic copying of the pup_xxx.sfs file from a live CD to the hard drive to be an irritant. Some things are best done only if you explicitly want them to be done.

// Edited an hour later: The parameter I tried was -w, not -m1. It works in Rxvt but not in the main body of init. With it, you can distinguish between "pup_save" and "pup_save2" without adding the .2fs at the end. But I still like the code intact better. It gives the most flexibility. As I said in the original post, it is extremely robust.

User avatar
WhoDo
Posts: 4428
Joined: Wed 12 Jul 2006, 01:58
Location: Lake Macquarie NSW Australia

#12 Post by WhoDo »

Crash wrote:Some things are best done only if you explicitly want them to be done.
So, just for practice :P will you meld your code into the current init supplied in the post above so I can use the combined init for the next release?

Trust me, you don't want me messing around with code in init files! If I did we could be waiting until my granddaughter's graduation for the next stable Puppy release. My granddaugher is just 2 weeks old tonight. :roll: Pizzasgood was kind enough to supply an actual patch with an install script, but I'd just be happy if you added your code to the current version that already includes PG's and posted it back here. 8)

Cheers
[i]Actions speak louder than words ... and they usually work when words don't![/i]
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#13 Post by Pizzasgood »

I also find the automatic copying of the pup_xxx.sfs file from a live CD to the hard drive to be an irritant. Some things are best done only if you explicitly want them to be done.
I've done that too.
http://www.murga-linux.com/puppy/viewto ... 093#273093
This particular change doesn't seem to be included in the above initrd.gz file WhoDo uploaded.
Last edited by Pizzasgood on Sat 14 Feb 2009, 04:47, edited 1 time in total.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#14 Post by Pizzasgood »

@WhoDo: you should probably remove of the init-original file you have in there. I think it's actually from 411, not 412, but either way it isn't needed. We can just look at the actual initrd.gz file from 412.

I have some free time tonight, so I'll create a patch with Crash's changes and show how I did it. May come in handy for you. I won't, however, actually be testing this (other than making sure it applies properly). I'm going to spend the rest of my free time comparing Git and SVN. Caneri's all ready to go, so we just need to determine which will be best. I'm personally favoring Git at this point, as it would work best for me, but that may not be the best choice for Puppy at large, which is what matters, not me.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

User avatar
Crash
Posts: 453
Joined: Fri 09 Dec 2005, 06:34
Location: Melbourne, FL

#15 Post by Crash »

Here is the stuff folded together. I have it in three forms - initrd.gz, just the init file, and a diff comparison with the init that was in the initrd.gz file posted above.

Initrd.gz is a little bit larger since I kept the last version of init, renaming it to init-original2.

Note I did this work while two more posts were taking place ... Things happen too fast for me!

Pizzasgood- I did this work before I read about you addressing the "automatic copying of the pup_xxx.sfs file from a live CD" issue. I was busy testing this version that I'm posting, so I didn't get a chance to include that into it. Looks like there will be one more go-around.
Attachments
diff.txt.gz
(527 Bytes) Downloaded 983 times
init.gz
(17.19 KiB) Downloaded 1001 times

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#16 Post by Pizzasgood »

Okay, here's the complete init script.

Note: I have not tested this.

I used .tar.gz rather than just .gz, because .gz doesn't preserve permissions. This way WhoDo doesn't have to remember to make sure it's set executable.

By the way, if you make the patch file end in .diff or .patch, then Geany will automatically use syntax highlighting when you read it. And if you use the -u parameter, it will have diff output additional context information, which allows the diff file to be used to patch other versions of the file, so long as the differences between those versions and the version you used aren't too large, and don't overlap the changes you made. Otherwise diff just uses line numbers, which means the patch can only reliably be used against the same original file as the one you used.

I usually use diff -u if I'm dealing with a single file, or diff -Naur if dealing with multiple files. The latter requires different syntax to apply the patch than the former though.
Attachments
init.tar.gz
Includes no auto copy pup_xxx.sfs, no auto update, and option for supplying psave and psubok boot parameters.
(17.13 KiB) Downloaded 482 times
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

User avatar
Crash
Posts: 453
Joined: Fri 09 Dec 2005, 06:34
Location: Melbourne, FL

#17 Post by Crash »

Cool! I'll hammer on this over the weekend and try to break it. If it survives me, it probably will survive anyone.

User avatar
WhoDo
Posts: 4428
Joined: Wed 12 Jul 2006, 01:58
Location: Lake Macquarie NSW Australia

#18 Post by WhoDo »

Pizzasgood wrote:@WhoDo: you should probably remove of the init-original file you have in there. I think it's actually from 411, not 412, but either way it isn't needed. We can just look at the actual initrd.gz file from 412.
Ok, will do. That's just my conservative side coming out. I didn't realise it was being bundled in the initrd! :shock:

Git got a good review somewhere I was looking recently ... can't remember where but it was somewhere that really impressed me and made me think you were on the right track because I remembered you favoured it too. :idea:
[i]Actions speak louder than words ... and they usually work when words don't![/i]
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

#19 Post by Dougal »

Crash wrote:
responsible
First I'm told to drink responsibly, now I've got to code responsibly! You're asking a lot...
Better than the kind of things they try and teach kids these days...
I tried using the pupsave parameter directly, but if I had a typo, the boot process would choke and dump me to the shell prompt - probably the most common boot complaint that I see on the Forum. If I make a typo using the psave parameter, the worst that happens is the the boot process finishes without a save file being loaded. Leaving out the parameter entirely makes the original code execute unaltered. I thought this is pretty safe.
Well, part of my choosing the PUPSAVE format was because it's not something you're likely to type... you'll copy it or have the installer put it into grub.conf. Also, note that if you detect it, you can actually check that the file exists (mount partition, check for file...). Anyway, the reason I put it in is to enable skipping the search part, which also means PUPSFS, so unless you do that it doesn't really matter.
// Edited an hour later: The parameter I tried was -w, not -m1. It works in Rxvt but not in the main body of init. With it, you can distinguish between "pup_save" and "pup_save2" without adding the .2fs at the end. But I still like the code intact better. It gives the most flexibility. As I said in the original post, it is extremely robust.
I think the "grep" in the initrd is the busybox applet, so might not support that option.
I think the "-m1" might actually not matter, since I have a feeling Barry's script only takes the first entry or whatever -- I was afraid of it just getting the entire contents of that file...
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

#20 Post by Dougal »

Pizzasgood wrote:
I also find the automatic copying of the pup_xxx.sfs file from a live CD to the hard drive to be an irritant. Some things are best done only if you explicitly want them to be done.
I've done that too.
That should probably be moved to rc.shutdown, to be offered to the user when they create a pup_save...
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

Post Reply