Archive for March, 2012

Dear disk – don’t die


My trusty crusty home desktop (a Dell OptiPlex GX260) is nearly ten years old, and it’s been a bit flaky on recent occasions when booting up Fedora 16. One time this week I let it have about six attempts before I gave up; it would get stuck – after quite a while – and say something like

udevadm settle - timeout of 120 seconds reached, the event queue contains:
/sys/devices/pci0001:00/0001:00:02.0/0001:01:0b.1/usb3/3-2 (623)
/sys/devices/pci0001:00/0001:00:02.0/0001:01:0b.1/usb3/3-2/3-2:1.0 (624)
/sys/devices/pci0001:00/0001:00:02.0/0001:01:0b.1/usb3/3-2/3-2:1.0/0003:05AC:1000.0001 (625)
/sys/devices/pci0001:00/0001:00:02.0/0001:01:0b.1/usb3/3-2/3-2:1.0/0003:05AC:1000.0001/hidraw/hidraw0 (626)

(Unfortunately I don’t have the exact details to hand. I’m writing this from memory, but the OP’s question at udev reaching timeout is pretty much what was happening to me.)

The Disk Utility in the Accessories area

Accessories, Disk Utility

told me in the SMART Data section for the drive that there are bad sectors

SMART Data, bad sectors

For any repair work to be able to happen the drive has to be not mounted, so I booted from an old Fedora 15 Beta LiveCD I had lying around. I ran

$ sudo lvdisplay

to find my root partition (since it’s on a logical volume), and then ran

$ e2fsck -c my_root_partition

After several days of usage following this, booting seems a lot more stable. Hopefully there are another few years left in the old girl.

libc ya later, alligator


Yesterday, like a n00by n00b, I deleted my Fedora’s /lib64/ symbolic link. It was intentional; not an act of deliberate vandalism, but neither in retrospect do I think it would have actually helped me achieve what I was trying to. The details of what I was attempting aren’t important. What shocked me is
how destructive this simple mistake was
: remember – I’ve only deleted the symlink, not the actual target library.

Try it yourself!

$ sudo rm /lib64/
$ ls
ls: error while loading shared libraries: cannot open shared object file: No such file or directory

It’s all gone wrong. You can get some functionality back by setting LD_PRELOAD, e.g.

$ setenv LD_PRELOAD /lib64/
$ ls

Yay. Ish: we really want to restore that little symlink though.

$ su
su: error while loading shared libraries: cannot open shared object file: No such file or directory

I guess that LD_PRELOAD trick isn’t supposed to work here with stuff like su, otherwise we could load in any old junk library to bypass security, etc.

Is there really no way this can be fixed while the system is still live?

The superuser question How to restore /lib/ helped with the above, but I was hoping to avoid having to continue with the advice there which is to restore using a LiveCD. The problem has such a tantalizingly simple cause I was rooting for a simple solution.

In the end I dug out an old installation CD, but not first without seeing if the system would reboot. Ha!

Kernel panic - not syncing: Attempt to kill init!

and so on and so forth. But in the end sorting the problem out with the installation CD was simple. The rescue option mounted my installation under /mnt/sysimage/, so I just

$ cd /mnt/sysimage/lib64
$ ln -s

and with a reboot again, everything is back to normal.

I said ‘Hello World!’


To be precise:

import antigravity
print("Hello World!")