Description of problem: System doesn't boot after installation with rootfs on iSCSI LUN. Booting ends up in dracut emergency shell. Looking at the kernel boot options in grub.cfg, there are no iscsi target/lun parameters and network configuration is missing too: dracut:/# cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.17.2-300.fc21.x86_64 root=UUID=02e386f2-d4af-43ff-9916-5dccbe001317 ro LANG=en_US.UTF-8 console=ttyS0 dracut:/# Version-Release number of selected component (if applicable): Fedora 21_TC1 anaconda-21.48.13-1 How reproducible: always Steps to Reproduce: 1. start graphical installation 2. add an iSCSI LUN 3. create following partitioning: /boot and swap on local disk rootfs on the iSCSI LUN 4. finish the installation and reboot Actual results: system doesn't start, cannot mount rootfs Expected results: system starts successfully with all filesystems mounted Additional info: Test case: https://fedoraproject.org/wiki/QA:Testcase_install_to_iSCSI_no_authentication
Created attachment 955083 [details] anaconda.log
Created attachment 955084 [details] grub.cfg
Created attachment 955085 [details] ifcfg.log
Created attachment 955086 [details] packaging.log
Created attachment 955087 [details] program.log
Created attachment 955088 [details] storage.log
Created attachment 955089 [details] syslog
Created attachment 955090 [details] X.log
Proposed as a Blocker for 21-final by Fedora user jstodola using the blocker tracking app because: Fedora 21 Final Release Criteria is not met: The installer must be able to detect (if possible) and install to supported network-attached storage devices. Supported network-attached storage types include iSCSI, Fibre Channel and Fibre Channel over Ethernet (FCoE).
Most probably has the same root cause as bug 1161644.
Discussed at today's blocker review meeting [1]. Accepted as a blocker. This is a clear violation of the Final criteria: "The installer must be able to detect (if possible) and install to supported network-attached storage devices." [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2014-11-12/
Moving to systemd. Like Radek says, the underlying cause is that we can no longer detect iscsi disks as being iscsi. systemd 216 removed ID_PATH from the information passed to us by udev (see http://cgit.freedesktop.org/systemd/systemd/commit/?id=e98bbfd2074e2b1079b7059341eac25741baf319). The problem being that this was an unannounced API change to a base system component, and we kind of need that information.
*** Bug 1161644 has been marked as a duplicate of this bug. ***
Hm, I don't see the systemd version in either of the reports. systemd-python-216-8.fc21.x86_64 is listed in packaging.log, but I'm not sure if it's the one running when the problem is exhibited. Anyway, this should be fixed by systemd-216-11.fc21 (currently in stable). It'd be great if you could confirm that.
Retested on Fedora 21 TC2 with systemd-216-11.fc21, this issue is fixed. Installation finished successfully, iscsi kernel command line parameters are present in grub.conf and system boots after reboot with iSCSI root file system mounted: [root@rh-g3 ~]# cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.17.2-300.fc21.x86_64 root=UUID=c8364acc-5039-4a44-9511-ca6ae53b2b3a ro netroot=iscsi:@10.16.67.167::3260::iqn.2009-02.com.example:for.all ip=eth0:dhcp iscsi_initiator=iqn.1994-05.com.redhat:4239b0ed319e console=ttyS0,115200 LANG=en_US.UTF-8 [root@rh-g3 ~]# "udevadm info --export-db" returns ID_PATH for iscsi devices: E: ID_PATH=ip-10.16.67.167:3260-iscsi-iqn.2009-02.com.example:for.all-lun-1 E: ID_PATH_TAG=ip-10_16_67_167_3260-iscsi-iqn_2009-02_com_example_for_all-lun-1 E: ID_PATH=ip-10.16.67.167:3260-iscsi-iqn.2009-02.com.example:for.all-lun-1 E: ID_PATH_TAG=ip-10_16_67_167_3260-iscsi-iqn_2009-02_com_example_for_all-lun-1 Closing the bug as fixed.