Description of problem: The xfs filesystem module in kernel-desktop 3.8.0rc3 depends on libcrc32c but it (also?) needs the crc32c module to be loaded, at least on my AMD x86-64 system. Otherwise it will complain about unresolved symbols. The installer has this module available but does not load it when loading xfs.ko, so it can't mount XFS filesystems. Initrds do not get the crc32c module - I guess some dependency is missing - so booting with this kernel fails to mount an XFS root fs. How reproducible: Try to install a system with a XFS root fs. and/or Update an existing system that uses XFS to kernel 3.8.0rc3.1 . Workaround: In the installer, manually load crc32c. After installing e.g. kernel-desktop-3.8.0-0.rc3.1.mga3, regenerate the initrd with mkinitrd --with=crc32c --preload crc32c ... There is also a crc32c_intel module that I can't load on this AMD system.
I guess you are using cauldron ? :)
Version: 2 => CauldronAssignee: bugsquad => tmb
Yes cauldron only, thanks. The problem is not really in xfs.ko but in libcrc32c and is apparently an old issue that won't be solved in the kernel. The new thing is that XFS now uses (lib)crc32c. The problem was reported for btrfs in bug #3214 and can be resolved in dracut. I'm not sure if an additional fix is needed for the installer.
Assignee: tmb => mageiaSource RPM: kernel-3.8.0-0.rc3.1.mga3.src.rpm => dracut-023-12.mga3.src.rpm
Yeah I remember fixing this for btrfs, same can be done with xen I reckon... tho' btrfs is kinda specially handled in dracut, so it might need a more generic fix (i.e. just changing our default config to always include that modules...?)
I think I've included an appropriate fix in dracut for this now. Can you please check as I've not got an easy way to test.
- dracut-023-14.mga3 installed - old initrd saved - mkinitrd /boot/initrd-3.8.0-desktop-0.rc3.1.mga3.img 3.8.0-desktop-0.rc3.1.mga3 - lilo (with this kernel as default) The system still boots with the right kernel so I think the boot problem is fixed. I have not tried a new install.
I believe something like the following patch is needed to get XFS mounts working with the installer + kernel 3.8.0 . Patch not tested. Index: perl-install/modules.pm =================================================================== --- perl-install/modules.pm (revision 7107) +++ perl-install/modules.pm (working copy) @@ -111,7 +111,7 @@ my @l = map { if_(member($_, 'plip', @parallel_zip_modules), 'parport_pc'), if_($_ eq 'vfat', 'nls_cp437', 'nls_iso8859_1'), - if_($_ eq 'btrfs', 'crc32c', 'crc32c-intel'), + if_($_ eq 'btrfs' || $_ eq 'xfs', 'crc32c', 'crc32c-intel'), dependencies_closure(cond_mapping_24_26($_)); } @$l;
Component: RPM Packages => InstallerAssignee: mageia => thierry.vignaud
CC: (none) => tmb
Fixed in SVN. Colin, Thomas, shouldn't the kernel or udev autoloads the module when needed?
Status: NEW => RESOLVEDCC: (none) => mageiaResolution: (none) => FIXED
I forgot we run insmod instead of modprobe in installer
Since we now include modprobe in drakx for udev, we could as well run modprobe instead of insmod...
Yep, I think that would be a good idea, and would help avoiding cases like this
Done in SVN.
OK, there is actually a bug in my dracut module hack in some setups, but I'll fix that one shortly.