[SOLVED] regression -current with kernels 5.14.0/1 and lvm2

ceed · 09-05-2021, 10:03 AM

system: slackware 32bit -current
[edit] generic-smp kernel

Code:

lsblk:
NAME              MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda                 8:0    0 931.5G  0 disk
├─sda1              8:1    0   200M  0 part /boot
└─sda2              8:2    0 931.3G  0 part
  ├─slacklvm-root 253:0    0    50G  0 lvm  /
  ├─slacklvm-swap 253:1    0     4G  0 lvm
  └─slacklvm-home 253:2    0   500G  0 lvm  /home
sr0                11:0    1  1024M  0 rom
zram0             252:0    0     2G  0 disk [SWAP]

On shutdown or reboot system hangs at:

Code:

Unmounting local filesystems:
...
Remounting root filesystem read-only:
mount: /dev/mapper/slacklvm-root mounted on /.
Deactivating LVM volume groups:
  Logical volume slacklvm/root contains a filesystem in use.
  Can't deactivate volume group "slacklvm" with 1 open logical volume(s)

While the message (not sure if exactly the same) has always appeared, the machine has nevertheless gone on to either reboot or shutdown. The machine now simply hangs requiring either an alt+sysreq or hard shutdown.

It may of course be something other than the recent kernels causing this; however, the kernels are the closest I can narrow down to.

Thanks.

marav · 09-06-2021, 03:16 AM

According to the changelogs :

https://cdn.kernel.org/pub/linux/ker...ChangeLog-5.14

https://cdn.kernel.org/pub/linux/ker...angeLog-5.14.1

There has been no change regarding LVM

Richard Cranium · 09-06-2021, 04:12 AM

This won't help, but I've had no problems with the 64bit versions. (I use LVM on top of RAID, in case that's an even more different use case than the -64 verses -32 bit difference).

marav · 09-06-2021, 04:36 AM

Quote:

Originally Posted by Richard Cranium

This won't help

Of course, this doesn't solve the problem
But my POV is that, to find a culprit, eliminating a possibility always helps...

ceed · 09-06-2021, 08:26 AM

Thank you both for your input. I greatly appreciate it.

UPDATE: Tonight I had the time to revert to the 5.13.13-generic-smp* kernel, the result being the systems behaving as per usual -- i.e. it shuts down and reboots despite the usual warning reproduced in the code above.

I think it is fair to conclude that the culprit is definitely kernel based, perhaps specific to 32bit or even smp. At this point I think I'll just content myself with using 5.13.13 and keep an eye on future developments.

* apologies I ought to have mentioned it being the generic-smp kernel initially.

marav · 09-06-2021, 08:59 AM

Quote:

Originally Posted by ceed

Thank you both for your input. I greatly appreciate it.

UPDATE: Tonight I had the time to revert to the 5.13.13-generic-smp* kernel, the result being the systems behaving as per usual -- i.e. it shuts down and reboots despite the usual warning reproduced in the code above.

I think it is fair to conclude that the culprit is definitely kernel based, perhaps specific to 32bit or even smp. At this point I think I'll just content myself with using 5.13.13 and keep an eye on future developments.

* apologies I ought to have mentioned it being the generic-smp kernel initially.

This message :

Quote:

Unmounting local filesystems:
...
Remounting root filesystem read-only:
mount: /dev/mapper/slacklvm-root mounted on /.
Deactivating LVM volume groups:
Logical volume slacklvm/root contains a filesystem in use.
Can't deactivate volume group "slacklvm" with 1 open logical volume(s)

Will be always there, because when your system reboots or shuts down one of the last tasks is to unmount all of the volumes to avoid data loss.
In the case of LVM this is impossible becausee the "/" is still in use,
so you will receive this warning, no matter which kernel you use

The truth is out there

ceed · 12-04-2021, 05:19 AM

Well it seems patience has paid off!

As of the latest Slackware kernel 5.15.6-smp, my machine is shutting down and rebooting sans magic sysreq intervention.

I couldn't find any mention of a change concerning LVM2 in the changelogs for 5.15.5 or 5.15.6 so I am no closer to an explanation as when the problem first appeared. The nice thing is that I can now reboot over ssh after kernel upgrades now, which I do have occasion to do now and again. Yay!

Thought this may be of general interest. I can now mark this as solved