OCS Inventory NG Forums

Hi,

Can you please just check you get this message by doing a "fdisk -s /dev/sdb" ? Do you have the lshal command avalaible?

Cheers

Ok and this command?:
hdparm -I /dev/sdb

and?: fdisk -l

Are you sure those error are created during the agent execution?

Only during install o_O Which version of the agent do you install?

Are you sure you can reproduct the problem?

We've had this same exact issue on all of our CentOS machines. It seems to happen on older systems which do not use the libata driver for the CDROM/DVDROM. On any server with a kernel >=2.6.20 or  with cdroms that show up as "/dev/sd*" or "/dev/sr*" devices, this doesn't seem to happen. We've also suspected OCS of causing some instability on a few of our HP machines which run the hp raid querying utilities, so I would also be interested in the ability to disable certain things in OCS. We've had these boxes reboot seemingly randomly, until we noticed the reboot time possibly correlates with the OCS cronjob which is a bit concerning. We've reduced the frequency that we run the agent due to this.

Also, this happens for us regardless of whether OCS is ran from cron or not, but it definitely corresponds to OCS. It actually scared us a bit at first since we thought it might have been a bad hard drive until realizing it was the cdrom. It would definitely be nice to at least make things a lot quieter.

In regards to the hp issue, the server in question is an hp dl585 with 2 raid controllers, a p400 which handles the 8 internal drives and a p800 which has 4 external arrays with 100 drives total. The p800 does not seem to get inventoried at all. I've noticed OCS taking quite a long time to run on these servers, doing a "ps faux" while running it shows it running tons of hp commands one after another. I'm afraid that there's some kind of bug in the HP utilities and/or the hardware that is causing problems with querying this stuff repetitively. We have 2 such servers, one of which acts as a hot-standby to the other. Currently only the standby server is running OCS as having the main server go down is very, very bad.

Hi all,
the problem is generated when the command
hdparm -I /dev/xxx
is started on a IDE ATAPI device like a CDROM.
The module of OCS interested by the issue is Storages.pm
This issue is well known on hdparm. Look at http://www.mail-archive.com/debian-bugs … 96279.html
I am trying to write a piece of code that understand if the device is an ATAPI one in order to avoid starting hdparm on it.
The funny thing is that hdparm gives you the correct information BUT it gaves also a kernel message because "hdparm doesn't "know" what kind of device it is talking to,
so it first tries "IDENTIFY" (which works only for hard disks) and then if that fails it tries "PACKET_IDENTIFY" (which works only for ATAPI devices)":

Example:

hdparm -I /dev/cdrom

/dev/cdrom:

ATAPI CD-ROM, with removable media
    Model Number:       HL-DT-STDVD-ROM GDR-T10N               
    Serial Number:     
    Firmware Revision:  1.05   
Standards:
    Likely used CD-ROM ATAPI-1
Configuration:
    DRQ response: 50us.
    Packet size: 12 bytes
Capabilities:
    LBA, IORDY(can be disabled)
    DMA: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 *udma2
         Cycle time: min=120ns recommended=120ns
    PIO: pio0 pio1 pio2 pio3 pio4
         Cycle time: no flow control=120ns  IORDY flow control=120ns
HW reset results:
    CBLID- below Vih
    Device num = 0 determined by CSEL

Error:

hda: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hda: drive_cmd: error=0x04 { AbortedCommand }
ide: failed opcode was: 0xec

Thank you Goneri

Hi Goneri,
I have seen the previous problem is the use of an old version of smartctl on those servers. On other servers it runs ok.
But using only smartctl you have a less detailed output on the inventory:

hdparm
sda           PERC_5i      SCSI      disk      71041      60019b90d0c6f7000e0188d471453957      1.03

smartctl
                  DELL          IDE      disk      71041      360019b90d0c6f7000e0188d471453957


Probably you could add only an "if" inside the hdparm code in order to exclude only the hd* devices (usually IDE) and pass them to smartctl.
What do you think?

Hi Goneri,
another thing.

The version 9.22 of hdparm doesn't have the issue described yesterday and manages correctly the error on ATAPI devices.

hdparm -V
hdparm v9.22

hdparm -I /dev/cdrom
/dev/cdrom:
HDIO_DRIVE_CMD(identify) failed: Invalid exchange

No error on dmesg.

Last edited by 4ngel (2009-08-04 12:34:10)