System boots in emergency mode with iscsi and multipath device enabled in fstab

Latest response


we have a Lenovo DE4000 Storage running.
We configured the iscsi and multipath connection to the storage and can connect and use the shares without any problems.

mpathb (36d039ea0002af9e60000013261531515) dm-0 LENOVO,DE_Series
size=40T features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=enabled
| |- 16:0:0:1 sde  8:64   active ready running
| |- 17:0:0:1 sdf  8:80   active ready running
| |- 23:0:0:1 sdo  8:224  active ready running
| |- 24:0:0:1 sdr  65:16  active ready running
| |- 22:0:0:1 sdn  8:208  active ready running
| `- 19:0:0:1 sdl  8:176  active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  |- 15:0:0:1 sdd  8:48   active ready running
  |- 18:0:0:1 sdg  8:96   active ready running
  |- 20:0:0:1 sdp  8:240  active ready running
  |- 26:0:0:1 sdt  65:48  active ready running
  |- 25:0:0:1 sds  65:32  active ready running
  `- 21:0:0:1 sdm  8:192  active ready running
mpatha (36d039ea0002b0edd0000015161531658) dm-2 LENOVO,DE_Series
size=10T features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=enabled
| |- 15:0:0:2 sdh  8:112  active ready running
| |- 18:0:0:2 sdk  8:160  active ready running
| |- 25:0:0:2 sdaa 65:160 active ready running
| |- 20:0:0:2 sdz  65:144 active ready running
| |- 26:0:0:2 sdy  65:128 active ready running
| `- 21:0:0:2 sdu  65:64  active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  |- 16:0:0:2 sdi  8:128  active ready running
  |- 17:0:0:2 sdj  8:144  active ready running
  |- 19:0:0:2 sdq  65:0   active ready running
  |- 22:0:0:2 sdv  65:80  active ready running
  |- 24:0:0:2 sdx  65:112 active ready running
  `- 23:0:0:2 sdw  65:96  active ready running

The next step was to put these devices into the fstab and mount the shares at boot.
If we do this, the system boots up and finally goes into the Emergency Mode because it can not reach the shares.

If I login into the console I can see that the network connection is not active but iscsid and multipathd are running at this moment, so it is correct that the system can not reach the devices. My understanding of systemd startup is that the multipath service is depending from the Network Manager, so the network config should be active at this time. @2min 20.718s
└─ @2min 20.718s
  └─getty@tty1.service @2min 20.718s
    └─plymouth-quit-wait.service @2min 20.674s +40ms
      └─systemd-user-sessions.service @2min 20.646s +19ms
        └─ @2min 20.643s
          └─ @2min 20.643s
            └─iscsi.service @6.360s +2min 14.281s
              └─iscsid.service @6.330s +23ms
                └─ @6.327s
                  └─network.service @4.667s +1.658s
                    └─NetworkManager-wait-online.service @3.629s +1.033s
                      └─NetworkManager.service @3.581s +44ms
                        └─ @3.579s
                          └─firewalld.service @3.106s +472ms
                            └─polkit.service @2.965s +138ms
                              └─ @2.960s
                                └─ @2.960s
                                  └─cockpit.socket @2.913s +46ms
                                    └─ @2.905s
                                      └─systemd-update-utmp.service @2.882s +22ms
                                        └─auditd.service @2.802s +76ms
                                          └─systemd-tmpfiles-setup.service @2.725s +71ms
                                            └─import-state.service @2.673s +49ms
                                              └─ @2.671s
                                                └─boot-efi.mount @2.638s +32ms
                                                  └─boot.mount @2.606s +23ms
                                                    └─systemd-fsck@dev-disk-by\x2duuid-f626ce00\x2d15c0\x2d40b2\x2da1b4\x2d7bb2caf135af.service @2.561s +38ms
                                                      └─ @2.550s
                                                        └─multipathd.service @2.474s +75ms
                                                          └─systemd-udev-settle.service @731ms +1.741s
                                                            └─systemd-udev-trigger.service @473ms +235ms
                                                              └─systemd-udevd-control.socket @472ms

What i do not understand is how the iscsid service should be active before the NetworkManager -> no net, no iscsi ....

If I disable the fstab entries the system boots normal and after the boot i can see all shares.

Can someone give me i hint how to handle this correct and eventually why this happens or there my mistake in thinking is.





I ran into the same problem

Refer to the link below and the problem has been resolved

Hello Dayan,

thanks for your response and the link. The usage of the "nowait" option was also my fix.

But i think that this is only a fix and not a solution. If i understand the problem right then the solution has to be the right order/dependecies of the services like in former RedHat systems. We had no iscsi fstab mount problems with an old RHEL6 system ....



Hi Silvio,

(Thanks Dayan he for the tip to Silvio)

Just curious what you had in /etc/fstab for this filesystem now that it is working. While this Red Hat solution does not specifically mention RHEL8, I've seen where adding _netdev can make a difference from instructors mentioning this in RHEL classes (I've not used iscsi, we use SAN a lot though, and use _netdev).

If your issue is resolved, can you make an update here of the one line in /etc/fstab that now works?