Bug 236393 - sysutils/sg3_utils After update to 1.44 relative path of device is no longer accepted
Summary: sysutils/sg3_utils After update to 1.44 relative path of device is no longer ...
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-ports-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-03-08 14:05 UTC by Andrew
Modified: 2019-10-12 20:29 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback?


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew 2019-03-08 14:05:26 UTC
I do not know if it is the intended behavior from now on, but after the latest upgrade (from 1.42 to 1.44), sg3_utils commands do not take for granted the "/dev" prefix any longer in the device name parameter. This broke some scripts of ours which leverage the sg_persist(8) command.

Here is an example transcript:

# sg_persist -V
version: 0.52 20160201
# sg_persist -i -s da0
  FREEBSD   CTLDISK           0001
  Peripheral device type: disk
  PR generation=0x9
    Key=0x223220250
      All target ports bit clear
      Relative port address: 0x6
      << Reservation holder >>
      scope: LU_SCOPE,  type: Write Exclusive
      Transport Id of initiator:
        iSCSI world wide unique port id: iqn.1994-09.org.freebsd:xxx.xxx.xxx,i,0x80118193bc0b

# sg_persist -V
version: 0.66 20180615
# sg_persist -i -s da0
scsi_pt_open_flags: unable to stat(da0): No such file or directory
sg_persist: error opening file (ro): da0: No such file or directory


I examined the changelog (https://github.com/hreinecke/sg3_utils/blob/master/ChangeLog), but I didn't find anything about this.
Comment 1 Walter Schwarzenfeld freebsd_triage 2019-08-14 11:13:00 UTC
Maintainer feedback, please !
Comment 2 Andrew 2019-10-12 16:48:02 UTC
Since we noticed that sg_persist(8) coming from version 1.44 of sg3_utils also presented another issue (it does not seem to be able to register a disk device ignoring any previous registration key), we just gave up to use it and changed our code to use camcontrol(8), which is integrated in FreeBSD base.

Since we do not make use of this port anymore, we are not directly interested in its behavior. Still waiting a little more for maintainer's feedback before closing this PR.