Tru64 to Knoppix USB vdump/vrestore

[BFCsaus]

Hi,

I am trying to perform a standard vdump/vrestore from a Tru64 V4.0F server to a USB drive mounted on a KNOPPIX V2.6.19 dist.

Ive shared the USB drive out from KNOPPIX and mounted on Tru64, I can write to the USB drive but am seeing the following errors when doing the vdump/vrestore... everything else works perfectly...

Share from KNOPPIX is:-

:/media/sda1/KX *(rw,async,no_root_squash)

# vdump -0f - / | vrestore -xf - -D /KX_nfs

vrestore: error creating symbolic link ./tftpboot @-> /usr/tftpboot [45} operation not supported

The message appears for every link in / and /usr so obviously no links are written to the USB.

Ive added the KNOPPIX user and group to Tru64 and also adding KNOPPIX to root etc etc to no avail.

vdump/vrestore to a directory on the local Tru64 works ok so presume its something from the KNOPPIX share...

Hopefully someone out there may have had a similiar issue as google shows no results..



Thanks in advance...

[Steven Schweda]

> I am trying to perform a standard
> vdump/vrestore [...]

Why? "vrestore" to an NFS-remote file
system? "man vrestore": "The vrestore and
rvrestore commands are the restore facility
for the AdvFS file system." Note: AdvFS,
_not_ who-knows-what-behind-NFS.

I can't see which file system is used on this
USB storage gizmo, so I can't tell what it
should or should not be capable of doing
(even before NFS gets in the way).

> [...] no links are written to the USB.

Can you create a link there using "ln", or is
vreatore the only one having trouble?

If you just wish to copy the files, have you
considered a "tar" pipeline instead of
vdump+vrestore?


> everything else works perfectly...

You've tried _everything_?


> [...] someone out there may have had a
> similiar issue [...]

Issue? Is that anything like a _problem_?

[Rob Leadbeater]

Hi,

I'll guess this might be something to do with NFS versions...

"However, do you need to be able to read the backed up file system from the USB drive ?"

Why not use something like:

# vdump -0 -f /KX_nfs/root.vdump /

Cheers,

Rob

[BFCsaus]

Hi,

Steve/Rob, thanks for the replies...

Its a long story why we have to go to such lengths to take a backup but Steve was correct in that we are unable to link a file on the USB and also unable to mkfs a UFS file system on the USB which would have resolved our issues (unless someone knows a way).

Anyway, I now intend to 'clone' the filesystems, tar then copy to the USB so I have the links, long winded but should work.

Finally, according to WikiAnswers, the difference between an issue and a problem is a problem can be solved while an issue will continue to become an issue when answered..




Thanks again...




Steve...

[Steven Schweda]

> [...] unable to mkfs a UFS file system on
> the USB [...]

A problem description like "unable to"
explains neither what you did nor what
happened when you did it, making it generally
useless.

I'd expect that this would depend on how the
USB gizmo was formatted. On a VMS system,
it's easy enough to do a native ODS2 or ODS5
INITIALIZE, or, using a tool like mtools, a
FAT format. What to do rather depends on
what you want done. If your "USB drive" is
a flash EEPROM gizmo, and your plan was to
carry it to a Windows system, then a FAT
format could be reasonable. If it's staying
on a UNIX-like system, then I'd expect that
a mkfs-like command could give you a non-FAT
UFS (or ext3, or whatever these things use
nowadays). It's been a long time, but I
believe that I've made UFS file systems on
floppies and USB flash gizmos on a Solaris
system. Hard to believe it's not possible on
a Linux system.

USB gizmos tend to act like disk drives.
What you put on a disk drive is largely up to
you. Same with a USB gizmo.


> Finally, according to WikiAnswers, [...]

Not the universal authority. Magazines have
issues. You have problems.

[Steven Schweda]

And, of course, if the problem is actually a
Linux problem, then this may not be the best
forum for it.