Ah, yes, maybe it didn't work before. Since the old release used devfs, I
would never have noticed if /dev on the filesystem was messed up.
Thanks,
Brent
On Thu, 12 Jul 2001, Steve Lord wrote:
> > > 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
>
>
>
>
|