complete shutdown impossible (fedora 24)

[François Patte]

Bonsoir,

I am facing a problem: when I shutdown my computer

1) the screen is immediately turned off so I can't see the shutdown
messages.

2) the computer does not stop, I have to press for a long time on the
power button.

Installation uses encrypted  raid arrays (raid 1) on 2 disks.

After reboot, I went to journalctl and here are the last messages of the
shutdown sequence (I am unable to interpret thes messages, so maybe some
other preceeding  messages could be important.

<--------------------
janv. 09 19:26:12 bhaskara blkdeactivate[10933]:   [UMOUNT]: unmounting
luks-63be2188-bd3d-4552-9a8b-9481d942fb46 (dm-5) mounted on /opt... done
janv. 09 19:26:12 bhaskara blkdeactivate[10933]:   [UMOUNT]: unmounting
luks-2bb52af6-efb8-4c10-b103-565bb3239551 (dm-3) mounted on /home...
skipping
janv. 09 19:26:12 bhaskara blkdeactivate[10933]:   [SKIP]: unmount of
luks-1ebb3482-1442-4706-94bc-b87cffd651fb (dm-1) mounted on /
janv. 09 19:26:12 bhaskara systemd[1]: Stopping ABRT Automated Bug
Reporting Tool...
janv. 09 19:26:12 bhaskara systemd[1]: Stopped ABRT Automated Bug
Reporting Tool.
janv. 09 19:26:12 bhaskara audit[1]: SERVICE_START pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=abrtd comm="systemd" exe="/usr/lib/systemd/systemd"
hostname=?
addr=? terminal=? res=success'
janv. 09 19:26:12 bhaskara audit[1]: SERVICE_STOP pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=abrtd comm="systemd" exe="/usr/lib/systemd/systemd"
hostname=?
addr=? terminal=? res=success'
janv. 09 19:26:12 bhaskara systemd[1]: Stopped
/dev/mapper/luks-63be2188-bd3d-4552-9a8b-9481d942fb46.
janv. 09 19:26:12 bhaskara systemd[1]: Stopped
/dev/disk/by-uuid/d7deece3-a820-41cd-a177-9ce867b56408.
janv. 09 19:26:12 bhaskara systemd[1]: Stopped
/dev/disk/by-id/dm-uuid-CRYPT-LUKS1-63be2188bd3d45529a8b9481d942fb46-luks-63be2188-bd3d-4552-9a8b-9481d942fb46.
janv. 09 19:26:12 bhaskara systemd[1]: Stopped
/dev/disk/by-id/dm-name-luks-63be2188-bd3d-4552-9a8b-9481d942fb46.
janv. 09 19:26:12 bhaskara systemd[1]: Stopped /dev/dm-5.
janv. 09 19:26:12 bhaskara systemd[1]: Stopped
/sys/devices/virtual/block/dm-5.
janv. 09 19:26:12 bhaskara blkdeactivate[10933]:   [DM]: deactivating
crypt device luks-63be2188-bd3d-4552-9a8b-9481d942fb46 (dm-5)... done
janv. 09 19:26:12 bhaskara kernel: md122: detected capacity change from
42951770112 to 0
janv. 09 19:26:12 bhaskara kernel: md: md122 stopped.
janv. 09 19:26:12 bhaskara kernel: md: unbind<sdb2>
janv. 09 19:26:12 bhaskara kernel: md: export_rdev(sdb2)
janv. 09 19:26:12 bhaskara kernel: md: unbind<sda2>
janv. 09 19:26:12 bhaskara kernel: md: export_rdev(sda2)
janv. 09 19:26:12 bhaskara kernel: BUG: unable to handle kernel paging
request at ffff8f3f29ea8000
<--------------------------------

Any ideas on how to solve this or test to run?

Thank you.

-- 
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. [phone]
http://www.math-info.univ-paris5.fr/~patte

[Tom Horsley]

On Mon, 9 Jan 2017 19:54:28 +0100
François Patte wrote:

>  1) the screen is immediately turned off so I can't see the
> shutdown
>  messages. 
I get this with the binary nvidia drivers. With the nouveau driver
I can usually still see messages during shutdown.

>  2) the computer does not stop, I have to press for a long time on
> the
>  power button. 
The newer versions of systemd sometime are willing to stop waiting
for whatever silly thing it is waiting on if you repeat Ctrl-Alt-Del
several times (which usually happens if you hold them down on most
keyboards). This can be less drastic than powering off.

My experience has been that systemd always waits for "user deamons"
which it never shuts down, but I keep adding things to the list
that it can't shutdown properly (for instance, I've seen it shutdown
the network interface then start waiting for NFS unmounts to finish :-).

My web page at http://tomhorsley.com/game/punch.html describes what I do
to make reboot work fast. Just changing the alias to do a shutdown
rather than a reboot would probably make shutdown fast as well.

[François Patte]

Le 09/01/2017 20:16, Tom Horsley a écrit :
>  On Mon, 9 Jan 2017 19:54:28 +0100
>  François Patte wrote:
>  
> > 1) the screen is immediately turned off so I can't see the shutdown
> > messages.
>  
>  I get this with the binary nvidia drivers. With the nouveau driver
>  I can usually still see messages during shutdown.
>  
> > 2) the computer does not stop, I have to press for a long time on the
> > power button.
>  
>  The newer versions of systemd sometime are willing to stop waiting
>  for whatever silly thing it is waiting on if you repeat Ctrl-Alt-Del
>  several times (which usually happens if you hold them down on most
>  keyboards). This can be less drastic than powering off.
>  
>  My experience has been that systemd always waits for "user deamons"
>  which it never shuts down, but I keep adding things to the list
>  that it can't shutdown properly (for instance, I've seen it shutdown
>  the network interface then start waiting for NFS unmounts to finish :-).
>  
>  My web page at http://tomhorsley.com/game/punch.html describes what I do
>  to make reboot work fast. Just changing the alias to do a shutdown
>  rather than a reboot would probably make shutdown fast as well. 
Thank you for your answer. I tried your tools but I am unable to say if
this solves my problems: since yesterday, I did not have the awfull
shutdowns I had 2 days ago....


-- 
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. [phone]
http://www.math-info.univ-paris5.fr/~patte

[François Patte]

Le 09/01/2017 20:16, Tom Horsley a écrit :
>  On Mon, 9 Jan 2017 19:54:28 +0100
>  François Patte wrote:
>  
> > 1) the screen is immediately turned off so I can't see the shutdown
> > messages.
>  
>  I get this with the binary nvidia drivers. With the nouveau driver
>  I can usually still see messages during shutdown.
>  
> > 2) the computer does not stop, I have to press for a long time on the
> > power button.
>  
>  The newer versions of systemd sometime are willing to stop waiting
>  for whatever silly thing it is waiting on if you repeat Ctrl-Alt-Del
>  several times (which usually happens if you hold them down on most
>  keyboards). This can be less drastic than powering off.
>  
>  My experience has been that systemd always waits for "user deamons"
>  which it never shuts down, but I keep adding things to the list
>  that it can't shutdown properly (for instance, I've seen it shutdown
>  the network interface then start waiting for NFS unmounts to finish :-).
>  
>  My web page at http://tomhorsley.com/game/punch.html describes what I do
>  to make reboot work fast. Just changing the alias to do a shutdown
>  rather than a reboot would probably make shutdown fast as well. 
I tried this today and it failed! No reboot at all: computer stays alive
with a black screen and fan running.

I installed the last kernel available for fedora 24 (4.8.16). When I do
not work with computer (ie. Just start it, log-in and shutdown) the
computer shutdowns normaly. If I do something (read my mail, open a text
file...) the computer is unable to shutdown. Conclusion: a computer is
not made forworking! Just have it, start it and stare at your background
image (and do not change it, or you will be unable to shut it down!).


Chris Murphy says that it is a "regression". OK! So on fedora 27, the
system will be unable to even start!

-- 
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. [phone]
http://www.math-info.univ-paris5.fr/~patte

[stan]

On Sun, 15 Jan 2017 11:45:47 +0100
François Patte <francois.patte(a)mi.parisdescartes.fr&gt; wrote:
[snip]
>  I installed the last kernel available for fedora 24 (4.8.16). When I
>  do not work with computer (ie. Just start it, log-in and shutdown) the
>  computer shutdowns normaly. If I do something (read my mail, open a
>  text file...) the computer is unable to shutdown. Conclusion: a
>  computer is not made forworking! Just have it, start it and stare at
>  your background image (and do not change it, or you will be unable to
>  shut it down!). 
I see this same behavior on F25, running a 4.10 kernel.  I also tried
Tom's solution of getting rid of the a11y... file.  It didn't work for
me either, and I get processes complaining that it is missing.

If I let the computer sit when it says shutdown reached, about 90
seconds later it completes the shutdown.  The screen flashes too
quickly for me to read what is holding up the shutdown, but it is
probably the systemd --user daemons that Tom mentions in his article.

I haven't yet experimented with changing the timeout options in a
custom file in /etc/dbus-1, but will probably do so in the future.
There has to be a way to set the timeouts for a sigterm on those
processes to be less than 90 seconds, say 10 seconds.

So, if you let your computer sit for a few minutes, it will shut down
when those processes time out.

[François Patte]

Le 15/01/2017 17:30, stan a écrit :
>  On Sun, 15 Jan 2017 11:45:47 +0100
>  François Patte <francois.patte(a)mi.parisdescartes.fr&gt; wrote:
>  [snip]
> > I installed the last kernel available for fedora 24 (4.8.16). When I
> > do not work with computer (ie. Just start it, log-in and shutdown) the
> > computer shutdowns normaly. If I do something (read my mail, open a
> > text file...) the computer is unable to shutdown. Conclusion: a
> > computer is not made forworking! Just have it, start it and stare at
> > your background image (and do not change it, or you will be unable to
> > shut it down!).
>  
>  I see this same behavior on F25, running a 4.10 kernel.  I also tried
>  Tom's solution of getting rid of the a11y... file.  It didn't work for
>  me either, and I get processes complaining that it is missing.
>  
>  If I let the computer sit when it says shutdown reached, about 90
>  seconds later it completes the shutdown.  The screen flashes too
>  quickly for me to read what is holding up the shutdown, but it is
>  probably the systemd --user daemons that Tom mentions in his article.
>  
>  I haven't yet experimented with changing the timeout options in a
>  custom file in /etc/dbus-1, but will probably do so in the future.
>  There has to be a way to set the timeouts for a sigterm on those
>  processes to be less than 90 seconds, say 10 seconds.
>  
>  So, if you let your computer sit for a few minutes, it will shut down
>  when those processes time out. 
No! Even after half an hour, the computer is still "on", the screen is
black, fan is running, I cannot do anything with the keyboard.

I think that there something wrong with encryption (my system use
encrypted RAID1 partitions); here is what reports logwatch:


systemd-cryptsetup(a)luks\x2d1ebb3482\x2d1442\x2d4706\x2d94bc\x2db87cffd651fb.service:
Control process exited, code=exited status=1: 1 Time(s)

systemd-cryptsetup(a)luks\x2d1ebb3482\x2d1442\x2d4706\x2d94bc\x2db87cffd651fb.service:
Failed with result 'exit-code'.: 1 Time(s)

systemd-cryptsetup(a)luks\x2d1ebb3482\x2d1442\x2d4706\x2d94bc\x2db87cffd651fb.service:
Unit entered failed state.: 1 Time(s)

systemd-cryptsetup(a)luks\x2d2bb52af6\x2defb8\x2d4c10\x2db103\x2d565bb3239551.service:
Control process exited, code=exited status=1: 1 Time(s)

systemd-cryptsetup(a)luks\x2d2bb52af6\x2defb8\x2d4c10\x2db103\x2d565bb3239551.service:
Failed with result 'exit-code'.: 1 Time(s)

systemd-cryptsetup(a)luks\x2d2bb52af6\x2defb8\x2d4c10\x2db103\x2d565bb3239551.service:
Unit entered failed state.: 1 Time(s)

systemd-cryptsetup(a)luks\x2d55c35866\x2dd305\x2d4c39\x2db9f6\x2d2c81fcf8cdcb.service:
Control process exited, code=exited status=1: 1 Time(s)

systemd-cryptsetup(a)luks\x2d55c35866\x2dd305\x2d4c39\x2db9f6\x2d2c81fcf8cdcb.service:
Failed with result 'exit-code'.: 1 Time(s)

systemd-cryptsetup(a)luks\x2d55c35866\x2dd305\x2d4c39\x2db9f6\x2d2c81fcf8cdcb.service:
Unit entered failed state.: 1 Time(s)

systemd-cryptsetup(a)luks\x2d63be2188\x2dbd3d\x2d4552\x2d9a8b\x2d9481d942fb46.service:
Control process exited, code=exited status=1: 1 Time(s)

systemd-cryptsetup(a)luks\x2d63be2188\x2dbd3d\x2d4552\x2d9a8b\x2d9481d942fb46.service:
Failed with result 'exit-code'.: 1 Time(s)

systemd-cryptsetup(a)luks\x2d63be2188\x2dbd3d\x2d4552\x2d9a8b\x2d9481d942fb46.service:
Unit entered failed state.: 1 Time(s)

systemd-cryptsetup(a)luks\x2d6677ab72\x2d4ddc\x2d414f\x2dac64\x2d391b3ce2de50.service:
Control process exited, code=exited status=1: 1 Time(s)

systemd-cryptsetup(a)luks\x2d6677ab72\x2d4ddc\x2d414f\x2dac64\x2d391b3ce2de50.service:
Failed with result 'exit-code'.: 1 Time(s)

systemd-cryptsetup(a)luks\x2d6677ab72\x2d4ddc\x2d414f\x2dac64\x2d391b3ce2de50.service:
Unit entered failed state.: 1 Time(s)
    usr.mount: Mount process exited, code=exited status=32: 1 Time(s)
    var.mount: Mount process exited, code=exited status=32: 1 Time(s)

I don't know if I can trust that system! Things used to run smoothly
before fedora 22....

-- 
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. [phone]
http://www.math-info.univ-paris5.fr/~patte

[stan]

On Sun, 15 Jan 2017 18:33:12 +0100
François Patte <francois.patte(a)mi.parisdescartes.fr&gt; wrote:


>  No! Even after half an hour, the computer is still "on",
> the screen is
>  black, fan is running, I cannot do anything with the keyboard.
>  
>  I think that there something wrong with encryption (my system use
>  encrypted RAID1 partitions); here is what reports logwatch: 
[snip]
>  I don't know if I can trust that system! Things used to run
> smoothly
>  before fedora 22.... 
I think I agree with you.  Your case is very different than mine.  If
it was my system, I would save any unique information, reinstall from
scratch, then reintroduce the unique information.

Maybe you could paste it somewhere on the web (twice to be redundant) in
encrypted form, and recover it after the new install.

[François Patte]

Le 15/01/2017 21:30, stan a écrit :
>  On Sun, 15 Jan 2017 18:33:12 +0100
>  François Patte <francois.patte(a)mi.parisdescartes.fr&gt; wrote:
>  
>  
> > No! Even after half an hour, the computer is still "on", the screen is
> > black, fan is running, I cannot do anything with the keyboard.
> >
> > I think that there something wrong with encryption (my system use
> > encrypted RAID1 partitions); here is what reports logwatch:
>  [snip]
> > I don't know if I can trust that system! Things used to run smoothly
> > before fedora 22....
>  
>  I think I agree with you.  Your case is very different than mine.  If
>  it was my system, I would save any unique information, reinstall from
>  scratch, then reintroduce the unique information.
>  
>  Maybe you could paste it somewhere on the web (twice to be redundant) in
>  encrypted form, and recover it after the new install. 
But it is a *new* install: I first installed f25 and it was awfull: some
app like firefox were unable to read properly html pages, and I could
read one mail out of three with thunderbird!

So I installed fedora 24 and it works normally (up to now!) except this
shutdown problem.

I don't know where to report this problem, I think that devellopers and
packagers don't care about this. To proove this, try to install with
anaconda an encrypted raid system, preserving your home and opt
directories. It took me 3 hours before the install could begin: anaconda
hanged or crashed many times.

So my thoughts are that these fedora version (>21) are only done for
standard instalations not for secure ones!

-- 
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. [phone]
http://www.math-info.univ-paris5.fr/~patte

[stan]

On Mon, 16 Jan 2017 11:00:33 +0100
François Patte <francois.patte(a)mi.parisdescartes.fr&gt; wrote:

>  But it is a *new* install: I first installed f25 and it was awfull:
>  some app like firefox were unable to read properly html pages, and I
>  could read one mail out of three with thunderbird! 
This doesn't sound like a software problem.  If thunderbird reads one
mail, it should be able to read all mails.  An email is an email.  And
the same for firefox.  An html page is an html page (sort of, it's a
lot more complicated than email).  But if thousands of other people can
read an html page with firefox that you can't, it sounds like there is
a problem with the system that firefox is running on, not with firefox.

>  So I installed fedora 24 and it works normally (up to now!) except
>  this shutdown problem.
>  
>  I don't know where to report this problem, I think that devellopers 
I think you should report it against anaconda.

>  and packagers don't care about this. To proove this, try to
> install
>  with anaconda an encrypted raid system, preserving your home and opt
>  directories. It took me 3 hours before the install could begin:
>  anaconda hanged or crashed many times.
>  
>  So my thoughts are that these fedora version (>21) are only done for
>  standard instalations not for secure ones!
>   
I expect you are right that the secure installations aren't tested as
thoroughly as the standard installations, though I don't know that, and
might be completely wrong.  But if they are tested at all they should
have caught problems like yours, if those problems aren't somehow
hardware related.

Is it possible you are experiencing hardware problems?  Overheating
because of ventilation, dust shorting, loose memory sticks, failing
memory, etc.?

[Chris Murphy]

On Mon, Jan 9, 2017 at 11:54 AM, François Patte
<francois.patte(a)mi.parisdescartes.fr&gt; wrote:

>  janv. 09 19:26:12 bhaskara systemd[1]: Stopped /dev/dm-5.
>  janv. 09 19:26:12 bhaskara systemd[1]: Stopped
>  /sys/devices/virtual/block/dm-5.
>  janv. 09 19:26:12 bhaskara blkdeactivate[10933]:   [DM]: deactivating
>  crypt device luks-63be2188-bd3d-4552-9a8b-9481d942fb46 (dm-5)... done
>  janv. 09 19:26:12 bhaskara kernel: md122: detected capacity change from
>  42951770112 to 0
>  janv. 09 19:26:12 bhaskara kernel: md: md122 stopped.
>  janv. 09 19:26:12 bhaskara kernel: md: unbind<sdb2>
>  janv. 09 19:26:12 bhaskara kernel: md: export_rdev(sdb2)
>  janv. 09 19:26:12 bhaskara kernel: md: unbind<sda2>
>  janv. 09 19:26:12 bhaskara kernel: md: export_rdev(sda2)
>  janv. 09 19:26:12 bhaskara kernel: BUG: unable to handle kernel paging
>  request at ffff8f3f29ea8000 
OK well it's a kernel bug, seems like to me. The simplest thing to do
is try a different kernel. But which one? I'm not seeing immediately
relevant patches for md in either 4.8.16 or 4.8.17. What kernel
version are you using now? If it's 4.18.15, sure you can try either
4.18.16 (which is in updates-testing) or you can get 4.8.17 from koji.
Looks like 4.9.2 is building now in koji and should be done shortly so
you could also try that one.

If it reproduces with 4.9.2, for sure you should try to get more
information. If you can ssh into the system remotely so you can get a
complete dmesg that'd be useful. If ssh gets killed off before the
bug, then you might see if any of these ideas will get you more
information on the nature of the failure.

https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1

Even if it's not shutting down, maybe the special logging instructions
for the "eventually shuts down" case will still log something useful
that you can check out at the next reboot.



-- 
Chris Murphy

[Chris Murphy]

And yeah, don't use proprietary video drivers when trying to
troubleshoot kernel related problems. That could be the cause of the
bug, or it could prevent you from seeing or logging the call trace of
the bug.

[François Patte]

Le 10/01/2017 05:44, Chris Murphy a écrit :
>  On Mon, Jan 9, 2017 at 11:54 AM, François Patte
>  <francois.patte(a)mi.parisdescartes.fr&gt; wrote:
>  
> > janv. 09 19:26:12 bhaskara systemd[1]: Stopped /dev/dm-5.
> > janv. 09 19:26:12 bhaskara systemd[1]: Stopped
> > /sys/devices/virtual/block/dm-5.
> > janv. 09 19:26:12 bhaskara blkdeactivate[10933]:   [DM]: deactivating
> > crypt device luks-63be2188-bd3d-4552-9a8b-9481d942fb46 (dm-5)... done
> > janv. 09 19:26:12 bhaskara kernel: md122: detected capacity change from
> > 42951770112 to 0
> > janv. 09 19:26:12 bhaskara kernel: md: md122 stopped.
> > janv. 09 19:26:12 bhaskara kernel: md: unbind<sdb2>
> > janv. 09 19:26:12 bhaskara kernel: md: export_rdev(sdb2)
> > janv. 09 19:26:12 bhaskara kernel: md: unbind<sda2>
> > janv. 09 19:26:12 bhaskara kernel: md: export_rdev(sda2)
> > janv. 09 19:26:12 bhaskara kernel: BUG: unable to handle kernel paging
> > request at ffff8f3f29ea8000
>  
>  OK well it's a kernel bug, seems like to me. The simplest thing to do
>  is try a different kernel. But which one? I'm not seeing immediately
>  relevant patches for md in either 4.8.16 or 4.8.17. What kernel
>  version are you using now? If it's 4.18.15, sure you can try either
>  4.18.16 (which is in updates-testing) or you can get 4.8.17 from koji.
>  Looks like 4.9.2 is building now in koji and should be done shortly so
>  you could also try that one. 
I use 4.8.15 and 4.8.16 is not yet in the update reposirory.

>  
>  If it reproduces with 4.9.2, for sure you should try to get more
>  information. If you can ssh into the system remotely so you can get a
>  complete dmesg that'd be useful. If ssh gets killed off before the
>  bug, then you might see if any of these ideas will get you more
>  information on the nature of the failure.
>  
>  https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1 
This bug appears randomly: today, I could shutdown my machine normaly
(almost normaly: sysstemd try to write on journactl while /var is
unmounted.... for instance).

I don't undersstand why these things are going backward: I have a fedora
21 install which boot and shutdown without problems and systemd is
running on this machine.


-- 
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. [phone]
http://www.math-info.univ-paris5.fr/~patte

[Chris Murphy]

On Tue, Jan 10, 2017 at 2:45 PM, François Patte
<francois.patte(a)mi.parisdescartes.fr&gt; wrote:
>  Le 10/01/2017 05:44, Chris Murphy a écrit :
> > On Mon, Jan 9, 2017 at 11:54 AM, François Patte
> > <francois.patte(a)mi.parisdescartes.fr&gt; wrote:
> >
> >> janv. 09 19:26:12 bhaskara systemd[1]: Stopped /dev/dm-5.
> >> janv. 09 19:26:12 bhaskara systemd[1]: Stopped
> >> /sys/devices/virtual/block/dm-5.
> >> janv. 09 19:26:12 bhaskara blkdeactivate[10933]:   [DM]: deactivating
> >> crypt device luks-63be2188-bd3d-4552-9a8b-9481d942fb46 (dm-5)... done
> >> janv. 09 19:26:12 bhaskara kernel: md122: detected capacity change from
> >> 42951770112 to 0
> >> janv. 09 19:26:12 bhaskara kernel: md: md122 stopped.
> >> janv. 09 19:26:12 bhaskara kernel: md: unbind<sdb2>
> >> janv. 09 19:26:12 bhaskara kernel: md: export_rdev(sdb2)
> >> janv. 09 19:26:12 bhaskara kernel: md: unbind<sda2>
> >> janv. 09 19:26:12 bhaskara kernel: md: export_rdev(sda2)
> >> janv. 09 19:26:12 bhaskara kernel: BUG: unable to handle kernel paging
> >> request at ffff8f3f29ea8000
> >
> > OK well it's a kernel bug, seems like to me. The simplest thing to do
> > is try a different kernel. But which one? I'm not seeing immediately
> > relevant patches for md in either 4.8.16 or 4.8.17. What kernel
> > version are you using now? If it's 4.18.15, sure you can try either
> > 4.18.16 (which is in updates-testing) or you can get 4.8.17 from koji.
> > Looks like 4.9.2 is building now in koji and should be done shortly so
> > you could also try that one.
>
>  I use 4.8.15 and 4.8.16 is not yet in the update reposirory.
>
> >
> > If it reproduces with 4.9.2, for sure you should try to get more
> > information. If you can ssh into the system remotely so you can get a
> > complete dmesg that'd be useful. If ssh gets killed off before the
> > bug, then you might see if any of these ideas will get you more
> > information on the nature of the failure.
> >
> > https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1
>
>  This bug appears randomly: today, I could shutdown my machine normaly
>  (almost normaly: sysstemd try to write on journactl while /var is
>  unmounted.... for instance).
>
>  I don't undersstand why these things are going backward: I have a fedora
>  21 install which boot and shutdown without problems and systemd is
>  running on this machine. 
This class of bug is called a regression. They're extremely common.
And Fedora having generally newer packages, is inevitably going to get
hit with some portion of these. Par for the course.


-- 
Chris Murphy