[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 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: