Description of problem: The /dev/disk/by-id/wwn-* links are wrong for SATA devices, and have changed from F21 to F22, therefore rendering these presumably "persistent" links pretty much useless across updates. The fact that WWN are explicitly taken as persistent and stable, also across platforms, and now have changed from one distro version to another, qualifies for severity high in my opinion. Version-Release number of selected component (if applicable): systemd-219-15.fc22.x86_64 How reproducible: always Check the WWN of a SATA device: # hdparm -I /dev/sda | grep WWN Logical Unit WWN Device Identifier: 50014ee2602c6589 Steps to Reproduce: 1. Use F22 with systemd-219-15.fc22.x86_64 2. Check the WWN of a SATA device with hdparm -I 3. Check the link(s) in /dev/disk/by-id/wwn-* Actual results: Actual link created for WWN 50014ee2602c6589: /dev/disk/by-id/wwn-0x7316484813058363393x Expected results: Expected link: /dev/disk/by-id/wwn-0x50014ee2602c6589 Additional info: Worked as expected with F21, changed behaviour with F22. The /dev/disk/by-id/wwn-* link apparently has no relation, or none I could obviously see, to the WWN reported by hdparm -I, or any other string reported by hdparm or other tools like smartctl -a: # smartctl -a /dev/sda | grep WWN LU WWN Device Id: 5 0014ee 2602c6589 Nevertheless, udevadm info gives the wrong WWN, and absolutely no value containing the correct WWN: # udevadm info -p /sys/class/block/sda | grep -E '7316484813058363393|50014ee2602c6589' S: disk/by-id/wwn-0x7316484813058363393x E: DEVLINKS=/dev/disk/by-id/ata-WDC_WD50EZRX-00MVLB1_WD-WXC1H3443687 /dev/disk/by-id/wwn-0x7316484813058363393x E: ID_WWN=0x7316484813058363393x E: ID_WWN_WITH_EXTENSION=0x7316484813058363393x
I think I found the relation: ID_WWN=0x7316484813058363393x Decimal 7316484813058363393 is hex 6589 602C 4EE2 5001 WWN is 5001 4ee2 602c 6589 So this seems to be some formatting error, and the additional 'x' at the end is maybe also a leftover from that.
I think this commit is the culprit: https://github.com/systemd/systemd/commit/11c6f693e94e9013c8df91210b8b0e2e343de809#diff-206cbcfb4490ed3d44bbb51fbd935625R647 $ git diff 6024a6e302bad6bcf073fa84a41a6123305dc845 11c6f693e94e9013c8df91210b8b0e2e343de809 ata_id.c | nl 111 - if ((word & 0xf000) == 0x5000) { 112 - uint64_t wwwn; 113 - 114 - wwwn = identify.octa[108/4]; 115 - printf("ID_WWN=0x%llx\n", (unsigned long long int) wwwn); 116 - /* ATA devices have no vendor extension */ 117 - printf("ID_WWN_WITH_EXTENSION=0x%llx\n", (unsigned long long int) wwwn); 118 - } 119 + if ((word & 0xf000) == 0x5000) 120 + printf("ID_WWN=0x%1$"PRIu64"x\n" 121 + "ID_WWN_WITH_EXTENSION=0x%1$"PRIu64"x\n", 122 + identify.octa[108/4]);
FWIW, here's the scsi_id output: # /usr/lib/udev/scsi_id -g -x /dev/sda ID_SCSI=1 ID_VENDOR=ATA ID_VENDOR_ENC=ATA\x20\x20\x20\x20\x20 ID_MODEL=WDC_WD50EZRX-00M ID_MODEL_ENC=WDC\x20WD50EZRX-00M ID_REVISION=0A80 ID_TYPE=disk ID_SERIAL=350014ee2602c6589 ID_SERIAL_SHORT=50014ee2602c6589 ID_WWN=0x50014ee2602c6589 ID_WWN_WITH_EXTENSION=0x50014ee2602c6589 ID_SCSI_SERIAL=[edited]
http://lists.freedesktop.org/archives/systemd-devel/2015-June/033251.html
Merged upstream.
This bug seems to be duplicate of #1214305. Maybe one of the two should be marked properly. Thanks, bye, pg
*** This bug has been marked as a duplicate of bug 1214305 ***
Unfortunately this fix (included in systemd-219-19.fc22.x86_64) doesn't do it. It now prints the hex numbers, but the words are swapped: Correct: # /usr/lib/udev/scsi_id -g -x /dev/sda | grep WWN ID_WWN=0x50014ee2602c6589 ID_WWN_WITH_EXTENSION=0x50014ee2602c6589 Actual output: # udevadm info -p /sys/class/block/sda | grep WWN E: ID_WWN=0x6589602c4ee25001 E: ID_WWN_WITH_EXTENSION=0x6589602c4ee25001
https://github.com/systemd/systemd/pull/651 Pfff, I'm not sure what to do about backwards compatibility. Bad formatting was introduced in systemd-219, i.e. it has been bad for the whole life of F22. One option would be to assume that anyone to be bitten by this already changed to use a different link. Another option would be to provide a backwards compatible link under the broken name (with "x") at the end, since this is the link used during installation. I'm leaning towards the second option.
And the temporary hack would look like this: https://github.com/keszybz/systemd/commit/c505b456a6b23ffe1d11b597f4aa82f5bead961f. Hopefully this would minimize breakage of existing installations.
systemd-219-20.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/systemd-219-20.fc22
Package systemd-219-20.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-219-20.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-12261/systemd-219-20.fc22 then log in and leave karma (feedback).
systemd-219-20.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
I updated to F23, and it seems the issue with the swapped hex parts reappeared, I get the same output as in #c8. systemd-222-8.fc23.x86_64
Is it a problem to push the existing fix for F22 to current F23? I'm at systemd-222-13.fc23.x86_64 now, where the issue still exists.
Fixed in cf22cddcfd07d10fecd7b03ef465e957054daec2 upstream a while back.
We've just hit this ourselves in RHEL 7.2 (kernel 3.10.0-327.4.5.el7.x86_64). This blocks us from moving to this release since we use the drive wwn numbers and assume they will never change. When do we expect to see this fixed in RHEL?
(In reply to Peter Steele from comment #17) > We've just hit this ourselves in RHEL 7.2 (kernel > 3.10.0-327.4.5.el7.x86_64). This blocks us from moving to this release since > we use the drive wwn numbers and assume they will never change. When do we > expect to see this fixed in RHEL? We have scheduled this fix to land in RHEL-7.3. But we can certainly deliver sooner. AFAICT, next 7.2 z-stream batch is planned to be released at the end of the March. In order to get that fix into z-stream you have to escalate via your support representative.
Okay, I'll investigate doing that...
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.