transition from 2.9 to 2.10 goes pretty smooth

[Ethan Grammatikidis]

On Mon, 22 Jun 2009 09:48:41 -0400
"Carlos O'Donell" <carlos@systemhalted.org> wrote:

> On Thu, May 14, 2009 at 7:33 PM, Justin Mattock<justinmattock@gmail.com> wrote:
> > After compiling glibc-20090511
> > and installing(you guys do a good job)
> > I noticed that libc-2.9.90.so
> > changes to libc-2.10.1.so.(was a bit nervous
> > about the transition from 2.9 to 2.10, but now
> > I realize it's already done).
> >
> > Anyways now that I've made the transistion from
> > 2.9 to 2.10 without even realizing, how would I go
> > and remove the old libs?(manually or run make uninstall
> > from glibc-20090504's(glibc-build directory)?
> >
> > In any case everything seems good..
> 
> Installing glibc using "make install" is not a good idea, you are left
> with some applications running with cached and loaded old libc and new
> ones that have started up with the new libc.
> 
> The correct way is:
> 1) Use alternate root fs.
> 2) Install glibc into target root fs using tools from alternate root fs.
> 3) Pivot into the new root fs.

I'm not entirely sure what you mean by "pivot" here. It's been some time since I played with pivot_root() but I'm pretty sure it's not capable of substituting "cached and loaded" shared libraries within already-running applications. AFAIK the only way to do that is to restart every running process linked against glibc, AKA almost everything.

Installing to a new root may be a good idea for the sake of having a sane uninstall path, but really nothing short of rebooting will ensure everything is using the new libc. You could take the system down to single-user mode, make sure everything except kernel processes are killed, pivot, & then bring everything back up, but what would that accomplish other than wasting your own time? Bear in mind udevd is one of the processes that will need restarting.

I'm making a point of this because it often seems to me there is a lot of, if you'll pardon the strong term, FUD being spread on some areas of base-system maintenance. The worst area is fdisk; the very strongest warnings I've seen concerning anything Linux-related were instructions to never ever do things which I *have* done successfully using fdisk, so you understand my concern.

> To fix a mistake:
> 1) Pive to old root fs.
> 2) Uninstall glibc from new root fs.
> 3) Install old glibc to new root fs.
> 4) Pivot to new root fs.
> 
> I use chroot's built with debootstrap to test new glibc builds.
> 
> Cheers,
> Carlos.


-- 
Ethan Grammatikidis
The lyf so short, the craft so long to lerne. -- Chaucer