2009/11/18 Maxim Wexler <maxim.wex...@gmail.com>: > Hi group, > > I ran emerge -avuDN world and came up with blocked packages which I > eliminated by un-merging device-mapper and e2fsprogs-libs. When I > rebooted was greeted by a maintenance console and the message > "libblkid.so.1 cannot open shared object file". A little googling > later I realized that e2fsprogs-libs should not have been removed. No > problem, I'll chroot and fix it. > > After the chroot I was able to mount /dev/sda1 on /mnt/gentoo but > couldn't mount /dev/sdb2 > on /var where portage is kept on this system. The error was identical > to the original one when the pc was first rebooted: > > "mount: error while loading shared libraries: libblkid.so.1..." > > I tried to run e2fsck on /dev/sda2 but got this error msg: > > "e2fsck: error while loading shared libraries: libcom_err.so.2: cannot > open shared object file..." > > Any one see a way past this impasse? I'm using ext2 with the journal option.
I had to downgrade e2fsprogs last night to test some apparent incompatibility with the new HAL version (which won't compile on older util-linux, and this depends on e2fsprogs). I believe the advice already posted would be a good start and should fix your system. For the future, I suggest a useful thing to avoid annoyance and hassles like this in portage: One thing I suggest here is if you can spare some harddisk space, universally enable the portage feature buildpkg in make.conf. This will keep a .tgz of all binary packages as they were compiled before they were installed by portage. I've had the feature enabled for a few months, in which time a very large portion of my system has been re-compiled. Right now, /usr/portage/packages takes up about 600 MB of my disk space. When I was downgrading e2fsprogs (more difficult and risky than upgrade), I was able to emerge -k on e2fsprogs and libs (I had to disable collision-protect and protect-owned, which is only recommended for special cases when you are aware of what you're doing) and resume the system. For upgrading these kinds of files, what you need to do is a --fetchonly first on any blocked packages. If your problems persist and you just cannot get the system back in shape using a live CD, I suggest emailing the list your architecture and system details (ideally, just attach make.conf), and someone with similar hardware and USE flags might be nice enough to run a buildpkg for you and post the binaries somewhere. I'd post mine right now, but I'd rather wait to hear back your results and hardware specs. ~daid
