> > Under release 1.0.1, I noticed a problem with xfsdump/xfsrestore that
> > wasn't there in 1.0 (although it did fix an OOPS, and the earlier SUID
> > problem). Doing an xfsdump of / piped to a restore on another partition,
> > I noticed that the /dev directory didn't transfer correctly. The major
> > numbers on all the devices were set to 0.
> >
> > It seems that I must have read about this problem being fixed before, so
> > I'm guessing the CVS version of xfsdump doesn't have this problem?
>
> Yes, there is a problem here, I just replicated it locally on the current
> cvs kernel and xfsdump/restore packages. A mknod on its own creates the
> correct information, so this is either dump not getting the correct info
> out of the kernel, or an issue between dump and restore themselves.
Hmm, I am pretty sure this would never have worked, the code to mknod the
device in the restore program has always taken the unconverted device
number from the archive and passed it to the kernel. Since this is a
32 bit value in Irix format the major number gets dropped by the kernel.
I have a working version here now and just need to work out how to
package it - since the xfsprog rpm where the source code should really
reside for this just went through a major version change. I can
certainly fix the cvs version though.
Steve
|