@yuwata, thanks for your thorough review. I fixed the issues you mentioned.

Hmm... I think removing scsi_id is drastic change. It may be used somewhere. Rather than completely 'kill' it, I prefer that scsi_id outputs a deprecate message and announce that somewhere, e.g. NEWS.

I am not sure that it can be comparable, but udevadm hwdb command is deprecated few years ago, but it still left there for compatibility.

I was about to comment about the same thing; my idea for this whole conversion is to move all calls to scsi_id out of 60-persistent-storage.rules (like Martin did), but keep it in a rule set which complements the sg3_utils rules. The overall idea would be that one could keep one or other (or both or, of course, none); we would then have a series like

55-scsi-sg3_id.rules
58-scsi-sg3_symlink.rules
59-scsi-scsi_id.rules
60-persistent-storage.rules

And one could leave out the first two (if eg sg3_utils is not installed), or the 59 rules (if and when scsi_id gets deprecated), and still get the same user experience.

@yuwata, I had the impression that removing scsi_id was a set goal. One reason was the line in the TODO file that my patch removes, another remarks from @poettering I'd seen (e.g. his first comment on #7190), as well as various discussions with @hreinecke and @fbuihuu. I'm also quite positive that there are hardly any users of scsi_id outside udev/systemd.

However, if you prefer to keep it around, I've no problem with dropping the last patch in the series.

I'm sick today, I'll look into the build/packaging failures in detail later.
Obviously the additional rules files may cause packaging errors. They will also require changes in dracut.

OTOH scsi_id lives in /usr/lib/udev so it's not supposed to be used by anything but udev.

dropping scsi_id makes a lot of sense to me, but i figure @kaysievers should review this before we merge this.

@hreinecke, I'm not sure I understand your proposal correctly. It's crucial to separate

1. determination of device properties and creation of udev environment variables
2. symlink creation based on environment variables
3. further processing based on environment variables

After applying my patch set, the job of 60-persistent-storage.rules is 2.) exclusively - creation of symlinks based on certain generic environment variables which all follow the ID_xxx naming convention. We don't care any more by which utility these ID_xxx variables had been set before. It could be scsi_id, sg_inq, or whatever else. That's a big step forward.

This distinction should be mapped to rule numbers, too. In particular, 60 should be the separator between 1.) and 2.) above. IOW, SYMLINK calls should start only after 60. The rationale is simple - be sure all variables are correctly set before starting to set symlinks (there are a few exceptions for device-mapper rules currently, which we may want to address at a later stage).

It's also important to split step 1) above into hardware property detection an content-based property detection, mostly because we need to make "further processing" decisions between these two steps (think multipath). We need a distinction by number here as well, and as multipath is currently at 56, I chose that. Unfortunately, number space is becoming a bit tight between 55 and 60.

If we decide to keep scsi_id calls for setting ID_xxx variables, these rules should be placed after 55-scsi-sg3_utils.rules and before 56-multipath.rules. That's a bit tricky but it can be done.

58-scsi-sg3_symlink.rules is a bit special. It creates lots of symlinks which are not normally used by systemd or other tools which aren't specific to SCSI. I wonder if anyone except SUSE is using it.

There has been no progress for 4 weeks, any suggestions?

Rebased, and modified the patch set as follows:

Instead of instantly removing the calls to scsi_id, I move them to a separate, new rule file "55-zz-scsi_id.rules". This means the rules using scsi_id are still in place. So distributions or users can choose using these or using something else (I would recommend sg3_utils). The scsi_id rules are only run if nothing else has set ENV{ID_SERIAL}.

The last patch removes the new rules file again, together with scsi_id itself. The idea is to give systemd maintainers the chance to wait a bit until killing of scsi_id, and open a migration path, by applying this series without the last patch. This also unties the dependency to the sg3_utils pull request hreinecke/sg3_utils#22 (as long as scsi_id rules are in present, no replacement is necessary).

Furthermore, I merged together the commits affecting the same device classes. I think review is easier this way, as you can see better how code is moved.

The udev rules from this patch set have been tested with various SCSI devices including disks, tapes, and medium changers, both using the scsi_id rules (all but last patch applied) and using the sg3_utils rules. I also verified that sg3_utils rules take precedence if both are installed. More testing is of course always welcome.

So, 5+ years, issue still appears on Supermicro X10DDW-iN + Intel® C612 chipset.
any chance to catch it ?

So, 5+ years, issue still appears on Supermicro X10DDW-iN + Intel® C612 chipset. any chance to catch it ?

What issue are you referring to concretely?

@mwilck referenced one #7157
tl;tr : same ID_PATH reported by udev

see #7157 (comment)

@mwilck missed by me! thanks. will reply to origin

@mwilck Any chance to see this merged in the near future? I see this issue over and over in Ubuntu where sg3_utils is present and that breaks 60-persistent-storage rules, preventing ata_id properties to be imported. This have some nasty implications around disks APM capabilities not detected downstream.