You are not logged in.
'GLIBC_2.17' not found (required by udevd)
Can anyone help with this please? I'm at my wit's end.
I did pacman -Syu , carefully following the advice at https://wiki.archlinux.org/index.php/De … iki:usrlib.
/lib turned into a symlink to usr/lib as promised - but my system has not booted since, throwing:
udevd: /usr/lib/libc.so.6: version 'GLIBC_2.17' not found (required by udevd) ... and ending up at the recovery shell option.
I burned archlinux-2013.01.04-dual.iso to a CD to try and rescue the situation, and that boots OK. But I can't fix my 'upgraded' system - always coming back to the same problem on reboot.
Can anyone tell me what I did wrong, and how to resurrect my system? - else I might have to go back to Debian!
Thanks.
Offline
What have you attempted from the live CD?
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
I mounted my dead system partitions and did arch-chroot /mnt then I repeated pacman -Syu and pacman -S glibc. Apparently no problems but the system will not boot, as reported.
Offline
From the chroot, check that the file exists, and check `pacman -Qi glibc` for the version.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
/lib/libc-2.17.so exists, and /lib/libc.so.6 as a symlink to it:
lrwxrwxrwx 1 root root 12 Dec 26 10:23 /lib/libc.so.6 -> libc-2.17.so
pacman -Qi glibc reports:
Name : glibc
Version : 2.17-1
URL : http://www.gnu.org/software/libc
Licenses : GPL LGPL
Groups : base
Provides : None
Depends On : linux-api-headers>=3.7 tzdata
Optional Deps : None
Required By : a52dec alsa-lib attr babl bash binutils bzip2 cdparanoia cfitsio chmlib convertlit coreutils cracklib device-mapper dhcpcd diffutils dosfstools dotconf eventlog expat faac faad2 fakeroot fftw file findutils fribidi fuse gawk gcc-libs gdbm grep gsl gsm gutenprint gzip hspell hyphen initscripts iproute2 iptables json-c kbd keyutils kmod libasyncns libburn libcap libcap-ng libcdaudio libcddb libdatrie libdiscid libdmtx libdrm libexif libffi libglapi libgpg-error libgssglue libical libice libidn libiodbc libirman libjpeg-turbo libksba libmad libmcrypt libmowgli libnl libnova libogg libpcap libpciaccess libpipeline libraw1394 libsigsegv libtasn1 libusbx libutempter libvpx libwbclient libx86emu libxau libxdmcp libytnef lpsolve lsof m4 make mcpp mdadm mkinitcpio-busybox mtdev ncurses net-tools nspr openal opencore-amr orc p11-kit pacman pam patch pciutils perl pixman popt ppp procmail pth r8168-lts readline recode run-parts sdl sg3_utils sip sudo sysfsutils sysvinit-tools talloc tar tidyhtml util-linux v4l-utils vte-common wavpack which x264 xf86-input-evdev xf86-video-fbdev xf86-video-vesa xorg-sessreg xvidcore zlib
Conflicts With : None
Replaces : None
Installed Size : 38832.00 KiB
Packager : Allan McRae <allan@archlinux.org>
Architecture : x86_64
Build Date : Wed Dec 26 10:23:56 2012
Install Date : Mon Jan 21 11:31:54 2013
Install Reason : Explicitly installed
Install Script : Yes
Description : GNU C Library
Last edited by JohnColeman (2013-01-21 14:19:38)
Offline
/lib/libc-2.17.so exists, and /lib/libc.so.6 as a symlink to it:
lrwxrwxrwx 1 root root 12 Dec 26 10:23 /lib/libc.so.6 -> libc-2.17.so
There's the problem. Something went wrong in your glibc update - those should be in /usr/lib.
EDIT: perhaps this is not a problem if you only checked /lib/libc.so.6 as that would show up as yours did. But you need to check for the file that is reported as missing: /usr/lib/libc.so.6
While you're at it, the results of `ls -l /` would also be worth a check.
Lastly, you don't have /usr/ on a separate partition do you?
Last edited by Trilby (2013-01-21 14:32:29)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Remember /lib turned into a symlink to usr/lib as promised ?
The libc files in my filesystem look just like those on archlinux-2013.01.04-dual.iso - which boots OK.
No, /usr is not on a separate partition. I have boot, swap, root, home.
Offline
Remember /lib turned into a symlink to usr/lib as promised
I remember you saying that - but I have no other evidence of that. It's very easy to check for the file that is reported missing - why not actually check for it?
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
ls -l /usr/lib/libc.so.6
lrwxrwxrwx 1 root root 12 Dec 26 10:23 /usr/lib/libc.so.6 -> libc-2.17.so
re While you're at it, the results of `ls -l /` would also be worth a check. :
drwxr-xr-x 2 root root 4096 Jan 20 20:19 bin
drwxr-xr-x 7 root root 1024 Jan 18 20:11 boot
-rw-r--r-- 1 root root 318 Jul 2 2012 chroot.sh
drwxr-xr-x 18 root root 3340 Jan 21 14:58 dev
drwxr-xr-x 89 root root 4096 Jan 21 11:31 etc
drwxr-xr-x 2 root root 4096 Jul 1 2012 home
lrwxrwxrwx 1 root root 7 Dec 26 10:23 lib -> usr/lib
lrwxrwxrwx 1 root root 7 Dec 26 10:23 lib64 -> usr/lib
drwx------ 2 root root 16384 Jul 1 2012 lost+found
-rw-r--r-- 1 root root 70 Jan 21 13:57 lslibc.txt
-rw-r--r-- 1 root root 0 Jan 21 15:01 lsroot.txt
drwxr-xr-x 12 root root 4096 Dec 16 17:44 media
drwxr-xr-x 4 root root 4096 Dec 17 16:57 mnt
drwxr-xr-x 4 root root 4096 Oct 24 16:17 opt
-rw-r--r-- 1 root root 1843 Jan 21 14:01 pqglibc.txt
dr-xr-xr-x 76 root root 0 Jan 21 14:57 proc
drwxr-xr-x 3 root root 4096 Sep 3 09:44 rails
-rw-r--r-- 1 root root 50780 Sep 13 19:03 regexer-1.0-1-x86_64.pkg.tar.xz
drwxr-x--- 32 root root 4096 Jan 3 21:49 root
drwxr-xr-x 2 root root 40 Jan 21 14:59 run
drwxr-xr-x 2 root root 4096 Jan 21 11:31 sbin
drwxr-xr-x 5 root root 4096 Jan 18 20:08 srv
dr-xr-xr-x 13 root root 0 Jan 21 14:57 sys
drwxrwxrwt 2 root root 40 Jan 21 14:59 tmp
drwxr-xr-x 12 root root 4096 Jan 18 20:08 usr
drwxr-xr-x 14 root root 4096 Jan 18 20:12 var
Offline
Do you know what /lib64 is? It's a bit outside my experience, but I run one i686 install and one x64. Both only have /lib and /usr/lib. As I understand it, if I enabled multilib on my x64 I might get a lib32, but I don't know what lib64 would be.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Do you know what /lib64 is?
Not really, the processor is AMD64 and multilib is enabled in pacman.conf.
Offline
Other than that, everything does look in order - I can't see where that error would come from. Sorry if my "show me the evidence" attitude seemed cynical, but in troubleshooting we all think we have done everything right, but most problems come from when we are mistaken about that.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Other than that, everything does look in order - I can't see where that error would come from.
Thanks anyway Trilby, for giving your time and effort to help me. You're quite right about most problems being simple mistakes we have overlooked, that's why I appealed to this forum for some objective advice from others. Unfortunately this wee problem is something of a show stopper just now. In Scotland they might say that Arch Linux is from Disneyland..., because it ...disnae work.
Offline
This sounds like the problem may be in the initramfs.
I hope you did run mkinitcpio -p linux from the chroot after updating ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
The /lib64 symlink is normal as far as I can tell. It's created by the glibc 2.17-1 package but looks like it'll be created by the filesystem package shortly.
Offline
Hi guys, thanks.
Yes I remembered to do mkinitcpio -p linux - several times now! At present all I can think to do is format the root partition with mkfs.ext4 /dev/sdc3 and start again, but that will involve a lot of work before I am back to where I was - assuming it works of course. Comments please.
Offline
Had the same issue and worked around it (for now, at least) by reverting to the prior versions of systemd and libdrm, and reinstalling nss-myhostname. The versions that worked for me were: libdrm-2.4.40-1-i686.pkg systemd-196-2-i686.pkg nss-myhostname-0.3-3-i686
Offline
Thanks coop, it's very interesting that you have seen this too. My drastic Plan B is working out OK though, thanks mainly to having a separate home partition, which survived. So, I re-formatted the root partition and followed the Beginners' Guide from there. I've already reinstalled most of my favourite applications, as confirmed by the reappearance their icons on Xfce's launcher panel.
So I'm almost back in business, but my confidence in Arch Linux is badly shaken. Just as well that /dev/sdb is partioned for booting Debian (and /dev/sda can still do Windows).
Offline
So I'm almost back in business, but my confidence in Arch Linux is badly shaken.
Arch is NOT set up for people that only update once every 6 months or longer. The update that got you into trouble should have been taken care of last July.
Offline