[Ltsp-developer] NBI and ELF images in Fedora

Nadav Kavalerchik nadavkav at gmail.com
Sat Aug 23 16:00:08 UTC 2008


since i had no elf.ltsp or wraplinux-nbi.ltsp i used :

wraplinux -E -i initrd.ltsp -p "rw selinux=0 verbose noquiet sysrq=1" -o
wrap.ltsp vmlinuz.ltsp

to generate one.

and then i used

# Etherboot NBI (older clients)
     elsif substring (option vendor-class-identifier, 0, 9) = "Etherboot"
     {
        #filename      "/ltsp/i386/wraplinux-nbi.ltsp";
        filename      "/ltsp/i386/wrap.ltsp";
     }

to make it work :-)


On Fri, Aug 15, 2008 at 5:49 AM, Jim McQuillan <jam at mcquil.com> wrote:

>
>
> Warren Togami wrote:
>
>> I did some testing of mkelfimage, mknbi and wraplinux.
>>
>> Etherboot-5.0.5 in NSC Geode GX1 (DisklessWorkstations.com Jammin-125)
>> Failed to boot with mknbi.
>> Boots with wraplinux --nbi.
>>
>> Etherboot-5.4 with real BIOS (qemu-kvm)
>> Failed to boot with mknbi.
>> Boots with wraplinux --nbi.
>> Boots with mkelfimage with ram base detection patch.
>>
>> Etherboot-5.4 with coreboot (ArtecGroup ThinCan DBE61)
>> Fails to boot wraplinux --elf.
>> Fails to boot mknbi ELF or NBI.
>> Boots with mkelfimage with ram base detection patch.
>>
>> Based upon these findings, I am dropping mknbi entirely from Fedora.
>> mkelfimage will be for ELF images, coreboot and Etherboot-5.4. wraplinux
>> --nbi will be for NBI images.
>>
>>      # Etherboot ELF (only 5.4), should work with Coreboot
>>      elsif substring (option vendor-class-identifier, 0, 13) =
>> "Etherboot-5.4"
>>      {
>>         filename      "/ltsp/i386/elf.ltsp";
>>      }
>>      # Etherboot NBI (older clients)
>>      elsif substring (option vendor-class-identifier, 0, 9) = "Etherboot"
>>      {
>>         filename      "/ltsp/i386/wraplinux-nbi.ltsp";
>>      }
>>      # PXE
>>      elsif substring (option vendor-class-identifier, 0, 9) = "PXEClient"
>>      {
>>         # NOTE: kernels are specified in /tftpboot/ltsp/i386/pxelinux.cfg/
>>         filename      "/ltsp/i386/pxelinux.0";
>>      }
>>      # default to an i386 BOOTP image
>>      else
>>      {
>>         filename      "/ltsp/i386/vmlinuz.ltsp";
>>      }
>>
>> We are using this in Fedora's default dhcpd.conf.  I totally have not
>> tested any BOOTP clients in like 7 years now.  I inherited this from Eric
>> Harrison's default dhcpd.conf.  I can't see how it could possibly work?  How
>> could it find the initrd image?
>>
>
>
> Back in the old days, we'd prepare an LTSP boot image using mknbi to
> combine the kernel and the initrd. the result was a single large file.
>
>
> Jim McQuillan
> jam at Ltsp.org
>
>
>
>> Warren Togami
>> wtogami at redhat.com
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _____________________________________________________________________
>> Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
>>      https://lists.sourceforge.net/lists/listinfo/ltsp-developer
>> For additional LTSP help,   try #ltsp channel on irc.freenode.net
>>
>
> _______________________________________________
> K12Linux-devel-list mailing list
> K12Linux-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/k12linux-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/k12linux-devel-list/attachments/20080823/adb03dde/attachment.htm>


More information about the K12Linux-devel-list mailing list