Bug 519412 - dracut doesn't boot on iscsi root
Summary: dracut doesn't boot on iscsi root
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 11
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2009-08-26 14:28 UTC by Alexander Todorov
Modified: 2009-08-27 14:21 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-08-27 14:21:39 UTC

Attachments (Terms of Use)
/tmp from dracut shell (3.53 KB, application/x-gzip)
2009-08-26 14:59 UTC, Alexander Todorov
no flags Details
output from dracut -f -v initrd.img `uname -r` (98.31 KB, text/plain)
2009-08-27 10:44 UTC, Jan Stodola
no flags Details
/tmp from dracut shell when using NBD root (2.65 KB, application/x-gzip)
2009-08-27 11:49 UTC, Alexander Todorov
no flags Details
/tmp from dracut shell with iSCSI and updated dracut/udev from rawhide (3.50 KB, application/x-gzip)
2009-08-27 13:45 UTC, Alexander Todorov
no flags Details

Description Alexander Todorov 2009-08-26 14:28:18 UTC
Description of problem:
A system with iSCSI root doesn't boot when initrd is generated by dracut.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Configure iSCSI target. Mine is RHEL5 server with scsi-target-utils
2. Install F11-GOLD in xen PV guest with local /boot disk and / on the iSCSI target. Configure / in Anaconda and complete the install. The system has only 1 NIC.
3. System boots fine
4. yum install dracut --enablerepo=updates-testing
5. dracut -H /boot/dracut.img $(uname -r)
6. configure grub (grub.conf is attached below)
7. reboot into new target
Actual results:
Can't find root file system. System fails to boot. 

Expected results:
System boots.

Additional info:
I think dracut is not making any DHCP requests to bring up the interface. 

Looking at my DHCP server (cheap hardware device) there's no trace of DHCP requests when booting with dracut. Booting with standard initrd makes the DHCP server produce log entries. 

I can try executing this against dhcpd and get some real log files if needed.

# grub.conf generated by anaconda
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/sda1
#          initrd /initrd-version.img
title Fedora (
        root (hd0,0)
        kernel /vmlinuz- ro root=UUID=6d320d2d-57bc-427e-a1ec-58c276488ce1 rhgb quiet 
        initrd /initrd-
title Dracut
        root (hd0,0)
        kernel /vmlinuz- ro root=UUID=6d320d2d-57bc-427e-a1ec-58c276488ce1 netroot=iscsi: ip=eth0:dhcp 
        initrd /dracut.img

Comment 1 Alexander Todorov 2009-08-26 14:33:16 UTC
booting with `rdinitdebug rdbreak rdnetdebug' appended dracut drops me to a shell where under /tmp I have only 3 files:

net.bootdev - contains "eth0"
net.ifaces - contains "eth0"
root.info - contains the boot parameters and they look just fine. 

Booting with ip=dhcp instead of ip=eth0:dhcp the contents of /tmp are:
ifup.lo.322.out - looks like it tries to bring up the loopback interface
net.lo.up - empty
root.info - same as before

Comment 2 Alexander Todorov 2009-08-26 14:36:32 UTC
with ip=eth0:dhcp I get:

# ip addr show
1: lo: <LOOPBACK> mtu 16436 qdisc noop state DOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

Comment 3 Harald Hoyer 2009-08-26 14:40:21 UTC
Seems like the network driver is not loaded. Odd.. which network card/driver/module is this?

Comment 4 Harald Hoyer 2009-08-26 14:41:46 UTC
Ah! Here we go:
5. dracut -H /boot/dracut.img $(uname -r)

can you rebuild the dracut image and remove the -H ?

also be sure to 

# yum install dracut-kernel dracut-generic

Comment 5 Alexander Todorov 2009-08-26 14:53:00 UTC
# yum install dracut-*  - didn't have that previously
# dracut -f /boot/dracut.img $(uname -r)

Still fails but now /tmp contains lots more files. Some questions:

Are dracut-kernel and dracut-generic essential for building the initrd? If yes why they were not pulled in as dependencies? It looks like dracut alone will generate faulty ramdisk images then.

I have to figure out if it's possible to tar the contents of /tmp. For the time being let me know which files do you need.

Comment 6 Alexander Todorov 2009-08-26 14:59:40 UTC
Created attachment 358730 [details]
/tmp from dracut shell

Contains files:


Comment 7 Harald Hoyer 2009-08-26 15:05:21 UTC

iscsistart -i iqn.1994-05.com.fedora:439bcc18a7ba -t iqn.rhel5.nxnode -g 1 -a -p 3260
iscsistart: transport class version 2.0-870. iscsid version 2.0-870
iscsistart: version 2.0-870
iscsistart: conn 0 login rejected: initiator error - target not found (02/03)
iscsistart: initiator reported error (19 - encountered non-retryable iSCSI login failure)

Comment 8 Jan Stodola 2009-08-27 10:06:42 UTC
I think I have similar problem when booting from nfs root. From what I've discovered, driver for my network card (e100) is not included in the initamfs image generated by dracut using this command:
dracut initrd.img `uname -r`

Using initramfs generated by this command:
dracut -d e100 initrd.img `uname -r`
I'm able to mount nfs root on boot and driver e100 is included in the initramfs image.

I'm testing with fedora 11 on ppc and dracut from git.

Part of my yaboot.conf:
        append="console=hvc0 root="

Comment 9 Harald Hoyer 2009-08-27 10:15:41 UTC
strange.. which version of dracut generated this?

you can check the image with:

# lsinitrd <image> | grep e100.ko

Comment 10 Jan Stodola 2009-08-27 10:39:39 UTC
[root@ibm-p5-04 ~]# dracut initrd.img `uname -r`
W: Possible missing firmware aic94xx-seq.fw for module aic94xx.ko
W: Possible missing firmware ql8100_fw.bin for module qla2xxx.ko
W: Possible missing firmware ql2500_fw.bin for module qla2xxx.ko

73036 blocks
[root@ibm-p5-04 ~]# lsinitrd initrd.img | grep e100.ko

[root@ibm-p5-04 ~]# dracut -f -d e100 initrd.img `uname -r`

40817 blocks
[root@ibm-p5-04 ~]# lsinitrd initrd.img | grep e100.ko
-rwxr--r--   1 root     root        67568 Aug 27 06:28 lib/modules/

version of dracut:

Comment 11 Jan Stodola 2009-08-27 10:44:57 UTC
Created attachment 358839 [details]
output from dracut -f -v initrd.img `uname -r`

Comment 12 Harald Hoyer 2009-08-27 10:54:33 UTC
please use the version in rawhide/F11 ... not the git version

Comment 13 Harald Hoyer 2009-08-27 11:09:22 UTC
ok, fixed the git version, e100.ko should be included now.

Comment 14 Jan Stodola 2009-08-27 11:25:19 UTC
driver for network card is included when using dracut-0.9-1.fc11

Comment 15 Alexander Todorov 2009-08-27 11:34:37 UTC
I hit a problem with NBD root too although the NIC driver is not a problem. 

My boot line is:
kernel /vmlinuz- ro root=UUID=123456 netroot=nbd: ip=eth0:dhcp

Where UUID is the correct UUID of the NBD image (as reported on the server). 

This fails to boot but debugging shows that /dev/nbd0 is there and is connected to the server. If I modify the boot line such as:


then /dev/nbd0 is mounted under /sysroot but the init process still fails. 

Not sure if this is a separate issue.

Comment 16 Alexander Todorov 2009-08-27 11:49:13 UTC
Created attachment 358852 [details]
/tmp from dracut shell when using NBD root

This contains:

grub entry is:
title dracut NBD
        root (hd0,0)
        kernel /vmlinuz- ro root=UUID=75e88635-50b1-4d95-840e-6aabef99dbfc netroot=nbd: ip=eth0:dhcp rdinitdebug rdbreak rdnetdebug
        initrd /dracut.img

Comment 17 Alexander Todorov 2009-08-27 12:42:16 UTC
with NBD 
root=UUID=75e88635-50b1-4d95-840e-6aabef99dbfc netroot=nbd:

in F11 this fails because /dev/disk is not present. Updating dracut and udev to rawhide makes it work. 

All NBD works. Continuing to track iSCSI.

Comment 18 Alexander Todorov 2009-08-27 13:45:41 UTC
Created attachment 358872 [details]
/tmp from dracut shell with iSCSI and updated dracut/udev from rawhide

Comment 19 Alexander Todorov 2009-08-27 14:21:39 UTC
in the end it turned out to be user error, iscsi target was not correctly configured in grub.conf

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