|
Bugzilla – Full Text Bug Listing |
| Summary: | YaST2-Bootloader complains "Unknown udev device" then crashes. | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Bruno Pesavento <mail> |
| Component: | YaST2 | Assignee: | Josef Reidinger <jreidinger> |
| Status: | RESOLVED FIXED | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | ancor, anonimo.oculto, conde.philippe, devin, forgotten_Jn-cEY2O8q, forgotten_nAoIgPHvoE, forgotten_SyAnLjn-Km, forgotten_TerRWwXMnx, forgotten_TzAsMPeZbK, hare, hdf3, jreidinger, ke, lmuelle, mail, rmilasan, simonf.lees, thomas.blume, werner |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | SUSE Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
yast2-log and udev information
Yast2-log look for "2015-10-09 17:28:54" Bootloader update log: look at lines 4863 - 4914 - 5018 udevadm info -e for the ATA subsystem use-ID_WWN-without-extension.patch YaST log |
||
Please, attach full yast logs, not only those 2 lines. Created attachment 651137 [details]
Yast2-log look for "2015-10-09 17:28:54"
Sorry, didn't look through the whole log.
Please search for "2015-10-09 17:28:54" to find the offfending lines.
Josef, please, check this bugreport. sound a bit familiar, I think there is some problem with udev names for wwn...I check a bit history if I found original one. It is quite strange as in logs I see only once this wn device and it is mentioned as boot_custom, so it means, that bootloader cannot pair it with existing, device. How do you install your system? Also complete logs especially from installation can help to detect if in installation time device is present. In current system it looks like offending partition is not used even for root. Created attachment 651255 [details]
Bootloader update log: look at lines 4863 - 4914 - 5018
Maybe I've spotted the origin of the problem. See the attached perl-BL-standalone-log.
At line 4863: lrwxrwxrwx 1 root root 10 Jul 25 20:16 wwn-0x50025388a064af10-part3 -> ../../sda3
the offending partition is still identified by its wwn.
At line 5018: lrwxrwxrwx 1 root root 10 Jul 31 00:16 scsi-SATA_Samsung_SSD_840_S1DBNSBF844694B-part3 -> ../../sda3
or the following, there are no more wwn- identifiers.
In-between is line 4914: bootloader_entry was called as: add desktop 4.1.3-1-desktop vmlinuz-4.1.3-1-desktop initrd-4.1.3-1-desktop
a bootloader update, likely the result of a routine "zypper dup" involving a new kernel.
The next wwn- is at line 6433: a new DVD drive, nothing to do with the problem at hand.
If this is only my own corner case, close the bug report and I'll live with it till the next clean install.
If this is of more general interest, I'm ready to help chasing it down.
OK, so udev persistent link dispappeared. Systemd maintainers I think that wwn devices sounds familiar for me, so known issue or dup? (In reply to Josef Reidinger from comment #7) No ... in short if the device disappears then the link disappears. Why do you think this is a udev/systemd problem, the bug number please? There is no change log entry accordingly to wwn nor any patch around. (In reply to Dr. Werner Fink from comment #8) > (In reply to Josef Reidinger from comment #7) > > No ... in short if the device disappears then the link disappears. Why do > you think this is a udev/systemd problem, the bug number please? There is > no change log entry accordingly to wwn nor any patch around. In general problem is not that device disappeared. PRoblem is that in past device wwn-0x50025388a064af10-part3 points to ../../sda3,, but later such device do not exists at all, so udev do not create it anymore. So reason why I think it is udev problem is that persistent device is not persistent. I cannot find bug number, but my memory say that wwn device I already see in similar issue, but cannot find it. So it is just question for you. This could be due to changes to sg3_utils. Blaming udev wont help. There is a lot of rules which are not part of udev itself and an update on those rules, can lead to changes or issue.
In latest openSUSE's a lot of the 'device' links in /dev/disk/{by-id,by-path} are generated by sg3_utils rules not udev rules (they are of course rules for udev, but don't come with systemd/udev).
This is not 100%, but could be.
(In reply to Josef Reidinger from comment #9) Sorry, but my crystal ball is currently beamless :) Please be more specific AFAICS from a search the bug #909561 and do passing mentioned wwn only bug #913515 seems to have the simliar problem and no feedback (In reply to Dr. Werner Fink from comment #11) > (In reply to Josef Reidinger from comment #9) > > Sorry, but my crystal ball is currently beamless :) > Please be more specific > > AFAICS from a search the bug #909561 and do passing mentioned wwn > only bug #913515 seems to have the simliar problem and no feedback I'd blame these rules from /usr/lib/udev/rules.d/55-scsi-sg3_id.rules: # ID_WWN compat mapping ENV{SCSI_IDENT_LUN_NAA_REGEXT}=="?*", ENV{ID_WWN}!="?*", ENV{ID_WWN}="0x$env{SCSI_IDENT_LUN_NAA_REGEXT}" ENV{SCSI_IDENT_LUN_NAA_REG}=="?*", ENV{ID_WWN}!="?*", ENV{ID_WWN}="0x$env{SCSI_IDENT_LUN_NAA_REG}" ENV{SCSI_IDENT_LUN_NAA_EXT}=="?*", ENV{ID_WWN}!="?*", ENV{ID_WWN}="0x$env{SCSI_IDENT_LUN_NAA_EXT}" ENV{SCSI_IDENT_LUN_NAA_LOCAL}=="?*", ENV{ID_WWN}!="?*", ENV{ID_WWN}="0x$env{SCSI_IDENT_LUN_NAA_LOCAL}" ENV{SCSI_IDENT_LUN_NAA_REGEXT}=="?*", ENV{ID_WWN_WITH_EXTENSION}!="?*", ENV{ID_WWN_WITH_EXTENSION}="0x$env{SCSI_IDENT_LUN_NAA_REGEXT}" ENV{SCSI_IDENT_LUN_NAA_EXT}=="?*", ENV{ID_WWN_WITH_EXTENSION}!="?*", ENV{ID_WWN_WITH_EXTENSION}="0x$env{SCSI_IDENT_LUN_NAA_EXT}" A test shows that the above SCSI_IDENT_LUN_NAA* information are filled via: /usr/bin/sg_inq --export --page=di /dev/sdX (X is the letter of the disc). Later ID_WWN is used in 60-persistent-storage.rules to create the symlinks. Can you provide the output of: /usr/bin/sg_inq --export --page=di /dev/sda and: udevadm info -e ? Created attachment 651345 [details]
udevadm info -e for the ATA subsystem
SCSI_IDENT_LUN_NAA_REG=50025388a064af10 seems correct (line 461)
but the DEVLINKS=/dev/disk/by-id/wwn-* is missing from line 420.
According to logs, the problem first appeared on July 31st, seemingly after a "zypper dup" that should have involved Tumbleweed snapshots # 20150725, 20150727 and 20150728. The only relevant entry I see in the changelogs of those snapshots is in Changes.20150725.txt: ==== yast2-storage ==== Version update (3.1.63 -> 3.1.64) - Added NoCoW subvolume for /var/lib/libvirt/images (Fate#319299) - 3.1.64 Hope this helps. (In reply to Thomas Blume from comment #12) > (In reply to Dr. Werner Fink from comment #11) > > (In reply to Josef Reidinger from comment #9) > > > > Sorry, but my crystal ball is currently beamless :) > > Please be more specific > > > > AFAICS from a search the bug #909561 and do passing mentioned wwn > > only bug #913515 seems to have the simliar problem and no feedback > > I'd blame these rules from /usr/lib/udev/rules.d/55-scsi-sg3_id.rules: > > # ID_WWN compat mapping > ENV{SCSI_IDENT_LUN_NAA_REGEXT}=="?*", ENV{ID_WWN}!="?*", > ENV{ID_WWN}="0x$env{SCSI_IDENT_LUN_NAA_REGEXT}" > ENV{SCSI_IDENT_LUN_NAA_REG}=="?*", ENV{ID_WWN}!="?*", > ENV{ID_WWN}="0x$env{SCSI_IDENT_LUN_NAA_REG}" > ENV{SCSI_IDENT_LUN_NAA_EXT}=="?*", ENV{ID_WWN}!="?*", > ENV{ID_WWN}="0x$env{SCSI_IDENT_LUN_NAA_EXT}" > ENV{SCSI_IDENT_LUN_NAA_LOCAL}=="?*", ENV{ID_WWN}!="?*", > ENV{ID_WWN}="0x$env{SCSI_IDENT_LUN_NAA_LOCAL}" > ENV{SCSI_IDENT_LUN_NAA_REGEXT}=="?*", ENV{ID_WWN_WITH_EXTENSION}!="?*", > ENV{ID_WWN_WITH_EXTENSION}="0x$env{SCSI_IDENT_LUN_NAA_REGEXT}" > ENV{SCSI_IDENT_LUN_NAA_EXT}=="?*", ENV{ID_WWN_WITH_EXTENSION}!="?*", > ENV{ID_WWN_WITH_EXTENSION}="0x$env{SCSI_IDENT_LUN_NAA_EXT}" > > A test shows that the above SCSI_IDENT_LUN_NAA* information are filled via: > > /usr/bin/sg_inq --export --page=di /dev/sdX > > (X is the letter of the disc). > > Later ID_WWN is used in 60-persistent-storage.rules to create the symlinks. > > Can you provide the output of: > > /usr/bin/sg_inq --export --page=di /dev/sda > > and: > > udevadm info -e > > ? I double checked and sg3_utils 1.41-1.1 was installed on 20150725 at 20:56:24. The last correct wwn-* entries in the Bootloader update log are marked "Jul 25 20:16". Maybe those entries were the last ones made using the old version? And when the new version was first called the problem appeared? If so, the bug might hide in the updated 55-scsi-sg3_id.rules or 58-scsi-sg3_symlink.rules (In reply to Bruno Pesavento from comment #15) > > ? > > I double checked and sg3_utils 1.41-1.1 was installed on 20150725 at > 20:56:24. > The last correct wwn-* entries in the Bootloader update log are marked "Jul > 25 20:16". > Maybe those entries were the last ones made using the old version? > And when the new version was first called the problem appeared? > If so, the bug might hide in the updated 55-scsi-sg3_id.rules or > 58-scsi-sg3_symlink.rules The wwn symlink is not created, because ID_WWN_WITH_EXTENSION was not created. It would have been created if SCSI_IDENT_LUN_NAA_REGEXT exists: /usr/lib/udev/rules.d/55-scsi-sg3_id.rules:ENV{SCSI_IDENT_LUN_NAA_REGEXT}=="?*", ENV{ID_WWN_WITH_EXTENSION}!="?*", ENV{ID_WWN_WITH_EXTENSION}="0x$env{SCSI_IDENT_LUN_NAA_REGEXT}" /usr/lib/udev/rules.d/55-scsi-sg3_id.rules:ENV{SCSI_IDENT_LUN_NAA_EXT}=="?*", ENV{ID_WWN_WITH_EXTENSION}!="?*", ENV{ID_WWN_WITH_EXTENSION}="0x$env{SCSI_IDENT_LUN_NAA_EXT}" But we only have SCSI_IDENT_LUN_NAA_REG for sda. You can see it by comparing the udev information between sr0 (where this works) and sda. Due to the missing ID_WWN_WITH_EXTENSION, this rule isn't executed: -->-- rules.d/60-persistent-storage.rules:ENV{DEVTYPE}=="disk", ENV{ID_WWN_WITH_EXTENSION}=="?*", SYMLINK+="disk/by-id/wwn-$env{ID_WWN_WITH_EXTENSION}" rules.d/60-persistent-storage.rules:ENV{DEVTYPE}=="partition", ENV{ID_WWN_WITH_EXTENSION}=="?*", SYMLINK+="disk/by-id/wwn-$env{ID_WWN_WITH_EXTENSION}-part%n" --<-- I wondering why ID_WWN isn't used directly to create a wwn symlink. Going to check how this was different in the former sg3_utils/udev version. The commit that removed the direct usage of ID_WWN is here: http://people.freedesktop.org/~david/0001-Export-ID_WWN_VENDOR_EXTENSION-and-ID_WWN_WITH_EXTEN.patch With this patch, scsi_id and ata_id are supposed to provide ID_WWN_WITH_EXTENSION instread. They do on my test machine: # /usr/lib/udev/scsi_id --whitelisted --export -d /dev/sda | grep WWN ID_WWN=0x5000c50065f76fd4 ID_WWN_WITH_EXTENSION=0x5000c50065f76fd4 # /usr/lib/udev/ata_id --export /dev/sda | grep WWN ID_WWN=0x5000c50065f76fd4 ID_WWN_WITH_EXTENSION=0x5000c50065f76fd4 Still the udev database doesn't show ID_WWN_WITH_EXTENSION for /dev/sda: # udevadm info -q property /dev/sda | grep WWN ID_WWN=0x5000c50065f76fd4 Robert, it seems that the IMPORT rule for ata_id and scsi_id in usr/lib/udev/rules.d/60-persistent-storage.rules is too restrictive. It is only executed if there is no ID_SERIAL: -->-- # ATA KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*", SUBSYSTEMS=="scsi", ATTRS{vendor}=="ATA", IMPORT{program}="ata_id --export $dev node" KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*", IMPORT{program}="scsi_id --export --whitelisted -d $devnode", ENV{ID_BUS}="scsi" --<-- I guess therefore, ID_WWN_WITH_EXTENSION isn't present. still, I'm wondering how this had worked before. These rules seem to be there for a long time. Any idea? At first glance no, I have no idea. BTW, ID_WWN_WITH_EXTENSION never existed, so there was no need for it. Possible the commit which you pointed out has introduced a regression. Why is ID_SERIAL a problem? BTW, on my machine, everything works as expected, so maybe the issues is someplace? robert@coolcat:/usr/lib/udev/rules.d> sudo /usr/lib/udev/scsi_id --whitelisted --export -d /dev/sda | grep WWN ID_WWN=0x50026b725501876e ID_WWN_WITH_EXTENSION=0x50026b725501876e robert@coolcat:/usr/lib/udev/rules.d> udevadm info -q property /dev/sda | grep WWN ID_WWN=0x50026b725501876e ID_WWN_WITH_EXTENSION=0x50026b725501876e robert@coolcat:/usr/lib/udev/rules.d> Another question here is: why should it be a ID_SERIAL? from here? (In reply to Robert Milasan from comment #20) > Another question here is: why should it be a ID_SERIAL? from here? I'm just trying to understand why ID_WWN_WITH_EXTENSION isn't present in the udev database whereas it is provided by scsi/ata_id. I've concluded that there must be a problem with importing the keys from scsi/ata_id. ID_SERIAL is present on my machine, so the condition: ENV{ID_SERIAL}!="?*" should fail, which would skip the import. Concerning your machine, there is another rule that fills ID_WWN_WITH_EXTENSION from the sq_inq output (55-scsi-sg3_id.rules): -->-- ENV{SCSI_IDENT_LUN_NAA_REGEXT}=="?*", ENV{ID_WWN_WITH_EXTENSION}!="?*", ENV{ID_WWN_WITH_EXTENSION}="0x$env{SCSI_IDENT_LUN_NAA_REGEXT}" ENV{SCSI_IDENT_LUN_NAA_EXT}=="?*", ENV{ID_WWN_WITH_EXTENSION}!="?*", ENV{ID_WWN_WITH_EXTENSION}="0x$env{SCSI_IDENT_LUN_NAA_EXT}" --<-- But SCSI_IDENT_LUN_NAA_EXT* isn't present on my machine either: # /usr/bin/sg_inq --export --page=di /dev/sda | grep SCSI_IDENT_LUN_NAA_EXT # Maybe it is present on your machine, and therefore it works for you? (In reply to Thomas Blume from comment #21) > But SCSI_IDENT_LUN_NAA_EXT* isn't present on my machine either: > > # /usr/bin/sg_inq --export --page=di /dev/sda | grep SCSI_IDENT_LUN_NAA_EXT > # > > Maybe it is present on your machine, and therefore it works for you? Sorry, I forgot, the same goes for SCSI_IDENT_LUN_NAA_REGEXT: # /usr/bin/sg_inq --export --page=di /dev/sda | grep SCSI_IDENT_LUN_NAA_REGEXT # Created attachment 651470 [details]
use-ID_WWN-without-extension.patch
Based on the description in the original commit:
-->--
Some SCSI devices use the same WWN and have a WWN extension that we
need to take into account when creating the /dev/disk/by-id/wwn
symlinks. Thus, introduce ID_WWN_WITH_EXTENSION. This property will
contain either the WWN (if no extension is present) or the WWN with
the vendor extension appended.
--<--
I'm proposing the attached patch for sg3_utils.
Comment on attachment 651470 [details] use-ID_WWN-without-extension.patch >Index: sg3_utils-1.41/scripts/55-scsi-sg3_id.rules >=================================================================== >--- sg3_utils-1.41.orig/scripts/55-scsi-sg3_id.rules >+++ sg3_utils-1.41/scripts/55-scsi-sg3_id.rules >@@ -36,6 +36,7 @@ ENV{SCSI_IDENT_LUN_NAA_EXT}=="?*", ENV{I > ENV{SCSI_IDENT_LUN_NAA_LOCAL}=="?*", ENV{ID_WWN}!="?*", ENV{ID_WWN}="0x$env{SCSI_IDENT_LUN_NAA_LOCAL}" > ENV{SCSI_IDENT_LUN_NAA_REGEXT}=="?*", ENV{ID_WWN_WITH_EXTENSION}!="?*", ENV{ID_WWN_WITH_EXTENSION}="0x$env{SCSI_IDENT_LUN_NAA_REGEXT}" > ENV{SCSI_IDENT_LUN_NAA_EXT}=="?*", ENV{ID_WWN_WITH_EXTENSION}!="?*", ENV{ID_WWN_WITH_EXTENSION}="0x$env{SCSI_IDENT_LUN_NAA_EXT}" >+ENV{ID_WWN}=="?*", ENV{ID_WWN_WITH_EXTENSION}!="?*", ENV{ID_WWN_WITH_EXTENSION}="$env{ID_WWN}" > > # ata_id compability > ENV{ID_SERIAL}!="?*", ENV{SCSI_IDENT_LUN_ATA}=="?*", ENV{ID_BUS}="ata", ENV{ID_ATA}="1", ENV{ID_SERIAL}="$env{SCSI_IDENT_LUN_ATA}" Seems like not: robert@coolcat:~> sudo /usr/bin/sg_inq --export --page=di /dev/sda | grep SCSI_IDENT_LUN_NAA_EXT robert@coolcat:~> sudo /usr/bin/sg_inq --export --page=di /dev/sda | grep SCSI_IDENT_LUN_NAA_REGEXT robert@coolcat:~> P.S. I like the patch from comment #24, but dont know if its correct or not. (In reply to Robert Milasan from comment #26) > P.S. I like the patch from comment #24, but dont know if its correct or not. Thanks Robert, sure, I'd also like confirmation wheter I got this right. Hannes, ok with the reasoning of comment#23 and the patch from comment#24? Actually, we _NEVER_ claimed the /dev/disk/by-id/wwn* links would be stable. /dev/disk/by-id/scsi* _are_ stable, and will continue to be so. The wwn links got introduced by some ultra-clever RH bloke, totally failing to figure out that /dev/disk/by-id/scsi* contains essentially the same information. And I've always advised _against_ the wwn links. But okay, patch is correct. Another compability setting we have to carry around. But still, you might want to fixup yast2-bootloader, too. yast2 crashing is always horrible, for whatever reason. Blaming that on the underlying programs is not a good design principle. Josef, have you fixed up yast2? Just FYI, I've checked Leap Beta1 on my test box (presumably with sg3_utils coming from SLED): NO wwn-* whatsoever and Yast2-bootloader works as expected. So this is limited to Tumbleweed currently? That's the reason why nobody reported since July? (In reply to Bruno Pesavento from comment #31) > Just FYI, I've checked Leap Beta1 on my test box (presumably with sg3_utils > coming from SLED): > NO wwn-* whatsoever and Yast2-bootloader works as expected. > So this is limited to Tumbleweed currently? That's the reason why nobody > reported since July? Actually, it depends wheter YaST2-Bootloader is using a /dev/disk/by-id/wwn- link. I guess on your leap installation it is just using a alternative link, maybe /dev/disk/by-id/scsi- or such. So, you don't see the problem. Considering Hannes comments, it might be better if YaST2-Bootloader would never use /dev/disk/by-id/wwn- links. (In reply to Hannes Reinecke from comment #30) > But still, you might want to fixup yast2-bootloader, too. > > yast2 crashing is always horrible, for whatever reason. > Blaming that on the underlying programs is not a good design principle. > > Josef, have you fixed up yast2? What can be changed is to modify storage to not use wwn as udev device. But how do you expect I can fix yast2-bootloader? grub2 have specified that it is booting from /dev/disk/by-id/wwn* so yast2-bootloader report problem, as it do not know what it is. For me error with "Unknown udev device" reflect reality...it is udev link that should be persistent and it disappeared, so yast2-bootloader do not know what it is and in bootloader area I am very restrictive to report about problems as it is better to say it earlier then stuck during try to boot with black screen and unknown device. I would have expected it to print / show a message about an invalid device, but certainly not crashing ... (In reply to Hannes Reinecke from comment #34) > I would have expected it to print / show a message about an invalid device, > but certainly not crashing ... It is not crash. It is exception that is handled by top level handler, that write error popup and exit yast2 bootloader module as there is no way how to continue without manual fix. So no segfault, sigabort or something like that. Or what behavior do you expect? (In reply to Thomas Blume from comment #32) > (In reply to Bruno Pesavento from comment #31) > > Just FYI, I've checked Leap Beta1 on my test box (presumably with sg3_utils > > coming from SLED): > > NO wwn-* whatsoever and Yast2-bootloader works as expected. > > So this is limited to Tumbleweed currently? That's the reason why nobody > > reported since July? > > Actually, it depends wheter YaST2-Bootloader is using a /dev/disk/by-id/wwn- > link. > I guess on your leap installation it is just using a alternative link, maybe > /dev/disk/by-id/scsi- or such. > So, you don't see the problem. > > Considering Hannes comments, it might be better if YaST2-Bootloader would > never use /dev/disk/by-id/wwn- links. bootloader do not store any blacklist of udev devices. What yast2-storage return as udev persistent devices is used. So only if arvin will remove some specific devices from libstorage or yast2-storage. I do not like to store such list in yast2-bootloader. *** Bug 950535 has been marked as a duplicate of this bug. *** (In reply to Josef Reidinger from comment #33) > (In reply to Hannes Reinecke from comment #30) > > But still, you might want to fixup yast2-bootloader, too. > > > > yast2 crashing is always horrible, for whatever reason. > > Blaming that on the underlying programs is not a good design principle. > > > > Josef, have you fixed up yast2? > > What can be changed is to modify storage to not use wwn as udev device. But > how do you expect I can fix yast2-bootloader? grub2 have specified that it > is booting from /dev/disk/by-id/wwn* so yast2-bootloader report problem, as > it do not know what it is. >... This is not entirely true, at least in my setup. My current GRUB2 setup references UUIDs throughout, local disks only, no attempt at even looking for WWNs. I didn't even "know" about WWNs until this bug surfaced. From what I see here, Yast warns and exits just looking at /dev/disk/by-id and doesn't even get to GRUB files. If I manually change the GRUB config and rebuild GRUB, everything works. The system has been "zypper dup"-ed several times since the bug appeared, GRUB menu updated, newly installed kernels booted without problems. Maybe just deferring the WWN check until an actual attempt at using network disks, where hopefully needed WWNs are in place, could be a safer choice. Just an user's standpoint... So the correct handling for YaST would be to resolve the symlinks for persistent device names (as it does now), but to ignore any dangling symlinks. Only if no persistent device names are left it should open a pop-up window; in all other cases there is enough information to go on. Josef? (In reply to Hannes Reinecke from comment #39) > So the correct handling for YaST would be to resolve the symlinks for > persistent device names (as it does now), but to ignore any dangling > symlinks. > > Only if no persistent device names are left it should open a pop-up window; > in all other cases there is enough information to go on. > > Josef? How can I handle it? Let me summary workflow: 1) during installation there is udev link so bootloader use it 2) in running system udev link is seen, so yast2-bootloader try to resolve it to see what device it is 3) device cannot be resolved...bootloader do not know where it is Only option for me is to have way how to recognize future dangling symlinks in installation, but currently there is not way ( and I do not want to have list of useless udev devices, as it is hard to maintain such list ). *** Bug 953622 has been marked as a duplicate of this bug. *** hannes: failing for opensuse Leap ( current dups ), so it probably need also such patch there. I can confirm that its happening on my older laptop running leap recently upgraded from 13.2. A screenshot of my disk setup is at the following link (mostly because i took it for other reasons earlier) https://www.enlightenment.org/ss/display.php?image=e-564323711815c7.40034673.jpg (In reply to Simon Lees from comment #43) > I can confirm that its happening on my older laptop running leap recently > upgraded from 13.2. A screenshot of my disk setup is at the following link > (mostly because i took it for other reasons earlier) > https://www.enlightenment.org/ss/display.php?image=e-564323711815c7.40034673. > jpg FYI this problem is NOT showing anymore after a clean Leap 42.1 install after a complete disk reformatting (GPT) on the same HW where I originally reported this bug. At the time of first reporting this laptop had been first installed with 13.2 Beta (Legacy, MBR), updated to 13.2 release, upgraded to Tumbleweed and "zypper dup"-ed several times since. Maybe the bug is rooted in incompatibilities or leftovers from previous installs. I also wonder if GPT or MBR might matter. (In reply to Bruno Pesavento from comment #45) > (In reply to Simon Lees from comment #43) > > I can confirm that its happening on my older laptop running leap recently > > upgraded from 13.2. A screenshot of my disk setup is at the following link > > (mostly because i took it for other reasons earlier) > > https://www.enlightenment.org/ss/display.php?image=e-564323711815c7.40034673. > > jpg > > FYI this problem is NOT showing anymore after a clean Leap 42.1 install > after a complete disk reformatting (GPT) on the same HW where I originally > reported this bug. > At the time of first reporting this laptop had been first installed with > 13.2 Beta (Legacy, MBR), updated to 13.2 release, upgraded to Tumbleweed and > "zypper dup"-ed several times since. > Maybe the bug is rooted in incompatibilities or leftovers from previous > installs. I also wonder if GPT or MBR might matter. It is expected as problem is that udev link in format wwn disappeared, so new installation is not affected. It probably doesn't make much difference that the last time this laptop had a clean install was 12.3, i've zypper dup'd through everything since then I've got the same bug since OpenSUSE 13.1. On each upgrade, the installer complains about udev mounted by kernel device. On OpenSUSE Leap too. The difference is that Yast cannot load the bootloader configuration under OpenSUSE LEAP 42.1 :
2015-12-05 13:54:14 <1> Spirit(17430) [Ruby] routines/lib_iface.rb:250 Reading device mapping
2015-12-05 13:54:15 <1> Spirit(17430) [Ruby] routines/lib_iface.rb:262 Read device mapping: $["/dev/disk/by-id/ata-Hitachi_HDS721050CLA362_JPB540HA0K0H8B":"hd0", "/dev/disk/by-id/ata-ST3160811AS_6PT14L2J":"hd1"]
2015-12-05 13:54:15 <1> Spirit(17430) [Ruby] bootloader/udev_mapping.rb:63 /dev/disk/by-id/ata-Hitachi_HDS721050CLA362_JPB540HA0K0H8B looked as kernel device name: /dev/sda
2015-12-05 13:54:15 <1> Spirit(17430) [Ruby] bootloader/udev_mapping.rb:83 mount by: id
2015-12-05 13:54:15 <1> Spirit(17430) [Ruby] bootloader/udev_mapping.rb:63 /dev/disk/by-id/ata-ST3160811AS_6PT14L2J looked as kernel device name: /dev/sdb
2015-12-05 13:54:15 <1> Spirit(17430) [Ruby] bootloader/udev_mapping.rb:83 mount by: id
2015-12-05 13:54:15 <3> Spirit(17430) [Ruby] yast/wfm.rb:202 Client call failed with 'Unknown udev device /dev/disk/by-id/wwn-0x5000cca371c7bc28-part4' and backtrace ["/usr/share/YaST2/lib/bootloader/udev_mapping.rb:42:in `to_kernel_device'", "/usr/share/YaST2/modules/BootCommon.rb:201:in `block in Read'", "/usr/lib64/ruby/vendor_ruby/2.1.0/yast/builtins.rb:518:in `call'", "/usr/lib64/ruby/vendor_ruby/2.1.0/yast/builtins.rb:518:in `block in mapmap'", "/usr/lib64/ruby/vendor_ruby/2.1.0/yast/builtins.rb:517:in `each'", "/usr/lib64/ruby/vendor_ruby/2.1.0/yast/builtins.rb:517:in `mapmap'", "/usr/share/YaST2/modules/BootCommon.rb:199:in `Read'", "/usr/share/YaST2/modules/BootGRUB2.rb:58:in `Read'", "/usr/lib64/ruby/vendor_ruby/2.1.0/yast/fun_ref.rb:33:in `call'", "/usr/lib64/ruby/vendor_ruby/2.1.0/yast/fun_ref.rb:33:in `call'", "/usr/share/YaST2/include/bootloader/routines/switcher.rb:70:in `blRead'", "/usr/share/YaST2/modules/Bootloader.rb:195:in `Read'", "/usr/share/YaST2/include/bootloader/routines/dialogs.rb:52:in `ReadDialog'", "/usr/share/YaST2/include/bootloader/routines/wizards.rb:94:in `block in BootloaderSequence'", "/usr/lib64/ruby/vendor_ruby/2.1.0/yast/builtins.rb:542:in `call'", "/usr/lib64/ruby/vendor_ruby/2.1.0/yast/builtins.rb:542:in `eval'", "/usr/share/YaST2/modules/Sequencer.rb:263:in `WS_run'", "/usr/share/YaST2/modules/Sequencer.rb:335:in `block in Run'", "/usr/share/YaST2/modules/Sequencer.rb:327:in `loop'", "/usr/share/YaST2/modules/Sequencer.rb:327:in `Run'", "/usr/share/YaST2/include/bootloader/routines/wizards.rb:115:in `BootloaderSequence'", "/usr/share/YaST2/clients/bootloader.rb:117:in `GuiHandler'", "/usr/lib64/ruby/vendor_ruby/2.1.0/yast/fun_ref.rb:33:in `call'", "/usr/lib64/ruby/vendor_ruby/2.1.0/yast/fun_ref.rb:33:in `call'", "/usr/share/YaST2/modules/CommandLine.rb:1541:in `Run'", "/usr/share/YaST2/clients/bootloader.rb:105:in `main'", "/usr/share/YaST2/clients/bootloader.rb:190:in `<top (required)>'", "/usr/lib64/ruby/vendor_ruby/2.1.0/yast/wfm.rb:189:in `eval'", "/usr/lib64/ruby/vendor_ruby/2.1.0/yast/wfm.rb:189:in `run_client'"]
2015-12-05 13:54:15 <3> Spirit(17430) [Ruby] yast/wfm.rb:207 Internal error. Please report a bug report with logs.
Details: Unknown udev device /dev/disk/by-id/wwn-0x5000cca371c7bc28-part4
Caller: /usr/share/YaST2/lib/bootloader/udev_mapping.rb:42:in `to_kernel_device'
2015-12-05 13:54:15 <1> Spirit(17430) [ui] YPushButton.cc(setFunctionKey):202 Guessing button role YOKButton for YPushButton "OK" at 0x7fc3503a0540 from function key F10
No WWN références in my grub configuration :
Spirit:/var/log/YaST2 # cd /boot/grub2
Spirit:/boot/grub2 # grep wwn *
Spirit:/boot/grub2 # grep wwn */*
Spirit:/boot/grub2 # grep wwn */*/*
Spirit:/boot/grub2 # grep by-id *
grep: backgrounds: Is a directory
device.map:(hd1) /dev/disk/by-id/scsi-SATA_ST3160811AS_6PT14L2J
device.map:(hd0) /dev/disk/by-id/ata-Hitachi_HDS721050CLA362_JPB540HA0K0H8B
Spirit:/boot/grub2 # grep "/dev/sd" *
device.map.old:(hd0) /dev/sda
device.map.old:(hd1) /dev/sdb
grub.cfg:menuentry 'Microsoft Windows XP Professionnel (on /dev/sda1)' --class windows --class os $menuentry_id_option 'osprober-chain-3C441846441804F4' {
grub.cfg.20151111:menuentry 'Microsoft Windows XP Professionnel (sur /dev/sda1)' --class windows --class os $menuentry_id_option 'osprober-chain-3C441846441804F4' {
SUSE-RU-2016:0056-1: An update that has four recommended fixes can now be installed. Category: recommended (moderate) Bug References: 949796,955222,955856,956815 CVE References: Sources used: SUSE Linux Enterprise Software Development Kit 12-SP1 (src): sg3_utils-1.41-5.1 SUSE Linux Enterprise Server 12-SP1 (src): sg3_utils-1.41-5.1 SUSE Linux Enterprise Desktop 12-SP1 (src): sg3_utils-1.41-5.1 openSUSE-RU-2016:0129-1: An update that has four recommended fixes can now be installed. Category: recommended (moderate) Bug References: 949796,955222,955856,956815 CVE References: Sources used: openSUSE Leap 42.1 (src): sg3_utils-1.41-8.1 *** Bug 963247 has been marked as a duplicate of this bug. *** So, to add a final statement here: Before upgrading a system please make sure to _not_ use the /dev/disk/by-id/wwn-* symlinks. There have been issues where the above symlink is not stable, and might have changed in between releases. Please use /dev/disk/by-id/scsi-* symlinks or select the UUID mount option. Can we add this to a TID or something? Perhaps this may help at least to confirm bug. Similar problem, please see bug 972784. https://bugzilla.suse.com/show_bug.cgi?id=972784 Tanks. Perhaps this may help at least confirm bug. Similar problem, please see bug 972784. https://bugzilla.suse.com/show_bug.cgi?id=972784 Tanks. (In reply to Anonimo Oculto from comment #54) > Perhaps this may help at least confirm bug. Similar problem, please see bug > 972784. > > https://bugzilla.suse.com/show_bug.cgi?id=972784 > > Tanks. no, it is different issue with cloning disks, where id changed. Got to this issue after changing rootfs device connection. System was installed on QEMU-KVM, then booted on physical hardware. So if I start "Boot Loader" YaST2 module I get error window with text: "Error Internal error. Please report a bug report with logs. Details: Unknown udev device /dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1 Caller: /usr/share/YaST2/lib/bootloader/device_mapping.rb:42 in `to_kernel_device' " I need to update bootloader manually with "grub2-mkconfig -o /boot/grub2/grub.cfg". This problem is openSUSE-specific. Ubuntu, for example, does not have this problem. I can confirm this exist in 42.1 whenever I clone a hard drive with clonezilla. Related BUG # 993643 Cloned drives not booting, I had this bug happen when trying to fix that issue. Hello I have also a similar problem but it refers to a non existing disk "Internal error: Please report a bug report with logs. Details:Unknown udev device /dev/disk/by-label/msdos Caller: /usr/share/YaSTé/lib/bootloader/udev_mapping.rb:33.in 'to_kernel_device'" I never had a msdos partition : maybe it can refers to a USB stick? the fstab content is /dev/disk/by-id/scsi-3600508b1001c99233458581ffb65cc88-part2 / ext4 acl,user_xattr 1 1 LABEL=usr /usr ext4 acl,user_xattr 1 2 LABEL=home /home ext4 acl,user_xattr 1 2 LABEL=srv /srv ext4 acl,user_xattr 1 2 LABEL=var /var ext4 acl,user_xattr 1 2 LABEL=local /local ext4 acl,user_xattr 1 2 LABEL=opt /opt ext4 acl,user_xattr 1 2 /dev/disk/by-id/scsi-3600508b1001c99233458581ffb65cc88-part1 swap swap defaults 0 0 I'll attach the full YaST.log Regard Philippe Created attachment 691733 [details]
YaST log
*** Bug 999513 has been marked as a duplicate of this bug. *** I built a system from openSUSE 13.2 and performed online updates (3.16.7-53-desktop) over the past couple years. I used ACRONIS to image that system and installed it on 8 other systems which all have the smae problem. I suspect my problem is related to the uuid from the original system that I imaged. When I start Yast2 as root and select either Kernel Settings or Bootloader I get the below error. If someone knows a simple file I can edit to resolve the problem it is much appreciated. Error Internal error. Please report a bug report with logs. Details: Unknown udev device /dev/disk/by-id/scsi-1ATA_MTFDDAK256MAY-1AH1ZASHA_14500E0C147D-part2 Caller: /usr/share/Yast2/lib/bootloader/device_mapping.rb:42:in `to_kernel_device’ /dev/disk/by-id: lrwxrwxrwx 1 root root 9 Jan 20 13:10 ata-MTFDDAK256MAY-1AH1ZABHA_14280CF191FF -> ../../sda lrwxrwxrwx 1 root root 10 Jan 20 13:10 ata-MTFDDAK256MAY-1AH1ZABHA_14280CF191FF-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Jan 20 13:10 ata-MTFDDAK256MAY-1AH1ZABHA_14280CF191FF-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Jan 20 13:10 ata-MTFDDAK256MAY-1AH1ZABHA_14280CF191FF-part3 -> ../../sda3 lrwxrwxrwx 1 root root 9 Jan 20 13:03 ata-hp_DVD_A_DH16AESH_248427914038 -> ../../sr0 lrwxrwxrwx 1 root root 9 Jan 20 13:10 scsi-0ATA_MTFDDAK256MAY-1A_14280CF191FF -> ../../sda lrwxrwxrwx 1 root root 10 Jan 20 13:10 scsi-0ATA_MTFDDAK256MAY-1A_14280CF191FF-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Jan 20 13:10 scsi-0ATA_MTFDDAK256MAY-1A_14280CF191FF-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Jan 20 13:10 scsi-0ATA_MTFDDAK256MAY-1A_14280CF191FF-part3 -> ../../sda3 lrwxrwxrwx 1 root root 9 Jan 20 13:10 scsi-1ATA_MTFDDAK256MAY-1AH1ZABHA_14280CF191FF -> ../../sda lrwxrwxrwx 1 root root 10 Jan 20 13:10 scsi-1ATA_MTFDDAK256MAY-1AH1ZABHA_14280CF191FF-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Jan 20 13:10 scsi-1ATA_MTFDDAK256MAY-1AH1ZABHA_14280CF191FF-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Jan 20 13:10 scsi-1ATA_MTFDDAK256MAY-1AH1ZABHA_14280CF191FF-part3 -> ../../sda3 lrwxrwxrwx 1 root root 9 Jan 20 13:10 scsi-3500a07510cf191ff -> ../../sda lrwxrwxrwx 1 root root 10 Jan 20 13:10 scsi-3500a07510cf191ff-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Jan 20 13:10 scsi-3500a07510cf191ff-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Jan 20 13:10 scsi-3500a07510cf191ff-part3 -> ../../sda3 lrwxrwxrwx 1 root root 9 Jan 20 13:10 scsi-3600508e000000000c1f3e9201d0f5609 -> ../../sdb lrwxrwxrwx 1 root root 10 Jan 20 13:10 scsi-3600508e000000000c1f3e9201d0f5609-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 9 Jan 20 13:10 scsi-3600d02310002c4d779a774fc49535b55 -> ../../sdc lrwxrwxrwx 1 root root 10 Jan 20 13:10 scsi-3600d02310002c4d779a774fc49535b55-part1 -> ../../sdc1 lrwxrwxrwx 1 root root 9 Jan 20 13:10 scsi-SATA_MTFDDAK256MAY-1A_14280CF191FF -> ../../sda lrwxrwxrwx 1 root root 10 Jan 20 13:10 scsi-SATA_MTFDDAK256MAY-1A_14280CF191FF-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Jan 20 13:10 scsi-SATA_MTFDDAK256MAY-1A_14280CF191FF-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Jan 20 13:10 scsi-SATA_MTFDDAK256MAY-1A_14280CF191FF-part3 -> ../../sda3 lrwxrwxrwx 1 root root 9 Jan 20 13:10 scsi-SATA_MTFDDAK256MAY-1_14280CF191FF -> ../../sda lrwxrwxrwx 1 root root 10 Jan 20 13:10 scsi-SATA_MTFDDAK256MAY-1_14280CF191FF-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Jan 20 13:10 scsi-SATA_MTFDDAK256MAY-1_14280CF191FF-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Jan 20 13:10 scsi-SATA_MTFDDAK256MAY-1_14280CF191FF-part3 -> ../../sda3 lrwxrwxrwx 1 root root 9 Jan 20 13:10 scsi-SIFT_DS_S12S-G2240-4_02C4D779A774FC49535B55 -> ../../sdc lrwxrwxrwx 1 root root 10 Jan 20 13:10 scsi-SIFT_DS_S12S-G2240-4_02C4D779A774FC49535B55-part1 -> ../../sdc1 lrwxrwxrwx 1 root root 9 Jan 20 13:10 scsi-SLSI_Logical_Volume_552203201156634909 -> ../../sdb lrwxrwxrwx 1 root root 10 Jan 20 13:10 scsi-SLSI_Logical_Volume_552203201156634909-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 9 Jan 20 13:10 wwn-0x500a07510cf191ff -> ../../sda lrwxrwxrwx 1 root root 10 Jan 20 13:10 wwn-0x500a07510cf191ff-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Jan 20 13:10 wwn-0x500a07510cf191ff-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Jan 20 13:10 wwn-0x500a07510cf191ff-part3 -> ../../sda3 lrwxrwxrwx 1 root root 9 Jan 20 13:10 wwn-0x600508e000000000c1f3e9201d0f5609 -> ../../sdb lrwxrwxrwx 1 root root 10 Jan 20 13:10 wwn-0x600508e000000000c1f3e9201d0f5609-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 9 Jan 20 13:10 wwn-0x600d02310002c4d779a774fc49535b55 -> ../../sdc lrwxrwxrwx 1 root root 10 Jan 20 13:10 wwn-0x600d02310002c4d779a774fc49535b55-part1 -> ../../sdc1 /etc/fstab: LABEL=swap swap swap defaults 0 0 LABEL=system / btrfs defaults 0 0 LABEL=home /home xfs defaults 1 2 LABEL=system /boot/grub2/i386-pc btrfs subvol=boot/grub2/i386-pc 0 0 LABEL=system /boot/grub2/x86_64-efi btrfs subvol=boot/grub2/x86_64-efi 0 0 LABEL=system /opt btrfs subvol=opt 0 0 LABEL=system /srv btrfs subvol=srv 0 0 LABEL=system /tmp btrfs subvol=tmp 0 0 LABEL=system /usr/local btrfs subvol=usr/local 0 0 LABEL=system /var/crash btrfs subvol=var/crash 0 0 LABEL=system /var/lib/mailman btrfs subvol=var/lib/mailman 0 0 LABEL=system /var/lib/named btrfs subvol=var/lib/named 0 0 LABEL=system /var/lib/pgsql btrfs subvol=var/lib/pgsql 0 0 LABEL=system /var/log btrfs subvol=var/log 0 0 LABEL=system /var/opt btrfs subvol=var/opt 0 0 LABEL=system /var/spool btrfs subvol=var/spool 0 0 LABEL=system /var/tmp btrfs subvol=var/tmp 0 0 LABEL=system /.snapshots btrfs subvol=.snapshots 0 0 LABEL=eraid /eraid xfs defaults,nofail 0 0 LABEL=iraid /iraid xfs defaults,nofail 0 0 #hp2:/RAID/shared/ /eve2 nfs auto,nofail 0 0 #hp1:/eraid /eve1 nfs auto,nofail 0 0 If additional information is needed I will be happy to accommodate the request. I'm at a loss what I should be doing here. Josef, can you check what would be the appropriate next steps? (In reply to Hannes Reinecke from comment #62) > I'm at a loss what I should be doing here. > Josef, can you check what would be the appropriate next steps? well, problem bootloader has is that udev device which should be persistent is renamed/disappeared. So bootloader complain that device disappear and no longer know how to cope with it. In TW and SP3 there is already code, that detect such situation and allow to repropose configuration, but in general persistent names in udev should never be renamed or disapper. so lets close it as fixed as we have way how to cope with it now, but please keep in mind to not rename devices in udev rules. |
Created attachment 651027 [details] yast2-log and udev information Trying to modify the bootloader setup, YaST2-Bootloader complains: Internal error. Please report a bug report with logs. Details: Unknown udev device /dev/disk/by-id/wwn-0x50025388a064af10-part3 Caller: /usr/share/YaST2/lib/bootloader/udev_mapping.rb:42:in `to_kernel_device' Then crashes on user acknowledge. The offending partition is mounted as / (root) and is where the bootloader code is stored. The disk is a plain MBR formatted SSD that worked for years, no RAID or LVM or the like. Looking at the attached details it's no wonder that udev_mapping.rb at line 42 complains. Reproducible: always Tested with Tumbleweed 20151002 X86_64 (but the problem is likely there from the last few snapshots)