Arch Linux

mdcclxv

Member

Registered: 2022-04-26

Posts: 207

[SOLVED] [SORT OF] Unable to shutdown cleanly

Hi all,

For the last month or so, I've been unable to cleanly shutdown my system. Almost every time I perform a shutdown or a restart I get the message block bellow, in an infinite loop, and I have to shutdown the machine by keeping the power button pressed for 4 seconds.

blkdev_get_no_open: 103 callbacks suppresed
blockdevice autoloading is deprecated and will be removed
blockdevice autoloading is deprecated and will be removed
blockdevice autoloading is deprecated and will be removed
blockdevice autoloading is deprecated and will be removed
blockdevice autoloading is deprecated and will be removed
blockdevice autoloading is deprecated and will be removed
blockdevice autoloading is deprecated and will be removed

The "103" count varies from one loop to another.

Searching and navigating via several links I found this article that points me to renaming the mdadm.conf references to my RAID devices.

https://bbs.archlinux.org/viewtopic.php?id=276716 Post #16

Check your mdadm.conf definitions vs your actual /dev/mdXXX devices. My mdadm.conf was referencing a link for the device specification in the ARRAY line for the RAID10 array. I replaced this with a direct reference to the device .. changing something like this:
ARRAY /dev/userraid10  metadata=1.2 name=phenom:UserRAID10 UUID=bee9ca99:c9a86e5e:0d3e9c1a:c5473a21
to look like this:
ARRAY /dev/md127  metadata=1.2 name=phenom:UserRAID10 UUID=bee9ca99:c9a86e5e:0d3e9c1a:c5473a21

This is what I have in my mdamd.conf:

ARRAY /dev/md/3 metadata=1.2 name=archiso:3 UUID=d39fa2ee:195afe21:ab4f8432:13d14741
ARRAY /dev/md/4 metadata=1.2 name=archiso:4 UUID=df84c06b:02376a95:6e747c9c:f79e239a
ARRAY /dev/md/2 metadata=1.2 name=archiso:2 UUID=cde6eed0:01531240:74d7f739:c305a67b

This is the output of lsblk:

NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme1n1     259:0    0 232.9G  0 disk  
├─nvme1n1p1 259:2    0   500M  0 part  
├─nvme1n1p2 259:3    0    16G  0 part  
│ └─md2       9:2    0    32G  0 raid0 
├─nvme1n1p3 259:4    0    50G  0 part  
│ └─md3       9:3    0  99.9G  0 raid0 /
└─nvme1n1p4 259:5    0 166.4G  0 part  
  └─md4       9:4    0 332.5G  0 raid0 /zork
nvme0n1     259:1    0 232.9G  0 disk  
├─nvme0n1p1 259:6    0   500M  0 part  /boot
├─nvme0n1p2 259:7    0    16G  0 part  
│ └─md2       9:2    0    32G  0 raid0 
├─nvme0n1p3 259:8    0    50G  0 part  
│ └─md3       9:3    0  99.9G  0 raid0 /
└─nvme0n1p4 259:9    0 166.4G  0 part  
  └─md4       9:4    0 332.5G  0 raid0 /zork

This is output of ls /dev/md* :

/dev/md2  /dev/md3  /dev/md4

So, am I supposed to change my mdadm.conf lines from

/dev/md/1

to

/dev/md1

?
I'm asking this because I'm afraid of making my system unbootable.

Thanks in advance.

Last edited by mdcclxv (2022-09-04 00:24:23)

jasonwryan

Anarchist

From: .nz

Registered: 2009-05-09

Posts: 30,426

Website

Re: [SOLVED] [SORT OF] Unable to shutdown cleanly

Use the name(s) in /proc/mdstat.

And it's no big deal if the system doesn't boot: it is simple enough to fix from a chroot.

---

Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

mdcclxv

Member

Registered: 2022-04-26

Posts: 207

Re: [SOLVED] [SORT OF] Unable to shutdown cleanly

Ok, so changing the mdadm names from md/1 to md1 didn't crash my system, but didn't help either. I'm still getting those nasty deprecation messages. I'm at a loss.

timax

Member

Registered: 2022-08-31

Posts: 1

Re: [SOLVED] [SORT OF] Unable to shutdown cleanly

I found this, Fedora issue but seems to be related.
https://www.spinics.net/lists/linux-block/msg88418.html
Also, take a look at "more details" links while you at it.

mdcclxv

Member

Registered: 2022-04-26

Posts: 207

Re: [SOLVED] [SORT OF] Unable to shutdown cleanly

I found this, Fedora issue but seems to be related.
https://www.spinics.net/lists/linux-block/msg88418.html
Also, take a look at "more details" links while you at it.

You rock!

I don't I'm definitely not on the level of patching and recompiling a kernel. So I guess I'll have to wait for a kernel upgrade that gets it fixed. At least there is a light at the end of the tunnel since responsible people do know about and are actively working on the issue.

Thanks for the effort.

Last edited by mdcclxv (2022-08-31 12:00:39)