Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 12 Dec 2017, 18:01
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Misc
I accidentally delete glibc
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 1 [9 Posts]  
Author Message
jamesbond

Joined: 26 Feb 2007
Posts: 3103
Location: The Blue Marble

PostPosted: Mon 04 Dec 2017, 03:14    Post subject:  I accidentally delete glibc
Subject description: Fatdog64-only
 

I accidentally removed glibc.

I was running Fatdog build process and I wanted to remove glibc from its chroot.
The correct command was this:
Code:
ROOT=chroot removepkg glibc32 glibc


but I typed in the wrong way:
Code:
removepkg ROOT=chroot glibc32 glibc


This has the unintended effect of attempting to remove ROOT=chroot package (which didn't exist), and then glibc32, and glibc.

Of course it wasn't fully successful, but the dynamic linker
/lib64/ld-linux-x64_64.so.2 was deleted and that's enough to stop
almost anything.

What to do? Read more: http://lightofdawn.org/blog/?viewDetailed=00179

_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2632

PostPosted: Mon 04 Dec 2017, 06:45    Post subject:  

Surely you have this:
installpkg glibc32 glibc
although your installpkg&Co are probably hostage to glibc. So, reboot with some sort of live CD and then:
ROOT=/path/to/mounted/ partition installpkg glibc32 glibc
Are your install/removepkg homegrown or from slackware or??
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 3103
Location: The Blue Marble

PostPosted: Mon 04 Dec 2017, 07:02    Post subject:  

amigo wrote:
Surely you have this:
installpkg glibc32 glibc
although your installpkg&Co are probably hostage to glibc.

Exactly. installpkg is a shell script, and /bin/sh requires glibc to run.

Quote:
So, reboot with some sort of live CD and then:
ROOT=/path/to/mounted/ partition installpkg glibc32 glibc

The point is to recover without re-booting

Quote:
Are your install/removepkg homegrown or from slackware or??

From Slackware 14.0, modified to support some additional features (e.g. faster operation, support for uninstall script) but still fully backward-compatible with Slackware's original. I choose to drop improvements that would break compatibility.

_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.
Back to top
View user's profile Send private message 
battleshooter


Joined: 14 May 2008
Posts: 1368
Location: Australia

PostPosted: Mon 04 Dec 2017, 07:18    Post subject:  

That was an interesting read James, very clever. I've done that many times when playing around with glibc, making the whole system unusable but not wanting to lose all the work I'd done. I'm constantly fascinated by the innovations you and the Fatdog team come up with Smile
_________________
LMMS 1.0.2, Ardour 3.5.389, Kdenlive 0.9.8
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2632

PostPosted: Mon 04 Dec 2017, 14:50    Post subject:  

plus, installpkg will call gz or xz and tar and possibly ln and others from doinst.sh
with glibc gone you may not be unable to start *anything* -even statically compiled stuff because your ld-linux.so is gone.
I would have thought that you had thought about this situation before. You could maybe avoid this by using statically-compiled tools in the installpkg script and /bin/sh.

The other thing to think about here is how does one successfully upgrade glibc or any of the tools used during package installation. Study slackware's doinst.sh for glibc/glibc-solibs and also what upgradepkg does.
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 3103
Location: The Blue Marble

PostPosted: Fri 08 Dec 2017, 12:03    Post subject:  

@battleshooter: thanks! Necessity is mother of invention - we use the feature and find it lacking, so we strive to do better so next time we all have less pain when *** hits the fan, as my friend likes to say Smile

@amigo:
Quote:
plus, installpkg will call gz or xz and tar and possibly ln and others from doinst.sh
Indeed.
Quote:
with glibc gone you may not be unable to start *anything* -even statically compiled stuff because your ld-linux.so is gone.
Statically compiled stuff don't need ld-linux.so. They can still run. But most of the stuff in the system are indeed dynamically compiled, once ld-linux.so is gone they all will stop working.
Quote:
I would have thought that you had thought about this situation before. You could maybe avoid this by using statically-compiled tools in the installpkg script and /bin/sh.
Indeed. My solution is to always carry a statically compiled busybox with all applets, including ash, compiled with PREFER_APPLET.
Quote:
The other thing to think about here is how does one successfully upgrade glibc or any of the tools used during package installation. Study slackware's doinst.sh for glibc/glibc-solibs and also what upgradepkg does.
Of all pkgtools script, upgradepkg is the only one I haven't modfied. upgradepkg says that what it does is do "installpkg" and the remove files not in the new package. That doesn't sound interesting to me, because you can always do it using removepkg/installpkg combination.
There is a certain value of upgradepkg, but I think in reality it isn't very useful especially for us that runs layered filesystem; we can always boot pristine and do any "upgrades" we need by using "ROOT=/mnt/savefile removepkg or installpkg". This is much safer than actually using upgradepkg; because the binaries/libs more often than not cannot be overwritten (="upgraded") if they're being locked/mmmap-ed by a running process.
That being said, I probably need to start looking at it for completeness reasons (at least for performance improvement if not for anything else).

glibc-solibs update is always very risky; you have said so yourself in many of your other posts. I don't do that, and I don't recommend anyone to do that; which is why what battleshooter does is commendable Smile she's trying and succeeding at glibc update; something that are risky and in theory can cause a lot of breakage Smile

_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2632

PostPosted: Fri 08 Dec 2017, 16:33    Post subject:  

upgradepkg != removepkg + installpkg
That procedure won't allow you to update things like tar or xz

upgradepkg:
1. first moves the database file for the old package out of the way,
2. then installs the new package,
3. then removes files from the old package which are not in the new package,
4. installs the new package a second time to 'make sure' (actually to cover an old corner case when doing a major upgrade from long, long ago.

Again #3, uses the (moved) file list from the old package to cross-reference.

Do you understand the reasoning in 1, 2 and 3? The problem is how to upgrade something which is being used by installpkg/removepkg. Upgrading glibc is the same, except it needs special handling in the doinst.sh in order to have working libc.so for all the other tools.

Of course, having a dedicated set of static-tools can ease that some. But the upgrade process is still the same: overwrite old files with new files, remove any old files which were not overwritten. Note also that link-creation must also be done at the proper point.
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 3103
Location: The Blue Marble

PostPosted: Sat 09 Dec 2017, 04:26    Post subject:  

amigo wrote:
upgradepkg != removepkg + installpkg
That procedure won't allow you to update things like tar or xz

upgradepkg:
1. first moves the database file for the old package out of the way,
2. then installs the new package,
3. then removes files from the old package which are not in the new package,
4. installs the new package a second time to 'make sure' (actually to cover an old corner case when doing a major upgrade from long, long ago.

Again #3, uses the (moved) file list from the old package to cross-reference.

Do you understand the reasoning in 1, 2 and 3? The problem is how to upgrade something which is being used by installpkg/removepkg.

Thanks, I've read upgradepkg source and yes I understand both the steps and the reasoning.
Indeed that's the only way to do it in non-layered filesystem.
In a layered filesystem there is a much more comfortable way as I wrote above; altthough obviously upgradepkg will work as well (if the package is created carefully).

Quote:
Upgrading glibc is the same, except it needs special handling in the doinst.sh in order to have working libc.so for all the other tools.

I can't recall whether I have read glibc-solibs doinst.sh or not. But I remember reading one of package install script (could be debian or could be slackware) where the new incoming glibc has so many files that was renamed during packaging and need to be renamed back, in the correct order, to keep the (non-static) tools going until installation is complete. A lot of hassle Smile

Quote:
Of course, having a dedicated set of static-tools can ease that some.

I think it will help a lot. Static busybox is really helpful. But for this to work, the pkgtools must be written to use only features supported by busybox, which they are (I think); because pkgtools is also designed to be used from a Slackware "floppy rescue" disk (or is it install disk? Can't recall) that only has busybox.

Even glibc can't help it - when you build glibc it installs for itself, a file in /sbin/sln which is 600K in size. It is a glibc-statically-compiled "ln" which is used to create glibc symlinks.

Quote:
But the upgrade process is still the same: overwrite old files with new files, remove any old files which were not overwritten. Note also that link-creation must also be done at the proper point.

Indeed.

_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2632

PostPosted: Sat 09 Dec 2017, 12:14    Post subject:  

You also need to understand the nuances of the tar version and options being used both to create and to unpack the packages. if you've ever wondered why slackware uses an ancient version of tar (1.13) it's precisely because it did/does something which newer versions of tar did not. Someone did at tar-1.27 create an option to tar which does the 'old thing' which tar-1.13 did. The thing is to not overwrite links-to-directories with a real directory when unpacking the archives. The 'admin' should be able to use links to mount-points, for instance, at his will, without the installation of a package un-doing that.

Also, installpkg unpacks the archive first, and directly into place, before running the doinst.sh even. I once saw a user who complained that upgrading a package should not overwrite any old files...?? No clue there...

My replacement packaging system (tpkg/tpm) allow also for pre-install, pre-uninstall and post-uninstall scripts. I experimented with first unpacking packages in a discreet location before moving them into the right place. But, just as with the slack pkgtools doing an install/remove/re-install sequence when upgrading, it becomes a long, slow process. The same scrutiny can be done by long-listing the tar archive before unpacking -and even unpacking just the install-scripts so that any pre-installation stuff can be done.

Listing the archive before installing is a good idea anyway -because it provides confirmation that the package is well-formed and complete. Anyway, the really critical points of installation and especially upgrade of any critical binaries, is when the links get destroyed by installpkg and then re-created by the doinst.sh.

tpkg/tpm are now using links *in the archive* as the newer tar does the proper thing with them. PatV's decision to use doinst.sh scripts was owing in-part to the old tars' faulty behaviour when overwriting exisiting links. Most packaging systems frown on having package installation run scripts because of security issues. Instead they use 'triggers' which cause the package installer to carry out the needed tasks -but only the tasks that it knows how to do -no arbitrary commands possible. This also the way the android app-installation process works. Each app contains its' own installer binary and installation script -but the script language is like the triggers system beacause it can only do a limited set of things.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 1 [9 Posts]  
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Taking the Puppy out for a walk » Misc
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0582s ][ Queries: 11 (0.0046s) ][ GZIP on ]