1. libc5->glibc2... now can't unmount /usr
When I upgraded my system from libc5 to glibc, I had this problem whenever
/etc/rc.d/rc.6 tried to umount /usr: /usr wouldn't get unmounted, because
it was busy. The reason is this. In the glibc upgrade guide, it said to
* create a directory for the libc-5 libraries
The problem is that since I just recently upgraded from libc5 -> glibc2,
the umount command, and some other commands in the shutdown script are
still linked to libc5. But, the old shared libs, now in
/usr/i586-linuxlibc5/lib, are on the /usr partition. That's why I
couldn't unmount /usr.
The obvious solution would be to replace all the important system admin.
commands with glibc2 versions, but I don't know if that's an effecient
solution. My solution was to just create a symlink like this:
# ls -l /usr/i586-linuxlibc5/lib
lrwxrwxrwx 1 root root 5 May 4 13:03 /usr/i586-linuxlibc5/lib
So, I'm just leaving the old libs in /lib, but I'll just fool the linker
by creating the symlink instead of actually putting them there. I don't
think it's hurting anything, plus I moved all the other headers, gcc-lib
stuff etc. to the right places according to the docs.
So does gcc -b i586-linuxlibc5 need to look in /usr/i586-linuxlibc5/lib
for compiling, or is this just to keep the libs separate? If I put the
libs on the /usr partition by creating an actual directory (not symlink),
then the shutdown script, which is linked to shared libs on /usr, can't
All this trouble is because my major commands are still linked with libc5.
Anyone want to comment on how they handled this?
2. About 'jiffies'
3. Unmounting /usr
4. .i2c-old.ver.d: No such file or directory
5. How can I unmount /usr to run fsck on it?
6. Linux versions compatibility
7. unmounting /usr
8. RPM to cpio
9. cannot unmount /usr to run fsck
10. Problem unmounting /usr
11. How do I unmount /usr -- solution
12. fsck with /usr unmounted
13. unmounting /usr - how to?