init development

Under development: PCMCIA, wireless, etc.
Message
Author
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

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

#21 Post by Pizzasgood »

It's already there, at line 718 for the version in Puppy 4.12.
[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]

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#22 Post by amigo »

If your grep doesn't support '-m 1', use 'grep .... |head -n 1'

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

#23 Post by Crash »

In my testing so far, everything looks really good. Pizzasgood's pup_save mod is nice - if I have two pup_save files, the first choice screen lets me pick either one, but if the one I pick is not a V4.20 file, the second choice screen gives me the opportunity to not upgrade it. The code I added is still working too.

To do a more thorough test, I attempted to create a modified .iso using ISOMaster. At this point I encountered a problem unrelated to this thread, but essential to do more testing. When I attempt to save the edited .iso, or simply save an unedited .iso for that matter, I get this error message box:

Failed to write image to 'initrd/mnt/dev_save/linux/puppy/p42a/test.iso.': 'Size of no emulation boot record visible on image must be divisible by 4 so i can do a checksum (invalid boot file?)'

I checked back with version 4.0 and it has the same problem. I went back to V3.01 and V2.17 and ISOMaster saves both of them OK. This seems to point to something in the version 4 series that is different. I note that when doing a Properties on the BootRecord for versions 2.14R, 2.17, and 3.01, the length is 10648, whereas for versions 4.00, 4.12, and 4.2alpha3, the boot record length is 12241.

The V4.2A3 .iso boots fine from a live CD, so the problem isn't in any corruption in the file. The md5sum's are all consistent too.

Can someone else confirm that this is a real issue rather than some cockpit error on my part? ISOMaster is the only program that I use to generate modified .iso's, although if there was another program that I could use as a workaround, I would be willing to use it.

P.S: Thanks everyone for the grep and diff tips. It's funny how long I've used these utilities without knowing anything about their features!

/// Edited an hour later

I see this thread that addresses the issue: http://www.murga-linux.com/puppy/viewtopic.php?t=36017
I'm not sure if there is a quick fix to this or not.

I also see this:
http://freshmeat.net/projects/isomaster ... _id=264650
I'm not sure if this version is in Puppy Linux or not.

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

#24 Post by Dougal »

Pizzasgood wrote:It's already there, at line 718 for the version in Puppy 4.12.
Aha. So why was it still in the init script? Preposterous, I tell you.
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

#25 Post by Dougal »

Crash wrote:I also see this:
http://freshmeat.net/projects/isomaster ... _id=264650
I'm not sure if this version is in Puppy Linux or not.
You can look in /root/.packages/* and see which version is included...
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

ICPUG
Posts: 1308
Joined: Mon 25 Jul 2005, 00:09
Location: UK

#26 Post by ICPUG »

Dougal wrote:
Pizzasgood wrote:

It's already there, at line 718 for the version in Puppy 4.12.

Aha. So why was it still in the init script? Preposterous, I tell you.
Barry put it in the init script to avoid some conflict or other when people were messing with retro and standard versions. Read the blog at the time of 4.1.

Just goes to show Barry can be fallible!

Thanks for Pizzasgood efforts and hopefully we can rid this stupidity from 4.2

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

#27 Post by Crash »

OK, so /root/.packages/packages.txt indicates ISOMaster is at version 1.1 vs. 1.2 that the Freshmeat link references. Any chance of including the later version in the distro package? I've never added a version update myself into Puppy - I suppose it takes some "real" programming like running a compiler. If not, maybe a .pet?

Again, this is off the subject. As far as I'm concerned, Pizzasgood's init file is good to go.

I notice that Puppy version 4.2 is up to Beta stage now. Great progress. The rest of the community can create two more iterations of an entire operating system in the time it takes me to just look at a couple of minor items in an init script!

/// Edited a few minutes later

I notice from the http://www.littlesvr.ca/isomaster/download/ web site that the actual latest version of ISOMaster is 1.3.5. I downloaded it and am looking at it. Gives me something to do. At this point, someone else will be far more efficient at getting it incorporated into Puppy, though.

/// Edited a few minutes later yet:

I downloaded devx (first time!) and did an ISOMaster "make install". ISOMaster v. 1.3.5 now comes up when I click on it in the Multimedia menu. It saves the Puppy Linux version 4 .iso like a champ! How easy...

I burned a Live CD of version 4.2alpha3 with the mods and it works great. I'll try it out on as many computers as I can, but for now, things look very good.

/// Edited Tue. Feb 17

I've tried out the Live CD on four different computers and it works fine. I'd say that Pizzasgood's init file is a keeper.

pupshock
Posts: 140
Joined: Fri 23 Mar 2007, 05:30

#28 Post by pupshock »

Crash wrote: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. .
This is getting too interesting.

Suppose i have frugal installs
puppy 4.20 in hda3/p420
puppy 3.01 in hda3/p301
user-A's pup_save.2fs of puppy 4.20 in hda3/userA (different folder)
user-B's pup_save.2fs of puppy 3.01 in hda1/userB (different partition)
user-C's pup_save.2fs of puppy 4.20 in hda3/p420/userC (in sub-folder)
user-D's pup_save.2fs of puppy 3.01 in hda3/p301 (in standard folder)

What would a menu.lst look like to boot into for users A, B, C, D?

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

#29 Post by vg1 »

Pupshock,

yes, it is indeed very flexible, and works on p3 & p4. However, it is implemented only in p420's initrd. If you want it to work on other p4 versions, or p3, you have to hack the init and insert the code.

If I understand you correctly you would have each save_file in a different folder. This is not really necessary. If they are all named the same [pup_save.2fs] as in your example, then yes, they cannot exist in the same folder. However if you name them, say, pup_save301a.2fs, pup_save301b.2fs pup_save420c.2fs, pup_save420d.2fs then they can coexist in the same folder. Say you have the first two in hda3/p301 and the other two in hda3/p420, to have a simple and neat setup.

In that case you would have on the kernel line:
psave= with only the difference in each file's name. The difference can be any combination as explained above, so in your case you would have as the shortest version:
psave=301a.2
psave=301b.2
psave=420c.2
psave=420d.2
or any of the longer versions above, ie specifying the full .2fs or pup_save in each case.
With the combination of psubdir= and psave= the init is able to boot the correct version and pick the correct save_file.

Is this what you meant, can you figure out the rest of the entry, or would you need full grub entries?

As said above this code is implemented only in p420, For p301 you have to hack the init and insert the code manually in the appropriate place. I have done it for all my p3 versions and other p4 versions, and they all reside in subdirs two levels deep with multiple save_files named according to the above convention. And they all work.

regards
vg

pupshock
Posts: 140
Joined: Fri 23 Mar 2007, 05:30

#30 Post by pupshock »

vg1 wrote: can you figure out the rest of the entry, or would you need full grub entries?
thanks, vg, i can figure out the rest of the menu.lst.
The final issue is whether psave can find the save_file if it is in a
different partition (boot or non-boot partition?).

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

#31 Post by vg1 »

yes, you are right. I had missed it in your previous post.
I made several tests and could not get it to find a pup_save on another partition, vfat or linux. I tried various combinations and none worked.

Crash - is it possible at all to have your code find a pup_save on another partition?

vg

ICPUG
Posts: 1308
Joined: Mon 25 Jul 2005, 00:09
Location: UK

#32 Post by ICPUG »

vg1,

Have you tried removing the PDEV1 parameter? I know without psubdir and PDEV1 the pupsave file could be found on another partition. Not sure what happens if you have only psubdir and not PDEV1. I think it would filter for the associated subdir on any partition before Crash implemented his mods.

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

#33 Post by Crash »

Vg1,
Crash - is it possible at all to have your code find a pup_save on another partition?
Yes, if you specify the complete set of parameters, you can locate the save file in any partition, for example (from the original post):

psave=hda3,ext2,/pup220/pup_save.2fs

I can choose the save file to be as diverse as being on a hard drive or on a USB thumb drive.

As you said, the code was only implemented beginning with (I think) 4.2 Beta and later. You have to hack the earlier versions, which may be more trouble than it is worth.

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

#34 Post by vg1 »

Crash,

it still doesn't work for me, specifying all params as above. Yes, I had dropped PDEV1 as ICPUG suggests already in my earleir tests. If I drop psubdir then puppy is not found in subdir, only on root. But psave on another partition still doesn't work, with or without psubdir.

Here's my setup:
pup_410, initrd & vmlinuz on sda3/puppy4/410k2 [vfat]
pup_save41k27-3wm.2fs on sda7/p420 [ext2]

here's the grub entry:

title P410 k2.6.27 - pup_save on sda7
rootnoverify (hd0,2)/puppy4/410k27
kernel /vmlinuz20 psubdir=puppy4/410k27 PMEDIA=satahd psubok=TRUE psave=sda7,ext2,/p420/pup_save-41k27-3wm.2fs
initrd /initrd20-2s-ps.gz

Puppy is found correctly, but then boots to ram as on first boot, & pup_save is not found.
Have also tried with pup_save on sda10[vfat], and with p420 on hda3 & its pup_saves in both sda7 & sda10. None of these work.

Can you spot anything wrong in the above setup or entry?

regards
vg

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

#35 Post by Crash »

vg1,

I've been using LINLD to boot, and I'm not sure what you need to do using GRUB. I'll mess around with GRUB and give you a report on what I find. It's a good excuse for me to become re-acquainted with GRUB, anyway.

Looking back, the psubok=TRUE parameter tells INIT to ONLY look at the directory you chose when you set the parameter psubdir=puppy4/410k27. It says "all the files are in this subdirectory". You may be able to store a save file on another partition with the same subdirectory name and it should work. This is probably getting clear as mud now. One thing you can do is look at the contents of /initrd/tmp/PUPPYFILES after bootup. It contains the results of INIT's search for all Puppy files. The save file has to show up there in order for it to be recognized.

... I just did some tests after writing the above comments. It turns out that if I don't use the psubok parameter, the boot process will see the save file in different partitions. But when I used the psubok parameter, the first try was a bust. The loader expected the pup_xxx.sfs to be in the first partition that it searched. So I put a copy of the .sfs file there too. Then it booted OK, but didn't bother searching any more partitions for the save file. Actually I can't explain this behavior yet - I need to do more testing.

So what I know so far is that without the psubok parameter, the psave parameter works across partitions. Of course this limits you to putting the Puppy files only one subdirectory deep.

Like I said, this is probably clear as mud. I need to do some more testing. For instance, the two partitions I used were FAT and NTFS. I'm not sure if there are any issues there. Also, I'm using my butchered INIT file and Puppy 4.12 to do the testing. I suppose I should really use version 4.2 to make sure I am using an official released version.

Like usual, it may take me a while to see what is going on. To tell you the truth, you have a configuration that I haven't been using. I normally have one version of Puppy on the hard drive, and another on a USB thumb drive. There are only two other partitions on the hard drive and I don't like to mess with them: one is the NTFS Vista partition ("don't mess with me"), and the other one is the restore partition ("really, really don't mess with me"). What I may do is shrink the NTFS partition again and make room for another partition on the hard drive. That will make testing more straightforward.

So I don't know if this information will help your particular situation, but it may shed some more light on the overall process.

Post Reply