|
Bugzilla – Full Text Bug Listing |
| Summary: | journalctl shows error about duplicate /dev/disk/by-id/ with hardware raid HP P420i | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Philippe Condé <conde.philippe> |
| Component: | Basesystem | Assignee: | Thomas Blume <thomas.blume> |
| Status: | RESOLVED INVALID | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | bwiedemann, chcao, conde.philippe, hare, rmilasan, systemd-maintainers, thomas.blume, tiwai |
| Version: | 201503* | ||
| Target Milestone: | --- | ||
| Hardware: | HP | ||
| OS: | openSUSE 13.2 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
file 1 sda
file 2 sdb file 3 sdc output of /lib/udev/scsi_id KInfoCenter udevadm output |
||
|
Description
Philippe Condé
2015-04-06 13:51:07 UTC
Can you check that the older kernel (3.18?) showed the different device paths, to confirm that it's a kernel regression? Hello, I have only two kernel-xen : kernel-xen-3.19.2-1.1.x86_64 kernel-xen-devel-3.19.3-1.1.x86_64 kernel-xen-devel-3.19.2-1.1.x86_64 kernel-xen-3.19.3-1.1.x86_64 The problem occurs also with kernel 3.19.2-1.1. I didn't find an older kernel 3.18 on OpenSuse site. I'm practically sure that this didn't occur with kernel 3.18: I check regularly the journalctl due to a problem with some sensors and I didn't see these warnings before. DO you have a link with a old kernel? I can download it and install it Regards Philippe Condé You can find kernel packages for 3.18 in OBS home:tiwai:kernel:3.18 repo. But I didn't build kernel-xen, so I enabled it now but it takes some time until the build finishes. If you'll need kernel-xen, check the repo later (after one or two hours). Hello, I tested it with your kernel 3.18 and the problem occurs also. I found this strange so I reinstalled the GA kernel 3.16.7.7 and here also the problem occurred. I think that this is not kernel related but another component (systemd?) I had a deeper look in journalctl and I found that the warnings are preceded every time by this ACPI Error related to the sensors AFAIK Apr 09 21:46:56 hpprol2 kernel: ACPI Error: SMBus/IPMI/GenericSerialBus write requires Buffer of length 66, found length 32 (20141107/exfield-418) Apr 09 21:46:56 hpprol2 kernel: ACPI Error: Method parse/execution failed [\_SB_.PMI0._PMM] (Node ffff8802d6cc4220), AE_AML_BUFFER_LIMIT (20141107/psparse-536) Apr 09 21:46:56 hpprol2 kernel: ACPI Exception: AE_AML_BUFFER_LIMIT, Evaluating _PMM (20141107/power_meter-338) Apr 09 21:46:56 hpprol2 systemd[2093]: Device dev-disk-by\x2did-scsi\x2dSHP_LOGICAL_VOLUME_0014380280B60D0.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:02.2/0000:03:00.0/host0/target0:0:0/0 Apr 09 21:46:56 hpprol2 systemd[1]: Device dev-disk-by\x2did-scsi\x2dSHP_LOGICAL_VOLUME_0014380280B60D0\x2dpart1.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:02.2/0000:03:00.0/host0/target0 Apr 09 21:46:56 hpprol2 systemd[2093]: Device dev-disk-by\x2did-scsi\x2dSHP_LOGICAL_VOLUME_0014380280B60D0\x2dpart1.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:02.2/0000:03:00.0/host0/targ Apr 09 21:46:56 hpprol2 systemd[1]: Device dev-disk-by\x2did-scsi\x2dSHP_LOGICAL_VOLUME_0014380280B60D0\x2dpart4.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:02.2/0000:03:00.0/host0/target0 Apr 09 21:46:56 hpprol2 systemd[2093]: Device dev-disk-by\x2did-scsi\x2dSHP_LOGICAL_VOLUME_0014380280B60D0\x2dpart4.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:02.2/0000:03:00.0/host0/targ Apr 09 21:46:56 hpprol2 systemd[2093]: Device dev-disk-by\x2did-scsi\x2dSHP_LOGICAL_VOLUME_0014380280B60D0\x2dpart2.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:02.2/0000:03:00.0/host0/targ Apr 09 21:46:56 hpprol2 systemd[2093]: Device dev-disk-by\x2did-scsi\x2dSHP_LOGICAL_VOLUME_0014380280B60D0\x2dpart3.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:02.2/0000:03:00.0/host0/targ Apr 09 21:46:56 hpprol2 systemd[1]: Device dev-disk-by\x2did-scsi\x2dSHP_LOGICAL_VOLUME_0014380280B60D0\x2dpart2.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:02.2/0000:03:00.0/host0/target0 Apr 09 21:46:56 hpprol2 systemd[1]: Device dev-disk-by\x2did-scsi\x2dSHP_LOGICAL_VOLUME_0014380280B60D0\x2dpart3.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:02.2/0000:03:00.0/host0/target0 Apr 09 21:46:56 hpprol2 systemd[2093]: Device dev-disk-by\x2did-scsi\x2dSHP_LOGICAL_VOLUME_0014380280B60D0.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:02.2/0000:03:00.0/host0/target0:0:0/0 Apr 09 21:46:56 hpprol2 systemd[1]: Device dev-disk-by\x2did-scsi\x2dSHP_LOGICAL_VOLUME_0014380280B60D0.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:02.2/0000:03:00.0/host0/target0:0:0/0:0: Apr 09 21:46:56 hpprol2 kernel: sdc: sdc1 sdc2 sdc3 sdc4 The last line is also related to the ACPI errors. So I disabled the service for lm-sensor but the warnings still occur. I removed then packages openipmi and freeipmi but the warnings remain even after reboot Regards Philippe Condé Hello, this problem remains with kerenl 4.0.1.1 The device by-uuid seems correct. command blkid gives hpprol2:~ # blkid /dev/sda1: UUID="ab7656ab-41e6-41e8-aa16-bbb4ca3c643e" TYPE="swap" PARTUUID="000aab75-01" /dev/sda2: LABEL="OpenSuse" UUID="0d169d88-fe6d-4ca8-bebf-916cae9ec3d7" TYPE="ext4" PARTUUID="000aab75-02" /dev/sda3: LABEL="usr" UUID="0e2de715-8f0b-4206-842c-2a1f4c4e5669" TYPE="ext4" PARTUUID="000aab75-03" /dev/sda4: LABEL="home" UUID="dc7675a1-24a2-4ec2-a3a1-458af1b9d1e0" TYPE="ext4" PARTUUID="000aab75-04" /dev/sdb1: LABEL="srv" UUID="bf2e6374-cee0-4c18-96b5-851f821ac807" TYPE="ext4" PARTUUID="0005f844-01" /dev/sdb2: LABEL="var" UUID="b4849ee9-4a6c-4304-bc8d-cdca4f113408" TYPE="ext4" PARTUUID="0005f844-02" /dev/sdb3: LABEL="local" UUID="89036c77-2a68-4ad2-9dfd-f950288600fa" TYPE="ext4" PARTUUID="0005f844-03" /dev/sdb4: LABEL="opt" UUID="55cafd49-1996-4599-8af6-46fbaf61b5eb" TYPE="ext4" PARTUUID="0005f844-04" /dev/sdc1: LABEL="vmroot" UUID="f14d0615-94ce-4f37-b491-4cefc8b83ff0" TYPE="ext4" PARTUUID="0001a1e7-01" /dev/sdc2: LABEL="vmswap" UUID="e29476d3-e6a3-4083-ac21-12999fcb072c" TYPE="swap" PARTUUID="0001a1e7-02" /dev/sdc3: LABEL="vmuser" UUID="506b37dd-4412-4398-abd1-970f223592a1" TYPE="ext4" PARTUUID="0001a1e7-03" /dev/sdc4: LABEL="vmhome" UUID="0ddfdd63-b1a1-446b-8518-119273bdeff8" TYPE="ext4" PARTUUID="0001a1e7-04" and hpprol2:~ # lsblk -f NAME FSTYPE LABEL UUID MOUNTPOINT sda ├─sda1 swap ab7656ab-41e6-41e8-aa16-bbb4ca3c643e [SWAP] ├─sda2 ext4 OpenSuse 0d169d88-fe6d-4ca8-bebf-916cae9ec3d7 / ├─sda3 ext4 usr 0e2de715-8f0b-4206-842c-2a1f4c4e5669 /usr └─sda4 ext4 home dc7675a1-24a2-4ec2-a3a1-458af1b9d1e0 /home sdb ├─sdb1 ext4 srv bf2e6374-cee0-4c18-96b5-851f821ac807 /srv ├─sdb2 ext4 var b4849ee9-4a6c-4304-bc8d-cdca4f113408 /var ├─sdb3 ext4 local 89036c77-2a68-4ad2-9dfd-f950288600fa /local └─sdb4 ext4 opt 55cafd49-1996-4599-8af6-46fbaf61b5eb /opt sdc ├─sdc1 ext4 vmroot f14d0615-94ce-4f37-b491-4cefc8b83ff0 ├─sdc2 swap vmswap e29476d3-e6a3-4083-ac21-12999fcb072c ├─sdc3 ext4 vmuser 506b37dd-4412-4398-abd1-970f223592a1 └─sdc4 ext4 vmhome 0ddfdd63-b1a1-446b-8518-119273bdeff8 I think that the by-id generation uses some hardware information that is taken from the 4 disks that are in a raid 5 configuration and receive the same info for the 3 logical disks Is it possible changing the default use of by-id by by_uuid? In Yast ==> /etc/sysconfig ==> system==> Yast2 ==> storage ==> DEVICE_NAMES I changed the "id" in "label" but this doesn't change anything for the errors in journalctl. Do I need doing manually some rebuild? Regards Philippe Change the component, as it's apparently no kernel issue. Is any multipath involved? Check ps ax|grep multipath could be related to udev or be hw-specific? (In reply to Bernhard Wiedemann from comment #7) > Is any multipath involved? Check > ps ax|grep multipath > > could be related to udev or be hw-specific? No there is no multipath involved. I think that the generation of the dev-ID uses some hardware information but the hardware raid 5 probably send the same information for the 3 logical disks that I defined. Regards Philippe (In reply to Philippe Condé from comment #8) > (In reply to Bernhard Wiedemann from comment #7) > > Is any multipath involved? Check > > ps ax|grep multipath > > > > could be related to udev or be hw-specific? > > No there is no multipath involved. > I think that the generation of the dev-ID uses some hardware information but > the hardware raid 5 probably send the same information for the 3 logical > disks that I defined. > Can you please show the output of: /lib/udev/scsi_id --export --whitelisted -d /dev/sda /lib/udev/scsi_id --export --whitelisted -d /dev/sdb Hello, here the output for the 3 logical disks: As you can see the field ID_SCSI_SERIAL is the same for the 3 disks hpprol2:~ # /lib/udev/scsi_id --export --whitelisted -d /dev/sda ID_SCSI=1 ID_VENDOR=HP ID_VENDOR_ENC=HP\x20\x20\x20\x20\x20\x20 ID_MODEL=LOGICAL_VOLUME ID_MODEL_ENC=LOGICAL\x20VOLUME\x20\x20 ID_REVISION=4.68 ID_TYPE=disk ID_SERIAL=3600508b1001c99233458581ffb65cc88 ID_SERIAL_COMPAT= ID_SERIAL_SHORT=600508b1001c99233458581ffb65cc88 ID_WWN=0x600508b1001c9923 ID_WWN_VENDOR_EXTENSION=0x3458581ffb65cc88 ID_WWN_WITH_EXTENSION=0x600508b1001c99233458581ffb65cc88 ID_SCSI_SERIAL=0014380280B60D0 hpprol2:~ # /lib/udev/scsi_id --export --whitelisted -d /dev/sdb ID_SCSI=1 ID_VENDOR=HP ID_VENDOR_ENC=HP\x20\x20\x20\x20\x20\x20 ID_MODEL=LOGICAL_VOLUME ID_MODEL_ENC=LOGICAL\x20VOLUME\x20\x20 ID_REVISION=4.68 ID_TYPE=disk ID_SERIAL=3600508b1001cd3e7527deb3b931a6639 ID_SERIAL_COMPAT= ID_SERIAL_SHORT=600508b1001cd3e7527deb3b931a6639 ID_WWN=0x600508b1001cd3e7 ID_WWN_VENDOR_EXTENSION=0x527deb3b931a6639 ID_WWN_WITH_EXTENSION=0x600508b1001cd3e7527deb3b931a6639 ID_SCSI_SERIAL=0014380280B60D0 hpprol2:~ # /lib/udev/scsi_id --export --whitelisted -d /dev/sdc ID_SCSI=1 ID_VENDOR=HP ID_VENDOR_ENC=HP\x20\x20\x20\x20\x20\x20 ID_MODEL=LOGICAL_VOLUME ID_MODEL_ENC=LOGICAL\x20VOLUME\x20\x20 ID_REVISION=4.68 ID_TYPE=disk ID_SERIAL=3600508b1001c21d488c454a46bc39f22 ID_SERIAL_COMPAT= ID_SERIAL_SHORT=600508b1001c21d488c454a46bc39f22 ID_WWN=0x600508b1001c21d4 ID_WWN_VENDOR_EXTENSION=0x88c454a46bc39f22 ID_WWN_WITH_EXTENSION=0x600508b1001c21d488c454a46bc39f22 ID_SCSI_SERIAL=0014380280B60D0 Regards Philippe Ok, thanks for the feedback. So, the problem is ID_SCSI_SERIAL. I'm just wondering how this could have changed with the kernel version. WOuld it be possible to also send this output from a previous kernel that didn't show this bug? Hello, I found the errors after some update of tumbleweed. I thought first that is was related to the new kernel delivered at this time (kernel 3.19). But I tested with a kernel 3.18 and the errors were also present: maybe this is not related to the kernel but to something else which is used by all kernels As far as I remember this occurred end of march 2015 Regards Philippe (In reply to Philippe Condé from comment #12) > Hello, > > I found the errors after some update of tumbleweed. I thought first that is > was related to the new kernel delivered at this time (kernel 3.19). But I > tested with a kernel 3.18 and the errors were also present: maybe this is > not related to the kernel but to something else which is used by all kernels > > As far as I remember this occurred end of march 2015 > Ok, maybe something has changed in the scsi_id code. Robert, are there any patches for /lib/udev/scsi_id in recent tumbleweed versions that could explain this? No, I haven't touch scsi_id for tumbleweed nor there are many changes in scsi_id now a days. Can you try sg_inq: /usr/bin/sg_inq -p di --export /dev/sda /usr/bin/sg_inq -p di --export /dev/sdb /usr/bin/sg_inq -p di --export /dev/sdc Adding Hannes to the bug, this seems more his 'area'. Sorry, better try this:
for disk in sda sdb sdc; do
sg_inq /dev/$disk > disk_$disk.log 2>&1
done
This way we include, or we should unit_serial_number. Please attach the 3 file created.
Created attachment 636509 [details]
file 1 sda
Created attachment 636510 [details]
file 2 sdb
Created attachment 636511 [details]
file 3 sdc
Hello, Here the result hpprol2:~ # /usr/bin/sg_inq -p di --export /dev/sda SCSI_IDENT_LUN_NAA=600508b1001c99233458581ffb65cc88 SCSI_IDENT_LUN_VENDOR=00000000 hpprol2:~ # /usr/bin/sg_inq -p di --export /dev/sdb SCSI_IDENT_LUN_NAA=600508b1001cd3e7527deb3b931a6639 SCSI_IDENT_LUN_VENDOR=01000000 hpprol2:~ # /usr/bin/sg_inq -p di --export /dev/sdc SCSI_IDENT_LUN_NAA=600508b1001c21d488c454a46bc39f22 SCSI_IDENT_LUN_VENDOR=02000000 3 files also attached Regards Philippe OK, so, from the results this is not udev nor scsi_id, but possibly kernel or hardware (not really sure). Thomas, please check it yourself too and think of adding Hannes to the bug. (In reply to Robert Milasan from comment #20) > OK, so, from the results this is not udev nor scsi_id, but possibly kernel > or hardware (not really sure). > > Thomas, please check it yourself too and think of adding Hannes to the bug. Hm, the attachments show: -->-- standard INQUIRY: PQual=0 Device_type=0 RMB=0 LU_CONG=0 version=0x05 [SPC-3] [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=1 Resp_data_format=2 SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 [BQue=0] EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0 [RelAdr=0] WBus16=0 Sync=0 [Linked=0] [TranDis=0] CmdQue=1 length=56 (0x38) Peripheral device type: disk Vendor identification: HP Product identification: LOGICAL VOLUME Product revision level: 4.68 Unit serial number: 0014380280B60D0 --<-- Seems the standard inquiry gets codepage 0x80, e.g.: # sg_inq -p 0x80 /dev/sdde VPD INQUIRY: Unit serial number page [...] According to the scsi_id code: /* * Get page 0, the page of the pages. By default, try from best to * worst of supported pages: 0x83 then 0x80. */ this should only be done if no better codepage is available. Philippe, can you please attach the output of: /lib/udev/scsi_id --export --whitelisted -p 0x80 -d /dev/sda /lib/udev/scsi_id --export --whitelisted -p 0x83 -d /dev/sda /lib/udev/scsi_id --export --whitelisted -p pre-spc3-83 -d /dev/sda Hello, Here the output asked. i executed the same command on the 3 disks see file b926053_scsi_id.txt as far as i see the next line is the same for the 3 disks ID_SCSI_SERIAL=0014380280B60D0 Regards Philippe Created attachment 636666 [details]
output of /lib/udev/scsi_id
(In reply to Philippe Condé from comment #23) > Created attachment 636666 [details] > output of /lib/udev/scsi_id Ok, scsi_id is correctly using page 0x83. Seems that ID_SCSI_SERIAL is unusable for udev, at least in hardware raid setups. Hannes, can we get a comment on this? Who's using and why is using ID_SCSI_SERIAL? (In reply to Robert Milasan from comment #25) > Who's using and why is using ID_SCSI_SERIAL? Ah, Robert, you are right, it isn't ID_SCSI_SERIAL. It is ID_SERIAL_COMPAT from codepage 0x80. See this rule, it calls explicitely page 0x80: -->-- # scsi compat links for ATA devices KERNEL=="sd*[!0-9]", ENV{ID_BUS}=="ata", PROGRAM="scsi_id --whitelisted --replace-whitespace -p0x80 -d $devnode", RESULT=="?*" , ENV{ID_SCSI_COMPAT}="$result", SYMLINK+="disk/by-id/scsi-$env{ID_SCSI_COMPAT}" KERNEL=="sd*[0-9]", ENV{ID_SCSI_COMPAT}=="?*", SYMLINK+="disk/by-id/scsi-$env{ID_SCSI_COMPAT}-part%n" --<-- But in any case: This is a firmware issue. The 'hpsa' driver is responsible for retrieving page 0x80 from the HBA firmware. As the driver doesn't modify the returned contents the firmware returns incorrect information. So it's more an issue for HP. Ok, thanks Robert, Hannes.
Philippe, your raid controllers firmware does soemthing wrong.
Either it wrongly reports the bus to be ata (ENV{ID_BUS}=="ata") or it reports a wrong ID_SERIAL for your disks.
Can you please check wheter there is a firmware update for your raid controller available?
Hello, the system is a HP proliant ML350p gen8 with a hardware raid controller p420i I checked on HP site for this system and opensuse: The only firmware controller is at version 1.28 (opensuse 11.4) But my current firmware is at version 4.68. for SLES 12 I find a more recent firmware (6.34) but the fixes are related to raid6 and other system (blade systems) see http://h20565.www2.hp.com/hpsc/swd/public/detail?sp4ts.oid=5195931&swItemId=MTX_13fcbd530be24670b72b5c96fe&swEnvOid=4175#tab5 If you think that this should solve the problem I can try to install this version but I'm not sure that SLES 12 version is compatible with Opensuse Tumbleweed Regards Philippe Created attachment 636906 [details]
KInfoCenter
Hello
See attached kinfo.txt
This is the output from KInfoCenter: I find this for the device information ==> scsi
I don't see any sata?
Regards
Philippe
(In reply to Philippe Condé from comment #37) > Created attachment 636906 [details] > KInfoCenter > > Hello > > See attached kinfo.txt > This is the output from KInfoCenter: I find this for the device information > ==> scsi > > I don't see any sata? It depends what udev sees. Can you please provide the ouptut of: udevadm info /dev/sda udevadm info /dev/sdb udevadm info /dev/sdc Created attachment 637074 [details]
udevadm output
Hello,
Here the output.
Remark that I have two sata devices
- 1 dvdrom
- 1 dvdram
But udevadm gives scsi as far as I see for sda, sdb and sdc
Regards
Philippe
(In reply to Philippe Condé from comment #39) > Created attachment 637074 [details] > udevadm output > > Hello, > > Here the output. > > Remark that I have two sata devices > - 1 dvdrom > - 1 dvdram > > But udevadm gives scsi as far as I see for sda, sdb and sdc > Regards > Philippe Ok, thanks, now it's clear. It isn't a wrong identification of your disks as ata devices. It is a wrong value in codepage 0x80. /lib/udev/rules.d/58-scsi-sg3_symlink.rules is using SCSI_IDENT_SERIAL, which takes the value of 'Unit serial number' from codepage 0x80. The value of 'Unit serial number' must be uniqe for a disk. I your case, it is not. I'd recommend to report this as a firmware bug to HP. As an interim solution, you might just comment out the problematic rule, so that the symlinks don't get created (they are broken anyway since they can point to any of your scsi disks). Hello, I checked in /etc/udev/rules.d but I don't have the 58-scsi-sg3_symlink.rules I find only 40-xen.rules 55-iscan.rules 55-libsane.rules 56-sane-backends-autoconfig.rules 60-libpisock.rules 70-persistent-net.rules I'll try to open an incident by HP Regards Philippe Hello,
I updated the firmware op the raid controller to the last version (6.34) but this doesn't help.
I have seen that I didn't read carefully your last comment and was not looking in the correct library.
I have then changed the file /lib/udev/rules.d/58-scsi-sgr_symlink.rules
I commented first the line
ENV{SCSI_IDENT_SERIAL}=="?*", ENV{DEVTYPE}=="disk", SYMLINK+="disk/by-id/scsi-S$env{SCSI_VENDOR}_$env{SCSI_MODEL}_$env{SCSI_IDENT_SERIAL}"
and rebooted the system but some error messages were still present
I commented then also the next line:
ENV{SCSI_IDENT_SERIAL}=="?*", ENV{DEVTYPE}=="partition", SYMLINK+="disk/by-id/scsi-S$env{SCSI_VENDOR}_$env{SCSI_MODEL}_$env{SCSI_IDENT_SERIAL}-part%n"
After reboot the error messages have disappear.
One question: are there some drawback with these settings?
Many thanks in advance
Philippe
(In reply to Philippe Condé from comment #45) > Hello, > > I updated the firmware op the raid controller to the last version (6.34) but > this doesn't help. > > I have seen that I didn't read carefully your last comment and was not > looking in the correct library. > > I have then changed the file /lib/udev/rules.d/58-scsi-sgr_symlink.rules > I commented first the line > ENV{SCSI_IDENT_SERIAL}=="?*", ENV{DEVTYPE}=="disk", > SYMLINK+="disk/by-id/scsi- > S$env{SCSI_VENDOR}_$env{SCSI_MODEL}_$env{SCSI_IDENT_SERIAL}" > and rebooted the system but some error messages were still present > > I commented then also the next line: > ENV{SCSI_IDENT_SERIAL}=="?*", ENV{DEVTYPE}=="partition", > SYMLINK+="disk/by-id/scsi- > S$env{SCSI_VENDOR}_$env{SCSI_MODEL}_$env{SCSI_IDENT_SERIAL}-part%n" > > After reboot the error messages have disappear. Ok > One question: are there some drawback with these settings? > It would only be problematic if something would be using these symlinks (for example mounts or lvm). But per default they are not used, so you can savely omit them. Since the open questions are clarified, I'm closing the bug. |