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
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."
> 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?
(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.
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?
*** Bug 1882888 has been marked as a duplicate of this bug. ***
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.
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.
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.
Fixed in a pull request: https://github.com/storaged-project/blivet/pull/903
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!