Device File name appears as (null) to HWMGR

[R Swenson]

# /sbin/disklabel -rw dsk5
disklabel: dsk5: No such file or directory

This is the response I get when trying to use disklabel in /devices/disk. I get the same results in /devices/ndisk. Both directories contain the files dsk0a-h through dsk4a-h.

Additional information: When I use HWMGR, the disk shows up, but the DEVICE FILE name is this: (null) My other disks show up as dsk0 - dsk4.

Thanks in advance.

[Michael Schulte zur Sur]

Hi,

when you delete the device with hwmgr and do a scan, does that change anything?
A NULL means that there is no device behind that file anymore.

greetings,

Michael

[R Swenson]

What device specification do I use to delete? The HWID? "(null)"?

[Ivan Ferreira]

when you run hwmgr v d you get the HWID, using that information run:

hwmgr delete -id

[R Swenson]

# /sbin/hwmgr delete -id 59
hwmgr: Error unable to find subsystem name in command line.

No luck.

[Mulgund]

#/sbin/hwmgr -delete scsi -id

Else try,
#/sbin/hwmgr -show scsi
Chk. the did (2nd column) corresponding to dsk5

then,
#/sbin/hwmgr -delete scsi -did

Hope this helps,
-Srinivas

[Kapil Jha]

Hi
I had same problem tried everything but of no use then I removed the disk from array put put it again and problem solved.
Hope this wul solve ur problem
Thanks

[Hein van den Heuvel]

I happened to have dealt with a much similar sounding problem yesterday.
It was a little more complicated, as it was a cluster and the disk _seemed_ to work as an other cluster member was performing a distributed raw device service for it.

We had a 'null' and yet there were 2 path indicated and a BLT entries visible.
'hwmgr -show comp inconsisten' did also highlight that device ID.

We cleaned up using:
hwmgr -delete -d xxx
hwmgr -scan scsi

The device now re-appeared, with a fresh ID and a fresh dskXX name.
You can rename that with cfsmgr, but why bother for a new device, and for us we only flipped the softlink in /etc/fdmns/yyy_domain to point to the new disk file.

note 1...
We further cleaned up with: hwmgr -refresh component.

Note 2...
Consider hwmgr -scan component

Hth,
Hein.

[Pieter 't Hart]

apearently dsk5 was once present in the system but isn't at this time.
Remember Tru64 now disks have "unique" id's
they are not mapped to a SCSI-slot anymore.
once unix has detected the disks you can move them around in the slots and theyremain operational (as long as you reboot the system first or send rescan de scsibus).

at boottime the system runs "dsfmgr -K" to create the special-files in /dev/disks.
so when at boottime the disk5 is not present there will not be any dsk5a-h special file.

so after "hwmgr -scan scsi" and "hwmgr -show scsi" the file name still is NULL then the disk is not in the system or the disk is
not functioning.
and dsfmgr -K or dsfmgr -F will not create any special files in /dev/disk.


Pieter

[R Swenson]

I solved my own problem, but thanks for the feedback.

My console log had this message on it: "hwc_user_cmd:framework error 60" "hwc_run_dsfmgr_cmd: cmd failure (frame=60), (subsys=0)"

As recommended by the system itself, I entered the following command: "/sbin/dn_setup -boot" to synchronize dsfmgr with kernel

Resulting messages were: "dsfmgr: NOTE: updating kernel basenames and old devnames for system at /" "dsfmgr:NOTE: creating device special files for system at /" "+dsk5a +dsk5a +dsk5b +dsk5b ... +dsk5h +dsk5h"

After this I did an hwmgr -scan scsi and an hwmgr -show scsi The device that had showed up as "(null)" previously now shows up as dsk5. On to the next staep, thanks to everyone for their suggestions.