Bug 1908847 - [4.6.z] RHCOS 4.6 - Missing Initiatorname
Summary: [4.6.z] RHCOS 4.6 - Missing Initiatorname
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: RHCOS
Version: 4.6
Hardware: x86_64
OS: Linux
Target Milestone: ---
: 4.6.z
Assignee: Jonathan Lebon
QA Contact: Michael Nguyen
Depends On: 1908830
TreeView+ depends on / blocked
Reported: 2020-12-17 17:50 UTC by Micah Abbott
Modified: 2021-01-18 17:59 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: The service unit which regenerates the iSCSI initiator name only worked on first boot. Consequence: Upgrading nodes would not receive uniquely generated initiator names. Fix: The service unit now runs on every boot. Result: Upgrading nodes now receive generated initiator names if one doesn't already exist.
Clone Of: 1908830
Last Closed: 2021-01-18 17:59:31 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2021:0037 0 None None None 2021-01-18 17:59:57 UTC

Description Micah Abbott 2020-12-17 17:50:24 UTC
+++ This bug was initially created as a clone of Bug #1908830 +++

Description of problem:
RHCOS compute nodes does not have /etc/iscsi/initiatorname.iscsi

[core@compute-1 ~]$ cat /etc/iscsi/initiatorname.iscsi
cat: /etc/iscsi/initiatorname.iscsi: No such file or directory

Version-Release number of selected component (if applicable):
[core@csah ~]$ oc get clusterversion
version   4.6.8     True        False         3h46m   Cluster version is 4.6.8

How reproducible:

- Any basic install of RHCOS will show the file not being created.

Actual results:

[core@compute-1 ~]$ systemctl status coreos-generate-iscsi-initiatorname
● coreos-generate-iscsi-initiatorname.service - CoreOS Generate iSCSI Initiator Name
   Loaded: loaded (/usr/lib/systemd/system/coreos-generate-iscsi-initiatorname.service; enabled; vendor preset: enabled)
   Active: inactive (dead)
Condition: start condition failed at Thu 2020-12-17 17:05:21 UTC; 4s ago
           └─ ConditionFirstBoot=true was not met
     Docs: https://bugzilla.redhat.com/show_bug.cgi?id=1493296

[core@compute-1 ~]$ cat /etc/iscsi/initiatorname.iscsi
cat: /etc/iscsi/initiatorname.iscsi: No such file or directory

Expected results:
- Service coreos-generate-iscsi-initiatorname should be in running state and file /etc/iscsi/initiatorname.iscsi to be created with a unique iscsi name

Additional info:
Same bug is opened in https://bugzilla.redhat.com/show_bug.cgi?id=1901021. It is mentioned in the report that, 4.6.7 should fix this but considering I am currently in 4.6.8 and not seeing the necessary file, reopening the BUG again as per the comment

https://bugzilla.redhat.com/show_bug.cgi?id=1904243 is also created with same BUG but the version is set to 4.7. I am not sure if we need to wait till 4.7 to get this fixed. If that is the case, need to find an alternative to get this fixed in 4.6.x versions as this a long term support version.

--- Additional comment from Micah Abbott on 2020-12-17 17:49:37 UTC ---

The service is configured to run only at first boot, so that's why the file is not being generated on upgrades.

We can modify our service to drop the `ConditionFirstBoot` and just let the service test for the `/etc/iscsi/initiatorname.iscsi` file, so any installs that are missing the file will get a new initiatorname generated.

This matches the upstream change that will should be delivered as part of RHEL 8.4


Comment 2 Micah Abbott 2021-01-04 18:49:30 UTC
This change landed in RHCOS 4.6 build 46.82.202012182233-0

Comment 5 Michael Nguyen 2021-01-06 14:40:35 UTC
Verfied on 4.6.0-0.nightly-2021-01-05-203053

$ oc get clusterversion
NAME      VERSION                             AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.6.0-0.nightly-2021-01-05-203053   True        False         104s    Cluster version is 4.6.0-0.nightly-2021-01-05-203053

$ oc get node -o name | xargs -I {} oc debug {} -- chroot /host cat /etc/iscsi/initiatorname.iscsi
Starting pod/ip-10-0-131-102us-west-2computeinternal-debug ...
To use host binaries, run `chroot /host`

Removing debug pod ...
Starting pod/ip-10-0-151-28us-west-2computeinternal-debug ...
To use host binaries, run `chroot /host`

Removing debug pod ...
Starting pod/ip-10-0-165-63us-west-2computeinternal-debug ...
To use host binaries, run `chroot /host`

Removing debug pod ...
Starting pod/ip-10-0-167-229us-west-2computeinternal-debug ...
To use host binaries, run `chroot /host`

Removing debug pod ...
Starting pod/ip-10-0-208-239us-west-2computeinternal-debug ...
To use host binaries, run `chroot /host`

Removing debug pod ...
Starting pod/ip-10-0-221-245us-west-2computeinternal-debug ...
To use host binaries, run `chroot /host`

Comment 7 errata-xmlrpc 2021-01-18 17:59:31 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: OpenShift Container Platform 4.6.12 bug fix and security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.