> It runs a command like this:
> /usr/ucb/rsh "alsatian /sbin/vdump 0uf - /" | dd of=/dev/nrmt0h obs=10240
Thanks to a hint from Harald Lundberg, I noticed this rather serious
problem with vdump
:
1] # /sbin/vdump 0uf - / > /tmp/vd1
1] # vrestore tf vd1 > list1
2] # rsh alsatian /sbin/vdump 0uf - / > /tmp/vd2
2] roott_at_alsatian:/tmp % vrestore tf vd2 > list2
2] vrestore: empty save-set
2]DECthreads Last Chance handler: thread 1 exiting on status exception 0x177db005
2] Exception: Invalid memory address (dce / thd)
3] # vdump 0Df /tmp/vd3 /
3] vrestore tf vd3 > list3
4] # rsh alsatian '/sbin/vdump -0 -u -b 60 -f - /' > /tmp/vd4
4] vrestore tf vd3 4 list4
5] # rsh alsatian '/sbin/vdump -0 -u -f - /' > /tmp/vd5
5] roott_at_alsatian:/tmp % vrestore tf vd5 > list5
5] vrestore: empty save-set
5]DECthreads Last Chance handler: thread 1 exiting on status exception 0x177db005
5] Exception: Invalid memory address (dce / thd)
Methods 2 and 5 fail, presumably (as seen with 4) because the
blocksize of 60 is not specified. Now, since the man page EXPLICITLY states
that vdump defaults to a blocksize of 60, I would regard this as a rather
serious bug.
This leaves me with three questions:
1) What is the blocksize set to if not 60?
2) Why must the blocksize be specified when vrestore has no corrosponding
option? It must sense the correct blocksize _somehow_?
3) HOW DO I GET MY DATA BACK!?!?!?!?
--
Eli Burke
eburke_at_vt.edu
http://csugrad.cs.vt.edu/~eburke/
Received on Fri Nov 22 1996 - 16:51:15 NZDT