Ideally, please look at this before Mageia 3 is released.. Some users may be affected during installation. Description of problem: System won't boot after installation, because, it fails to mount /usr. It fails to mount /usr, with the following mount error: drakcut: drakcut: Mounting /usr with -o relatime,acl,relatime The above, looks like it has relatime twice, which may be an error, however, the problem appears to be the acl option. From drakcut, Running: mount -o relatime /dev/mapper/vg--mga-usr /sysroot/usr works OK, but: mount -o relatime,acl /dev/mapper/vg--mga-usr /sysroot/usr fails, with the same error that is displayed by drakcut. How reproducible: It can be reliably reproduced, against:Mageia-3-RC-x86_64-DVD.iso date: Wed Apr 24 18:49:47 CEST 201 Steps to Reproduce: Install, with the following partition layout: First partition / ext4 2GB Second partition (extended, vda5), Type: LVM On LVM swap 1 GB /usr XFS 5 GB Reproducible: Steps to Reproduce:
Created attachment 3824 [details] sosreport.txt
The reason this fails, is that "acl" is not a valid mount option for an XFS file system.
CC: (none) => mageia, thierry.vignaudVersion: 3 => Cauldron
You should not have enabled 'acl' option :-) Fixed in SVN, now this option is only enabled for fses that support it Thanks for the report & thks for finding the issue
Status: NEW => RESOLVEDResolution: (none) => FIXEDSummary: /usr failed to be mounted during boot => /usr failed to be mounted during boot as XFS does not support the 'acl' option
(In reply to Thierry Vignaud from comment #3) > You should not have enabled 'acl' option :-) > Fixed in SVN, now this option is only enabled for fses that support it > Thanks for the report & thks for finding the issue Just to be clear, I didn't enable the ACL option, it seemed to default on. I didn't even go to advanced mode in the installer where the ACL option can be set.
Version: Cauldron => 3
I have not had a chance to test this yet from cauldron, but just a thought. Could this bug also be in drakcut? I ask this, because in the image that didn't work for me, fstab didn't have the acl option, although it was still being tried by drakcut on boot. I guess it might just have been the way the installer wrote the initrd file..
I guess dracut just uses the initial mount options from /etc/fstab
Tested today: Using stage2: 15.45 I an confirm that under advanced mode, ACL is not an option in the installer. However, boot still fails as it still has the acl option for the xfs filesystem in /usr... On a complete fresh install fro m cauldron. Md5sum of stage2 I tested: 9bcfa5717163ff75c76273250d5268ed x86_64/install/stage2/mdkinst.sqfs Further debugging: In installed system which won't boot: /etc/fstab is correct, it does not have the acl option. If I boot into rescue mode, bind mount the needed file systems, chroot and rebuild initrd, it still has the same problem. After a bit of digging: I suspect this bug is actually in dracut: dracut-025/modules.d/98usrmount/mount-usr.sh It looks to me like, that dracut's script to mount /usr, just uses the same options as is set for the root file system maybe?
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
(In reply to Glen Ogilvie from comment #7) > After a bit of digging: > I suspect this bug is actually in dracut: > dracut-025/modules.d/98usrmount/mount-usr.sh > > It looks to me like, that dracut's script to mount /usr, just uses the same > options as is set for the root file system maybe? Hmm, can you point out where it reuses the root opts? To me it looks very much like it uses the $NEWROOT/etc/fstab to find the /usr mount and then appends it to the initramfs's /etc/fstab before it is mounted. It does adjust the options slightly in that it will do some btrfs specific tweaks and it will append "ro" or "rw" to the options if needed. So I'm confused... can you point out where you think the error lies? Can you confirm the /etc/fstab in the initramfs contains the wrong options for /sysroot/usr entry?
The /etc/fstab within the initramfs does contain the wrong options. But the one in /sysroot/etc/fstab is correct. I was just struggling to set where $_opts got set. So was wondering if it came from the root fs. One reason for wondering this, is that the mount command that fails has relatime twice.. so was wondering if it's reading the options from both file systems and joining them together. (I have not found proof of this). Do you know how the /etc/fstab within the initramfs gets created? Glen
The system's fstab is read as part of a while loop which filters the entries any only extracts the /usr one then appends that to the initramfs's fstab. The code that does that is here: http://colin.guthr.ie/git/boot/dracut/tree/modules.d/98usrmount/mount-usr.sh?h=mga-025#n57 I can't see how it would result in things looking as strange as it does for you :( Can you post your system /etc/fstab? Perhaps something is in there that is messing up the parsing code linked above for some reason?
Did you manage to poke at this any more Glen? It's a bit tricky to work with so debugging can be slow :)
Hi Colin, I am keen to have a go at fixing this, but I've had a flat out week, so am not sure think I won't be able to look at this until the weekend. So, I still have it in mind. What I can get you now, is my filesystem layout on the test system. It's a little unusual, but that's the point, since I am testing the unusual: 2 x 4GB disks, each with 1 partition on them, (/dev/vda1 and /dev/vda2), both of type: 8e (lvm). Both partitions are added to a volume group. in the volume group, I have the following LVs. boot (368MB), xfs filesystem ntfs (688MB), ntfs filesystem opt (160MB), reiserFS root (5.65GB), encrypted XFS. swap (492m) In the installer, when I first open up the VG and click on the encrypted partition, it shows an encrypted, and the file system type as brtfs (which it is not).. When I click the use button, it asks me for the passphrase. After entering it, the tab is not refreshed and goes blank, however, if I switch to a disk tab, then switch back to the volume group tab, it shows up correctly, and I can click on the encrypted xfs partition and click view, to view the files. It is configured with grub2. The above test system won't actually boot up, because it didn't cope with the encrypted root file system, so it ends up in drakcut, complaining about not being able to find /dev/mapper/crypt_vg_mga_root, however, that's not what this bug is about.
(In reply to Glen Ogilvie from comment #12) > Hi Colin, > > I am keen to have a go at fixing this, but I've had a flat out week, so am > not sure think I won't be able to look at this until the weekend. So, I > still have it in mind. > > What I can get you now, is my filesystem layout on the test system. It's a > little unusual, but that's the point, since I am testing the unusual: ---> Sorry. the rest of the above comment was meant for bug #5661.
It's OK, I understood. I'd still like to get that one fixed too. Time for a new test VM methinks :D
(In reply to Colin Guthrie from comment #10) > > Can you post your system /etc/fstab? Perhaps something is in there that is > messing up the parsing code linked above for some reason? system fstab is not complex: It contains: /sysroot/etc/fstab ====================================== # Entry for /dev/vda1 : UUID=4dadb83a-8a4d-4fb9-84b3-e9f3717f88e8 / ext4 acl,relatime 1 1 none /proc proc defaults 0 0 /dev/vg-mga/usr /usr xfs relatime 1 2 /dev/vg-mga/swap swap swap defaults 0 0 ======================================== The fstab that is visible from drakcut: /etc/fstab ======================================== /dev/disk/by-uuid/4dadb83a-8a4d-4fb9-84b3-e9f3717f88e8 /sysroot ext4 acl,relatime 0 1 /dev/vg-mga/usr /sysroot/usr xfs relatime,acl,relatime 1 2 ========================================
Reproduced in a test VM.
And found the problem. Very obvious after putting in some debug statements. I just need to tidy up my dracut packaging a bit (I've got some uncommitted patches etc.) and will push out an update.
Should now be fixed (after dracut is pushed). It was a missing " && \" for what it's worth: http://svnweb.mageia.org/packages/cauldron/dracut/current/SOURCES/0514-usrmount-Fix-miss-detection-of-btrfs-subvolumes.patch?revision=412190&view=markup
Status: REOPENED => RESOLVEDResolution: (none) => FIXED