Re: Possible to force network configuration for boot=nfs?
Hello,
On Wed, Mar 07, 2012 at 03:15:30AM +0000, Andy Smith wrote:
> On a test client, the Xen domU configuration looks a bit like this:
>
> memory = 512
> name = 'test1'
> vif = [ 'mac=00:16:5e:00:00:51, ip=192.168.83.104, vifname=v-test1' ]
> disk = [ "phy:vg/test1_xvda,xvda,w",
> "phy:vg/test1_xvdb,xvdb,w" ]
> kernel = '/boot/vmlinuz-2.6.32-5-686-bigmem-rescue'
> ramdisk = '/boot/initrd.img-2.6.32-5-686-bigmem-rescue'
> extra = 'root=/dev/nfs ip=192.168.83.104::192.168.80.1:255.255.248.0:rescue:eth0:none boot=live nfsroot=192.168.80.243:/srv/rescue,tcp'
>
> On booting that, it initially seems fairly normal, but it always
> reaches this point before getting stuck:
[…]
> Waiting for ethernet card(s) up... If this fails, maybe the ethernet card is not supported by the kernel 2.6.32-5-686-bigmem?
> FATAL: Error inserting ide_generic (/lib/modules/2.6.32-5-686-bigmem/kernel/drivers/ide/ide-generic.ko): Device or resource busy
> done.
> IP-Config: eth0 hardware address 00:16:5e:00:00:51 mtu 1500 DHCP RARP
On and off I've been looking into the differences between how
debian-live and normal Debian call ipconfig from the initramfs. I
see that in scripts/live there is:
585 if [ -z "${NETBOOT}" ] && [ -z "${FETCH}" ] && \
586 [ -z "${HTTPFS}" ] && [ -z "${FTPFS}" ]
587 then
[…]
632 else
633 ipconfig ${DEVICE} | tee /netboot.config
634 fi
Without timeout (-t) on the ipconfig line it does wait forever to
get all info from DHCP.
In a normal Debian initramfs it
(/usr/share/initramfs-tools/scripts/functions) looks more like this:
http://paste.debian.net/161968/
$IP here is coming from the kernel command line ip= option, so I
tried same with scripts/live:
633 ipconfig -t ${ETHDEV_TIMEOUT} ${DEVICE} ip=${STATICIP} | tee /netboot.config
This then does allow me to netboot a debian-live install without
having to have it configure via DHCP+TFTP.
I don't really know what I'm doing so I don't even know if you
consider the current behaviour a bug. Is it worth filing this as
wishlist bug?
Cheers,
Andy
Reply to: