Description of problem: after update systemd, a lot of error about umount /usr failed, because /usr is busy on boot time Version-Release number of selected component (if applicable): systemd-217-8.mga5 How reproducible: 100% Steps to Reproduce: 1. Boot system 2. Look on console This looks to be the same problem as reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1159648 Reproducible: Steps to Reproduce:
I am going to rate it as a release blocker. Feel free to change this.
Priority: Normal => release_blockerAssignee: bugsquad => mageia
Please give more details if you want this rated as a release blocker, because it's not really clear what the issue is. What are the log messages? I'm not experiencing this on an up-to-date cauldron.
Ah nevermind, it supposes that one has a /usr partition, and I don't.
I have one, please give more details Thomas as I don't see this behaviour with systemd-217-8.mga5
CC: (none) => dirteat
Created attachment 6509 [details] fstab
Created attachment 6510 [details] journal -b
Created attachment 6511 [details] dmesg
(In reply to Chris Denice from comment #4) > I have one, please give more details Thomas as I don't see this behaviour > with systemd-217-8.mga5 See the three attachments
In my journalctl -b, I can only see one line: May 11 03:57:01 brenva systemd[1]: Unit usr.mount is bound to inactive service. Stopping, too. and that's all. It is on ext4, with acl: # Entry for /dev/sda7 : UUID=dfa4ec1e-5ee3-11dc-bbb5-21406f0e3933 /usr ext4 acl,relatime 1 2
I just installed mga5RC on a vbox. I made / usr var opt and home partitions, all btrfs I experienced the same problem with /usr, but the other partitions are fine. opt was mounted not like the bug reported on Fedora (see link in the report description.) I am going to attach the relevant part of journal -b of the vbox and an fstab copy
Created attachment 6513 [details] journal -b on vbox
Created attachment 6515 [details] fstab from vbox
Attachment 6515 mime type: application/octet-stream => text/plainCC: (none) => marja11
Since nobody could confirm the bug yet and it does not seem to break too much stuff, decreasing the priority. We really need to get Mageia 5 out now.
Priority: release_blocker => Normal
Whiteboard: (none) => MGA5TOO
Any news on this?
Again, any update? Bug is still there.
Any news?
Will this ever be fixed?
I'm sorry, but I'm super busy just now so not able to look into it. In all the times I've tried this kind of setup it works for me, but not looked overly recently. I suspect some kind of btrfs thing, but cannot be certain. I'm afraid that I'm unlikely to dedicate any of my limited time to looking at this directly. So if you can dig into the initramfs and debug it some more that would be good. Ultimately, you need to ensure that the system re-enters the initramfs again at shutdown and properly tries to stop applications and ensures the filesystem isn't busy. You should be able to use rd.break= kernel command line arguments to drop you to a debug shell in the initramfs during shutdown (see man dracut.cmdline) and generally fiddle around, try manual umounts etc, find out what is keeping the fs busy. You may need to make a custom initramfs to include various debugging binaries (e.g. fuser, ps etc).
Sorry too Thomas, but although I have /usr separate partition too, I am unable to reproduce it, it is ext4 though!
(In reply to Chris Denice from comment #19) > Sorry too Thomas, but although I have /usr separate partition too, I am > unable to reproduce it, it is ext4 though! As reported on comment 10, I have two boxes that show this problem. they are all btrfs. I will try to new vbox cauldron install if it is still present. The procedure Colin described goes over my head.
I just did a freshinstall of mga5 using these 3 partitions, all btrfs / /usr /home The problem is still present I also did a cauldron install and the problem is NOT present.
According comment 21 this problem was present in MGA5 with systemd-217.x but not anymore in MGA6 cauldron. MGA6 had systemd-230.x As MGA5 is EOL since end of 2017...closing as FIXED.
Resolution: (none) => FIXEDStatus: NEW => RESOLVED