Bug 1161779

Summary: System fails to boot with rootfs on iSCSI - missing kernel parameters
Product: [Fedora] Fedora Reporter: Jan Stodola <jstodola>
Component: systemdAssignee: systemd-maint
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: 21CC: anaconda-maint-list, g.kaviyarasu, johannbg, jonathan, jstodola, jsynacek, kparal, lnykryn, mkolman, msekleta, robatino, rvykydal, sbueno, s, systemd-maint, vanmeeuwen+fedora, vpavlin, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: AcceptedBlocker
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-11-17 15:39:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1043129    
Attachments:
Description Flags
anaconda.log
none
grub.cfg
none
ifcfg.log
none
packaging.log
none
program.log
none
storage.log
none
syslog
none
X.log none

Description Jan Stodola 2014-11-07 20:58:14 UTC 
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
Comment 1 Jan Stodola 2014-11-07 20:59:24 UTC 
Created attachment 955083 [details]
anaconda.log
Comment 2 Jan Stodola 2014-11-07 20:59:26 UTC 
Created attachment 955084 [details]
grub.cfg
Comment 3 Jan Stodola 2014-11-07 20:59:28 UTC 
Created attachment 955085 [details]
ifcfg.log
Comment 4 Jan Stodola 2014-11-07 20:59:31 UTC 
Created attachment 955086 [details]
packaging.log
Comment 5 Jan Stodola 2014-11-07 20:59:34 UTC 
Created attachment 955087 [details]
program.log
Comment 6 Jan Stodola 2014-11-07 20:59:38 UTC 
Created attachment 955088 [details]
storage.log
Comment 7 Jan Stodola 2014-11-07 20:59:41 UTC 
Created attachment 955089 [details]
syslog
Comment 8 Jan Stodola 2014-11-07 20:59:43 UTC 
Created attachment 955090 [details]
X.log
Comment 9 Fedora Blocker Bugs Application 2014-11-07 21:09:31 UTC 
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).
Comment 10 Radek Vykydal 2014-11-10 10:52:14 UTC 
Most probably has the same root cause as bug 1161644.
Comment 11 Kamil Páral 2014-11-12 16:15:06 UTC 
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/
Comment 12 David Shea 2014-11-14 15:07:34 UTC 
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.
Comment 13 David Shea 2014-11-14 15:08:21 UTC 
*** Bug 1161644 has been marked as a duplicate of this bug. ***
Comment 14 Zbigniew Jędrzejewski-Szmek 2014-11-16 14:28:21 UTC 
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.
Comment 15 Jan Stodola 2014-11-17 15:39:54 UTC 
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.