Since this release is different than other releases (it requires
different tools), I'd like to ask what the recommended update procedure
is? Imagine we have multiple booting with older kernels as well, and we
want to make both old kernel and this new kernel remain bootable...at
least until it has had time to be tested...what would be the way to go
about this and not end up with an unmanageable machine should the tool
update and new kernel not go in exactly as expected?
D. Stimits, stimits@xxxxxxxxxx
Nathan Scott wrote:
> hi folks,
> The merge to 2.4.18 is complete, the new bits should be arriving
> in CVS shortly. This merge includes the switch to the new extended
> attributes and ACL interfaces in the kernel, and hence userspace
> packages are all updated.
> Before building new tools, you should do a "make realclean" to get
> rid of any existing configure'd state. The new packages contain
> new checks for installed bits, and this forces autoconf/configure
> to be re-run.
> Let us know of any issues. Remember - version 2.0.0+ tools must
> be used with 2.4.18+ kernels, and should not be used with earlier
> kernels. I will do a merge to the current 2.5.x tree shortly, and
> same versioning rules will apply there.
> We expect to remove the ACL utilities from CVS in the future, once
> we are completely in sync with the ext2/ext3 project (very close),
> and will mostly likely just keep mirror copies of Andreas' ACL
> packages in the XFS ftp area on oss.sgi.com.
> In addition to the new EA/ACL interfaces, xfsprogs tools will now
> use the BLKGETSIZE64 ioctl (instead of BLKGETSIZE) to retrieve
> the size of the underlying device (this ioctl was incorrect in
> kernels before 2.4.18). Also, a few XFS ioctls (related to the
> old way of doing EAs, & related to unused "biosize" code in XFS)
> have been deprecated.
> Finally, there's a few remaining work items if anyone is keen to
> help with some of these...
> - glibc should export the new syscalls
> - strace(1) should be updated to recognise the new syscalls
> - syscall numbers for remaining architectures - currently, we have
> assigned numbers on these platforms: i386, ia64, sparc, sparc64,
> powerpc, and x86_64.
> Have fun.