Bug 1086931

(In reply to Ben Woodard from comment #0)
> Description of problem:
> In the dracut man page it says:
> 
>        If you specify ip=auto on the kernel command line, then dracut asks a
> dhcp server about the ip adress for the machine. The dhcp server can
>        also serve an additional root-path, which will set the root device
> for dracut. With this mechanism, you have static configuration on your
>        client machine and a centralized boot configuration on your TFTP/DHCP
> server. If you can’t pass a kernel command line, then you can inject
>        /etc/cmdline.d/mycmdline.conf, with a method described in the section
> called “Injecting custom Files”.
> 
> however when you try to use that to do a netboot the system won't boot up:
> 
> [    5.474907] dracut: FATAL: For argument 'ip=auto'\nSorry, unknown value
> 'auto'
> [    5.483506] dracut: Refusing to continue
> 
> 
> Version-Release number of selected component (if applicable):
> dracut-033-147.el7.x86_64
> 
> How reproducible:
> 
> 
> Steps to Reproduce:
> 1. try to netboot a machine with ip=auto on the kernel command line
> 
> Additional info:
> I think that this is best handled as a documentation bug and the man page
> should be fixed.

yeah, this should be "ip=dhcp" or "root=dhcp" rather than ip=auto

ip=dhcp doesn't seem to work either.

the kernel command line is:
   initrd=initramfs console=tty0 console=ttyS0,115200n8 crashkernel=256M enforcing=0 rd.debug ip=dhcp root=nfs:192.168.81.156:/tftpboot/images/rhel7-ben-cn.latest

but after it drops you into the dracut emergency shell you can see that it doesn't have an IP address:

dracut:/# ip addr show
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:1e:67:23:f9:f4 brd ff:ff:ff:ff:ff:ff
3: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:1e:67:23:f9:f5 brd ff:ff:ff:ff:ff:ff

if you remove the ip=dhcp then you get the same thing:

dracut:/# ip addr show
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:1e:67:23:f9:f4 brd ff:ff:ff:ff:ff:ff
3: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:1e:67:23:f9:f5 brd ff:ff:ff:ff:ff:ff
dracut:/# cat /proc/cmdline 
initrd=initramfs console=tty0 console=ttyS0,115200n8 crashkernel=256M enforcing=0 root=nfs:192.168.81.156:/tftpboot/images/rhel7-ben-cn.latest BOOT_IMAGE=vmlinuz BOOTIF=01-00-1e-67-23-f9-f4 

if you use root=dhcp and then try to specify the sysroot on the kernel command line in the ip=  option as suggested in parse-nfsroot.sh it doesn't even seem to bring up the ethernet:

dracut:/# ip addr show
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
dracut:/# cat /proc/cmdline 
initrd=initramfs console=tty0 console=ttyS0,115200n8 crashkernel=256M enforcing=0 root=dhcp ip=nfs:192.168.81.156:/tftpboot/images/rhel7-ben-cn.latest BOOT_IMAGE=vmlinuz BOOTIF=01-00-1e-67-23-f9-f4 

There seems to be some problem here.

Some additional notes:

the legacy format using root=/dev/nfs and nfsroot= doesn't work either:

dracut:/# cat /proc/cmdline 
initrd=initramfs console=tty0 console=ttyS0,115200n8 crashkernel=256M enforcing=0 root=/dev/nfs nfsroot=nfs:192.168.81.156:/tftpboot/images/rhel7-ben-cn.latest BOOT_IMAGE=vmlinuz BOOTIF=01-00-1e-67-23-f9-f4 

dracut:/# ip addr show
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:1e:67:23:f9:f4 brd ff:ff:ff:ff:ff:ff
3: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:1e:67:23:f9:f5 brd ff:ff:ff:ff:ff:ff

and it is not DHCP because we just got a DHCP address which allowed us to pull the kernel and the initramfs over tftp. Plus:
dracut:/# ip addr show
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:1e:67:23:f9:f4 brd ff:ff:ff:ff:ff:ff
3: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:1e:67:23:f9:f5 brd ff:ff:ff:ff:ff:ff
dracut:/# ifup eth0
[  203.811298] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[  208.162497] igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[  208.176173] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Starting dhcp for interface eth0
dracut:/# ip addr show
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:1e:67:23:f9:f4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.81.155/20 brd 192.168.95.255 scope global dynamic eth0
       valid_lft 43194sec preferred_lft 43194sec
    inet6 fe80::21e:67ff:fe23:f9f4/64 scope link 
       valid_lft forever preferred_lft forever
3: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:1e:67:23:f9:f5 brd ff:ff:ff:ff:ff:ff

So it appears like there is something wrong with dracut-network's ability to fetch the DHCP ip address it needs to get to the sysroot.

1. do you have dracut-network installed
2. how do you build the initramfs image?
3. what is the output of:

# lsinitrd <initramfs-image>

Of course I have dracut network installed.
I made the initrd using: 
dracut -f /boot/netboot-3.10.0-110.el7.x86_64.img 3.10.0-110.el7.x86_64
I'll get you number 3 shortly.

May I request that you actually try net booting a rhel7 host. It seems pretty obvious to me by the number of problems and the state of the documentation that this hasn't been tested recently. I would love to be shown that I'm wrong about that.

Created attachment 898717 [details]
Requested output from lsinitrd

Created attachment 898723 [details]
dracut debug log

Created attachment 898794 [details]
rdsosreport

This was captured after consulting with Harald. 

initramfs built with:
dracut -f /boot/netboot-3.10.0-110.el7.x86_64.img-m "nfs network  base systemd ifcfg debug"  3.10.0-110.el7.x86_64

Kernel cmdline was:
initrd=initramfs console=tty0 console=ttyS0,115200n8 crashkernel=256M enforcing=0 root=nfs:192.168.81.156:/tftpboot/images/rhel7-ben-cn.latest rd.debug

Seems to still be having a problem finding the root.

[   67.741492] localhost systemd-udevd[869]: error changing net interface name eth0 to eno1: File exists

this is the culprit. Your BIOS or the kernel driver is kind of broken.

Workaround for now: add "net.ifnames=0" to the kernel command line

Maybe try to update the BIOS?

Test:
$ grep . /sys/class/net/e*/index
$ grep . /sys/class/net/e*/acpi_index

should report different numbers for the different network interfaces.

If they are the same, then it's most likely a crappy BIOS.

just checked Intel's website, this is still the latest and greatest.

# hype356 /root > syscfg -i

       System Configuration Utility Version 12.0 Build 8
       Copyright (c) 2013 Intel Corporation

System BIOS and FW Versions:
BIOS Version.............. SE5C600.86B.02.02.0002

BMC Version
Boot Code............... 01.17
Op Code................. 1.20.5446

Yea that got me much farther. Now I've got to a new problem which is likely with my image. 

[root@fox sys]# grep . /sys/class/net/*/device/{index,acpi_index}
/sys/class/net/eth0/device/index:1
/sys/class/net/eth1/device/index:1
grep: /sys/class/net/*/device/acpi_index: No such file or directory

I asked the sysadmin to ask for a fixed bios I do believe that udev needs to handle this scenario better. Do you know of a udev bug for this issue or should I file one.

(In reply to Ben Woodard from comment #13)
> Yea that got me much farther. Now I've got to a new problem which is likely
> with my image. 
> 
> [root@fox sys]# grep . /sys/class/net/*/device/{index,acpi_index}
> /sys/class/net/eth0/device/index:1
> /sys/class/net/eth1/device/index:1
> grep: /sys/class/net/*/device/acpi_index: No such file or directory
> 
> I asked the sysadmin to ask for a fixed bios I do believe that udev needs to
> handle this scenario better. Do you know of a udev bug for this issue or
> should I file one.

https://bugzilla.redhat.com/show_bug.cgi?id=1093485#c21 has the same problem.

We should probably open 2 bugzillas. One against component kernel, if the same "index" number is a kernel or firmware bug, and one against udev, that it continues after the renaming failed.

systemd-udev bug opened in BZ#1102135

Harald, re it potentially being a kernel or a driver bug. I tracked down where the index sysfs attribute is coming from. 
http://lxr.free-electrons.com/source/drivers/pci/pci-label.c#L117 and http://lxr.free-electrons.com/source/drivers/pci/pci-label.c#L102 

and it looks like it is pulling it right out of the SMBIOS tables and so there is little possibility that the kernel would get it wrong. Therefore, I'm not sure what purpose a bz for the kernel component would have. As the dmidecode(8) man page states:

BUGS
       More often than not, information contained in the DMI tables is inaccurate, incomplete or simply wrong.

--- 

Why don't we let this BZ be the one about the ip=auto documentation bug as it originally was before I took it off scope. Then we will let BZ#1102135 be the one about the udev problem.

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, and where to find the updated
files, follow the link below.

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

https://rhn.redhat.com/errata/RHBA-2015-0375.html