Comment # 23
on bug 1200461
from Mike DeMicco
(In reply to Thomas Blume from comment #22)
> (In reply to Mike DeMicco from comment #21)
> > No, the problem was/is that somehow, multipath was turned on and os-prober
> > is not compatible with it. This is described in Bug 1097203, but
> > unfortunately, that bug was closed without resolving the incompatibility
> > with os-prober! That bug should either be reopened or a new one created.
> > Anyhow, I chrooted in and turned off multipath so os-prober works again. I'm
> > unsure if I inadvertently turned on multipath by messing with the kernel
> > commandline commands, or if installation of the new kernel caused it.
> >
> > I'm venting here but I've had a good experience with Tumbleweed for a number
> > of years, but currently am running into a number of bugs with it. One other
> > issue, I locked my old working kernel in zypper, but installation of a new
> > kernel deleted it. I don't think that should have happened.
> >
> > Incidentally, the problem with the "udevadm info -a" command is not unique
> > to OpenSuse. It occurs in Arch and Debian on my system too, but I don't have
> > issues with it on those systems because dracut is not being used and maybe
> > the dracut.sh script they use doesn't invoke it.
>
> Ok, so obviously, the udevadm commands in os-prober work, though it also
> gets executed as root.
> Are your Arch and Debian installations on the same machine like Tumbleweed?
> If so, the culprit might be hardware related.
> At least I cannot reproduce a system hang when executing udevadm info -a on
> any of my testmachines.
Yes, they are on the same extended partition:
Disk /dev/sdb: 931.51 GiB, 1000200658432 bytes, 1953516911 sectors
Disk model: Samsung SSD 860
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5a440a1e
Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 2048 204802047 204800000 97.7G 7 HPFS/NTFS/exFAT
/dev/sdb2 204804094 1091614719 886810626 422.9G 5 Extended
/dev/sdb5 204804096 221188095 16384000 7.8G 82 Linux swap / Solaris
/dev/sdb6 221190144 323592191 102402048 48.8G 83 Linux
/dev/sdb7 323594240 425996287 102402048 48.8G 83 Linux
/dev/sdb8 477200384 579600383 102400000 48.8G 83 Linux
/dev/sdb9 630806528 733206527 102400000 48.8G 83 Linux
/dev/sdb10 784412672 886814719 102402048 48.8G 83 Linux
/dev/sdb11 579602432 630804479 51202048 24.4G 83 Linux
/dev/sdb12 425998336 477198335 51200000 24.4G 83 Linux
/dev/sdb13 733210624 784410623 51200000 24.4G 83 Linux
/dev/sdb14 886816768 989214719 102397952 48.8G 83 Linux
/dev/sdb15 989216768 1091614719 102397952 48.8G 83 Linux
Partition table entries are not in disk order.
There probably is some incompatibility with my hardware, as I can't find others
having this problem. (In reply to Thomas Blume from comment #22)
> (In reply to Mike DeMicco from comment #21)
> > No, the problem was/is that somehow, multipath was turned on and os-prober
> > is not compatible with it. This is described in Bug 1097203, but
> > unfortunately, that bug was closed without resolving the incompatibility
> > with os-prober! That bug should either be reopened or a new one created.
> > Anyhow, I chrooted in and turned off multipath so os-prober works again. I'm
> > unsure if I inadvertently turned on multipath by messing with the kernel
> > commandline commands, or if installation of the new kernel caused it.
> >
> > I'm venting here but I've had a good experience with Tumbleweed for a number
> > of years, but currently am running into a number of bugs with it. One other
> > issue, I locked my old working kernel in zypper, but installation of a new
> > kernel deleted it. I don't think that should have happened.
> >
> > Incidentally, the problem with the "udevadm info -a" command is not unique
> > to OpenSuse. It occurs in Arch and Debian on my system too, but I don't have
> > issues with it on those systems because dracut is not being used and maybe
> > the dracut.sh script they use doesn't invoke it.
>
> Ok, so obviously, the udevadm commands in os-prober work, though it also
> gets executed as root.
> Are your Arch and Debian installations on the same machine like Tumbleweed?
> If so, the culprit might be hardware related.
> At least I cannot reproduce a system hang when executing udevadm info -a on
> any of my testmachines.
Yes, Arch and Debian are both on the same extended partition:
Disk /dev/sdb: 931.51 GiB, 1000200658432 bytes, 1953516911 sectors
Disk model: Samsung SSD 860
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5a440a1e
Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 2048 204802047 204800000 97.7G 7 HPFS/NTFS/exFAT
/dev/sdb2 204804094 1091614719 886810626 422.9G 5 Extended
/dev/sdb5 204804096 221188095 16384000 7.8G 82 Linux swap / Solaris
/dev/sdb6 221190144 323592191 102402048 48.8G 83 Linux
/dev/sdb7 323594240 425996287 102402048 48.8G 83 Linux
/dev/sdb8 477200384 579600383 102400000 48.8G 83 Linux
/dev/sdb9 630806528 733206527 102400000 48.8G 83 Linux
/dev/sdb10 784412672 886814719 102402048 48.8G 83 Linux
/dev/sdb11 579602432 630804479 51202048 24.4G 83 Linux
/dev/sdb12 425998336 477198335 51200000 24.4G 83 Linux
/dev/sdb13 733210624 784410623 51200000 24.4G 83 Linux
/dev/sdb14 886816768 989214719 102397952 48.8G 83 Linux
/dev/sdb15 989216768 1091614719 102397952 48.8G 83 Linux
Partition table entries are not in disk order.
There probably is some incompatibility with my hardware. I do believe the
computer is functioning properly as I've not had any other problems other than
this issue.
As mentioned above, I tried generating a new initrd with my old kernel, and got
the system freeze too.