This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: transition from 2.9 to 2.10 goes pretty smooth


On Mon, Jun 22, 2009 at 10:53 PM, Ethan
Grammatikidis<eekee57@fastmail.fm> wrote:
> 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
>

So it comes down to personal preference.
At the moment I've had no issues("knock on wood"),
with compiling libc while the system is up and running
(xserver,etc..) in a terminal. Seems faster and easier
to scroll up if there's an issue.
I just have to remember that /etc/localtime
gets rewritten causing the time to change.
(always forget that one).


-- 
Justin P. Mattock


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]