Etherboot floppy boot terminal appears to load image and failed with 'Issuing RESET:' on 9.10

[Adrian Kuepker]

When booting older terminals using Etherboot 5.4.x boot floppies, the image appears to load with all of the dots streaming across the screen and 'done' is displayed at the end.

Immediately thereafter 'Issuing RESET:' appears on the screen and booting stops.

Running Fresh install of Ubuntu 9.10

Other terminals such as DisklessWorkstations T1420 and same terminal using gPXE0.9.9 boot to login screen just fine.

[Oliver Grawert (ogra)]

note that we switched to mkelfimage instead of mknbi. mkelfimage was added because it can handle coreboot based thin clients (mainly it was added on request of arctech for the thincan clients) but it is knoen that mkelfimage does not work for some older etherboot versions. if you install mknbi in the chroot, run a chrooted update-initramfs and then ltsp-update-kernels on the server the resulting nbi image should be usable with older etherboot clients.

[atkuepker (a-kuepker)]

You mentioned "older" Etherboot, but I repllicated this with the new Etherboot 5.4.x release as indicated in the initial comment. Please explain.

[atkuepker (a-kuepker)]

Marked Invalid based on erroneous assumption of older Etherboot releases, not the 5.4 releases that exhibit the problem. Reopening.

[Oliver Grawert (ogra)]

you dont understand, the bug isnt in mknbi since mknbi isnt installed at all...

instead mkelfimage is installed, so either the bug is that we dont use mknbi, which would be a dependency bug in ltsp-client-core, but only one of mknbi or mkelfimage can be installed at a time and we made the deliberate decision to use mkelfimage here (which i'm really starting to doubt was a good one)

or the bug is that our documentation isnt good enough, i.e. you apparently didnt know that you need to install mknbi to support etherboot and what commands to run to get proper etherboot images etc

or the bug is that mkelfimage doesnt work with certain versions of etherboot images (most people use gpxe nowadays though, so that might be the reason nobody added/fixed etherboot support properly to mkelfimage)

it is definately *not* a mknbi bug ...

[jsass (sass-joel)]

Is it possible to create some documentation in order to assist individuals with the building of the proper image?

[Chris N (cu-north)]

I, too, would like some documentation on creating a etherboot compatible image using the method Oliver has described above but with more detail.

[teknoman (rvilaboa)]

I agree with UsUrPeR and Chris.
Such a documentation would be greatly appreciated.
Thank you.

[Kirk Steffensen (kirk-steffensen)]

Oliver, still having the same problem under 10.04.1. Tried installing mknbi in chroot and then running update-initramfs, exiting chroot and running ltsp-update-kernels. This did not update nbi.img. So I tried " mknbi-linux --output=nbi.img-2.6.32-25-generic vmlinuz initrd.img" from chroot /boot/. This did update nbi.img. Reupdated ltsp kernels. Still failed to boot.

You said that mknbi and mkelfimage cannot be installed at the same time. But, if I try to uninstall mkelfimage, it also uninstalls ltsp-client. When I try update-initramfs with mkelfimage uninstalled, it gives three errors of "grep: /proc/modules: No such file or directory"

Can you please develop a step-by-step set of instructions for restoring mknbi and getting a good nbi.img? We're using some ancient PCs for our thin clients at a secondary school in Tanzania. No hard disks, can't boot from USB, and no CDROMS, so it's impossible to get gPXE on them without buying hardware, which isn't in the budget.

Thanks in advance!
Kirk

[Martin-Éric Racine (q-funk)]

It has been suggested in another bug's thread that neither mkelfimage or mknbi work as intended anymore. Instead, wraplinux was recommended as a cleaner substitute for both. A package of it was previously submitted to Debian, but turned down by their FTP master. See: http://ftp-master.debian.org/new/wraplinux_1.6-1.html

[Martin-Éric Racine (q-funk)]

Actually, there seems to be an even more recent package, also stuck in NEW.
http://ftp-master.debian.org/new/wraplinux_1.7-1.html

[Martin-Éric Racine (q-funk)]

But the whole thing is maintained at: git://git.debian-maintainers.org/git/syslinux/wraplinux.git

[Alkis Georgopoulos (alkisg)]

Just an idea for a workaround:

Isn't it possible, outside of the LTSP code tree, to create one single gpxe-nbi.img file that would contain gPXE 1.0.0 and that could be used by anyone affected by this bug?

That could be used to properly boot all terminals that do not properly support PXE booting, and it would even give the sysadmin the usual pxelinux advantages, e.g. to easily pass kernel parameters from pxelinux.cfg/default or pass kernel parameters for specific clients from pxelinux.cfg/01-mac-address etc.

The sysadmin would just have to manually download the gpxe-nbi.img file from some site and change his dhcpd.conf to point to it instead of nbi.img.
The only downside I can think of is that gPXE would do a second DHCP request, which would add a small delay, but I don't think that would bother anyone.

[Openstep (openstep)]

Has this been fixed yet? I am also heaving this issue with older cleinets:

"When booting older terminals using Etherboot 5.4.x boot floppies, the image appears to load with all of the dots streaming across the screen and 'done' is displayed at the end."

Pxe boot is fine.

[Xavier Brochard (xavier)]

I have the same boot problem with Thincans client and Ubuntu 10.04: can't boot with nbi.img. Was working previously with Debian Lenny. Funny is that Thincans are those coreboot based thin clients made by Artec who requested the switch to mkelfimage instead of mknbi...

[Alkis Georgopoulos (alkisg)]

I propose that we completely remove support for NBI images from ltsp-trunk.
Copy from my mail to the ltsp-developer list:

AFAIK, NBI (Etherboot) support has been broken for years:
https://bugs.launchpad.net/ltsp/+bug/487826

I want to remove all of the NBI code from ltsp-trunk, so I'm proposing this commit:
http://bazaar.launchpad.net/~alkisg/+junk/ltsp/revision/2500

This touches files like dhcpd.conf from all distros, so please stop me from committing it if NBI images still work for you.

As for a workaround,
 * I think some etherboot clients support booting from pxelinux.0 (I had this in mind in the planned commit),
 * While for older etherboot clients that don't support pxelinux.0, someone that has such a client should create an ipxe.nbi wrapper, post it to our wiki and document how to change dhcpd.conf to boot from that.

I'll wait for a few days for feedback; if there's none, I'll go ahead and push.

Cheers,
Alkis

[Martin-Éric Racine (q-funk)]

As pointed out earlier, both mkelfimage and mknbi have become broken over time. The only clean solution left for older clients that don't support PXE is wraplinux. Making wraplinux bootstrap an iPXE blob should work for BIOS-based clients, but not for e.g. Coreboot-based clients.

[Alkis Georgopoulos (alkisg)]

> Making wraplinux bootstrap an iPXE blob should work for
> BIOS-based clients, but not for e.g. Coreboot-based clients.

Why not? iPXE works with Coreboot, doesn't it?
http://www.coreboot.org/IPXE‎

The blob approach sounds better, PXE allows for modifying the kernel parameters per client without recompiling an image.

If the iPXE blob approach won't work, and mkelfimage needs to be changed to wraplinux in ltsp-trunk, then someone that has such a client should send patches etc...

[Vagrant Cascadian (vagrantc)]

It seems like we should either remove support for the old image formats entirely, or provide an iPXE image capable of booting these legacy clients...

[Martin-Éric Racine (q-funk)]

iPXE only works with Coreboot on specific hardware platforms and only if SeaBIOS (a free software BIOS implementation) is included in the firmware build. It is not a universally supported option.

[Vagrant Cascadian (vagrantc)]

Given there's been no working cod efor this for years, and that there seem to be many permutations, they mostly affect quite old hardware, let's just drop support for this entirely.

[Vagrant Cascadian (vagrantc)]

Given there's been no working code for this for several years, and that there seem to be many permutations, they mostly affect quite old hardware, let's just drop support for this entirely.