Red Hat Bugzilla – Bug 959957
Auto install RHEV-H with "BOOTIF=link" parameter, it will enter tui install process not auto install process .
Last modified: 2014-01-21 14:33:06 EST
Description of problem: Auto install RHEV-H with the follow parameter: BOOTIF=link storage_init=/dev/sda firstboot actually, it will enter tui manual install process not auto install process can reproduce this issue on physical machine's nic named "ethx" or "emx". May the root cause happen in the follow code of /usr/libexec/ovirt-init-functions.sh: 404 link) 405 for eth in $(cd /sys/class/net; echo [ep]*); do 406 ip link set dev $eth up 407 if ethtool $eth 2>/dev/null|grep -q "Link detected: yes" 408 then 409 bootif=$eth 410 break 411 fi 412 done Append "sleep 5" after line 406 can resole this issue: 404 link) 405 for eth in $(cd /sys/class/net; echo [ep]*); do 406 ip link set dev $eth up 407 sleep 5 408 if ethtool $eth 2>/dev/null|grep -q "Link detected: yes" 409 then 410 bootif=$eth 411 break 412 fi 413 done Version-Release number of selected component (if applicable): rhev-hypervisor6-6.4-20130501.0.el6_4 How reproducible: 100% Steps to Reproduce: 1.Auto install RHEV-H with the follow parameter: BOOTIF=link storage_init=/dev/sda firstboot Actual result: Expect result: Auto install RHEV-H successfully with "BOOTIF=link" parameter Additional info:
(In reply to haiyang,dong from comment #0) > Append "sleep 5" after line 406 can resole this issue: > 404 link) > 405 for eth in $(cd /sys/class/net; echo [ep]*); do > 406 ip link set dev $eth up > 407 sleep 5 > 408 if ethtool $eth 2>/dev/null|grep -q "Link > detected: yes" > 409 then > 410 bootif=$eth > 411 break > 412 fi > 413 done I understand the solution. The problem I see is that it depends on the driver and hardware how long it takes until the device appears as up. Can you provide which NIC hardware and driver was used?
(In reply to Fabian Deutsch from comment #2) > (In reply to haiyang,dong from comment #0) > I understand the solution. The problem I see is that it depends on the > driver and hardware how long it takes until the device appears as up. > > Can you provide which NIC hardware and driver was used? [root@dhcp-9-31 admin]# lspci |grep "Ethernet" 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04) [root@dhcp-9-31 admin]# ls /sys/class/net/em1/device/driver/module -l lrwxrwxrwx. 1 root root 0 2013-09-18 09:07 /sys/class/net/em1/device/driver/module -> ../../../../module/e1000e
Thanks. Mike, shall we just 1) add one sleep (which might not help always) 2) shall loop a couple of times combined with sleep 3) loop and prompt the user now and then to stop polling? 4) other ideas? I'd tend to use (2). 10 loops each with a 5sec sleep. Fix would be to monitor the state change of the nic. Could work with `ip monitor`, but that might be problematic if it never comes up.
I would loop 5 times with 1 sec wait *only* if it's "link" If it's not up in that time frame, log a message and proceed to the tui.
Test version: rhev-hypervisor6-6.5-20131017.0.iso ovirt-node-3.0.1-4.el6 Auto install RHEV-H with the follow parameter: BOOTIF=link storage_init=/dev/sda firstboot actually, it still enter tui manual install process not auto install process so this bug wasn't fixed, need to re-assigned it again.
Test version: rhevh-6.5-20131031.1.0.iso ovirt-node-3.0.1-7.el6 Auto install RHEV-H with the follow parameter: BOOTIF=link storage_init=/dev/sda firstboot Auto install RHEV-H successfully with "BOOTIF=link" parameter so this bug has been fixed, after the status of this bug change into "ON_QA", i will verify it.
According to comment 8, change the status of this bug into "VERIFIED"
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. http://rhn.redhat.com/errata/RHBA-2014-0033.html