Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

Then I did the following steps to bring my machine back to live, hope this helps someone else

1. reboot, edit the line starting with linux(or kernel) in grub, add:

init=/usr/lib/ld-2.16.so /bin/sh

2. remount the disk rw:

/usr/lib/ld-2.16.so /bin/mount -o remount,rw /

3. remove the EMPTY(yes, the error above will leave it empty) /lib folder:

/usr/lib/ld-2.16.so /bin/rmdir /lib

4. ln /usr/lib to /lib:

/usr/lib/ld-2.16.so /bin/ln -s usr/lib /lib

5. press ctrl-alt-del to reboot the machine, and re-install glibc using pacman.

Then everything is back to normal, without using a rescue cd

I am stuck after an accidental --force update with a kernel panic, so I tried the above, and after step 1 and booting in, I get a shell but I cannot type. Every keystroke entered flashes numlock. This is the same thing when I try the other solution here: https://bbs.archlinux.org/viewtopic.php … 1#p1127251

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

Maybe the pacman binary should be linked statically to glibc or there should be a /usr/bin/pacman.static, so one can correct theproblem also in a running system. The same applies for all the other shared libraries.. Just a thought.

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

The trick of 'colbert' works, but I'm not sure if the linking of /lib to /usr/lib is a good idea. The 'pacman -S glibc' stores theC library into /usr/lib (which work as long as the symlink /lib is kept). Issues may arise later if the /lib symlink is kept permanently.

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

Roken wrote:

c0dege3k wrote:

Roken wrote:

Boot a live distribution, chroot into Arch and set about fixing things. (Go back and read through this thread for what you will need to do).

I've booted into a Ubuntu Live CD, and am trying the chroot. I've followed every command here and I get this error message when running "chroot . /bin/bash": chroot: failed to run command `bash': No such file or directory.

This is exactly what was happening to me when I was actually in my Arch system and, based on answers in this thread, I feel like it's something screwed up with the symbolic links. Am I right?

I read the news post, everything was already up-to-date other than glibc, and it was giving me errors. I read through this thread and wiki page referenced in the news post. The only package that owned anything in /lib was glibc, though some packages were owned by nobody, and some it could not determine the owner.

I read the news post, everything was already up-to-date other than glibc, and it was giving me errors. I read through this thread and wiki page referenced in the news post. The only package that owned anything in /lib was glibc, though some packages were owned by nobody, and some it could not determine the owner.

If it's any consolation, this newb did the same thing, and is in the same situation as yourself... Will manually deleting all of those files from /usr/lib/ fix it--or just make things worse?

[edit] Forgot to mention this is a 64bit system... wondering if that will complicate things?

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

wilberfan wrote:

padster wrote:

falconindy wrote:

Sure. You deserve that. Go back and read the news post again.

I read the news post, everything was already up-to-date other than glibc, and it was giving me errors. I read through this thread and wiki page referenced in the news post. The only package that owned anything in /lib was glibc, though some packages were owned by nobody, and some it could not determine the owner.

If it's any consolation, this newb did the same thing, and is in the same situation as yourself... Will manually deleting all of those files from /usr/lib/ fix it--or just make things worse?

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

marco_silva85 wrote:

wilberfan wrote:

padster wrote:

I read the news post, everything was already up-to-date other than glibc, and it was giving me errors. I read through this thread and wiki page referenced in the news post. The only package that owned anything in /lib was glibc, though some packages were owned by nobody, and some it could not determine the owner.

If it's any consolation, this newb did the same thing, and is in the same situation as yourself... Will manually deleting all of those files from /usr/lib/ fix it--or just make things worse?

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

For all those who did --force... Yeah - I did, a dumb, I know... But, I have an emergency ARCH partition to boot in case of such an issue. Ubuntu live disk will work here as well ( I know... ).

Steps done to resolve:

0) cd to the original ARCH / volume.1) mv lib lib<whatever>2) ln -s lib and lib64 to usr/lib3) reboot to the original ARCH. It won't run any GUI or network blaming on... whatever, but will allow an access to the pacman and we have all packages already in cache.4) pacman -Su. Reboot.5) "Dynts aka Boom!" - I'm in... GUI = OK. Network = OK. The rest seems OK as well. dmesg reporst no issues.

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

I have the same problem as girzel. Don't tell me to read the news post, I did that. After also borking my system for a while, I managed to get it back. Now I upgraded everything except for glibc and it persists to refuse. Here is my output:

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael FaradayYou assume people are rational and influenced by evidence. You must not work with the public much. -- Trilby----How to Ask Questions the Smart Way