Option '-R' works. It is Rock Ridge extensions that keep all file attributes as-is, vital for the multisession CD/DVD.

Oops... I got myself all confused, with the Rock Ridge and Joliet thing... I'll just make sure there's no "-J" there._________________What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

i think it would be useful if the 2.16 (frugal) install issues and workarounds could be detailed in a sticky announcement. i needed 2.12 and 2.16 both frugally installed on my win98 c drive (fat hda1). If anyone's interested the only config that worked:

For 2.12 : put vmlinuz and initrd.gz in a folder /pup212
All 2.12's sfs files and pup_save.3fs must remain in the root (presumably 2.16 was going to be able to have the sfs files in a nominated folder too?)
Create batch file to run 2.12:
cd \pup212
loadlin.exe vmlinuz rw init=/etc/init root=/dev/ram0 lang=us initrd=initrd.gz

For 2.16 : put vmlinuz and initrd.gz in root of drive c and all it's sfs files and pup_save.2fs must also be in the root.
Batch file to run 2.16:
cd\
loadlin.exe vmlinuz rw init=/etc/init root=/dev/ram0 initrd=initrd.gz

i have tried passing various combos of PSAVEDIR=/pup216, PDEV1=hda1, PFILE=pup_216.sfs all to no avail.

--

My outstanding questions regarding puppy 2.16:

1. have tried PUPSAVE=ext2,hda1,pup_save.2fs but the loader still asks me to choose which save file to use. i've pup_save.3fs for 2.12, and pup_save.2fs for 2.16 (2.12 doesn't look for the 2fs thankfully)

2. sfs boot manager - why won't it allow you to select sfs's with _puppuversion in the name (eg winexx_212.sfs)? I understand there will be trouble if the wrong devx sfs is selected but some sfs's will work fine on many puppy versions, wine being one. Since puppys earlier than 2.16 require the version in the filename the only option for 'dual puppy frug installs' is to have multiple copies of the sfs files. win98 users could use .bat files to rename as necessary but xp users are stuck with ntlr/grub

I can see things are getting more slick/polished in the 2.16 front-end. this can only help bring more interest , but it would be nice if startup stuff was more retro-friendly and modular...

The boot manager DOES allow one to use the Puppy version.
DO NOT UNCHECK the box towards the bottom,
and rename up to 3 sfs with _"VERSION",
or (OO_2.16.sfs) to automagically load em on boot.

Bob

this is exactly the problem! i have winexx_212.sfs which i want to use for both puppy 2.12 and 2.16 which are frugally stored on drive c.
2.16 boot manager specifically states that it excludes from selection all sfs files like _nnn.sfs where nnn not equal to 216.

The boot manager DOES allow one to use the Puppy version.
DO NOT UNCHECK the box towards the bottom,
and rename up to 3 sfs with _"VERSION",
or (OO_2.16.sfs) to automagically load em on boot.

Bob

this is exactly the problem! i have winexx_212.sfs which i want to use for both puppy 2.12 and 2.16 which are frugally stored on drive c.
2.16 boot manager specifically states that it excludes from selection all sfs files like _nnn.sfs where nnn not equal to 216.

Well, then do it manually by unchecking the box, and selecting which sfs you want to load, THEN you do NOT have to rename them for each version of Puppy...

'_xxx' SFS files that are not for the current version get totally excluded from the left-pane selection list, so you can't load them. I did that deliberately, as my experience is that if people are given the slightest chance to do something wrong, then someone will -- well, most people will realise that a '_215' SFS may not be intended for say v216. But, I decided to play safe and leave them off the list.

'_xxx' SFS files that are not for the current version get totally excluded from the left-pane selection list, so you can't load them. I did that deliberately, as my experience is that if people are given the slightest chance to do something wrong, then someone will -- well, most people will realise that a '_215' SFS may not be intended for say v216. But, I decided to play safe and leave them off the list.

So you are saying, that in order for a person to use the same sfs file in
different versions of puppy, you have to have a copy renamed for each of the
puppy versions...
Hmmmm, it would take up a LOT of needed space..

Could you add a checkbox in the mount utility to negate this feature??
Or provide some way ( different util version) to negate this feature??

My personal opinion is that users running multiple puppy versions should really be knowledgeable enough to manage this themselves or should invest the disk space needed to create multiple sfs file versions.

Open source allows any one to configure anything the way they wish if they invest the time in learning how. It is much better to guarantee a working solution to those that do not wish to learn how to configure things themselves._________________Will
contribute: community website, screenshots, puplets, wiki, rss

'_xxx' SFS files that are not for the current version get totally excluded from the left-pane selection list, so you can't load them. I did that deliberately, as my experience is that if people are given the slightest chance to do something wrong, then someone will -- well, most people will realise that a '_215' SFS may not be intended for say v216. But, I decided to play safe and leave them off the list.

fair point.
dialog could allow the selection of _214, _212 etc files after some warning/confirmation.

there's now a trend for creating sfs files without the _xxx in the filename - may cause problems in the future as they will be listed in future puppy version's boot manager dialog.

tricky one. maybe a hidden file in the sfs could let the sfs manager know if it's 'generic' enough for any puppy version.

or if it's just the system sfs's like devx and zdrv you're worried about, specifically exclude those from selection. ie, ensure devx and zdrv sfs always have the puppy version on them and for the list of known 'system' sfs's the _xxx is required.

The reason is simply that V2.16 insists that the initial ramdisk file is called "initrd.gz" - in V2.15 I could rename it to an arbitrary name (and change the boot configuration file accordingly) and everything continued to work fine. (This has nothing to do with filename capitalization.)

/usr/lib/mozilla/mozilla-bin: line 35: /usr/lib/mozilla/seamonkey-bin: No such file or directory
/usr/lib/mozilla/mozilla-bin: line 35: exec: /usr/lib/mozilla/seamonkey-bin: cannot execute: No such file or directory

I am anxiously seeking a solution else I will have to very reluctantly roll back to 2.14 -- what may have caused this odd anomaly and how might it be resolved, please?

We are in the middle of selling our home and E-mail and Internet access are critical.