It appears that in the installer Mageia-3-beta3-x86_64-DVD.iso, the xfs kernel module is not loaded. An error is produced when trying to mount a xfs filesystem, created during the installer. switching to the console, doing a modprobe xfs.. works. After that the installer can mount the partition. How reproducible: Every time Steps to Reproduce: 0. boot the installer 1. create a partition that is of type xfs, set a mount point 2. error Reproducible: Steps to Reproduce:
Priority: Normal => release_blocker
CC: (none) => mageia, thierry.vignaudSource RPM: (none) => dracut ?
Can you attach your /root/drakx/report*z
Keywords: (none) => NEEDINFO
Created attachment 3628 [details] display on f3 console As far as I can tell, the requested report files do not exist within the installer, at the point that it produces the error. I press: ctrl - alt - f2, then ls /root I have attached a screenshot of the console log, (xfs module bug 9428.png) that provides a littel more detail
Just plug an USB key then run "bug" on tty2
Created attachment 3639 [details] bug report attached. The bit of interest is: * formatting device sda1 (type xfs) * running: mkfs.xfs -f -q /dev/sda1 * running: -U /dev/sda1 * program not found: -U * running: blkid -o udev -p /dev/sda1 * blkid gave: xfs 865f3252-3df3-40dc-a9a4-5a27c37f029c * mount_part: device=sda1 mntpoint=/ isMounted= real_mntpoint= device_UUID=865f3252-3df3-40dc-a9a4-5a27c37f029c * mounting UUID=865f3252-3df3-40dc-a9a4-5a27c37f029c on /mnt/ as type xfs, options relatime * running: /sbin/modprobe crc32c modprobe: ERROR: could not insert 'crc32c_intel': No such device * running: /sbin/modprobe -n crc32c * running: mount -t xfs UUID=865f3252-3df3-40dc-a9a4-5a27c37f029c /mnt -o relatime mount: unknown filesystem type 'xfs' * step "formatPartitions" took: 0:00:00 * error: mounting partition UUID=865f3252-3df3-40dc-a9a4-5a27c37f029c in directory /mnt failed at /usr/lib/libDrakX/fs/mount.pm line 87.
From what I can tell the -U "command" is actually meant to be xfs_admin -U... Looking at the code, I can't see how the xfs_admin bit wouldn't be there :s Anyway, the fact the UUID changes isn't too crazy. The real problem appears to be a kernel one. xfs seems to require the crc modules these days, but then so does btrfs and it's compiled into the kernel now... not sure how that works... On my installed machine: [root@jimmy ~]# dd if=/dev/zero of=xfs.img bs=1M count=100 >/dev/null 2>&1; mkfs.xfs xfs.img >/dev/null 2>&1; xfs_check xfs.img [root@jimmy ~]# lsmod | grep xfs [root@jimmy ~]# mkdir xfs [root@jimmy ~]# mount -t xfs -o loop xfs.img xfs [root@jimmy ~]# lsmod | grep xfs xfs 869383 1 exportfs 13190 1 xfs [root@jimmy ~]# umount xfs [root@jimmy ~]# rmdir xfs [root@jimmy ~]# rmmod xfs It would be interesting to know if similar things work in the installer - i.e. that the module loads automatically when trying to mount an xfs filesystem or if this is where the problem lies...
(In reply to Colin Guthrie from comment #5) > From what I can tell the -U "command" is actually meant to be xfs_admin -U... > > Looking at the code, I can't see how the xfs_admin bit wouldn't be there :s > > > Anyway, the fact the UUID changes isn't too crazy. The real problem appears > to be a kernel one. > > xfs seems to require the crc modules these days, but then so does btrfs and > it's compiled into the kernel now... not sure how that works... > > On my installed machine: > > [root@jimmy ~]# dd if=/dev/zero of=xfs.img bs=1M count=100 >/dev/null 2>&1; > mkfs.xfs xfs.img >/dev/null 2>&1; xfs_check xfs.img > [root@jimmy ~]# lsmod | grep xfs > [root@jimmy ~]# mkdir xfs > [root@jimmy ~]# mount -t xfs -o loop xfs.img xfs > [root@jimmy ~]# lsmod | grep xfs > xfs 869383 1 > exportfs 13190 1 xfs > [root@jimmy ~]# umount xfs > [root@jimmy ~]# rmdir xfs > [root@jimmy ~]# rmmod xfs > > It would be interesting to know if similar things work in the installer - > i.e. that the module loads automatically when trying to mount an xfs > filesystem or if this is where the problem lies... Well, from the command line within the installer, If the xfs module is not loaded, it can't mount. See output below: bash-4.2# mount /dev/vda1 /mnt mount: unknown filesystem type `xfs` bash-4.2# modprobe xfs bash-4.2# mount /dev/vda1 /mnt bash-4.2# unmount /mnt bash-4.2# rmmod xfs bash-4.2# mount /dev/vda1 /mnt mount: unknown filesystem type `xfs` Also, the live CD version does not have this problem bug.
OK, so it seems we're missing whatever is required to allow the kernel to automatically load the modules as needed.
Can you double check the value of cat /proc/sys/kernel/modprobe? It should default to /sbin/modprobe. Does "which modprobe" point at /sbin/modprobe or is it actually some path in stage2 mount? (I'm hazy on the details of the installer) Assuming all is fine so far, can you do something like: echo "/sbin/modprobe.foo" >/proc/sys/kernel/modprobe Then write a simple script /sbin/modprobe.foo and log the output when it's called somewhere. This should trigger when you do a mount without the xfs module loaded such that the kernel tries to load it for you and you can see if it is called correctly etc.
OK, I checked myself and it seems /proc/sys/kernel/modprobe is empty... Simply doing "echo /sbin/modprobe >/proc/sys/kernel/modprobe" made it all work. Now to work out why it's blank :)
OK, it seems it's explicitly disabled: ./perl-install/install/install2.pm:610: eval { output('/proc/sys/kernel/modprobe', "\n") } if !$::local_install && !$::testing; #- disable kmod So I guess there should be code somewhere to load the xfs kernel module. Looking at ./perl-install/fs/mount.pm it does indeed call: modules::load(xfs); This in turn will try and load the crc module first and then xfs and because the crc module loading fails, it doesn't continue and try and load the xfs module... Not sure what's best here, but I suspect we should just drop the die() in modules::load_raw() and try and blast on regardless. The code is eval'ed anyway so the calling code just continues (as seen by your log) so we don't really lose anything by doing this. If you can rebuild your stage2 can you change the the die to a warn on line 96 of modules.pm?
Hi Colin, Thank you for your help so far. I might have a chance to rebuild stage2 tomorrow night.. it is 1am here right now. I have not built a stage2 installer before, so will have to figure out how to do so. Hopefully the wiki is helpful. Any idea why the crc module fails to load? is this because it is in a VM? Glen
I'm not sure what state the wiki is in, but I always struggle :D IIRC you need to be root to make the actual image. Don't worry about it too much. I do also see the same problem with the failure to load the crc module on VirtualBox. I'm not sure if this is a regression in the kernel or just something that is the way it is. Certainly up until recently both btrfs and xfs needed this module. Perhaps this is no longer needed on recent kernels?
CC: (none) => tmb
This is a very old change: disable kmod, otherwise we get a different behaviour in kernel vs kernel-BOOT "http://svn.mandriva.com/viewvc/soft/drakx/trunk/perl-install/install2.pm?r1=210201&r2=210285&pathrev=210910" (these days we'd a special optimized for size kernel-BOOT for the installer) I think we should just get rid of that, though xfs used to work before.
As for "program not found: -U", the issue was obvious and was there since introduced 4 years ago... Fixed in SVN
I have tested this, with SVN r7589. It appears to work. I have also tested the suggested change: "If you can rebuild your stage2 can you change the the die to a warn on line 96 of modules.pm?" Changing line 96 of modules.pm does not seem to have any effect, as it never seems to get run when creating an XFS partition. I think this can be set as resolved.
Closing then
Status: NEW => RESOLVEDResolution: (none) => FIXED
*** Bug 9675 has been marked as a duplicate of this bug. ***
CC: (none) => smorgan