Fatal bug uninstalling glibc-2.4.pet

[fernan]

Hi, I' m running 2.16 from CD, with a 512Mb pup_save file in my hda6 partition.

here is the scenary:

Trying to make Wine work, followed several instructions in this forum.
The only option that worked for me was to install glibc-2.4.pet and wine-0.9.35.pet.

http://www.murga-linux.com/puppy/viewto ... 80&t=17359

But, simultaneously, my Pure FTPD stops working,

http://www.murga-linux.com/puppy/viewtopic.php?t=19009

and I continued to look for info about running Wine.
And I found that Nathan F says that upgrading glibc can break things

http://www.linuxquestions.org/questions ... p?t=561875

So... I decided to uninstall glibc-2.4, using the package manager. It asked to uninstall the package, and I answered OK.
Suddendly, my 190 Mb free space came down to 18K, and then to NONE. Of course PUPPY stop responding. I had to power down the machine to restart it. And never rebooted. The last lines that I' ve got from puppy were this:

creating unionfs on (/initrd)/pup_new (to become '/')... done
/sbin/init: exec: 1784: chroot: not found
Kernel panic - not syncing: Attempted to kill init!

I can mount the old pup_save.2fs from a "live" session, so I restored my e-mails to another fresh pup_save file.
Tried to install wine again, this time using Wine-0.9.28_212.sfs (renamed to 216). And It didn' t work.
Tried to install again glibc-2.4.pet and wine-0.9.35.pet. PureFTP stop working again.
After testing in a "toram" session that actually installing glibc-2.4 was breaking my PureFTP, I decided to uninstall glibc-2.4 ... but my "free space" was now 480Mb. Started the package manager. It asked to uninstall the package, and I answered OK. My 480 Mb free space came down to 18K, and then to NONE. and the history repeats.
Now I have 2 broken pup_save.2fs ....

Any idea?

Thanks in advance.

[Barburo]

I have just experienced the same thing but via a different route:
I run Puppy 2.16 from live CD using a pupsave file, and I decided to upgrade to seamonkey 1.1.4 (no problem).
Found that 1.1.4 required a manual install of flash 9 plugin.
Followed instructions for manual install (through console) and it failed with message that my glibc was ver 2.2 or earlier.
Searched and found a dotpup for 2.3.2 - installed just fine.
Re-tried installing flash 9 through console and it again failed with message (in caps) that told me I needed glibc 2.4.3. at the same time my memory went to zero and nothing resonded so I tried to reboot using my existing pupsave file and got very similar messages to fernan's:

chroot: /lib/libc.so.6: version 'GLIBC_2.3.4' not found (required by chroot)
Kernel panic - not syncing: Attempted to kill init!

I then used my live CD with pfix=ram to get a puppy session and I renamed my pup.save file to a back-up name and renamed an old pup.save back-up to pup.save2fs.

I then used my Original 2.16 live CD to try to get back to a recovery point, and I am mystified as to why I get the same 'GLIBC_2.3.4' not found error again! Original CD and old pup.save file.
How can it know about any new glibc? --> turns out I needed to remove all system files from the HDD.

Anyone have any helpful explanation of why glibc update would kill puppy, and whether I can recover my old (now renamed) pupsave file?

[paulski]

fernan ,you don't need glibc2.4 for wine in Puppy 2.16
Here's what I did
Install the glibc 2.3.6 (you don't need 2.4 )
downloaded glibc-solibs-2.3.6-i486-6.tgz
from Slackware (www.slacky.eu)
Opened terminal in the folder where I saved it and then
tgz2pet glibc-solibs-2.3.6-i486-6.tgz
Which made a nice .pet that I installed
Then wine worked

[Pizzasgood]

Anyone have any helpful explanation of why glibc update would kill puppy

glibc is one of the most fundamental libraries in Linux. Nearly everything depends on it. So if you bork it, pretty much everything dies.

If you install a PETget package, PETget will log any new files that get installed, so that if you want to uninstall it, it can just remove those packages. However, it logs files that overwrite already existing files exactly the same as brand new files. So if you install a new version of a package that overwrites some files from the old package, then uninstall it, the original files that were overwritten will also be gone.

If you downloaded the Unleashed package for the standard glibc for your version of Puppy and installed that, it might put everything back.
Puppy 2.xx:
ftp://ftp.ibiblio.org/pub/linux/distrib ... ackages-2/
Puppy 3.xx:
ftp://ftp.ibiblio.org/pub/linux/distrib ... ackages-3/

Of course, that would need to be done manually from outside the save_file, since that's broken. You'd have to boot with pfix=ram, then mount the save file (go to the partition it was saved on and open a terminal there. Run mount pup_save.2fs /mnt/data -o loop to mount it). Now make an empty directory in /tmp/ to extract the package to. Put the glibc package there. Run these commands:
pet2tgz glibc-2.3.5.pet
tar -xf glibc-2.3.5.tar.gz
Now copy the files inside the glibc-2.3.5/ directory that was created into /mnt/data/ (the two usr/ directories should merge, along with the rest of them). If it gives you errors about symlinks, go into /mnt/data and delete whatever symlinks are causing problems, then try again.

Now unmount it with umount /mnt/data and reboot. It should hopefully be fixed. But maybe not. Might be a good idea to back the thing up before doing anything, in case the process just makes it worse

[Pizzasgood]

I then used my live CD with pfix=ram to get a puppy session and I renamed my pup.save file to a back-up name and renamed an old pup.save back-up to pup.save2fs.

I then used my Original 2.16 live CD to try to get back to a recovery point, and I am mystified as to why I get the same 'GLIBC_2.3.4' not found error again! Original CD and old pup.save file.
How can it know about any new glibc? --> turns out I needed to remove all system files from the HDD.

The save file is normally pup_save.2fs, but Puppy actually will look for anything that starts with pup_save and ends with either .2fs or .3fs (it depends on which version of Puppy you have for which it looks for, and some versions might look for both. I don't remember which). So to rename something so that Puppy won't see it anymore, you need to put something on the beginning or end rather than middle. I usually rename them to pup_save.2fs_BAK.

renamed an old pup.save back-up to pup.save2fs.

That might be the other half of your problem. It should be pup_save.2fs. That might just have been a typo though.

If you did do both renames correctly, then I'm not sure why Puppy messed up.

[Juveno41]

I'm planning to install glibc on my Puppy. But after reading this thread, I don't know what to do. It seems that i won't be able to do a clean uninstallation, or upgrade it later without leaving some useless files.
Does this mean that other pet packages are also likely to damage some part of Puppy?
And is there a way to make a more accurate installation log, like backing up the files that are overwritten, for example?

[Pizzasgood]

And is there a way to make a more accurate installation log, like backing up the files that are overwritten, for example?

AFAIK, you'd have to modify the petget script so that before copying the files it checks if any of them exist first. You could have it make a list and then show the list and ask if it should back them up somewhere.

Alternately, you could manually extract the package before installing it. Inside, it will have the standard filetree, except the only files in it are the ones it installs. So you could look through it and check your system for files with the same names by hand.

Yes, I know those aren't ideal solutions

Does this mean that other pet packages are also likely to damage some part of Puppy?

Most are probably fine. Only the ones which replace system files might be a problem. The problem of course is knowing which packages those are.

As far as upgrading goes, in a non-Full-hd install you would likely be reverted to the original versions of any overwritten files. I never let Puppy update me though, so I'm not certain.


My suggestion is to back up your save file every now and then, just in case. Especially before upgrading.

[Juveno41]

AFAIK, you'd have to modify the petget script so that before copying the files it checks if any of them exist first. You could have it make a list and then show the list and ask if it should back them up somewhere.

Yes, I know those aren't ideal solutions

It seems close to the ideal solution to me. One could make the petget script so it makes a backup of the files overwritten each time a package is installed, and restore them when one is removed.

I wonder why we don't do it that way, but you have to keep in mind that my experience is quite limited, so I guess that it must be hard to do for some reason?

[Pizzasgood]

I meant "not ideal" as in it isn't already implemented, so for now anyone who wanted it would have to resort to DIY. As for why we don't already do that, probably just because nobody took the time to think about it.