Unmount fail: /oldroot/sys: target is busy - causing improper shutdown

TheDcoder · 2020-10-23 04:46:20

Hi,

I recall seeing this error ever since I installed Arch, but recently I upgraded my PC with an SSD and this error is causing an improper shutdown according to its diagnostic logs. I took an image of the error with my mobile phone, it occurs at the very end before the screen turns off:

[	OK	] Finished Power-Off.
[	OK	] Reached target Power-Off.
Unmounting all devices.
umount: /oldroot/sys: target is busy.
Detaching loop devices.
Disassembling stacked devices.
[ 2345.678912] reboot: Power down
_

The messages from "Unmounting" are all not part of Systemd's journal, I have checked and couldn't find them even at the most verbose output level (debug). So here are my questions:

1. What is "oldroot"?
2. Why is the "sys" interface/directory busy in oldroot?
3. What does "disassembling stacked devices" mean?

Thank you for your answers in advance!

Last edited by TheDcoder (2020-10-23 04:47:35)

blispx · 2020-10-23 14:02:11

Are you using proprietary nvidia drivers?

I remember that I also had it on nvidia, on iGPU / AMD systemd did not throw this error

V1del · 2020-10-23 14:07:27

I'd say it's more likely that some usb device/hard disk or so cannot be properly unloaded. Do you see anything in dmesg like a certain piece of hardware throwing errors or so? Post an entire journal from an affected session

sudo journalctl -b-1

after reboot from a reproduction case if you can't single this out further.

TheDcoder · 2020-10-23 18:18:25

blispx wrote:

Are you using proprietary nvidia drivers?

You are right! I am indeed using the nVidia drivers, forgot to mention that in my first post. I saw an older thread with a similar problem but the OP was able to solve it by messing with Bumblebee. I don't use Bumblebee since nvidia now provides native support for "selective graphics" (i.e prime-run in Arch)

I forgot the specifics, but I think I have configured my Nvidia card as secondary with my Intel iGPU being primary. Happy to provide more information on this.

@V1del No messages in the systemd journal like I mentioned, and I just went through the entire log for my last boot and there were no logged errors for any devices being unable to be properly unloaded. I'd prefer not to post my entire log in public, sorry. But I am 99.9% sure there isn't anything related to my hard disk or SSD in there.. but still, for everyone's satisfaction, I posted the complete log here but it will expire in a day.

blispx · 2020-10-23 19:49:53

Just run the driver in late KMS and you already have this error when restarting/shutting down the system, it doesn't matter if the card is the first or discrete. Something the systemd developers don't really like nvidia and we have to accept that

https://bugs.archlinux.org/task/63697

I have sold my RTX 2060, I'm going to buy something from AMD, I've had enough problems with nvidia

Last edited by blispx (2020-10-23 19:51:27)

TheDcoder · 2020-10-23 19:56:20

That's sad

I don't really understand the issue and the discussion thread on the bug ticket is long... so I briefly glimpsed over everything and it looks like for Nvidia users, a possible solution is to remove the related modules from initramfs. Does this mean I can still load the modules at a later stage? Is there a wiki article on this?

I have sold my RTX 2060, I'm going to buy something from AMD, I've had enough problems with nvidia

Sadly I am stuck because I have a laptop with the GPU soldered into the Motherboard. Next time I buy a computer I will look for AMD graphics with their FOSS drivers

blispx · 2020-10-23 20:04:38

If this error does not cause anything dangerous (as it was with me) set it to discrete GPU and run the software via prime-run.

At this point, you have to wait for nvidia until mid-November, we'll see what they come up with interesting ...

V1del · 2020-10-23 22:00:23

I have no issues on the nvidia prop drivers here.

Oct 23 07:59:44 arch systemd[1]: lvm2-monitor.service: Succeeded.
Oct 23 07:59:44 arch systemd[1]: Stopped Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling.
Oct 23 07:59:44 arch audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=lvm2-monitor comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 23 07:59:44 arch systemd[1]: Stopping LVM2 metadata daemon...
Oct 23 07:59:44 arch systemd[1]: lvm2-lvmetad.service: Succeeded.
Oct 23 07:59:44 arch systemd[1]: Stopped LVM2 metadata daemon.
Oct 23 07:59:44 arch audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=lvm2-lvmetad comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 23 07:59:44 arch systemd[1]: Reached target Shutdown.
Oct 23 07:59:44 arch systemd[1]: Reached target Final Step.
Oct 23 07:59:44 arch systemd[1]: lvm2-lvmetad.socket: Succeeded.
Oct 23 07:59:44 arch systemd[1]: Closed LVM2 metadata daemon socket.
Oct 23 07:59:44 arch systemd[1]: systemd-poweroff.service: Succeeded.
Oct 23 07:59:44 arch systemd[1]: Finished Power-Off.

The lvm services have been susceptible for this in the past, if you don't actively use LVM I suggest you try masking those

systemctl mask --now lvm2-lvmetad.service lvm2-lvmetad.socket

and rule out /disable syncthing. In the case that the nvidia drivers and the issue with the uvm module is related, the error should disappear on the LTS kernel as there shouldn't be a module incompat there.

Regarding the later stage loading, if you don't remember configuring something you already use the later stage loading.

FWIW Stacked devices and an issue with the loop devices sounds like the underlying issue here. What's mounted on your loop devices before the shutdown?

sudo losetup -a

Last edited by V1del (2020-10-23 22:04:22)

TheDcoder · 2020-10-23 22:12:23

V1del wrote:

The lvm services have been susceptible for this in the past, if you don't actively use LVM I suggest you try masking those

That is exactly what I did just a few hours ago, and made a topic for that too

V1del wrote:

...and rule out /disable syncthing. In the case that the nvidia drivers and the issue with the uvm module is related, the error should disappear on the LTS kernel as there shouldn't be a module incompat there.

I have disabled syncthing now. And I will try the suggested fixes from that ticket to see if that has any effect... and finally I will test the LTS kernel.

V1del wrote:

FWIW Stacked devices and an issue with the loop devices sounds like the underlying issue here. What's mounted on your loop devices before the shutdown?

Nothing at the moment, I had mounted some extra partitions during that particular session but no loop devices as far as I can remember

TheDcoder · 2020-10-23 22:33:09

Wow! Removing all the nvidia modules from mkinitcpio.conf (those were the only ones I had in my conf) seems to have done the trick! And I can still use prime offloading to switch to my Nvidia GPU on-demand, nice

Will report back with updates if I find any.

TheDcoder · 2020-11-14 04:31:14

If for some reason you need the nvidia modules in initramfs, an alternative fix for this issue can be found in this post which I made for a related nvidia issue, this will unload the nvidia modules after X exits so it will no longer keep the /oldroot/sys target busy.

Arch Linux

#1 2020-10-23 04:46:20

Unmount fail: /oldroot/sys: target is busy - causing improper shutdown

#2 2020-10-23 14:02:11

Re: Unmount fail: /oldroot/sys: target is busy - causing improper shutdown

#3 2020-10-23 14:07:27

Re: Unmount fail: /oldroot/sys: target is busy - causing improper shutdown

#4 2020-10-23 18:18:25

Re: Unmount fail: /oldroot/sys: target is busy - causing improper shutdown

#5 2020-10-23 19:49:53

Re: Unmount fail: /oldroot/sys: target is busy - causing improper shutdown

#6 2020-10-23 19:56:20

Re: Unmount fail: /oldroot/sys: target is busy - causing improper shutdown

#7 2020-10-23 20:04:38

Re: Unmount fail: /oldroot/sys: target is busy - causing improper shutdown

#8 2020-10-23 22:00:23

Re: Unmount fail: /oldroot/sys: target is busy - causing improper shutdown

#9 2020-10-23 22:12:23

Re: Unmount fail: /oldroot/sys: target is busy - causing improper shutdown

#10 2020-10-23 22:33:09

Re: Unmount fail: /oldroot/sys: target is busy - causing improper shutdown

#11 2020-11-14 04:31:14

Re: Unmount fail: /oldroot/sys: target is busy - causing improper shutdown

Board footer