[K12OSN] Re: Running in to an Edubuntu Wall

[Jim McQuillan]

On Fri, August 4, 2006 4:38 pm, pogson wrote:
> "R. Scott Belford" <scott at hosef.org> wrote:
>
> 1. ebnet and UBF floppies do not boot clients.  They produce the error
> "loading 192.168.0.254:/pxelinux.0.......error, not a valid image"
> The same clients boot great with a PXE enabled NIC.

Etherboot is expecting a 'NBI Tagged kernel'.  pxelinux.0 isn't that.  I
think that newer versions of Etherboot are capable of loading a PXE boot
loader, but i've not tried it myself.

> 2. eth0 has to be configured, and dhcp likely has to be edited
> 3. Clients that work great with K12LTSP will not work as well with
> Edubuntu.  I had to use VESA emulation for some of my workhorses.

Which version of K12LTSP ?

> 4. This is hardly the place just to cry about problems.  At the end I
> have a proposed 'fix.'
> ----
>
> EdUbuntu does things a little differently than LTSP. LTSP normally boots
> by etherboot, which is similar in function but not identical to PXE in

LTSP boots very will both PXE and Etherboot.  We don't really cater to
either one.  We like them both.



> detail. The etherboot loader normally expects a different file structure
> than a PXE bootloader. Ubuntu will have a means of producing the
> appropriate boot floppy for Ubuntu expects a PXE bootloader to run.
>
> 1.
>>From http://www.ltsp.org/README.pxe
>
>          Normally, for Etherboot kernels, the kernel is placed
>         in /tftpboot/lts.
>         But, for PXE kernels, we create a subdirectory in that location
>         that
>         has a name that matches the version of the kernel.  For example,
>         in this release of the kernel, we create
>         '/tftpboot/lts/2.4.22-ltsp-1'.
>
>         Within that directory, we place the kernel, the initrd image,
>         the
>         pxelinux.0 bootloader and a configuration subdirectory.
>
> 2.If your primary (ISP connection) is on 192.168.0.x, Ubuntu requires
> editing. If you control your environment, make sure the LAN with thin
> clients is allowed to be 192.168.0.x and Ubuntu scripts do everything.
> No editing required. See an article I wrote for Free Software Magazine
> about EdUbuntu 5.10:
> http://www.freesoftwaremagazine.com/files/nodes/1263/1263.pdf
> This is a bit clumsy and lacking foresight, but the vast majority of
> EdUbuntu installations will either be in small schools or subnets behind
> a firewall/router so its not that limiting. I did the installation both
> ways. You want to do it the automatic way, believe me. Since the script
> is open source, this would be a neat project for one of my students, to
> tune it up for more general cases. "Here are our defaults. Change them
> to suit your wishes and click 'OK'". I can see it now.
>
> 3. Does LTSP still use XFree86? Dapper uses X.org, perhaps a difference
> in drivers. I had no difficulty with several clients I tried with 5.10.

For a long time, LTSP included both XFree86 AND Xorg.  As of LTSP-4.2,
only Xorg is included.


>
> 4. That's what open source is all about.
>
> EdUbuntu is the slickest installation of an X server and client
> configuration I have ever tried next to K12LTSP. Well, ClusterKNOPPIX
> was pretty cool, too (OpenMosix terminal server - uses PXE, DHCP and
> tftp to boot linux clients via the network.). I plan to install EdUbuntu
> next week in a production environment and I hope it goes smoothly as I
> have little time and much to do. Of course, life is always more
> interesting with a few challenges. Ubuntu had some difficulty meeting
> its target date. I hope some of the glitches will have been hunted down
> by next week or I will have to do some hunting myself. I would use
> K12LTSP except I have grown fond of apt and Ubuntu has some particular
> packages I need. K12LTSP/Fedora likely has them, too, but I know the
> Ubuntu repository and I have my own copy.
> --
> A problem is an opportunity.

the LTSP that is included in Dapper is fairly good, but not quite
feature-complete when compared to LTSP-4.2.  The LTSP that will ship with
Edgy will be MUCH better.  Also, we're now in the process of switching
LTSP.org's implementation to be based on the work that Matt and Oliver did
to get LTSP into Ubuntu.  Soon, they will be nearly identical, which will
allow us to focus on the parts of LTSP that really make it special.

Jim McQuillan
jam at Ltsp.org