problem about diskless booting

The kernel panic indicates it cannot find an ethernet adapter. I'd try to fix that symptom first.

Can you boot off a live-CD and check that networking works there. How are you building initramfs? Try adding the module name for your NIC to /etc/initramfs-tools/modules, rebuilding initramfs (update-initramfs -c -k all), and see if that helps.

Do you have a eth0 or are booting of an eth1 or similar?

Thanks for answering.

I did not built initrams because this step was not in the howto.
The client is exactly the same machine as the server, I am only making a test. I know both network cards work fine (at list when used with their local root filesystem).

As for your last question I am not sure I understand you. These machines only have one network card and the device is called eth0 everywhere. I never used eth1, eth2.... in any step of the diskless procedure. The client is doing a pxe lan boot enabled in its bios.

anyway i am going to try your suggestion and include the nic module in the initrams.
I guess I have to make the inclusion before I copy the whole filesystem on /nfsroot, isn't it?
anyway could you please explain why the stuff now present on the server in the nfs dir (which i call /nfsroot) works fine for local boot on the client and requires this inclusion to work via nfs from the server? once the client receives his ip address and loads the vmlinuz end initrrd file I thought it also loaded the root filesystem, the same which worked fine as a local filesystem!

Hi,

i have the same problem.
Rebuilding the initramfs with the nic did not solve the problem :-(

cu
Thomas

Hello,

I can report the same problem for a diskless client with two NICs.
During booting the diskless client, one time the NIC1 becomes eth0 and another time NIC2 becomes eth0.
The result is, that booting in case one works right and in case two the system hangs because of not getting an IP.
This error happens before the root file system via NFS is attached. So it can be either a problem of PXElinux or of a buggy initramfs which is built through initramfs-tools. I checked ubuntu versions 8.04-Desktop-amd64 and the new 8.10-server-amd64. The problem happens on both versions.
Does anybody has experiences in building initrd for diskless clients with multiple NICs and can report on which linux distribution or initramfs-tools version it works?

For those looking for a resolution to the issue #jgcb highlited, see here:

http://lists.debian.org/debian-live/2009/02/msg00088.html

Mirror: http://pastebin.com/f4b7d67b

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

I can report the same problem. A number of diskless clients go flawlessly through a PXE boot, then the net interface is brought down when the Linux kernel boots and suddenly, dhcp does not work anymore.

Background research on the network: The clients are connected to Cisco switches. The configuration of the switches makes them run spanning-tree calculations. This usually takes some seconds but for large networks it can take up to 30 40 seconds.
The network port on the switch is turned on, when this calculation has been finished. This is primarily a security measure.
See also: http://networkers-online.com/blog/2008/08/what-is-bpdu-filter/
If this security measure is turned off, the client boots without problems. :)

To debug the problem, the following boot line was used:

  kernel amd64/vmlinuz
  append ro initrd=amd64/initrd.img nbdport=2000 debug=100 break=1 ip=dhcp

In my case, this causes a timeout as can be seen on the attached screenshots. The kernel loads the NIC module e1000e and reports the type of NIC et.c. The kernel reported is 5.927 .

The debug shows the following:

configure_networking
[ -n eth0 ]
 [-e /tmp/net-eth0.conf ]
ipconfig -t 60 eth0

At about 6.4 in kernel time, the NIC module reports further about it's IRQ configuration.
Two seconds (2 sec) later at about 8.56 the NIC module reports that the Link is up at 100 Mbps full duplex.
Some milliseconds later it signals ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready .

At this point in time, ipconfig is just waiting for an answer to the DHCP-discover that really was choked by the switch.
Now this is an obvious flaw in the script. It would be much more reasonable to try repeatedly with increasing timouts.

may I suggest the following timeouts:
4
8
16
30
60

The sum of this timeout is about 120 seconds.

And also this screenshot

I made an untested patch.

I tested the patch today on a number of computers running in the computer LAB at the Unuversity of Iceland. The patch really solves the problem.
The patch also reveals another minor problem:
the ipconfig program reports that it is giving up at each timeout, when it has actually done the right job.
It is probably a bug in ipconfig.

Another thing about this patch: the booting process is much faster. :)

Upgrading status to Triaged. Thank you for the patch, I will subscribe Ubuntu Sponsors to see if this can be sponsored and included into Ubuntu as a fix. Thank you.

Sponsors Team subscribed. Patch above.

I tried to apply the patch in lucid and it failed as the function was changed since jaunty. While at it I checked what the upstream code for this was and found that this seems to have been fixed in debian a while ago. So it would be nice if someone could test the upstream code too and see if it resolves the issue. I copied it to a pastebin:

http://paste.ubuntu.com/427631/

setting to incomplete and unsubscribing the sponsors for now, it needs testing on lucid and the change needs to be updated if it's still required

I was able to fix the bug on lucid by running the ipconfig inside a for-loop following Anna Jonna Armannsdottir suggestion above.

I've attached an updated file that goes in /usr/share/initramfs-tools/scripts/functions
You may want to merge it with vimdiff or create proper diff patch.

After adding you file you must rebuild your ramdisk
dpkg-reconfigure linux-image-2.6.32-23-generic

Details about how/why the error occurs:
* All our schools run diskless clients.
* Some of our schools have HP switches with spanning-tree turned on in order to stop network loopbacks.
* Spanning Tree adds additional delay for network re-initialization.
* Kernel loading network driver resets the nic - causing spanning tree delay.
* initramfs' ipconfig fails because network link light is off at the time of execution.
* putting the initramfs' ipconfig inside a for loop resoves the issue.

For those that want to confirm the bug and don't have spanning tree on their network switches...

* Setup workstation for diskless boot.
* Turn on the diskless client...
- Watch the link light as soon as the kernel starts to load.
- You will see the link light turn off as the kernel loads the network driver...
- At the very moment the link light goes off - unplug your network cable for a few seconds.
- This will simulate a spanning-tree type delay that some switches have.

I am trying to get my 10.04.1 booting. I have included the module into /etc/initramfs-tools/modules which didn't help.

If I modify my /usr/share/initramfs-tools/scripts/functions is command

"mkinitramfs -o initrd.img"

the same as command

"dpkg-reconfigure initrd.img"

as Dean Montgomery suggested?

The /scripts/functions patch from Dean Montgomery (#15) saved my day. Thanks!

When I deployed a ubuntu/lucid netboot environment in a multi-media room for a workshop that bug affected me. The e1000e driver module did non complete its dhcp setup (link becomes ready .... giving up) and after 60s I got a kernel panic. I replaced /scripts/functions in the initrd image and it worked like a charm.

The various bug reports in this thread may be caused by different flaws. The presented /scripts/function patch makes the boot procedure more robust in either way. Therefore I'd suggest to include that patch irrespective of this bug report.

This is fixed in initramfs-tools from Maverick on. The patch landed in Debian 0.94 and thus got included in later Ubuntu sync.
It is indeed unfixed in Lucid.