Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

yesterday night my laptop executes a hard shutdown because my battery was out of charge. After the reboot Xorg hangs and the troubleshooting was pretty hard. A first file system check of my ext4 partition yields no error. Further I began to check the related logs and found nothing irregular. Since i use xdm i eventually looked in /var/log/xdm.log where i found the following line, that i had overlooked several times before

/usr/bin/X: symbol lookup error: /usr/lib/libpciaccess.so.0: undefined symbol: gzopen64

Then i invoked

apt-get install --reinstall libpciaccess

and after a reboot everything was fine again.

I know that a hard shutdown can corrupt data because the disc cache can't be physically written anylonger. Since i have no deeper understanding of the file systems interna i wonder why /usr/lib/libpciaccess.so.0 was harmed by the shutdown? Particularly given that the system only reads from a shared library so probably corruption is less likely to occur in those sectors where those are located.

Furthermore i would like to know which filesystems are more resistant to hard shutdowns and which are less.

Thanks for your time and best regards

share|improve this question
add comment

1 Answer

up vote 2 down vote accepted

It is not that much a question of the "right" filesystem, but how you use it and how you mount it.

In case of ext3 and ext4 you can use the ro, sync, dirsync options.

Filesystems with intent-write-log are normally better, if the metadata is being synced before the actual write.

In your case it might have been that the library-cache (/etc/ld.so.cache) was corrupted - a simple ldconfig might have fixed the problem.

Sometimes you need to force a full filesystem-check to find and correct errors. Sometimes you need a rescue boot via Netboot or CD/DVD (image) to do so.

fsck -f -y ... - write the output to a log-file for later review.

After that go through every file/directory that has been reported as buggy and look of the package is still ok (on rpm-based-systems: rpm -V) - Debian should have a comparable mechanism to determine which package a file belongs to and to verify the integrity of the package.

share|improve this answer
Thank you for your detailed answer. I already looked up the keywords you've mentioned and you bring me on the right track. By the way: i did a ldconfig without success. –  user1146332 Sep 9 '12 at 11:51
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.