FS#69293 - [lvm2] Disassembling stacked devices: device-mapper: remove ioctl failed: Device or resource busy

Attached to Project: Arch Linux
Opened by Alexander Shukaev (A.Shukaev) - Monday, 11 January 2021, 19:46 GMT
Last edited by Toolybird (Toolybird) - Thursday, 21 September 2023, 03:07 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Christian Hesse (eworm)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Both '/usr' and '/var' are on separate LVM logical volumes. Previously, I would see

failed unmounting /usr
failed unmounting /var

as per system shutdown, which appears to be normal behavior as already discussed in the past.

Since recently, I've been seeing something different:

[ OK ] Unmounted /var
...
[ OK ] Reached target Reboot.
Unmounting all devices.
umount: /oldroot/dev/pts: target is busy.
Detaching loop devices.
Disassembling stacked devices.
device-mapper: remove ioctl on xxx.vg-root.lv failed: Device or resource busy
Command failed.
device-mapper: remove ioctl on xxx.vg-usr.lv failed: Device or resource busy
Command failed.
device-mapper: remove ioctl on xxx.vg-root.lv failed: Device or resource busy
Command failed.
device-mapper: remove ioctl on xxx.vg-usr.lv failed: Device or resource busy
Command failed.
mdadm: Cannot get exclusive access to /dev/md126:Perhaps a running process, mounted filesystem or active volume group?
mdadm: Cannot get exclusive access to /dev/md126:Perhaps a running process, mounted filesystem or active volume group?

That is '/var' now is somehow properly unmounted and detached compared to how it was before. However, '/usr' (as in 'xxx.vg-usr.lv' device for LVM logical volume) is still not unmounted, but the errors are now reported in a different manner. Clearly, '/' (as in 'xxx.vg-root.lv' device for LVM logical volume) is also not unmounted properly as a consequence. All of that also leads to failure in disassembling of RAID0. It seems to be that previously, all these consequences didn't happen even though Systemd was unable to unmount '/usr' and '/var'.

Could somebody please take a look into this new behavior and confirm whether it's harmful or just a different way of reporting the old issue?
This task depends upon

Closed by  Toolybird (Toolybird)
Thursday, 21 September 2023, 03:07 GMT
Reason for closing:  None
Additional comments about closing:  Old and stale, and not a packaging issue. Things likely to have improved with recent systemd. Please refer to  FS#63697  for example.
Comment by Buggy McBugFace (bugbot) - Tuesday, 08 August 2023, 19:11 GMT
This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.

Loading...