Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1880673 - iSCSI target add fails since iscsi-initiator-utils-6.2.1.2-0.git802688d.fc34
Summary: iSCSI target add fails since iscsi-initiator-utils-6.2.1.2-0.git802688d.fc34
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: python-blivet
Version: rawhide
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Blivet Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa
: 1882888 (view as bug list)
Depends On:
Blocks: F34FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2020-09-18 23:43 UTC by Adam Williamson
Modified: 2020-10-20 08:43 UTC (History)
18 users (show)

Fixed In Version: python-blivet-3.3.1-1.fc34
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-20 08:43:03 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Adam Williamson 2020-09-18 23:43:58 UTC 
In Fedora-Rawhide-20200918.n.0, the openQA iSCSI install test started failing:

https://openqa.fedoraproject.org/tests/670332

the backtrace looks like this:

===

06:25:19,737 CRT exception: Traceback (most recent call last):

  File "/usr/lib64/python3.9/site-packages/pyanaconda/ui/gui/spokes/advanced_storage.py", line 701, in on_add_iscsi_clicked
    self._run_dialog_and_refresh(dialog)

  File "/usr/lib64/python3.9/site-packages/pyanaconda/ui/gui/spokes/advanced_storage.py", line 727, in _run_dialog_and_refresh
    dialog.refresh()

  File "/usr/lib64/python3.9/site-packages/pyanaconda/ui/gui/spokes/advstorage/iscsi.py", line 96, in refresh
    self._initiatorEntry.set_text(self._iscsi_module.Initiator)

  File "/usr/lib/python3.9/site-packages/dasbus/client/proxy.py", line 164, in __getattr__
    return member.get()

  File "/usr/lib/python3.9/site-packages/dasbus/client/property.py", line 43, in get
    return self.__get__(None, None)

  File "/usr/lib/python3.9/site-packages/dasbus/client/property.py", line 54, in __get__
    return self._getter()

  File "/usr/lib/python3.9/site-packages/dasbus/client/handler.py", line 376, in _get_property_value
    variant = self._call_method(

  File "/usr/lib/python3.9/site-packages/dasbus/client/handler.py", line 444, in _call_method
    return self._get_method_reply(

  File "/usr/lib/python3.9/site-packages/dasbus/client/handler.py", line 477, in _get_method_reply
    return self._handle_method_error(error)

  File "/usr/lib/python3.9/site-packages/dasbus/client/handler.py", line 497, in _handle_method_error
    raise exception from None

dasbus.error.DBusError: Failed to call GetInitiatorNameRaw method on /org/freedesktop/UDisks2/Manager with None arguments: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code4: Error reading iSCSI initiator name from '/etc/iscsi/initiatorname.iscsi': Failed to open file “/etc/iscsi/initiatorname.iscsi”: No such file or directory

===

anaconda did change in this compose, but I think the more likely cause is an update to iscsi-initiator-tools from 6.2.1.1-0.gitac87641.fc33.2 to 6.2.1.2-0.git802688d.fc34 , with this probably-significant changelog entry:

- Remove initiator name generation, as this is now handled by an init service
Comment 1 Adam Williamson 2020-09-18 23:45:14 UTC 
Sorry, I meant iscsi-initiator-utils , not iscsi-initiator-tools .

Proposing as an F34 Final blocker as a violation of Final criterion "The installer must be able to detect (if possible) and install to supported network-attached storage devices."
Comment 2 Vojtech Trefny 2020-09-21 11:04:54 UTC 
> Failed to open file “/etc/iscsi/initiatorname.iscsi”: No such file or directory

The problem is the "initiatorname.iscsi" file is no longer created in iscsi-initiator-utils %post section. It is now created by the new iscsi-init service which is required only by iscsi service and we are starting iscsid in blivet. We could simply start the service in blivet, but I'm not sure if this is the right place. Maybe UDisks should do that or iscsid should also require iscsi-init.

Related iscsi bug https://bugzilla.redhat.com/show_bug.cgi?id=1493296 and upstream PR https://github.com/open-iscsi/open-iscsi/pull/207

Christian who do you think should start the service to make sure the initiatorname.iscsi file exists?
Comment 3 Tomáš Bžatek 2020-09-21 12:40:22 UTC 
(In reply to Vojtech Trefny from comment #2)
> > Failed to open file “/etc/iscsi/initiatorname.iscsi”: No such file or directory
> 
> Maybe UDisks should do that or iscsid should also require iscsi-init.

The only rpm spec requirement that would make sense would be a presence of the iscsi-init.service systemd service. Would simple `Requires: %{_unitdir}/etc/systemd/iscsi-init.service` work or is there a specific rpm systemd macro available?

I think returning an error in case no initiator name has been set and preventing further access to UDisks2 iscsi module API is a proper way to go. There's no monitoring for initiator name change either.
Normally I would say something like "but for portability reasons..." however the open-iscsi's libiscsi is still downstream only. Foreign system service management should not be part of UDisks however, we would need to deal with supporting the number of init systems out there.
Comment 4 Christian Glombek 2020-09-22 14:09:33 UTC 
The iscsi.service unit declares a dependency on iscsi-init.service - i.e. if the service is started with systemd, the init service is started automatically.
Since the init service is installed as part of the RPM, I don't think an RPM Requires for it makes sense on the same package.

I am not familiar with the way openQA tests this, can it not start the service via systemd?
Comment 5 Vojtech Trefny 2020-09-29 04:59:12 UTC 
*** Bug 1882888 has been marked as a duplicate of this bug. ***
Comment 6 Adam Williamson 2020-10-04 17:24:11 UTC 
Christian: this is in the installer environment. openQA imitates a normal person running an interactive install and expects to be able to use an iSCSI device in the usual and documented way in the installer interface. No normal person running a Fedora install to an iSCSI target would expect to need to drop to a console and start a systemd service in order to be able to run the install.
Comment 7 Adam Williamson 2020-10-04 17:26:58 UTC 
To extend that a bit - yes, technically I *could* make the openQA test drop to a console and enable the service, but to do so would be nonsensical because it would defeat the purpose of the test. The purpose of the test is to ensure that a normal person installing in the normal way meets with success, thus it makes no sense to add workarounds to the test which we would not expect our users to have to do in order to install successfully.
Comment 8 Christian Glombek 2020-10-04 21:06:09 UTC 
If using systemd is not a viable option here, then I guess Anaconda will have to learn how to populate the `/etc/iscsi/initiatorname.iscsi` file itself, in a way similar to how the init service does it:
https://github.com/open-iscsi/open-iscsi/blob/master/etc/systemd/iscsi-init.service#L8

To give some context on why this change was made:
Initialization of that file in the RPM's %post directive as it was done before is incompatible with rpm-ostree images, because there %post is run server-side at compose time and the generated name would be hardcoded in the image and thus the same on every install.
Using an init service instead is what the packaging guidelines suggest in such a case.
Comment 9 Vendula Poncova 2020-10-05 16:04:31 UTC 
Fixed in a pull request: https://github.com/storaged-project/blivet/pull/903
Comment 10 Adam Williamson 2020-10-19 22:42:22 UTC 
The PR has been merged, but it seems a new release/build of blivet hasn't yet been done. Could we get one, please? Thanks!
Note You need to log in before you can comment on or make changes to this bug.