Manual Poor Man's HD Install w/2.x

[PeteTX]

I did a manual poor man's HD install with a boot floppy on an older version of Puppy (v1.0) a while back, and now I am trying to get V2.x on the same machine.

I want to be able to selectively boot the older V1 version, V2.01r2 (which seems more stable, and works with my AirLink USB), and V2.02 (to try it out). I left the old version files on C:\, and put the files for the newer versions on another FAT partition. I wasn't sure if the V2.x files files have to be on the root directory of the FAT partition, so I renamed vmlimuz and initrd.gz for each version to avoid conflicts, and adjusted the batch file(s) on my boot floppy appropriately.

My first attempts resulted in a system re-boot whenever I tried to load one of the new V2.x versions. I copied the newer version of tiny to my boot floppy, and adjusted the V2.x settings based on what I could find here. I finally got the new versions to boot, but I can't seem to get them to save their status properly, when I go to shut-down they seem to think that they are running on a multi-session CD.

I read something about a boot option to press "3" to let you specify the device and filename to save things to, but when I tried it seems to just ignore my keystroke and boot.

Following is an example from one of my boot batch files (for V2.02) -

Code: Select all

@ECHO .
@ECHO Booting Puppy V2.0.2...
@ECHO .

newtiny.exe H:\vm202 H:\initrd22.gz @puppy2.cfg

and the corresponding puppy2.cfg file -

Code: Select all

root=/dev/ram0
PHOME=hda11
PFILE=pup202-none-262144

What do I need to do to get V2.x to save changes to my hard disk?

Thanks!

[MU]

root=/dev/ram0 PMEDIA=idehd

Mark

[Sit Heel Speak]

vmlinuz and initrd.gz can be in individual subdirectories, e.g. here is my c:\p201disk\grub\menu.lst for Puppy 2.01r2:

title Puppy 2.01r2 on hard disk loaded by Grub.exe on hard disk
rootnoverify (hd0,0)
kernel (hd0,0)/p201disk/vmlinuz root=/dev/ram0 PHOME=hda1/p201disk PSLEEP=999 PMEDIA=idehd
initrd (hd0,0)/p201disk/initrd.gz

I am unsure whether it needs (or even uses) the PHOME and PSLEEP parameters, these are carried over (O, the simple joys of cut-and-paste) from my Puppy 1.08 menu.lst. In fact, I'm not even sure the PHOME= from Puppy 1.08 is observed by Puppy (either version) (I don't remember what this parameter does--can someone refresh my memory?).

pup001 and usr_devx.sfs (in Puppy 1.08...), and pup_save.3fs and devx_201.sfs (in Puppy 2.01r2...) need to go in C:\ (or, the topmost directory of whatever drive they're on). So, if you are playing with both 2.01r2 and 2.02, you will need to arrange a move or rename command in autoexec.bat (if that is how you are booting) in order to maintain separate personal-save files for each Puppy version.

[PeteTX]

OK, thanks Mark. Apparently it couldn't auto-detect that it was booting from a HD?

Thanks, Sit Heel Speak - good to know that those can go into subdirs.

I believe that PHOME specifies the device where PFILE resides. If I remember correctly, any path in PHOME is ignored and PFILE has to reside in the root directory (similar to .sfs files?).

I read somewhere that in V2, even if you boot from a different partition, it still puts your save file on c:\, is that correct? Or does it put it on the same device where the .sfs file is located?

Your comment about having to rename save files is an important point. With V1.x, you could use PFILE to specify different save file names for different versions. In V2, even though it uses different pre-defined .sfs file names for different versions (PUP_202.SFS, etc.), it still uses the same fixed filename/location for the save file? It appears that V2 is going backwards - why can't you specify the device and filename for the save file like you can in V1?

Or am I missing something?

[PeteTX]

Mark, nope, it still didn't work.

Per your suggestion, I modified my puppyr.cfg file as follows -

Code: Select all

root=/dev/ram0
PMEDIA=idehd
PHOME=hda11
PFILE=pup201-none-262144

After VMLINUZ and INITRD.GZ were loaded, it even displayed it in the line of params being passed (right after root=)

But after I booted and set Puppy up, and went to exit, it again tried to force me to only save the status on a CD Writer!

What is wrong???

[Sit Heel Speak]

...I believe that PHOME specifies the device where PFILE resides. If I remember correctly, any path in PHOME is ignored and PFILE has to reside in the root directory (similar to .sfs files?)....

Yes, I think you're right.

I read somewhere that in V2, even if you boot from a different partition, it still puts your save file on c:\, is that correct? Or does it put it on the same device where the .sfs file is located?

I don't know, I don't have a multi-drive'd machine I can conveniently test it on. I believe the pup_save.3fs file goes on the same device the pup_20x.sfs file is. (EDITED: come to think of it, I do know; when pup_20x.sfs is on a flash key, pup_save.3fs gets written to the flash key, not the hard disk).

Your comment about having to rename save files is an important point. With V1.x, you could use PFILE to specify different save file names for different versions. In V2, even though it uses different pre-defined .sfs file names for different versions (PUP_202.SFS, etc.), it still uses the same fixed filename/location for the save file? It appears that V2 is going backwards - why can't you specify the device and filename for the save file like you can in V1?

Maybe you can, I haven't the time to test it. One point which should be mentioned here: if you have two *.3fs savefiles, Puppy 2 will give you the option at boot time of which one to use in this session. Or, so I've read. I haven't actually tested it. If true, then you could do the following:

1. Eliminate the PFILE line.
2. Boot 2.01 and save the savefile.
3. In Windows, rename the savefile pup_save.old.
4. Boot 2.02 and save the savefile.
5. In Windows, rename this savefile pup202_save.3fs.
6. Rename pup_save.old to pup201_save.3fs.

and then you would have the option at boot time of which to use.

[PeteTX]

Excellent idea, Sit Heel Speak! The file copy approach I was considering got pretty messy if you want to save the latest session state, given that while it is easy to know what files to copy where before DOS passes control to Puppy, the reverse is not also true.

I don't know, I don't have a multi-drive'd machine I can conveniently test it on.

Just 1 drive here as well, I just have it partitioned.

I believe the pup_save.3fs file goes on the same device the pup_20x.sfs file is. (EDITED: come to think of it, I do know; when pup_20x.sfs is on a flash key, pup_save.3fs gets written to the flash key, not the hard disk).

But I think Puppy special-cases USB drives, doesn't it? (I know my boot floppy I used for V1 handled USB drives differently, with different params passed on boot, and no PFILE)

Even stranger, check-out this somewhat related topic, which was posted after our comments above -
http://www.murga.org/%7Epuppy/viewtopic.php?t=10147

If MooDog is correct, then...
1. Puppy doesn't look on c:\, nor the partition you booted from, instead, it scans through the partitions until it finds the first one with *.sfs files on it.
2. For some strange reason, this has to be a partition lower or equal to the partition you booted from.
3. Because of #1, all of the sfs files have to be on the same partition, even if the boot drives are on different partitions (and even if the sfs is on the same partition you booted from).

Your idea should still work, as long as all of the sfs files are on the same partition, and not higher than the boot partition.

However, at the moment, I can't even try any of this. As mentioned in my previous post, Puppy still thinks I'm on a multi-session CD, and refused to even save anything to my hard drive!

[Sit Heel Speak]

...I think Puppy special-cases USB drives, doesn't it?

The only special-casing I am aware of is, there is a tmpfs ramdisk to hold changes, which periodically get flushed to the pup_save.3fs file on the USB stick. This reduces write wear.

...If MooDog is correct, then...Your idea should still work, as long as all of the sfs files are on the same partition, and not higher than the boot partition.

Yes, though it might be that you must name the files pup_save*.3fs, e.g. pup_save_201.3fs. Or keep them the same name but differentiate by directory, e.g. c:\p201\pup_save.3fs.

However, at the moment, I can't even try any of this. As mentioned in my previous post, Puppy still thinks I'm on a multi-session CD, and refused to even save anything to my hard drive!

Dunno. Tiny is a very old bootloader and Puppy 2 isn't really designed with it in mind. Perhaps if you update to grub4dos (grub.exe) or WinGrub (grub mbr version) (both are at http://grub4dos.sourceforge.net/), that'll solve the problem. Or, grab pakt's WakePup 2 disk image at http://www.murga.org/%7Epuppy/viewtopic.php?t=9962 and use the linload bootloader from it, without using the USB drivers.

[PeteTX]

Yes, though it might be that you must name the files pup_save*.3fs, e.g. pup_save_201.3fs. Or keep them the same name but differentiate by directory, e.g. c:\p201\pup_save.3fs.

I'm not sure, but I think it only scans for them on the root directory of each volume. But the first idea should work.

Dunno. Tiny is a very old bootloader and Puppy 2 isn't really designed with it in mind. Perhaps if you update to grub4dos (grub.exe)...

I considered that issue back when I couldn't even get V2 to boot. I have since downloaded the latest version of Boot4DOS, and adapted my boot floppy to use the new version of tiny from it (dated 1/22/06). (I've had problems w/grub back when I did Puppy V1, but Boot4DOS works OK on my PC)

But Puppy V2 is booting fine now, tiny is passing params to it OK, so I don't think the problem is with the tiny-based Boot4DOS (which includes explicit support for Puppy V2)

After diagnosing this problem further, I think I may have found a bug in Puppy!

At first it appeared Puppy thought I had booted from a multi-session CD, but closer examination revealed something far stranger...Puppy thinks one of my hard drive partitions is a CDRW drive!

Following is the bizzare msg I get when I exit Puppy -

Please Insert the Puppy live-CD/DVD media that you booted from, into the same CD/DVD drive that you booted from -- this is /dev/hda9 and must be a burner drive! ...

Note the device name - this is not my CD burner, it is one of the FAT partitions on my hard drive! Nor is it even the partition I booted Puppy from!

Even stranger is when it then tries to "Close the Drive Door" on my hard drive! (This generates an error, apparently my hard drive doesn't know how to close it's drive door! )

This is obviously a bug - there is no logical reason for Puppy to believe a hard drive partition is a CDRW!

My drive is segmented into multiple partitions (some of which are hidden - a common practice when you want to run multiple OS's on the same machine). My guess is that Puppy is getting the partition #'s mixed-up when it tries to calculate where to put the s3f.

This seems to be confirmed by the fact that /dev/hda9 is a Windows FAT32 partition that is completely unrelated to Puppy - but is 2 partitions below the actual boot partition - /dev/hda11. I'm guessing that when Puppy is determining the save drive, it gets the partitions confused, and when it then looks for the .sfs it booted from on the wrong drive and doesn't find it, perhaps it wrongly assumes it must therefore be a removable-media CD?

Further investigation of the /initrd/sbin/init file referenced in that other thread was most enlightening. This is apparently the Puppy initialization script which, among other things, scans for the .s3f files. I can do DOS/Win programming, but I'm not that familiar with UNIX. But I was able to understand the purpose of the following code snippet -

Code: Select all

 echo -n "$PUPMODE" > /pup_rw/etc/rc.d/PUPMODE #to be read by rc.shutdown.
 echo -n "$PDEV1" > /pup_rw/etc/rc.d/PDEV1     # "
 echo -n "$FSTYPE" > /pup_rw/etc/rc.d/DEV1FS     # "
 echo -n "$PUPSFS" > /pup_rw/etc/rc.d/PUPSFS   # "
 echo -n "$PUPSAVE" > /pup_rw/etc/rc.d/PUPSAVE # "
 echo -n "$PMEDIA" > /pup_rw/etc/rc.d/PMEDIA   # "

It appeared Init was saving some calculated configuration settings to text files on /pup_rw/etc/rc.d/, presumably for use by the Puppy shutdown program?

Looking at that subdir showed those created text files, along with another program called Shutdown, which among other things apparently handles writing the .s3f file.

Looking at the saved text files seemed to indicate that part of them knew correctly where Puppy was booted from, and part of them didn't! ...

PMEDIA (type of device booted from) = idehd (correct)
PDEV1 (device booted from) = hda11 (correct)
DEV1FS (file system of boot device) = vfat (correct)
PUPSFS (name of sfs file booted from) = pup_201.sfs (correct)

But then there's ...

PUPSAVE (file system, device, and filename for .s3f save file) =
vfat,hda9,/20040621MOJ96D_MOJ96D.jpg (wrong!)

PUPMODE (Puppy Boot Mode, should be 5 for 1st boot?) =
77 - multi-session CD/DVD (wrong!)

So the config settings created by Init and used by Shutdown are inconsistent, even with themselves. They know that Puppy was booted from an ide hard drive, from the correct partition, and yet also say that Puppy was booted from a multi-session CD drive, from the wrong partition!

This clearly seems to be a bug, I think in the Puppy Init program?

I don't know UNIX programming, so perhaps someone who does can take a look at /initrd/sbin/init and tell us what the heck is going on, and how to fix it!

As it stands now, I can't even save any s3f file on my hard drive!

Thanks!

[J_Rey]

I assume you mean you are using Pup4DOS, which I just updated with the latest version of Gujin (tiny.exe) and expanded the documentation to make it easier to work with Puppy 2.x. Before delving into Puppy's init script, I'd like to find out exactly what boot parameters you're now passing to Puppy, since there were multiple ones mentioned. Also, you could boot to ramdisk only, to see if it could be the personal storage file that is confused. Finally, while you're waiting for a response, the two links I mentioned earlier in this post might give you more hints/clarification as well.

[PeteTX]

I assume you mean you are using Pup4DOS, which I just updated with the latest version of Gujin (tiny.exe) and expanded the documentation to make it easier to work with Puppy 2.x.

That is correct (late-night typo!) The new version of tiny I am now using was copied from Pup4DOS-0.5.zip.

I'd like to find out exactly what boot parameters you're now passing to Puppy, since there were multiple ones mentioned.

The current boot params are -

Code: Select all

@ECHO .
@ECHO Booting Puppy V2.0.1r2...
@ECHO .

newtiny.exe H:\vm201 H:\initrd21.gz @puppyr.cfg

and Puppyr.cfg -

Code: Select all

root=/dev/ram0
PMEDIA=idehd
PHOME=hda11
PFILE=pup201-none-262144

Discussion on this and the related thread now indicate that some of these params are not used by V2, but are simply ignored.

Also, you could boot to ramdisk only, to see if it could be the personal storage file that is confused.

If by "personal storage file" you mean the 3sf file - that's the problem, there is none! Puppy is misinterpreting my first-time boot of a poor man's hd install as a muilti-session CD.

Finally, while you're waiting for a response, the two links I mentioned earlier in this post might give you more hints/clarification as well.

Both of those had been quite helpful to me last week when I was just trying to get V2 to boot at all. I am interested to see what enhancements you have made to the documentation.

Before delving into Puppy's init script...

My gut-level feeling here is that the problem is more likely with Init. Tiny appears to be passing the params properly to Puppy. Given the fact that the config values being calculated by Init contradict each other would also seem to point to a coding error in Init.

[J_Rey]

OK I see what you mean. It does seem more obvious now about the init script's confusing behavior.

What I'd try next is to copy a version of tiny.exe to H:\ and add "H:" on its own line in the batch file before loading tiny.exe, which would load Puppy. Just in case, I'd remove the last two lines of puppyr.cfg. Another thing would be to move the needed files to the root directory of the first logical FAT32 partition (hda9). Lastly, give it a little time and then PM Barry to bring this to his attention.

If your curiousity is killing you and you want to hack the init script, you could read up more on how Puppy works.

[PeteTX]

Very interesting link, thanks! Now I've got some reading to do!