Thanks for the quick reply. On Thursday 28 February 2008, Nathan Scott wrote: > Been discussing this with the SGI guys. The problem is most likely > to be that current mkfs.xfs enables the "lazy superblock" accounting > feature, which was supported in kernels since 2.6.23. Nice that's a known problem. Did I overlook it in the BTS? > Can we confirm that the installer is using an earlier kernel? Yes, as I said D-I uses 2.6.22 ATM and that's also still the official kernel version in testing. > In the meantime, the following will resolve it: > - move d-i to a newer kernel (dunno if this is an option here?) That will not happen for the Beta1 release that is currently being prepared, but we'll switch to 2.6.24 almost immediately after (and testing will as well). > - run mkfs.xfs with the "-l lazy-count=0" option (probably not a > great option either). This works (tested). I think this is probably our best option. I could even include a test that only includes the option if the kernel version is <= 2.6.22. That way it'll automatically deprecate itself and we can also clean this up fairly easily later. We will also have to do something for the "etch+1/2" installer as that uses the D-I Lenny Beta release and will thus use the new XFS to create filesystems. Is a file system created using mkfs.xfs with "-l lazy-count=0" otherwise completely compatible with XFS as used in Etch? So with that the test would be: if kernel <= 2.6.22 OR target system = etch. Alternatively, is it possible to use a config file for mkfs.xfs to disable this default (comparable to /etc/mke2fs.conf)? > IMO, best bet is to get upstream to undo this change for another 6 > months or so. I'll keep pushing for that. I'd rather not patch in > such a change myself without them doing a release, but if we have > no other option, we can do that. That's only a stay of execution. IMHO reverting the change now that it's happened doesn't make much sense. _If_ you were aware of this in advance, the best option probably would have been to mention the incompatibility in the changelog and prevent migration of the package to testing before there is a suitable kernel there (by filing a dummy RC BR), but that's water under the bridge. Cheers, FJP (Please CC the d-boot list on replies instead of CCing me. TIA.)
Attachment:
signature.asc
Description: This is a digitally signed message part.