(old)Puppy Linux Discussion Forum

Dougal wrote:Barry, should I remove the "-R" from the remaster script?

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

tillerman wrote: - openoffice-2.2.0.sfs renamed to oo_216.sfs,

Who said you had to rename it? You don't.
You unchecked the checkbox, did you also move 'openoffice-2.2.0.sfs' over to the right pane?

openoffice-2.2.0 renamed oo_216.sfs and loaded with Bootmanager. This worked after reboot.
After reboot you can see that. Click on any item the program start immediately

Yes, but you don't have to rename it. You can use the SFS Boot Manager to choose to load a SFS file with any name. You just have to untick the checkbox and move the required SFS files over to the right pane, click OK then reboot.

Barry wrote:

Who said you had to rename it? You don't.

Yeah, well, when you run out of qualified ideas, you sometimes start shooting in the dark. At times, the programs shoot back, out of the dark! Well, I counter-renamed the .sfs, re-downloaded it, md5sum-checked it, rebooted, and the rest shows in the screenshot, but - still no dice! The OO-icons are present, but when I click them, nothing happens.
tillerman

BarryK wrote:

Dougal wrote:Barry, should I remove the "-R" from the remaster script?

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.

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

bobn9lvu wrote: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.

joki wrote:

bobn9lvu wrote: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...

Bob

'_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.

BarryK wrote:'_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??


Thanks !

Bob

try commenting out line 82 of /usr/sbin/bootmanager

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.

Agreed, AND I do have LOTS of drive space, but the way I asked the question,
was more of a learning curve/experience.

I am happy with 2.16 and OO with manually added specific programs...

Bob

BarryK wrote:'_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.

I had similar problems about "Puppy not found".

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.)

Is there any specific reason for this strict behaviour?

Anyway I would appreciate more detailed error messages, e.g. But despite of my criticism: Puppy is great and I like it!

This problem was solved in 2.12 and yet in 2.16 the driver was ommitted?

- anyway here s the solution

http://www.murga-linux.com/puppy/viewto ... 150#117150

2.16 broke Seamonkey, html, gxine, email

calendar, chat, calc, paint, dillo work OK.

/tmp/xerrs.log shows:

/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.

Help?

if you have a frugal install, copy the missing seamonkey-bin file from /initrd/pup_ro2/usr/lib/mozilla/ to /usr/lib/mozilla/

if you have a full install, boot the Puppy cd maybe using the pfix=ram option, mount the partition, and copy the missing seamonkey-bin file from /usr/lib/mozilla/ to the mounted partition

there may be other missing files

GuestToo wrote:if you have a frugal install, copy the missing seamonkey-bin file from /initrd/pup_ro2/usr/lib/mozilla/ to /usr/lib/mozilla/

if you have a full install, boot the Puppy cd maybe using the pfix=ram option, mount the partition, and copy the missing seamonkey-bin file from /usr/lib/mozilla/ to the mounted partition

there may be other missing files

Thanks, did the copy, will reboot.

Any idea why this would have happened?