ufsdump error 1

[tcsadm]

When trying to use "ufsdump 0f /dev/rmt/0cn /" I get the following error..
DUMP: Mapping (Pass II) [directories]
DUMP: Writing 32 Kilobyte records
DUMP: Estimated 507564 blocks (247.83MB).
DUMP: Unexpected condition detected: /dev/rmt/0cn must have exactly one link
DUMP: NEEDS ATTENTION: Cannot open `eagle:/dev/rmt/0cn'. Do you want to retry the open?: ("yes" or "no")
DUMP: The ENTIRE dump is aborted.

Tar command works to /dev/rmt/0cn
ufsdump to /dev/rmt/0c works as well

Sun External SCSI tape (Exabyte 8900 Mamoth) on Ultra 60 running Solaris 9

 

[bfitzmai]

Tcsadm. I found your exact problems on several sites. I take it you have posted this problem else where. What I don't get is the message "must have exactly one link". The device files in /dev/rmt are soft links to devices in /devices. Can you do a ls -aFl /dev/rmt/0cn to see if you have multiple soft links for the device.

 

[tcsadm]

lrwxrwxrwx 2 root root 44 Aug 18 2006 /dev/rmt/0cn -> ../../devices/pci@1f,2000/scsi@1,1/st@4,0:cn

 

[bfitzmai]

Look at man devfsadm for more information. You can try running command devfsadm -Csv. This command will perform a clean up of /dev and /devices all, changes will be suppressed and print the results (verbose mode). If you have any device issues, you should see it in the printout.

 

[tcsadm]

devfsadm -Csv completed - no output returned.

 

[tcsadm]

Solved! (oddly)
# ls -la /dev/tape
lrwxrwxrwx 2 root root 44 Aug 18 2006 /dev/tape -> ../../devices/pci@1f,2000/scsi@1,1/st@4,0:cn

# rm /dev/tape
# !8
ufsdump 0f /dev/tape /var
DUMP: Date of this level 0 dump: Tue Sep 18 15:31:54 2007
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rdsk/c0t0d0s4 (/var) to /dev/tape.
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Writing 32 Kilobyte records
DUMP: Estimated 1822292 blocks (889.79MB).
DUMP: Dumping (Pass III) [directories]
DUMP: Dumping (Pass IV) [regular files]
DUMP: 1821758 blocks (889.53MB) on 1 volume at 6847 KB/sec
DUMP: DUMP IS DONE

# mt -f /dev/tape rewind
/dev/tape rewind 1 failed: Inappropriate ioctl for device

# ls -la /dev/tape
-rw------- 1 root other 932741120 Sep 18 15:34 /dev/tape

# mt -f /dev/rmt/0cn rewind

What's perhaps odd about this is that ufsdump to /dev/rmt/0cn and to /dev/tape both failed prior to removing the link to /dev/tape. ufsdump 0f /dev/rmt/0cn works find now.

 

[spamly]

By removing the /dev/tape link, you created a dumpfile called "tape" in the /dev directory. That is why it is so big. You didn't actually dump to the tape device. I'd go ahead and remove /dev/tape as it is just taking up space.

I'm glad that /dev/rmt/0cn is working though.