You are not logged in.
I have a loop when I shutdown or reboot with this message
block device autoloading is deprecated and will be removed
I found this patch... Is there a possibility that Arch Linux Maintainers change this flag or have a I implement the second patch by hand for my kernel?
https://www.spinics.net/lists/linux-block/msg80356.html
Is this patch ok or is there a other way?
thx
Last edited by Morta (2022-09-02 13:20:00)
Offline
With LTS Kernel works
Offline
The commit you referenced setting the default for BLOCK_LEGACY_AUTOLOAD to y has been applied since 5.18 https://github.com/torvalds/linux/commi … b71f6d7875
Arch disabled BLOCK_LEGACY_AUTOLOAD for 5.18 which broke mdraid so was re-enabled in https://github.com/archlinux/svntogit-p … 5ceec985de
Edit:
I should note that BLOCK_LEGACY_AUTOLOAD still has the default set to y as of 6.0-rc3.
Last edited by loqs (2022-09-02 18:57:53)
Offline
On Linux 5.19.6-arch1-1 #1 error still occurs. any advice to fix it?
Last edited by rokku (2022-09-04 23:17:11)
Offline
There is no error, ignore it.
Offline
But my system stuck in a loop and does not shutdown. i have to use the reset switch.
Offline
But my system stuck in a loop and does not shutdown. i have to use the reset switch.
You could build a kernel with BLOCK_LEGACY_AUTOLOAD unset.
I doubt it would fix your shutdown issue. If the udev rules has not been fixed then you may have a new issue on booting.
Offline
A no framebuffer patch and set to BLOCK_LEGACY_AUTOLOAD=n fix the issue. Hope for a solution soon!
Offline
Is there a way to not use deprecated autoloading while setting up an encrypted raid1 with mdadm and cryptsetup?
With boot partition (luks1) and root (luks2) being encrypted.
Last edited by leomeinel (2022-09-07 10:41:01)
Offline
Yes I use RAID 0 with mdadm and it’s works described above
Offline
Yes I use RAID 0 with mdadm and it’s works described above
Okay, thats nice. However it is just a way to suppress the error that doesn't fix the underlying problem.
At least if you consider the deprecated feature to be the problem.
Last edited by leomeinel (2022-09-07 13:46:53)
Offline
This is now solved with linux 5.19.8.arch1-1 and linux-zen 5.19.8.zen1-1 probably also with the lts and hardened
Offline
CONFIG_BLOCK_LEGACY_AUTOLOAD=y is still set in the config https://github.com/archlinux/svntogit-p … onfig#L912
The warning message is still present https://github.com/archlinux/linux/blob … dev.c#L748
Offline
@loqs I can confirm. My last conclusion was wrong. The shutdown was just faster but the error messages are still present!
Offline
I can not see how the message could be connected to a loop on shutdown or reboot. What exactly do you mean by loop? Please post the journal for a shutdown or reboot showing the issue.
Offline
https://abload.de/img/auswahl_03493d14.png
looks like this in a endless queue. In journalctl -b I can't find anything but I can put to ix.io
[morta@5erver ~]$ sudo journalctl -b | curl -F 'f:1=<-' ix.io
Offline
Anyone?
Offline
Anyone?
Don't do that. https://wiki.archlinux.org/title/Genera … es#Bumping
Looking at your post history, you have been asked not to bump at least once before. Do not do this again.
Offline
From the screenshot something late in shutdown is calling a mount related call repeatedly and every call triggers the deprecation warning until the kernel's rate limit is reached. The shutdown itself seems very slow / blocked.
https://freedesktop.org/wiki/Software/s … wnproblems
Offline
sudo reboot —force works but I have a NFS Drive mounted and two LVM Raid 0
Offline
If you unmount the NFS mount before shutdown or avoid ever mounting it at boot is there any change? If not repeat for the LVM mount. Still no change see my link in post #19 and post the contents of shutdown-log.txt
Offline
cat /shutdown-log.txt | curl -F 'f:1=<-' ix.io
Seems to working again but here my shutdown-log.txt
Offline
I have a similar issue on my workstation, whose storage I recently upgraded from a single SSD to two SSDs in RAID-0.
When I shut down the system, it also prints a lot of those deprecation warnings.
However, the system will shut down eventually. This takes roughly between 30 sec to 5 minutes, apparently dependent on the constellation of the stars.
Inofficial first vice president of the Rust Evangelism Strike Force
Offline