Can't boot 2 different Puppies

[RickyVaio]

Hello
I've been runing Puppy 3.01 without problems for some time now, and I wanted to test DCL (Puppy+XCFE)
I have one 6 GB drive with Win2K, Puppy and an empty 1 GB FAT32 partition where I copied the DCL files (frugal install). The machine does not have a CD, and it can't boot from USB.

So I copied the DCL files in a different partition than the one Puppy uses, both as frugal installs.

My Grub menu.lst looks like this:


title Puppy
rootverify (hd0,5)
kernel /vmlinuz pmedia=idehd
initrd /initrd.gz

title DCL
rootverify (hd0,4)
kernel (hd0,4)/dcl2008/vmlinuz pmedia=idehd
initrd (hd0,4)/dcl2008/initrd.gz


For some reason grub boots directly to Puppy. Can it be because it finds my pup_save, and somehow links it to the distro that created it (puppy)? Should I be using a different boot command?


Thanks
RickyVaio

[disciple]

Maybe because you don't have

Code: Select all

timeout 10

or something at the top of menu.lst?
I don't know whether it boots straight into the default without it, or if it waits forever.
Do you see the menu.lst while booting? Is it the correct one?

[trapster]

Some good examples of menu.lst with multiple partitions Here

[RickyVaio]

Thanks for answering!

The problem was that no matter which grub entry I chose, I would eventually end with the original Puppy boot (and not the new DCL). It did a normal boot, no error messages.

I tried deleting the puppy_save.sfs (I made a copy first) and that did it: I was able to boot to DCL without problems. I do not know if that did it or if it's something else... but it seems the save.sfs has something to do with it.

For disciple, no, I'm not using any timeout (so that should have no influence).

Anyway, I'll investigate it further to see what happens (having a save.sfs with screen+keyboard config is necessary).

Any other ideas will be appreciated.
Thank you for your time, folks,

RickyVaio

[Bruce B]

Ricky,

DCL Puppy is not Puppy Linux.

I don't know if its a serious modification or a modest one.

Suppose each of the different Linuxes is looking for a user file called pup_save.2fs?

Puppy Linux goes through a search order and uses the first file of that name. If DCL Puppy is doing the same thing this could present a problem of the kind you are talking about.

If the people responsible for DCL Puppy wanted they could have it look for a file by a different name. If so there would be no problem of each different Linux trying to use pup_save.2fs

It's up to you to determine what is going on. If you determine they are both looking for and using pup_save.2fs, you can fix this.

To fix it open the initrd.gz archive, find the file(s) with references to pup_save.2fs and change the name. I'd recommend keeping the same number of characters. Then repack your archive.

On a version 2.xx based Puppy I believe all the initrd.gz files are gzipped.

On version 3.xx Puppys I believe the initrd.gz files are not gzipped, even though they have the gz extension.

Pizzagood made a post showing how to pack and unpack these files. If you need to, and don't know how, search for initrd.gz with Author as Pizzagood, I think you will find how.

Bruce

[Bruce B]

rootverify

For the record I'm not aware this is a GRUB command.

root
rootnoverify

Are the ones I'm aware of, and if rootverify is not a GRUB command I have no idea what effects this is having on your computer.

[Ray MK]

Hi

Some more examples from my 5/6yr old Patriot laptop which has 94mb ram
and a 1GHz celeron processor. 20gig hdd.


DCL, 216ce and 215ce are full hdd installs on hda1,2 and 5.
Breezy, TeenPup2008 and Grafpup are frugal on hda1.
MiniPup is frugal on hda2.

They all run superbly on what is really quite an old spec laptop.


# Linux bootable partition config begins
title DCL (on /dev/hda1)
root (hd0,0)
kernel /boot/vmlinuz root=/dev/hda1 ro vga=normal acpi=force
# Linux bootable partition config ends
# Linux bootable partition config begins
title 216ce (on /dev/hda2)
root (hd0,1)
kernel /boot/vmlinuz root=/dev/hda2 ro vga=normal acpi=force
# Linux bootable partition config ends
# Linux bootable partition config begins
title 215ce (on /dev/hda5)
root (hd0,4)
kernel /boot/vmlinuz root=/dev/hda5 ro vga=normal acpi=force
# Linux bootable partition config ends
# Linux bootable partition config begins <<<<<<<<<<<<<<<<<<<<<
title breezy - frugal (on /dev/hda1)
root (hd0,0)
kernel /zBreezy/vmlinuz root=/dev/ram0 PMEDIA=idehd pdev1=hda1 ro vga=normal acpi=force
initrd /zBreezy/initrd.gz
# Linux bootable partition config ends <<<<<<<<<<<<<<<<<<<<<
# Linux bootable partition config begins <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
title MinPup - Boot RAM (on /dev/hda2)
root (hd0,1)
kernel /boot/minpup/vmlinuz root=/dev/ram0 ro vga=normal acpi=force pfix=ram
initrd /boot/minpup/initrd.gz
# Linux bootable partition config ends <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
# Linux bootable partition config begins <<<<<<<<<<<<<<<<<<<<<
title TeenPup - frugal (on /dev/hda1)
root (hd0,0)
kernel /zTP/vmlinuz root=/dev/ram0 ro vga=normal acpi=force
initrd /zTP/initrd.gz
# Linux bootable partition config ends <<<<<<<<<<<<<<<<<<<<<
# Linux bootable partition config begins <<<<<<<<<<<<<<<<<<<<<
title Grafpup - frugal (on /dev/hda1)
root (hd0,0)
kernel /zGP/vmlinuz root=/dev/ram0 ro vga=normal acpi=force
initrd /zGP/initrd.gz
# Linux bootable partition config ends <<<<<<<<<<<<<<<<<<<<<

Hope that helps - Puppy n00bie - Ray MK

[Bruce B]

Ray,

The Full Installs would not conflict and if they did there would be a serious problem.

The boot to RAM would not conflict with any pup_save.2fs file as it would ignore them all.

If I can second guess Nathan's methods, I'd guess he's not using the name pup_save.2fs with GrafPup, because I think he's too smart.

How many files named pup_save.2fs does your rather elaborate Puppy computer have? If more than one, how did you control which one is to be used by which install?

Bruce

[Ray MK]

Hi Bruce

In addition to above I've also got 109ce, 214rm1(phoenix), LivingWater217(ttuuxxx) that I boot from CD and I am about to re-install PupEee(frugal) to hda1.

I'll post a pic of file layout - you will see that I've kept the vmlinuz & initrd.gz files from each distro(version) in its own seperate folder ie zTP for TeenPup, zGP for GrafPup etc.

Also you'll notice that the pup_save files all differ slightly - and with a process of experimentation (painful sometimes) I realised that certain 2.xx pups can live quite happily together on a partition. Some such as Breezy & TeenPup ask at bootup which save file to select(open), others don't and there is when problems occur.

As far as I can see all 3.xx pups are ok using this method as they are all capable of reading at least 2 diredtories down to find files at bootup - and they always ask for confirmation of which save_pup to open.

Same type pup's ie 3.01 (DCL & PupEee) and 2.14 (TeenPup & Phoenix) for example seem to happy enough sharing zdrv_xxx.sfs files when a frugal and a full install share the same partition - even multiple frugal's as you can see co-exist ok.

Also as this laptop has no CD burner (CDrom) only I usually open the iso after download using Isomaster and copy the files to appropiate location's - then point GRUB to appropriate sub-dir and boot 1st time as pfix=ram - set puppy up and save. All done except edit menu.lst to remove pfix=ram for 2nd boot onwards.

Have had a few brain strain's with above on occasion but have also learnt a bit in the process - hope it all makes some sort of sense.

Best Regards - Ray MK

[RickyVaio]

Could be the save.sfs thing: both versions use the same name, so...

Thanks for the input, folks.

[Béèm]

Ray MK,

With this size of image the thread is unreadable on a small display.
Bear in mind not everybody has such a hightech large lcd display.

So can you resize your picture, edit your post and re-submit with the resized picture.

[Ray MK]

Hi Beem

Thought I did reduce to 800x600 - but will reduce furrther - sorry about that

hope this ok - 600x480

regards - Ray

[Béèm]

The second picture is smaller, that's correct, but you had to go to the post with the first big picture. Resize it, edit that post and re-submit with the resized picture which has thus exactly the same name.

There was no need to re-submit a second picture, as the first one still overflows horizontaly.

[Bruce B]

The second picture is smaller, that's correct, but you had to go to the post with the first big picture. Resize it, edit that post and re-submit with the resized picture which has thus exactly the same name.

There was no need to re-submit a second picture, as the first one still overflows horizontaly.

Obviously he didn't understand what you wanted. At this point the first pic can just be deleted.