Skip to main content

How to hose a Fedora 17 system

The tg3 driver in this Ideapad S10 is acting weird and I wanted to install a new kernel that was built elsewhere:

$ cd /
$ xz -dc /var/tmp/linux-3.4.0.tar.xz | tar -xvf -
Nothing new here, this is what I usually do. So far, so good. But then all hell broke loose:
# ls -l
-bash: /bin/ls: /lib/ bad ELF interpreter: No such file or directory
Huh? Our current shell is still working, let's look around:
# echo /*
/bin /boot /dev /etc /home /lib /lost+found /media /mnt /opt /proc /root /run /sbin /srv /sys /tmp /usr /var

# echo /lib/*   
/lib/firmware /lib/modules

# echo /lib64/* 
What happened? Well, with Fedora 17, the UsrMove feature got implemented. This means /lib is just a symlink to /usr/lib. Not sure what this has to do with a /usr move, but that's what they did.

Apparently, when extracting the tarball, /lib (which is now symlinked to /usr/lib) got replaced by a directory and filled with the contents of the tarball. Of course, the tarball contains only the kernel and some kernel modules - that's why all the libraries could not be found anymore. The real libraries are located in /usr/lib - but all the userspace apps are still linked to /lib :-\

However, I wasn't able to reproduce this on this Debian/Squeeze system:
$ mkdir lib && touch lib/{foo,bar}
$ tar -cvf baz.tar ./lib
$ rm -rf lib

$ mkdir -p usr/lib && ln -s usr/lib 
$ ls -lgo
total 28
-rw------- 1 10240 May 31 03:14 baz.tar
lrwxrwxrwx 1     7 May 31 03:15 lib -> usr/lib
drwx--x--x 3  4096 May 31 03:15 usr
$ ls -l lib/
total 0

$ tar -xvf baz.tar 

$ ls -lgo . lib/
total 8
-rw------- 1  196 May 31 03:24 baz.tar.xz
lrwxrwxrwx 1    7 May 31 03:25 lib -> usr/lib
drwx--x--x 3 4096 May 31 03:25 usr

total 0
-rw------- 1 0 May 31 03:24 bar
-rw------- 1 0 May 31 03:24 foo
This time /lib was not replaced by a directory, but merely filled with the contents of the tarball. So, what went wrong on this Fedora system? Let's try again after the system has been recovered, shall we? ;-)