Booting multiple Puppies [SOLVED]

[WhoDo]

Hi guys,

I'm fooling around trying out different Puppy configurations on my one and only hdd, and I've run into a glitch. Here is the configuration.

hda1 - Window$ XP
hda2 - Puppy 2.11 hdd install type 2, ext3
hda3 - Linux swap
hda4 - Extended partition
hda5 - PCLinuxOS /, ext3
hda6 - PCLinuxOS /home, ext3
hda7 - Puppy 2.11 hdd install type 2, ext3 (backup copy of hda2)
hda8 - Puppy 2.11 hdd install type 1, ext3 frugal

I'm booting from GRUB with the boot files located on hda5.

Here is my menu.lst configuration:

timeout 10
color black/cyan yellow/cyan
shade 1
viewport 3 2 77 22
splashimage (hd0,4)/boot/grub/mdv-grub_splash.xpm.gz
default 0

title WindowsXP
root (hd0,0)
chainloader +1

title PuppyLinux
kernel (hd0,1)/boot/vmlinuz root=/dev/hda2 ro splash=silent

title PCLinuxOS
kernel (hd0,4)/boot/vmlinuz root=/dev/hda5 splash=silent vga=788
initrd (hd0,4)/boot/initrd.img

title PuppyLinux-Bak
kernel (hd0,6)/boot/vmlinuz root=/dev/hda7 ro splash=silent

title PuppyLinux-Frugal
rootnoverify (hd0,7)
kernel (hd0,7)/vmlinuz root=/dev/ram0 PMEDIA=idehd PHOME=hda8 PUPSFS=pup_211.sfs
initrd /initrd.gz

title linux-nonfb
kernel (hd0,4)/boot/vmlinuz root=/dev/hda5 splash=silent
initrd (hd0,4)/boot/initrd.img

title failsafe
kernel (hd0,4)/boot/vmlinuz root=/dev/hda5 failsafe
initrd (hd0,4)/boot/initrd.img

Problem I've got is that even though I elect to boot from the frugal install, puppy still searches for itself and despite my boot parameters it mounts hda2 instead of hda8! Yet that doesn't happen when I elect to boot from the backup install.

Any advice thoroughly welcomed!

Cheers

[GuestToo]

yes, i think Puppy 2.x ignores PHOME

somebody said something like this might work:

PUPSAVE='ext3,hda8,/pup_save.3fs'

i have not tried it, i don't know if it will work or whether it will blow up or not ... i am not responsible for damages, etc etc

see: /etc/rc.d/PUPSTATE

[Dougal]

What exactly does it load that you don't want it to: all of Puppy or the pup_save file?

If it's just a problem with pup_save, just create a dummy file "pup_save-dummy.3fs" next to the real one on hda2 (just chose make new file in a file manager -- a plain, empty, text file).
This way when Puppy boots it'll give you a menu to choose between the two on hda2 and you select "0", so it goes on searching.

[WhoDo]

What exactly does it load that you don't want it to: all of Puppy or the pup_save file?

If it's just a problem with pup_save, just create a dummy file "pup_save-dummy.3fs" next to the real one on hda2 (just chose make new file in a file manager -- a plain, empty, text file).
This way when Puppy boots it'll give you a menu to choose between the two on hda2 and you select "0", so it goes on searching.

hda2 is a full type 2 install, so no pupsave_3fs file is present.

I want it to load Puppy from the frugal install on hda8 when I select that from Grub. It doesn't. It starts to boot, looks at hda2 and says "ok, let's load that first!" I've tried all sorts of boot parameters and no luck. The closest I got was using a modified PUPSTATE file to force it to the frugal partition, and then it said it "couldn't find Puppy on media idehd" and defaulted to a debug editor.

I'm fast running out of options. Think I'll try it with the 2.12Beta.

[WhoDo]

I'm fast running out of options. Think I'll try it with the 2.12Beta.

Well, that didn't work! I received the following error after an entirely clean 2.12 type 1 install on hda8:

ERROR, cannot find Puppy on 'idehd' boot media
PUPMODE=9 PDEV1=hda2
Exited to initial-ramdisk (/dev/ram0) commandline...
(the Linux-guru can now debug. 'e3' editor is available)
/bin/sh: can't access tty; job control turned off
#

I don't think the problem is in my Grub command line, but here it is anyway:

title PuppyLinux-Frugal
rootnoverify (hd0,7)
kernel /vmlinuz root=/dev/ram0 PMEDIA=idehd PUPSAVE='ext2,hda8,pup_save.sfs'
initrd /initrd.gz

As you can see, I've even tried it on both ext3 and ext2 file systems.

All help greatly appreciated.

[Dougal]

Your PUPSAVE is wrong. It should be like this:

Code: Select all

 PUPSAVE='ext2,hda8,/pup_save.sfs'

note the slash.

[WhoDo]

Your PUPSAVE is wrong. It should be like this:

Code: Select all

 PUPSAVE='ext2,hda8,/pup_save.sfs'

note the slash.

Yes. Out of desperation I tried it both with and without the slash. Neither worked, unfortunately. I have since discovered that I can't even boot a Puppy 1.09 frugal install from that partition. *sigh*

I give up! I'm going back to a normal hard drive install anytime I need it. I was hoping that using a frugal install would make the install process easier for my project participants. Oh well, they'll just have to follow the script instead..

Thanks anyway, Dougal.

Cheers

[Philh]

I found when I was trying different puppys on different partitions(frugal),
it worked for me if I put all the vmlinuz and initrd in folders on hd0,0.
Then I put the pup2xx.sfs and the pupsave file on another partition.
Puppy just searched and found them.
And if you try 2 with the same pup_202.sfs name, put them on different partitions,
then make a dummy pupsave and when it asks which to use select 0
and it will move onto the next partition.
Though I havent got a full install.
Maybe it will work for you.

title Puppy202regression pfileNormal noACPI home=d:
root (hd0,0)
kernel /boot/pup202re/vmlinuz root=/dev/ram0 acpi=off
initrd /boot/pup202re/initrd.gz

title Puppy202opera pfileNormal noACPI home=e:
root (hd0,0)
kernel /boot/pup202op/vmlinuz root=/dev/ram0 acpi=off
initrd /boot/pup202op/initrd.gz

When I was trying 4 files on 1 partition and setting root hd0,5
something was getting confused and it didnt boot properly.

[ecomoney]

Im having trouble dual booting 2.02 Edupup (2.12 based remaster). This is a pain as it means we cant upgrade from 1.xx for the adults set up, which in turn means we cant have AMSN 0.96 and Flash 9 Beta for emoticons and flash movies. Someones gonna be crying in the new year when the cafe reopens either way

It seems that a single puppy can happly coexist with any other operating system, even windows, just not with different versions of itself

Would there be a way of remastering and changing one of the versions to look for a different name other than "pup_save.sfs", i.e. "edupup_save"?

[WhoDo]

It seems that a single puppy can happly coexist with any other operating system, even windows, just not with different versions of itself

I was given the solution to this in another thread, ecomoney. It rests with the Grub menu.lst file. Here is mine that allows me to multi-boot several versions of Puppy. Note the hide/unhide commands are the crucial part.

Code: Select all

timeout 10
color black/cyan yellow/cyan
shade 1
viewport 3 2 77 22
splashimage (hd0,4)/boot/grub/mdv-grub_splash.xpm.gz
default 0

title WindowsXP
root (hd0,0)
chainloader +1

title PuppyLinux-Experimental
hide (hd0,7)
hide (hd0,6)
unhide (hd0,1)
root (hd0,1)
kernel /vmlinuz root=/dev/ram0
initrd /initrd.gz

title PCLinuxOS
kernel (hd0,4)/boot/vmlinuz root=/dev/hda5 splash=silent vga=788
initrd (hd0,4)/boot/initrd.img

title PuppyLinux-Frugal
hide (hd0,1)
hide (hd0,6)
unhide (hd0,7)
root (hd0,7)
kernel /vmlinuz root=/dev/ram0
initrd /initrd.gz

title PuppyLinux-Full-Install
hide (hd0,7)
unhide (hd0,6)
kernel (hd0,6)/boot/vmlinuz root=/dev/hda7 ro splash=silent

title linux-nonfb
kernel (hd0,4)/boot/vmlinuz root=/dev/hda5 splash=silent
initrd (hd0,4)/boot/initrd.img

title failsafe
kernel (hd0,4)/boot/vmlinuz root=/dev/hda5 failsafe
initrd (hd0,4)/boot/initrd.img

Hope that helps.

[ecomoney]

WhoDo you have saved the day again, I dont know what I was dreading the most...the teenagers when they couldnt use AMSN or the kids when they couldnt play SuperTux

Im not sure I will have time tonight (Ive been banging my head against it til nearly 3AM), but I will try tommorow.

Very much obliged to you for taking the time to post, happy new year!!!

[ecomoney]

Hi, tried it up at the cybercafe today with just two simple ext2 partitions and a swap oartition on a primary master disk (cd primary slave). Worked fine the first time, but after I rebooted it came up with "grub error 17". After a bit of research I found that this was something to do with the type of partition. Ran cf disk and my disks had mysteriously been labeled as "amoeba" filesystems. I relabelled them as linux ext 2 and it worked again...once.

I reformatted and repartitoned the disk, reinstalled the two setups and had another go with the same result, it worked once and then relabelled my partitions and gave error 17.

I hear the latest version of puppy has a slightly differentname pup_save.2fs, not pup_save.3fs. So that would work with a single partion perhaps. Ive got a single partition setup working on the other computers between puppy 1.09ce and 2.11 edupup. Only problem is I cant install amsn 0.96 and flash beta 9 on 1.09ce or I would stick with that.

[WhoDo]

I hear the latest version of puppy has a slightly differentname pup_save.2fs, not pup_save.3fs. So that would work with a single partion perhaps. Ive got a single partition setup working on the other computers between puppy 1.09ce and 2.11 edupup. Only problem is I cant install amsn 0.96 and flash beta 9 on 1.09ce or I would stick with that.

ecomoney, pup_save.2fs refers to the fact that the pup_save file uses an ext2 (non-journaled) Linux filesystem for storage.

If you want to have both versions in the same partition, it might be best to separate the save files, even though Puppy 1.xx uses pup100 (?) and Puppy 2.xx uses pup_save.xfs

The problem with your weird swapping partitions has to be something in the BIOS of the machine itself, or a faulty hard drive. Check your BIOS settings to ensure Plug-and-Play OS = no, and everything else looks ok first.

Hope that helps.

Cheers

UPDATE: BTW, since SuperTux will run on EduPuppy 2.11, as will Tuxmath, etc why not just move up to that? Is it a kernel support issue or is there some "killer app" in 1.09CE that has you hooked?

[ecomoney]

Hi there whodo

Have tried swapping out with one of the new cybercafe spares (same make and model), although not with a new hard disk (will try this today). Assumedly there are some bios updates for this machine which I can hopefully load using Linux, so I will try that also.

The problem with having two versions booting from grub is that I am never sure which pup_save file is going to be picked up. If the one one is used then an automatic version upgrade is performed with no warning, most of the time this fails leaving an unuseable machine.

I have tried various bois configs (I always set plug n play OS = no), and even set the MBR virus protection on (would this have any effect...it didnt seem to).

With regards 1.09ce it has always served me well, but getting the latest software developed for it (specifically flash 9 beta and amsn 0.96) is difficult. We have to dual boot two puppies (one for the kids and one for the adults) in order to keep both systems separate. The only "killer app" that 1.09ce has is the fact it uses a different save file name (pup001) and I can dual boot with 2.xx .

I tried puppy 2.13 today but it if encounters a pup_save.3fs it will again run an automatic upgrade, and if I have both a pup_sae.2fs and .3fs if brings up a menu...not good for a cybercafe environment.

[WhoDo]

The problem with having two versions booting from grub is that I am never sure which pup_save file is going to be picked up. If the one one is used then an automatic version upgrade is performed with no warning, most of the time this fails leaving an unuseable machine.

Ok, that certainly is the case IF you boot both copies from the same location in the same partition. If you have each pup_save file in its own separate partition, then you could use the hide/unhide option in Grub to prevent Puppy from loading the wrong pup_save.3fs/.2fs at boot.

Linux, and by extension Puppy, is smart enough to let you specify to load the kernel from one place and find its file system (pup_save.3fs file) from another, simply by hiding and unhiding the relevant partitions at boot.

You need:

1. A partition for vmlinuz, initrd.gz, pup_213.sfs and zdrv_213.sfs - one pup_save.2fs will go here
2. A partition for vmlinuz, initrd.gz, and pup_211.sfs - one pup_save.3fs will go here.
3. A common Linux swap partition shared at boot by either installation.

Now you can boot from either partition, hiding the other one first so as to prevent the wrong pup_save file from being found and/or upgraded.

Technically, you could even boot from the same kernel and simply pick up your pup_save file depending on which partition you hide/unhide at boot.

For example:

1. Boot partition - contains vmlinuz, initrd.gz, pup_213.sfs and zdrv_213.sfs
2. A save partition - contains pup_save.3fs number 1
3. A save partition - contains pup_save.3fs number 2

That way you would have two separate setups accessible from boot using Grub.

I know others have done something similar by putting the pup_save files in separate directories in the same partition, and calling them separately from Grub, but either of the above methods is pretty much foolproof IMHO.

Hope that helps.

[ecomoney]

At the moment I have nine computers all dual booting 2.11/109ce using one linux partition (and a swapfile) so this obviously works with my hardware. The centre opens today and I want it to "just work". Will worry about the foolproof later.

Eventually I hope to make a boot cd of the setup so I can refresh each computer individually with a zipped up contents of the linux partition. That way to add a new coputer I would just have to boot into memory, partition the drive (one linux and a small swap), install GRUB to the MBR, then unzip the dive contents (including the /boot directory) to the new linux partion.

Since the cybercafe needs dual booting (and keep it needs to be kept simple...I want to offer the CD for download from the cybercafes upcoming website) how would dual booting separate pup_save.3fs from different directories in the same partion work?

[WhoDo]

Since the cybercafe needs dual booting (and keep it needs to be kept simple...I want to offer the CD for download from the cybercafes upcoming website) how would dual booting separate pup_save.3fs from different directories in the same partion work?

Actually, it may not even be necessary to use separate directories if you want to use different setups. Consider this contribution from Dougal:

If it's just a problem with pup_save, just create a dummy file "pup_save-dummy.3fs" next to the real one on hda2 (just chose make new file in a file manager -- a plain, empty, text file).
This way when Puppy boots it'll give you a menu to choose between the two...

If that works, you could simply rename your first pup_save as pup_save_boot1.3fs and your second as pup_save_boot2.3fs and Puppy should ask which to use.

Of course you would need to make the name mean something to help you decide which file to boot with.

That is only going to work if you use the same pup_2xx.sfs for both pup_save files. With split partitions, however, you could use entirely different 2.xx versions of Puppy.

There is no problem mixing Puppy 1.xx and 2.xx because they use different boot images - image.gz for Puppy 1.xx and initrd.gz for Puppy 2.xx - but there only way to mix 2 different versions of Puppy 2.xx is to put the pup_2xx.sfs files in separate directories and modify Grub to call the kernels from those directories. For example:

Code: Select all

title EduPuppy
root (hd0,0)
kernel /edupup/vmlinuz root=/dev/ram0
initrd /edupup/initrd.gz

title PuppyStar
root (hd0,0)
kernel /pupstar/vmlinuz root=/dev/ram0
initrd /pupstar/initrd.gz

Then you would save the EduPuppy pup_save.3fs to /edupup and the PuppyStar pup_save.3fs to /pupstar

Theoretically, Puppy should use the first pup_save file it finds, which should be the one in the current boot image directory. I haven't tried it, but that's the theory, ecomoney.

Hope that helps

[ecomoney]

Will try the "pup_save.3fs file in same directory as kernel" method you explained, edupuppy has many of the games already in RAM for faster loading so we cant use the same pup_2xx.sfs file for both, notwithstanding the menu would be very confusing for most people that visit the cafe.

Will report back in a moment.

[ecomoney]

Still no success

I created a GRUBed harddisk with one linux ext2 partition and a small swap partition. In the /grub directory I placed two subdirectories "office" and "edupup" and placed the init.gz, vmlinuz and pup_save.3fs for both edupup (2.11) and puppyoffice (2.02) in their respective directories. Grub file is as follows

Code: Select all

# Start GRUB global section
timeout 10
color light-gray/blue black/light-gray
# End GRUB global section
# Linux bootable partition config begins
  title Office
  root (hd0,0)
  kernel /boot/PuppyOffice/vmlinuz root=/dev/ram0
  initrd /boot/PuppyOffice/initrd.gz 
  title Edupup
  root (hd0,0)
  kernel /boot/Edupup/vmlinuz root=/dev/ram0
  initrd /boot/Edupup/initrd.gz 
# Linux bootable partition config ends

For both entries I get the text

Looking for pup_save.3fs file in hdc partition (iso9660 filesystem)
Looking for pup_save.3fs file in hda1 partition (ext2 filesystem)

then it adds the swap, then I get

Code: Select all

ERROR, cannot find Puppy on idehd boot media
PUPMODE=1 PDEV=

Exited to initial ramdisk commandline...
[/code]

It seems that puppy will only pick up pup_saves if they are in the root directory, and two pup_saves cannot exist in the same directory unless they are named different things.

If I didnt know better, I would call puppys handling of multiple booting positively redmundesque. With the wide wealth of puplets available for different jobs (medical puppy, office puppy, edupup etc) not being able to multi boot several versions is a big oversight. I wish there was just an option of specifying which files to use at boot time in the grub config, or specifying a new name for pup_save.3fs when a new puplet is created . This would solve a lot of problems and make puppy eminnently more useable.[/code]

[WhoDo]

It seems that puppy will only pick up pup_saves if they are in the root directory, and two pup_saves cannot exist in the same directory unless they are named different things.

Yeah, it's a worry if you want to stick with only one partition. Renaming the pup_save files will still require your users to make a choice at boot, but at least offering the choice is automatic i.e. independent of Grub (see earlier post).

Try this suggestion from Guesttoo on the kernel line in Grub:

somebody said something like this might work:

PUPSAVE='ext3,hda8,/pup_save.3fs'

i have not tried it, i don't know if it will work or whether it will blow up or not ... i am not responsible for damages, etc etc

see: /etc/rc.d/PUPSTATE

Maybe you could use that as a workaround. I don't know if Puppy 2.xx accepts that parameter but you have nothing to lose at this point.

Cheers