>Could you try this patch on Tru64.
This is probably a silly question, but did you try the patch on Linux?
I was playing with this too and my version (functionally the same as
yours, I think) put Linux back to trying to use /dev/root.
Here's what I think is happening. Amanda is trying to convert the
disklist entry (e.g. "/") to both a device name and a file system type.
It wants the device name to pass to dump, even though that's silly
because every version of dump I've been around already knows how to do
that (and probably better than Amanda). It wants the file system type
to know what dump program to run (e.g. advfs -> vdump instead of dump).
The 2.4.2p2 changes effectively caused search_fstab to fail if it could
not find a match. That, in turn, caused amname_to_devname to return
the input arg (e.g. "/") as the device name, which dump was perfectly
happy with.
One thing I cannot remember is why we had a problem in the first place
(the "LABEL=/xxx" /etc/fstab entries). I'm guessing what happened was
search_fstab returned a match based on the mount point, but the "device"
was returned as "LABEL=/xxx", which dump would definitely not have liked.
Amname_to_fstype is not so forgiving of search_fstab failing and returns
an empty string. So when we changed search_fstab to fail if the device
did not exist, we lost the ability to detect device type.
Note that in the advfs branch of sendbackup-dump, it passes the mount
point, not the device name, to dump. That's why this used to work.
So how about:
* We go back to the original search_fstab code. On Linux and advfs
systems, it will find a match on the mount point but return a
bogus device name.
* We change amname_to_devname to stat the device name and if it does
not exist, return whatever amname_to_dirname() returns. This should
solve the original Linux problem and put advfs back the way it was.
We might also re-consider the use of amname_to_devname in general and
maybe change to using amname_to_dirname like advfs is already doing.
>Jean-Louis
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
