NOW: Stay away from lshw! WAS: Retrieve hardware and modules info..
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][root@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.
>
Reply to: