upgrade of libc-2.3.3.so to libc-2.3.6.so problematic?

Dan Nicholson dbn.lists at gmail.com
Sat Aug 26 01:33:05 PDT 2006


On 8/26/06, lynx.abraxas at freenet.de <lynx.abraxas at freenet.de> wrote:
>
> In  the  FAQ  it  says: "Another rule of thumb is: don't upgrade the toolchain
> (gcc, glibc and binutils)"
> But in the introduction of BLFS is says: "For micro version updates, a  simple
> reinstallation usually works"

The BLFS intro is more accurate. The reason for the info in the FAQ is
that updating the toolchain can be disastrous if it goes wrong. It's
mainly a guard against people ruining their systems and getting upset
about it. Doing a micro version update is safe when done correctly.

> I would like to have some advice on this. Should I do the upgrade? And if, are
> there any special steps necessary? (like I found in a mail:  configure;  make;
> init 1; make install; init 3)

That's pretty accurate, but it leaves out a crucial safeguard.

First, change down to runlevel 1. Basically, you want to minimize the
number of running programs linking to glibc (all of them). That
recommendation comes from Ulrich Drepper himself.

Now, patch/configure/make just like in the LFS book, but don't "make
install" yet. If you run "make install" directly, it will remove
crucial existing libraries before installing the new ones. While this
may not cause a problem, it could be disastrous. Imagine having a
system with no libc. You're not going to get too far.

So, you want to install into a temporary location.

make install_root=/some/temp/location install

That will install all the files into /some/temp/location. This is how
all the distros do it. How you transfer the files from there to /
varies. Here's one suggestion that I use on my system. I upgraded from
glibc-2.3.4 to glibc-2.3.6 a couple months ago. I haven't had an
issue.

I stole this from Greg Shafer's scripts, and David Rosal, who wrote
the paco package manager, has dubbed it the "tar sandwich". As root:

cd /some/temp/location
tar -cf - . | tar -C / -xf -

Basically, you're using tar to archive all the files to stdout, then
changing directories to / and extracting them from stdin. Tar will
keep the permissions and ownership of the files when run as root. For
reasons that I can't explain fully, this is safer than "rm
/lib/libc.so.x.y.z && install -m755 libc.so.x.y.z /lib" which is
basically what the Makefile would do. Something about the inode of the
original files not being deleted because programs in use are linked to
them. I'm sure the cluebat will be pulled out for that gross
explanation.

Then, you may want to reboot so that all the running utilities will
release their link to the old libc. Or you could restart all the
programs. Or, you can just keep going because it's not a problem and
I'm misinformed.

> I have an LFS 5.1.1 and don't want to do a new one from scratch.
> Just out of interest: What happens if one does an glibc-upgrade in gentoo?

They all use package managers. For instance, RedHat uses RPM. It
installs to a temp dir and then uses cpio to copy to /. I don't know
how ebuild works, though.

Good luck. I'd make sure to make a backup of the original glibc and
make sure I had a LiveCD handy in case anything terrible happened.

--
Dan



More information about the lfs-support mailing list