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.



--
To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
Archive: http://lists.debian.org/4BB91059.7060401@xxxxxxxxxxxxxxxxx

Relevant Pages

  • Re: Retrieve hardware and modules info..
    ... I thought I'd give lshw a try. ... Reading package lists... ... Initializing package states... ... Writing extended state information... ...
    (Debian-User)
  • Re: install lshw
    ... Setting up Install Process ... Parsing package install arguments ... -bash: lshw: command not found ... download the src.rpm and rebuild the rpm ...
    (Fedora)
  • Re: Listing hardware
    ... Does lshw exist for FC4? ... really expecting to be told that package abcdexyz.rpm was the equivalent. ... the number of places rpms can be found. ...
    (Fedora)
  • Re: NOW: Stay away from lshw! WAS: Retrieve hardware and modules info..
    ... remaining hidden damage on my server. ... It could be that it expects something my old server ... lshw has been around for many years. ... doesn't hard lock a system. ...
    (Debian-User)