Bug 1305831

What type of filesystems do you have (ext4, btrfs)? RAID?

ext4 with root, swap and home in separate logical volumes. I'd say I'm not using RAID since cat /proc/mdstat gives

Personalities : 
unused devices: <none>

BTW, I don't get that iterated message with kernel 4.2.3, just with 4.3.5 and 4.3.5. In case this helps, with 4.2.3, after [ OK ] Reached target Shutdown I get:

dracut Warning: Killing all remaining processes
dracut Warning: Unmounted /oldroot.

I looked at the shutdown logs you've posted and they look pretty normal. Nothing out of the ordinary. I think that messages you see on the screen are from shutdown initrd environment. At that time systemd is not running anymore. Also you stated that with older kernel you don't experience the problems, so I really think this is probably device-mapper bug. Not sure whether userspace tools or kernel part is the culprit though.

Michal, thanks for your input. This is the first time I report a bug here, what should we do now? Shall I open a new report of we can transfer this one to the right people?

(In reply to Fernando from comment #5)
> Michal, thanks for your input. This is the first time I report a bug here,
> what should we do now? Shall I open a new report of we can transfer this one
> to the right people?

You don't need to submit separate bug report. Just change component of the existing one. 

Due to lack of the better idea I am reassigning to device-mapper. I hope they can reroute it to the proper place if necessary.

Does the file /run/initramfs/.need_shutdown exist?
# ls -l /run/initramfs/.need_shutdown

If you want to debug the final shutdown do:

# mkdir -p /run/initramfs/etc/cmdline.d
# echo "rd.debug rd.break=pre-shutdown rd.break=shutdown" \
  > /run/initramfs/etc/cmdline.d/debug.conf
# touch /run/initramfs/.need_shutdown

This will drop you to a shell in the end, and you will be able to take photos of the last messages.

Exit the shell:
# exit

You will be dropped to another shell... take a photo, then
# exit

Hi Harald, /run/initramfs/.need_shutdown does exist, but it's empty, I've done what you say (as super user) and nothing happens.

(In reply to Fernando from comment #8)
> Hi Harald, /run/initramfs/.need_shutdown does exist, but it's empty, I've
> done what you say (as super user) and nothing happens.

oh.. of course you have to shutdown/reboot

Created attachment 1123593 [details]
Following Harald's instructions

Created attachment 1123595 [details]
Halting

Oh, crap, I should have understood that those commands were not shutting down themselves... Anyway, I've followed your instructions but the first shell seems to have cleaned all previous output (see the picture). Nevertheless, I've also uploaded the result of a halt, in case this is what you're asking. As you can see, it's just the line in my first message repeated all over the screen. If I've failed again in following your instructions, please tell me, I'll repeat it. Thanks!

(In reply to Fernando from comment #12)
> Oh, crap, I should have understood that those commands were not shutting
> down themselves... Anyway, I've followed your instructions but the first
> shell seems to have cleaned all previous output (see the picture).
> Nevertheless, I've also uploaded the result of a halt, in case this is what
> you're asking. As you can see, it's just the line in my first message
> repeated all over the screen. If I've failed again in following your
> instructions, please tell me, I'll repeat it. Thanks!

you can always scroll up with <shift>+<pageup>

I'm afraid this isn't working. I've also tried other key combinations I've found in internet to no avail.

(In reply to Fernando from comment #14)
> I'm afraid this isn't working. I've also tried other key combinations I've
> found in internet to no avail.

did you remove "quiet" from the kernel command line?

Created attachment 1127632 [details]
first shot

Created attachment 1127633 [details]
second shot

No, I didn't, that was my mistake. Please, have a look at the two shots I've uploaded. Thanks!

(In reply to Fernando from comment #18)
> No, I didn't, that was my mistake. Please, have a look at the two shots I've
> uploaded. Thanks!

and exiting the last shell does not reboot?

(In reply to Harald Hoyer from comment #19)
> (In reply to Fernando from comment #18)
> > No, I didn't, that was my mistake. Please, have a look at the two shots I've
> > uploaded. Thanks!
> 
> and exiting the last shell does not reboot?

Yes, after the second shot 'exit' does reboot.

(In reply to Fernando from comment #20)
> (In reply to Harald Hoyer from comment #19)
> > (In reply to Fernando from comment #18)
> > > No, I didn't, that was my mistake. Please, have a look at the two shots I've
> > > uploaded. Thanks!
> > 
> > and exiting the last shell does not reboot?
> 
> Yes, after the second shot 'exit' does reboot.

and you have a problem to reboot without the debug changes of comment #7 ?

(In reply to Harald Hoyer from comment #21)
> (In reply to Fernando from comment #20)
> > (In reply to Harald Hoyer from comment #19)
> > > (In reply to Fernando from comment #18)
> > > > No, I didn't, that was my mistake. Please, have a look at the two shots I've
> > > > uploaded. Thanks!
> > > 
> > > and exiting the last shell does not reboot?
> > 
> > Yes, after the second shot 'exit' does reboot.
> 
> and you have a problem to reboot without the debug changes of comment #7 ?

Well, it always ends up rebooting/switching off, as I explained in the first message, quite often after a while, sometimes without the Fedora splash screen (it stays in a blocked Gnome session), and 99% of times with the following strange message:

device-mapper: remove ioctl on fedora-root failed: Device or resource busy

I also explain above that this started with a kernel upgrade.

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

I still experience this bug in Fedora 25.

I get three messages:

device-mapper: remove ioctl on fedora-root failed: Device or resource busy
Kernel not configured for semaphores (System V IPC). Not using udev synchronisation code.
Command failed


Multiple times over the screen, right before shutdown.

My Root partition is an LVM partition with one single ext4 partition inside. 

I read somewhere that device-mapper has been deprecated, but I couldn't remove it because it's protected by systemd-udevd.

Do you need help debugging this issue? I don't get hangs on shutdown, but it looks kind of ugly.

(In reply to Alexander Korsunsky from comment #24)
> I still experience this bug in Fedora 25.
> 
> I get three messages:
> 
> device-mapper: remove ioctl on fedora-root failed: Device or resource busy

The systemd/dracut shutdown hook is trying to deactivate a device which is still in use (not an LVM/device-mapper issue).

> Kernel not configured for semaphores (System V IPC). Not using udev
> synchronisation code.
> Command failed

This was already reported as bug #1359352 (which was closed as dup of bug #1385432 - an selinux issue in dracut environment at shutdown).

> 
> 
> Multiple times over the screen, right before shutdown.
> 
> My Root partition is an LVM partition with one single ext4 partition inside. 
> 
> I read somewhere that device-mapper has been deprecated, but I couldn't
> remove it because it's protected by systemd-udevd.


Device-mapper is definitely not deprecated.

(In reply to Peter Rajnoha from comment #25)
> (In reply to Alexander Korsunsky from comment #24)
> > device-mapper: remove ioctl on fedora-root failed: Device or resource busy
> 
> The systemd/dracut shutdown hook is trying to deactivate a device which is
> still in use (not an LVM/device-mapper issue).
So who's issue is that? Should I create a new bug for that? Which component?

> This was already reported as bug #1359352 (which was closed as dup of bug
> #1385432 - an selinux issue in dracut environment at shutdown).
Thanks for the links.


> Device-mapper is definitely not deprecated.
I must have misunderstood this comment from bug 1359352, comment 14


> By the way, the bug was missed because device-mapper (the fedora package, not the kernel functionality itself) is obsolete - orphaned.  It is now a sub-package of lvm2, and although I removed the bugzilla component when we did that, some fedora system has put it back!

(In reply to Alexander Korsunsky from comment #26)
> (In reply to Peter Rajnoha from comment #25)
> > (In reply to Alexander Korsunsky from comment #24)
> > > device-mapper: remove ioctl on fedora-root failed: Device or resource busy
> > 
> > The systemd/dracut shutdown hook is trying to deactivate a device which is
> > still in use (not an LVM/device-mapper issue).
> So who's issue is that? Should I create a new bug for that? Which component?
> 

That would be "dracut" component I suppose (if not, they will change to proper component surely).

> > Device-mapper is definitely not deprecated.
> I must have misunderstood this comment from bug 1359352, comment 14

Well, that was meant only for "device-mapper bugzilla component", not device-mapper driver itself.

> (In reply to Alexander Korsunsky from comment #26)
> > (In reply to Peter Rajnoha from comment #25)
> > > (In reply to Alexander Korsunsky from comment #24)
> > So who's issue is that? Should I create a new bug for that? Which component?
> > 
> 
> That would be "dracut" component I suppose (if not, they will change to
> proper component surely).

For reference, I created the bug #1402073

Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.