How do I manually select a pup_save.3fs?

Booting, installing, newbie
Post Reply
Message
Author
MooDog
Posts: 30
Joined: Sun 13 Aug 2006, 11:35
Location: Red Dot

How do I manually select a pup_save.3fs?

#1 Post by MooDog »

hi, all

I have a harddisk partitioned so:

hda1 = Debian etch
hda2 = swap
hda5 = Puppy 1.09 CE
hda6 = Puppy 2.02 seamonkey
hda7,hda8 = testing
hda9 = data

Boot selection is by grub menu installed in the /boot/grub directory of hda1 (debian) All my puppy's are installed manually by the 'frugal' method. So far everything's fine and dandy.

Yesterday I downloaded Puppy 2.02 Office CE for testing and 'frugal installed' onto hda7. I edited menu.lst and created a new section to load this pup, and created a pup_save.3fs upon shutdown.

Upon reboot and selecting 'puppy 2.02 office CE', puppy booted up fine, but defaulted to the pup_save.3fs file of hda6, the first one that it found. Is there a parameter that I can set that will force this puppy to disregard the one in hda6, and instead load the one set up in hda7? Something along the lines of puppy 1.0 series that defines a PHOME = parameter?

Thanks in advance for any insight to this!

billstclair
Posts: 106
Joined: Mon 27 Feb 2006, 01:23
Location: Upstate New York
Contact:

#2 Post by billstclair »

It appears from my reading of the 2.02 version of /initrd/sbin/init, that 2.02 looks at all partitions on an IDE drive. You can limit the search to just one media type by setting PMEDIA on the "kernel" grub line, but you can't select a partition there.

It looks to me that you can have more than one pup_save*.3fs file on a partition. If it finds more than one, the "init" script will ask you which one to use. You type the index of the one you want in the printed list, but typing "0" will choose not to use any and continue with the partition search.

Conclusion: I haven't tested this, but I think that if you create a pup_save_not.3fs file on the 2.02 Seamonkey partition (e.g. with "> pup_save_not.3fs"), you'll be able to type "0" when it asks for which file to use, and it will continue looking and find your office CE pup_save.3fs on partition hda7. You'll also have to type "1" to boot using the 2.02 Seamonkey's save file on hda6.

Hopefully Barry will validate this, but it shouldn't be hard to test.

MooDog
Posts: 30
Joined: Sun 13 Aug 2006, 11:35
Location: Red Dot

#3 Post by MooDog »

Thanks, Bill -

Last night I tried it out as you suggested, and discovered the following:

All the pup_save.3fs files must be in the same partition and a lower order than the /boot partition ie. if /boot was in hda6, pup_save.3fs cannot be in hda9 - the dialogue windows will open up again, and it will ask to create a new pup_save.3fs upon shutdown. I discovered this scenario when I had to copy my original pup_save.3fs to hda9 because it took up all of hda6 (500mb only...)
I then created a new pup_save.3fs and renamed it to pup_save01.3fs in hda6 and created another pup_save.3fs for office CE. Will fiddle with a bit more tonight. So far it works as you described, the init script does pop up to ask which pup_save file to use, but it's a bit of a bother since I'd already selected what I wanted in the grub menu.

Will await Barry's input on the internal workings of this system too...

Once again, thanks , Bill!

PeteTX
Posts: 22
Joined: Fri 11 Aug 2006, 14:34

#4 Post by PeteTX »

billstclair, thanks for the reference to /initrd/sbin/init, it helped me identify a possibly related bug!

MooDog, there is a related thread about possible problems with Puppy, save files and multiple partitions that you or billstclair may be interested in reading -

http://www.murga.org/~puppy/viewtopic.php?p=63431

Take care!

MooDog
Posts: 30
Joined: Sun 13 Aug 2006, 11:35
Location: Red Dot

#5 Post by MooDog »

Hi, PeteTX -

Hehe, I wouldn't call it a bug, maybe just a 'flea' :lol: :lol:

The thing is that Barry has automated the process of finding and loading the pup_save.3fs file, so new users have one less thing to worry about. Now all we need is for him to give puppy some 'obedience training' so that puppy will pick the pup_save that we want.

I think if Barry can re-use the PHOME parameter so that if we specify PHOME=hda5 or something, then puppy will disable all the auto search functions and just load the defined pup_save file. I'm not good at scripting, but I think it can be written so that if PHOME is not listed, then the auto search scripts get going. This way may be puppy can boot up even faster, as a lot of searching is bypassed, and at the same time new users are not affected.

Thanks for your input,

Don

PeteTX
Posts: 22
Joined: Fri 11 Aug 2006, 14:34

#6 Post by PeteTX »

MooDog wrote:Hehe, I wouldn't call it a bug, maybe just a 'flea'
Don, not a "flea" to me, as it is preventing me from saving any s3f files and using Puppy from my hard drive! :(

I'm also more than a little worried about what might happen if I told it to try to save to my "CD Burner" hda9! The Shutdown program (which handles writing the s3f) has some pretty scary comments in the code, like...

Code: Select all

  #ha ha, before had this, if aborted save after choosing save-partition, code
  #further down wiped all of the partition (it was mntd on /tmp/savepup)...

Ouch! It also looks like if it can't find Puppy on the multi-session CD, it may try to re-create a complete Puppy boot CD? (on an existing partition of my hard drive???) Given that the contradictory settings passed by Init are sure to confuse the hell out of the Shutdown code, god only knows what would happen if I accidentally hit RETURN when it asked to write to my "CD burner" hda9!
MooDog wrote:I think if Barry can re-use the PHOME parameter so that if we specify PHOME=hda5 or something, then puppy will disable all the auto search functions and just load the defined pup_save file.
I agree, and would go one better - I think he should retain both PHOME= (to explicitly specify what device to save to), as well as PFILE= (to explicitly specify the s3f file name to use, thus circumventing the need to manually choose from the selection menu on boot when there are multiple s3f's found), and in either case default to the automated approach (scan for s3f partition, or menu selection if multiple s3fs) if the param is not specified.

The concept of taking control away from the user, and instead forcing you to use an automated method, is more the kind of thing I would expect out of Bill G, and contradicts the basic philosophy that is one of the reasons for my exploring LINUX as an alterative to Win in the first place!

MooDog
Posts: 30
Joined: Sun 13 Aug 2006, 11:35
Location: Red Dot

#7 Post by MooDog »

Hi, Pete -

Sorry if I underestimated your problem. Can you elaborate your harddisk setup and I'll try to replicate the fault. The thing is, Puppy is so small and flexible that when I have problems, I can usually solve them by booting from the CD (using either 1.09 or 2.02) and using the pfix=ram parameter. This way I can simply mount the partition that has problem files and either delete the files and start all over again or edit them. Worst case a re-install is just overwriting the 3 main files.

Does your hard drive have windows installed? It may be safer to use Gparted to set aside an ext3 and swap partition and use grub altogether. I think Puppy's designed to work this way, that's why your situation has not cropped up before now.

Hopeyou don'tgive up on puppy yet!

Right now I'm typing this from an an old pc (AMD k6-2 450 mhz) with a 20 GB hard disk that has a broken mbr. I use a grub boot floppy and set the first 5 GB of HDD as free space that's not formatted and I still can use the other 15 GB. I have to use Puppy 1.09 for this though, since puppy 2 will spend a lot of time scrounging around the bad sectors looking for a pup_save.3fs. Puppy is just great, but still needs some work!!!

Don

PeteTX
Posts: 22
Joined: Fri 11 Aug 2006, 14:34

#8 Post by PeteTX »

MooDog wrote:Can you elaborate your harddisk setup and I'll try to replicate the fault.
The hard drive has 2 primary partitions, 1 hidden, the other boot. It also has an extended partition, containing several FAT32 and FAT16 partitions, 2 of which are hidden - the first one, and the second-to-the last one. The last partition is were Puppy is booting from, it is drive H:\ (Win), or dev/hda11 (Linux).

FreeDOS correctly sees all of the non-hidden partitions. In Puppy, the Media Utility Tool (on the desktop) spots all of the partitions (even the hidden ones), and labels them all as vfat. It also #'s all of them correctly.

The Puppy Drive Mounter only shows the non-hidden partitions, and only shows some of those! It did not show the Windows C and D drives. It did number the ones it displayed correctly.

As the missing C and D drives matched the 2-device offset I was seeing (i.e. - hda11 boot drive being misinterpreted as hda9), I thought this might be related. I have since read that this was actually a bug in that particular program (Driver Mounter), which has since been (partially) fixed in V2.02.

My guess is that Puppy understands the hidden primary partition, but that the 2 hidden partitions in the extended partition is what confused it, as the math matches (2-drive offset).

So if you wanted to try to duplicate the problem, you might first try putting several FAT partitions in an extended partition, hiding 2 of them, and then setting-up a poor man's install on the last partition.
MooDog wrote:Does your hard drive have windows installed? It may be safer to use Gparted to set aside an ext3 and swap partition and use grub altogether.
Yes, I have Win. I am doing a poor man's install (Puppy files running from a Win partition), I don't have a dedicated Linux partition. (I may eventually try to make the space for that, if I can ever get Puppy to run right!)
MooDog wrote:...a 20 GB hard disk that has a broken mbr. I use a grub boot floppy and set the first 5 GB of HDD as free space that's not formatted and I still can use the other 15 GB.
There must be something on the MBR, as I believe that's where the main Partition Table for the drive is stored (at least for DOS/Win). Or are you saying that you have a boot floppy configured to boot from a specific physical sector 5gb into the drive?
MooDog wrote:I have to use Puppy 1.09 for this though, since puppy 2 will spend a lot of time scrounging around the bad sectors...
Is that first 5gb actually completely unused space, or is it a partition that hasn't been formatted? If the later, you might try deleting the unused partition from your hard drive, that might solve your problem. Space outside any partition won't show up as a volume, so Puppy shouldn't scan it!
MooDog wrote:... looking for a pup_save.3fs.
Of course, if V2 implemented that PHOST= fix that we discussed, that problem would be eliminated! :wink:

User avatar
fluxit
Posts: 326
Joined: Sat 24 Jun 2006, 04:14
Location: Ketchikan, AK USA

#9 Post by fluxit »

My guess is that Puppy understands the hidden primary partition, but that the 2 hidden partitions in the extended partition is what confused it, as the math matches (2-drive offset).
I'm curious why you are hiding logical drives in your extended partition. I'm sure you have a good reason, but I'm not surprised that Puppy has problems when dealing with this case. It's a pretty rare setup AFAIK.

--Lee

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

#10 Post by Dougal »

MooDog: I'm not well aquainted with the details of the "frugal" install (means cd contents copied to HD but left as images, right?) but using grub implies booting from HD --> files can be modified.

Can't you hack the init script to use the partition you want? (could probably speed things up a bit, too)
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

MooDog
Posts: 30
Joined: Sun 13 Aug 2006, 11:35
Location: Red Dot

#11 Post by MooDog »

Hi,Dougal -

Well, today I got back to work on it. I did a type 2 harddisk install, which does not use the init file, and the problem still arises. I get the message "hdd_dma error..." which may be a part of kernel 2.6's feature set, so I guess the problem is deeper than just the init file... Anyway, puppy 1.09 works fine on this system and there's puppy 2.10 coming down the line... :lol: :lol: :lol:

MooDog
Posts: 30
Joined: Sun 13 Aug 2006, 11:35
Location: Red Dot

#12 Post by MooDog »

Hi, All-

FWIW, I'd solved the problems of 'hdd_dma' error messages during boot-up. I used MaxBlast software (mine is a Maxtor hdd) to write zeros to the disk (took me 4 whole days for the s/w to write 20 GB worth of zeros!!!) , and repartitioned the disk using CFDISK, leaving the first 5 GB free. Now it works just like with puppy 1.09, no error messages at all. I did discover some problems with a type 2 install which I'll list in another thread.

Just in case someone else has an old hdd he/she wants to try with puppy...

Don

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

#13 Post by Dougal »

MooDog wrote:Hi, All-

FWIW, I'd solved the problems of 'hdd_dma' error messages during boot-up. I used MaxBlast software (mine is a Maxtor hdd) to write zeros to the disk (took me 4 whole days for the s/w to write 20 GB worth of zeros!!!) , and repartitioned the disk using CFDISK, leaving the first 5 GB free. Now it works just like with puppy 1.09, no error messages at all. I did discover some problems with a type 2 install which I'll list in another thread.

Just in case someone else has an old hdd he/she wants to try with puppy...

Don
What do you mean "write zeros"? Couldn't you format it? Or write "nothing" (/dev/null) onto it?
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

MooDog
Posts: 30
Joined: Sun 13 Aug 2006, 11:35
Location: Red Dot

#14 Post by MooDog »

Hi, Dougal -

The Maxblast s/w has a utility called "zero-fill (quick)" and "zero-fill (full)" I read on the web that tihs is akin to low-level formatting for IDE drives. It essentially wipes out all data, in-case one wants to dispose of a hdd and does not want others to re-cover any data from it. the quick option only wipes out the MBR and takes a second, while the full option takes some days...

How do you write /dev/null to a hdd? I might try this sna see if it works as well...

Don

User avatar
Flash
Official Dog Handler
Posts: 13071
Joined: Wed 04 May 2005, 16:04
Location: Arizona USA

#15 Post by Flash »

Good grief, several days to fill a 20 GB hard drive with zeroes? At that rate you'd be much better off buying a DVD burner and running Puppy from a multisession DVD. :lol:

Seriously though, I'm not sure how fast a hard drive can write to the disk but I think it's in the range of 10~100 Mb/s. Surely it shouldn't take more than a few hours to write 20 GB.
[url=http://www.murga-linux.com/puppy/viewtopic.php?t=69321][color=blue]Puppy Help 101 - an interactive tutorial for Lupu 5.25[/color][/url]

MooDog
Posts: 30
Joined: Sun 13 Aug 2006, 11:35
Location: Red Dot

#16 Post by MooDog »

Hi, Flash!

Well, I started on Tuesday and the progress bar went only about 10% the next day, and finally finished onSaturday morning... :shock: :shock:

Chalk it down to a learning experience... I was using a AMD K6-450 mhz PC. Maybe if I tried it on a PIII it would be a bit faster.... but the 'quick' mode was almost instantaneous.

Don

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

#17 Post by Dougal »

MooDog wrote:How do you write /dev/null to a hdd? I might try this sna see if it works as well...Don
First, my mistake: it should be dev/zero

You can use the dd (data duplicator) command.
A command like the following will create a file named filename of size filesize (in K's) that contains zeros (one the HD, not as text):

Code: Select all

dd if=/dev/zero of=/your/partition/filename bs=1024 count=filesize
You can change the block-size (bs) but I don't know much about it, so I wouldn't know what is best... (it can be 1, 2048.. try checking the dd help)
You just need to make sure you change the filesize when you change the blocksize.
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