| Summary: | umount /usr failed, because /usr is busy on boot time | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Thomas Spuhler <thomas> |
| Component: | RPM Packages | Assignee: | Colin Guthrie <mageia> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | Normal | CC: | eatdirt, marja11 |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | MGA5TOO | ||
| Source RPM: | systemd-217-8.mga5 | CVE: | |
| Status comment: | |||
| Attachments: |
fstab
journal -b dmesg journal -b on vbox fstab from vbox |
||
|
Description
Thomas Spuhler
2015-05-10 01:32:58 CEST
I am going to rate it as a release blocker. Feel free to change this. Priority:
Normal =>
release_blocker 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
Marja Van Waes
2015-05-11 22:27:13 CEST
Attachment 6515 mime type:
application/octet-stream =>
text/plain 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
Samuel Verschelde
2015-06-06 15:57:46 CEST
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) =>
FIXED |