With some Google help I figured out how to fix the missing /var/lib/dpkg/available problem and got lshw removed. Hopefully there's no remaining hidden damage on my server. I don't think I'll ever be messing with lshw again. It could be that it expects something my old server doesn't have, and locks the machine when attempting to probe said non-existent device. Regardless, a production level (stable) information gathering tool should never hard lock a machine, no matter what, nor cause any kind of damage. I could understand installing a beta device driver doing this, but an information gathering tool causing a lockup?
In summary, based on my experience, I'd recommend everyone stay away from lshw and use dmidecode or other tools instead. lshw isn't worth the risk. -- Stan Stan Hoeppner put forth on 4/4/2010 4:46 PM: > Celejar put forth on 4/4/2010 4:03 PM: > >> Not a clue - I've just been in the habit of using lshw (although I >> don't use it all that often). I'll have to look into dmidecode. > > I thought I'd give lshw a try. Based on my brief experience, I'd recommend > others not do so. > > This is interesting, and really sucks. I installed lshw via aptitude, read > the man page, then executed "lshw" with no arguments. It hard locked my > server, requiring a hard reset via the button, and upon reboot fsck found a > bunch of errors on / (ext2) relating to the files involved in installing > lshw, probably because they hadn't been flushed to disk yet when I ran lshw > and the machine locked up. After successfully rebooting, upon trying to > remove lshw I get the following: > > [04:16:59][r...@greer]~$ aptitude remove lshw > Reading package lists... Done > Building dependency tree... Done > Initializing package states... Done > Writing extended state information... Done > The following packages will be REMOVED: > lshw > 0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded. > Need to get 0B of archives. After unpacking 872kB will be freed. > Writing extended state information... Done > dpkg: failed to open package info file `/var/lib/dpkg/available' for > reading: No such file or directory > E: Sub-process /usr/bin/dpkg returned an error code (2) > A package failed to install. Trying to recover: > dpkg: failed to open package info file `/var/lib/dpkg/available' for > reading: No such file or directory > Reading package lists... Done > Building dependency tree > Reading state information... Done > Reading extended state information > Initializing package states... Done > > I cannot find a log file with the list of inodes/files that fsck deleted. I > watched the system boot, and there were at least 6 files or so that fsck > touched, all related to this package and/or aptitude/dkpg. > > What all is affected by /var/lib/dpkg/available? How do I go about > repairing /var/lib/dpkg/available? How do I make sure I've cleaned > everything up properly that got screwed by this hard lock? I've searched > all the possibly relevant files in /var/log and can't find fsck logging of > the files that were affected by the fsck. My other filesystems are all XFS > and everything looks good there so I'm really only concerned with the > aptitude/dpkg stuff on the EXT2 / filesystem. > > BTW, I'm really surprised a "stable" package I installed would hard lock a > machine in such a manner. That's very disappointing. Maybe I'm just a nub > for not thoroughly reading the man pages, but even so, no stable program > should cause a hard lock. If hard locking is a possibility, the package > shouldn't be in the repos. > > Anyway, any help getting this mess cleaned up would be greatly appreciated. > I don't even know what all is broken at this point, but I'm pretty sure > it's only the stuff related to this package and related package management > files. > > Thanks. > -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bb91059.7060...@hardwarefreak.com
