Puppy 2.16 install problem(s)

[Dougal]

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.

[joki]

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

[bobn9lvu]

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

[joki]

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.

[bobn9lvu]

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

[BarryK]

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

[bobn9lvu]

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

[HairyWill]

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.

[bobn9lvu]

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

[joki]

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

[Leachim]

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.

Code: Select all

"/initrd.gz" not found on "/dev/sda1"

But despite of my criticism: Puppy is great and I like it!

[Lobster]

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

[edoc]

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?

[GuestToo]

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

[edoc]

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?

[edoc]

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?

You weren't kidding that there were other missing files!

I copied the entirety of /initrd/pup_ro2/usr/lib/mozilla/ TO /usr/lib/mozilla/
and Seamonkey seems to now be OK.

The HTML icon now returns the usual - open this under your browser
message, kind of a wasted icon.

gxine is still unresponsive.

How do I fix that, please?

And also, any idea what may have hiccupped to cause these significant
gaps in the upgrade process from 2.14 to 2.16?

[GuestToo]

it depends what the problem with gxine is ... if it's missing or corrupted files, the files need to be replaced ... there may be missing or corrupted library files or configuration files

depending on the circumstances, an upgrade may not work properly

in your case, it sounds like you are having hardware problems, or maybe the cd did not burn properly, or maybe the iso file did not download properly

if the iso does not download properly, you would have a corrupted iso file, which would not be a Puppy iso at all ... it would be some sort of corrupted thing that might do anything to your system

i usually download isos with wget, which usually works well ... i always check the iso file's md5sum to be sure it is perfect ... i usually run Puppy as a frugal install, so i don't burn a cd, i just mount the iso file and copy the 4 files from it ... so to upgrade Puppy i might do something like this:

wget -c http://distro.ibiblio.org/pub/linux/dis ... so.md5.txt
wget -c http://distro.ibiblio.org/pub/linux/dis ... rivers.iso
md5sum -c puppy-2.16-seamonkey-fulldrivers.iso.md5.txt
mount -o loop puppy-2.16-seamonkey-fulldrivers.iso /mnt/data
cp /mnt/data/vmlinuz /mnt/home/
cp /mnt/data/initrd.gz /mnt/home/
cp /mnt/data/pup_216.sfs /mnt/home/
cp /mnt/data/zdrv_216.sfs /mnt/home/

it's a good idea to backup the pup_save file first ... which is very easy, just copy the file somewhere ... i have never had a pup_save file larger than 256 megs

[GuestToo]

if you use a pup_save file (you seem to) you can look in /initrd/pup_rw ... corrupted and damaged and deleted files should be visible in there

there may be hidden .wh. whiteout files in pup_rw that are causing some files in pup_ro2 to be invisible and therefore "deleted" ... if there are .whw. files that should not be there, they could be deleted and the files in pup_ro2 (the pup_216.sfs file0 should be available again ... i have a script that deletes all .wh. whiteout files

find /initrd/pup_rw -noleaf -name '.wh.*' > /tmp/wh.txt
cat /tmp/wh.txt | while read J
do
echo rm -f \"$J\"
[ -r "$J" ] && rm -f "$J"
done
sync
sync

you need to reboot immediately after deleting files in pup_rw (unionfs does not like it)

[basslord1124]

I downloaded 2.16 today to try it out and didn't make it very far. It made it through the first few steps in the boot process on the CD and then it crashes telling me it can't find my CD or something to that effect. I don't remember the exact error but that's basically what it said. CD is good and checksum worked out fine. So for right now, I am halting on 2.16 and just gonna stick with 2.15.

And my 2 cents...
While I absolutely enjoy Puppy Linux, I just have not been impressed with the last 2 versions. While I can get 2.15 to work, it was not without a little bit of headache to make it work. I think the most trouble-free versions I have experienced so far is Puppy 2.13 and 2.14.

[edoc]

I downloaded 2.16 today to try it out and didn't make it very far. It made it through the first few steps in the boot process on the CD and then it crashes telling me it can't find my CD or something to that effect. I don't remember the exact error but that's basically what it said. CD is good and checksum worked out fine. So for right now, I am halting on 2.16 and just gonna stick with 2.15.

And my 2 cents...
While I absolutely enjoy Puppy Linux, I just have not been impressed with the last 2 versions. While I can get 2.15 to work, it was not without a little bit of headache to make it work. I think the most trouble-free versions I have experienced so far is Puppy 2.13 and 2.14.

I am guessing that the differences are partially hardware-specific because the
newer versions are accessing new hardware and are running more sophisticated
apps.

I have used most of the MS-like Linux distros with all of their code-bloat and
saw the same sort of occasional upgrade anomalies. The good thing about
Puppy is that the code is efficient and easier for the team to troubleshoot.