http://bugzilla.opensuse.org/show_bug.cgi?id=1200461 http://bugzilla.opensuse.org/show_bug.cgi?id=1200461#c23 --- Comment #23 from Mike DeMicco <mfdemicco@gmail.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.