FS#61925 - [Linux] Can't halt system with Linux 5.0
Attached to Project:
Arch Linux
Opened by LucaS (luca020400) - Wednesday, 06 March 2019, 07:51 GMT
Last edited by Jan de Groot (JGC) - Monday, 13 May 2019, 08:33 GMT
Opened by LucaS (luca020400) - Wednesday, 06 March 2019, 07:51 GMT
Last edited by Jan de Groot (JGC) - Monday, 13 May 2019, 08:33 GMT
|
Details
Description:
Right after installing Linux 5.0 I noticed my system won't reboot/shutdown unless I umount /home manually before attempting to halt my system. /home is a f2fs partition on a SSD device, reverting to old 4.20 f2fs sources didn't fix the issue. I tried to get into a root shell and killed every process using resources from /home before halting with no deal. Additional info: * package version(s): linux: 5.0 * cmdline: pti=off l1tf=off spectre_v1=off spectre_v2=off spectre_v2_user=off spec_store_bypass_disable=off module_blacklist=sp5100_tco * mount options: rw,noatime,lazytime,background_gc=on,discard,no_heap,inline_xattr,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,fsync_mode=nobarrier * link to upstream bug report: None (yet)? Steps to reproduce: reboot |
This task depends upon
I think the overlayfs isn't unmounted properly and somehow still references /home when systemd triggers partition umounts during the halt.
At this point I'm wondering if it's systemd that doesn't umount the partitions in the correct order ( unlikely since it worked fine before )
or something in the kernel broke recursive umount of partitions.
I'm now quite sure it's an issue with it, but using the 4.20 fs/f2fs under 5.0 doesn't fix it, so it's likely coming from fs or block stack
[Unit]
Before=basic.target
This would effectively avoid the glitch and resist an update of the dbus package. What it does is forcing systemd to keep dbus.service running until basic.target has been shut down.
HOWEVER:
This is a "dirty workaround". It would be better if the glitch would be actually fixed by either the developers of the Kernel or Systemd.
You can try out the workaround, its not guaranteed to work tho, so use it at your own risk. Remember to remove the config file when the bug gets fixed or if it does not help you.
Here are my sources: https://bbs.archlinux.org/viewtopic.php?id=170756
EDIT: My DBUS theory is garbage, it just "luckily" fixed the issue improperly. By all means, use the LVM patch instead.
After trying the dbus hack ( that didn't help ), I now see the real issue.
It fails to umount /run/user/1000
EDIT: It still does happen sometimes, but much less often than with the usbstick pluggen in. very weird. Well, for me, it seems like Systemd 241.7-2 is not ready for kernel 5.0, yet.
But I doubt anything there is the issue since Google drive isn't mounted by default and seems like there is sometimes else keeping dbus stuck
Indeed Linux 5.0 doesn't play nice with systemd
- Hardware is AMD 1700X, RTX 2070, SSD
- I use startx with openbox and nvidia drivers
- ext4 on / and /home
- FAT32 on /boot
What I've tried which doesn't work/change anything:
- don't mount any network drives
- try to debug it with https://wiki.archlinux.org/index.php/systemd#Shutdown.2Freboot_takes_terribly_long but I haven't found anything useful in those resulting logs; I can still attach them if needed
- create a new user with just my xinitrc and openbox configuration (to rule out user specific services and timers)
- adjust timeout values in systemd.conf file
What did work but feels hacky and is probably not a good solution:
- systemctl force like poweroff --force
- dbus.service basic.target thing mentioned here
Other observations:
- Don't start X at all and go to tty2 where getty is not enabled, login and issue commands there works most of the time but not 100%.
- Using the current LTS kernel (4.19.x) works 100% correctly.
I also have the same problem on my work laptop (T480, Intel graphics), but I only performed the steps above on my desktop machine.
find /usr/lib/systemd/system/*.service -type f | xargs grep --files-with-matches DefaultDependencies=no | xargs grep --files-with-matches "Conflicts=.*shutdown.target" | xargs grep --files-without-match "Before=.*shutdown.target"
I think the to-implement solution (according to GitHub) is to just show a warning which services are responsible.
Maybe this should be handled by the lvm2 package then? At least on my machine that's the only package which includes such service files. Should we then close it or wait for the lvm2 package to adapt (upstream)?
How do we proceed here? I think the solution cannot be to manually modify the file?
If you want me to post the PKGBUILD, let me know.
LVM needs to fix their service files. In the meantime I think the best approach would be a pacman hook which is automatically applied after upgrading the LVM package as long as it's not fixed upstream. If you have this, I'd be grateful if you share it.
Anyways, here's the PKGBUILD:
pkgname=lvm-patch
pkgver=1.0.0
pkgrel=1
pkgdesc="lvm-patch"
arch=('any')
license=('unknown')
package() {
mkdir "${pkgdir}/usr"
mkdir "${pkgdir}/usr/lib"
mkdir "${pkgdir}/usr/lib/systemd"
mkdir "${pkgdir}/usr/lib/systemd/system"
mkdir "${pkgdir}/usr/lib/systemd/system/lvm2-lvmetad.service.d"
echo "[Unit]" > ${pkgdir}/usr/lib/systemd/system/lvm2-lvmetad.service.d/lvm-patch.conf
echo "Before=shutdown.target" >> ${pkgdir}/usr/lib/systemd/system/lvm2-lvmetad.service.d/lvm-patch.conf
}
To install this just put the text into a file named "PKGBUILD" and run "makepkg -rsi" in the same directory where the PKGBUILD file is.
This will install a package called "lvm-patch".
After installing this the problem should be fixed.
If you want to remove the patch just run "sudo pacman -R lvm-patch" and it should be gone.
https://aur.archlinux.org/packages/lvm-order-patch/
EDIT: Good news, there is an Upstream patch for this issue on the way. Just wait for the newest version of lvm2 to pass testing (Shouldn't take long since we're on Arch) and the issue will be resolved.
FS#62302lvm2 2.02.184-4 currently in testing has the patch and the fix for
FS#62302Thanks!