sritej s
2009-May-28 18:33 UTC
[syslinux] Message 11 Syslinux Digest, Vol 74, Issue 24(Re: PXEboot trouble with Soekris 4826 (Miller, Shao)
Hi All,
I am still having troubling with PXE.
Thanks for replying Shao.I did follow ur suggestions and my results have
improved a bit.From Ethereal and TCPdump, I can see that the client
sucessfully dowloads the file pxelinux.0 from the server but stops at this
point.
here is the output of tcpdump
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96
bytes
11:05:41.966864 IP (tos 0x0, ttl 20, id 0, offset 0, flags [none], proto
17, le ngth: 576) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from 00: 00:24:c8:c9:60, length: 548, xid:0x25c8c960, secs:4, flags:
[Broadcast] (0x8000)
Client Ethernet Address: 00:00:24:c8:c9:60 [|bootp]
11:05:41.967522 IP (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto
17, l ength: 328) 192.168.200.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP,
Reply, le ngth: 300, xid:0x25c8c960, secs:4, flags: [Broadcast] (0x8000)
Your IP: 192.168.200.3
Server IP: 192.168.200.1
Client Ethernet Address: 00:00:24:c8:c9:60 [|bootp]
11:05:44.061326 IP (tos 0x0, ttl 20, id 1, offset 0, flags [none], proto
17, le ngth: 576) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from 00: 00:24:c8:c9:60, length: 548, xid:0x25c8c960, secs:4, flags:
[Broadcast] (0x8000)
Client Ethernet Address: 00:00:24:c8:c9:60 [|bootp]
11:05:44.066634 IP (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto
17, l ength: 328) 192.168.200.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP,
Reply, le ngth: 300, xid:0x25c8c960, secs:4, flags: [Broadcast] (0x8000)
Your IP: 192.168.200.3
Server IP: 192.168.200.1
Client Ethernet Address: 00:00:24:c8:c9:60 [|bootp]
11:05:44.201365 arp who-has 192.168.200.1 tell 192.168.200.3
11:05:44.201403 arp reply 192.168.200.1 is-at 00:0d:60:7b:b1:a6
11:05:44.201488 IP (tos 0x0, ttl 20, id 2, offset 0, flags [none], proto
17, le ngth: 55) 192.168.200.3.2070 > 192.168.200.1.tftp: [udp sum ok] 27
RRQ "pxelinu x.0" octet tsize 0
11:05:44.203227 IP (tos 0x0, ttl 64, id 51510, offset 0, flags [none],
proto 17 , length: 42) 192.168.200.1.32775 > 192.168.200.3.2070: [bad udp
cksum 7a79!] UD P, length 14
11:05:44.203364 IP (tos 0x0, ttl 20, id 3, offset 0, flags [none], proto
17, le ngth: 45) 192.168.200.3.2070 > 192.168.200.1.32775: [udp sum ok] UDP,
length 17
11:05:44.250960 IP (tos 0x0, ttl 20, id 4, offset 0, flags [none], proto
17, le ngth: 60) 192.168.200.3.2071 > 192.168.200.1.tftp: [udp sum ok] 32
RRQ "pxelinu x.0" octet blksize 1456
11:05:44.252470 IP (tos 0x0, ttl 64, id 51511, offset 0, flags [none],
proto 17 , length: 43) 192.168.200.1.32775 > 192.168.200.3.2071: [bad udp
cksum 152!] UDP , length 15
11:05:44.252587 IP (tos 0x0, ttl 20, id 5, offset 0, flags [none], proto
17, le ngth: 32) 192.168.200.3.2071 > 192.168.200.1.32775: [udp sum ok] UDP,
length 4
11:05:44.268451 IP (tos 0x0, ttl 64, id 51512, offset 0, flags [none],
proto 17 , length: 1488) 192.168.200.1.32775 > 192.168.200.3.2071: UDP,
length 1460
11:05:44.268824 IP (tos 0x0, ttl 20, id 6, offset 0, flags [none], proto
17, le ngth: 32) 192.168.200.3.2071 > 192.168.200.1.32775: [udp sum ok] UDP,
length 4
11:05:44.269470 IP (tos 0x0, ttl 64, id 51513, offset 0, flags [none],
proto 17 , length: 1488) 192.168.200.1.32775 > 192.168.200.3.2071: UDP,
length 1460
11:05:44.269824 IP (tos 0x0, ttl 20, id 7, offset 0, flags [none], proto
17, le ngth: 32) 192.168.200.3.2071 > 192.168.200.1.32775: [udp sum ok] UDP,
length 4
11:05:44.270015 IP (tos 0x0, ttl 64, id 51514, offset 0, flags [none],
proto 17 , length: 1488) 192.168.200.1.32775 > 192.168.200.3.2071: UDP,
length 1460
11:05:44.270323 IP (tos 0x0, ttl 20, id 8, offset 0, flags [none], proto
17, le ngth: 32) 192.168.200.3.2071 > 192.168.200.1.32775: [udp sum ok] UDP,
length 4
11:05:44.291488 IP (tos 0x0, ttl 64, id 51515, offset 0, flags [none],
proto 17 , length: 1488) 192.168.200.1.32775 > 192.168.200.3.2071: UDP,
length 1460
11:05:44.291808 IP (tos 0x0, ttl 20, id 9, offset 0, flags [none], proto
17, le ngth: 32) 192.168.200.3.2071 > 192.168.200.1.32775: [udp sum ok] UDP,
length 4
11:05:44.298478 IP (tos 0x0, ttl 64, id 51516, offset 0, flags [none],
proto 17 , length: 1488) 192.168.200.1.32775 > 192.168.200.3.2071: UDP,
length 1460
11:05:44.298804 IP (tos 0x0, ttl 20, id 10, offset 0, flags [none], proto
17, l ength: 32) 192.168.200.3.2071 > 192.168.200.1.32775: [udp sum ok] UDP,
length 4
11:05:44.305010 IP (tos 0x0, ttl 64, id 51517, offset 0, flags [none],
proto 17 , length: 1488) 192.168.200.1.32775 > 192.168.200.3.2071: UDP,
length 1460
11:05:44.305302 IP (tos 0x0, ttl 20, id 11, offset 0, flags [none], proto
17, l ength: 32) 192.168.200.3.2071 > 192.168.200.1.32775: [udp sum ok] UDP,
length 4
11:05:44.305491 IP (tos 0x0, ttl 64, id 51518, offset 0, flags [none],
proto 17 , length: 1488) 192.168.200.1.32775 > 192.168.200.3.2071: UDP,
length 1460
11:05:44.305801 IP (tos 0x0, ttl 20, id 12, offset 0, flags [none], proto
17, l ength: 32) 192.168.200.3.2071 > 192.168.200.1.32775: [udp sum ok] UDP,
length 4
11:05:44.326920 IP (tos 0x0, ttl 64, id 51519, offset 0, flags [none],
proto 17 , length: 1144) 192.168.200.1.32775 > 192.168.200.3.2071: UDP,
length 1116
11:05:44.327166 IP (tos 0x0, ttl 20, id 13, offset 0, flags [none], proto
17, l ength: 32) 192.168.200.3.2071 > 192.168.200.1.32775: [udp sum ok] UDP,
length 4
11:05:49.201807 arp who-has 192.168.200.3 tell 192.168.200.1
11:05:50.201654 arp who-has 192.168.200.3 tell 192.168.200.1
11:05:51.201502 arp who-has 192.168.200.3 tell 192.168.200.1
Any hints please?The result is the same when my pxelinux.cfg directory is
empty.Probably the problem is due to the directory not being accessed?I am
still unable to ping the client.
Thanks,
Sritej
On Sun, May 24, 2009 at 2:00 PM, <syslinux-request at zytor.com> wrote:
> Send Syslinux mailing list submissions to
> syslinux at zytor.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.zytor.com/mailman/listinfo/syslinux
> or, via email, send a message with subject or body 'help' to
> syslinux-request at zytor.com
>
> You can reach the person managing the list at
> syslinux-owner at zytor.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Syslinux digest..."
>
>
> Today's Topics:
>
> 1. Re: Syslinux.exe 64 bits Windows (Ryan McLean)
> 2. Location and name of configuration files (Andrew Yeomans)
> 3. Re: Location and name of configuration files (H. Peter Anvin)
> 4. Re: Syslinux.exe 64 bits Windows (H. Peter Anvin)
> 5. PXEboot trouble with Soekris 4826 (sritej s)
> 6. Sending UDP packets from comboot (Stefan Thomanek)
> 7. Re: Location and name of configuration files (Dag Wieers)
> 8. menu: alternative config file (Sebastian Herbszt)
> 9. Re: Booting firmware harddisk image with memdisk fails
> (Dag Wieers)
> 10. Re: Location and name of configuration files (Kim Mik)
> 11. Re: PXEboot trouble with Soekris 4826 (Miller, Shao)
> 12. Re: Booting firmware harddisk image with memdisk fails
> (Miller, Shao)
> 13. Re: Booting firmware harddisk image with memdisk fails
> (Dag Wieers)
> 14. Re: Booting firmware harddisk image with memdisk fails
> (Miller, Shao)
> 15. Re: Booting firmware harddisk image with memdisk fails
> (Dag Wieers)
> 16. Re: Booting firmware harddisk image with memdisk fails
> (Miller, Shao)
> 17. Re: Sending UDP packets from comboot (H. Peter Anvin)
> 18. Re: Location and name of configuration files (H. Peter Anvin)
> 19. Re: Sending UDP packets from comboot (H. Peter Anvin)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 19 May 2009 18:48:18 +0100
> From: Ryan McLean <pvtryan100 at googlemail.com>
> Subject: Re: [syslinux] Syslinux.exe 64 bits Windows
> To: For discussion of Syslinux and tftp-hpa <syslinux at zytor.com>
> Message-ID: <4A12F0E2.2070201 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> H. Peter Anvin wrote:
> > MILI Nadia wrote:
> >
> >> The main question is booting on Vista64, the syslinux.exe
isn't
> recognized.
> >>
> >>
> >
> > Why the heck wouldn't it "recognize" a simple Win32
executable? It may
> > not permit some of the operations Syslinux needs to work, though.
> >
> > -hpa
> >
> >
> Under vista64 try right clicking and running as admin. I am guessing the
> installer doesn't have the "vista elevate permissions code"
iirc this is
> set in the manifest file.
>
> Regards,
>
> Ryan
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 23 May 2009 21:49:16 +0100
> From: Andrew Yeomans <ajv at yeomans.org.uk>
> Subject: [syslinux] Location and name of configuration files
> To: syslinux at zytor.com
> Message-ID:
> <1d3f49850905231349l2e0fb1ect2e06861f8cfb9dfd at
mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Just thinking out loud, but thought I'd better check with you syslinux
> experts ...
>
> Far too many times I've converted an .iso file to boot off a USB disk
by
> renaming the isolinux directory and isolinux.cfg file, and far too many
> times also forgotten to do so the first time round. Looking at the various
> mailing lists on the web shows users often have problem getting a USB stick
> to work due to similar problems.
>
> Would it not be more user-friendly and less error-prone if isolinux could
> search both sets of directories, namely:-
>
> /boot/isolinux/isolinux.cfg
> /isolinux/isolinux.cfg
> /isolinux.cfg
> /boot/syslinux/syslinux.cfg
> /syslinux/syslinux.cfg
> /syslinux.cfg
>
> And similarly syslinux could do the same but with the syslinux.cfg files
> first. That would make it possible to have a single .iso file that was easy
> to copy across to a USB drive, without manually changing it. And would also
> support different config files in the same .iso image for syslinux and
> isolinux, if there was a good reason to have them different.
>
> I've just spotted that isohybrid also helps towards the aim of a single
> image for CD and USB; however a dd-able image is not so easy to use if you
> don't want to overwrite existing data. So supporting additional
locations
> and names would still be useful.
>
> Andrew Yeomans
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 23 May 2009 16:34:41 -0700
> From: "H. Peter Anvin" <hpa at zytor.com>
> Subject: Re: [syslinux] Location and name of configuration files
> To: For discussion of Syslinux and tftp-hpa <syslinux at zytor.com>
> Message-ID: <4A188811.3000709 at zytor.com>
> Content-Type: text/plain; charset=UTF-8
>
> Andrew Yeomans wrote:
> >
> > Would it not be more user-friendly and less error-prone if isolinux
could
> > search both sets of directories, namely:-
> >
> > /boot/isolinux/isolinux.cfg
> > /isolinux/isolinux.cfg
> > /isolinux.cfg
> > /boot/syslinux/syslinux.cfg
> > /syslinux/syslinux.cfg
> > /syslinux.cfg
> >
> > And similarly syslinux could do the same but with the syslinux.cfg
files
> > first. That would make it possible to have a single .iso file that was
> easy
> > to copy across to a USB drive, without manually changing it. And would
> also
> > support different config files in the same .iso image for syslinux and
> > isolinux, if there was a good reason to have them different.
> >
> > I've just spotted that isohybrid also helps towards the aim of a
single
> > image for CD and USB; however a dd-able image is not so easy to use if
> you
> > don't want to overwrite existing data. So supporting additional
locations
> > and names would still be useful.
> >
>
> Yes, I'm seriously thinking that having all derivatives fall back to
> syslinux.cfg is the right thing to do. It won't happen for 3.81
(it's
> way too late to make that change), but expect to see it in a future
> release.
>
> -hpa
>
> --
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel. I don't speak on their behalf.
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 23 May 2009 16:41:14 -0700
> From: "H. Peter Anvin" <hpa at zytor.com>
> Subject: Re: [syslinux] Syslinux.exe 64 bits Windows
> To: For discussion of Syslinux and tftp-hpa <syslinux at zytor.com>
> Message-ID: <4A18899A.4030407 at zytor.com>
> Content-Type: text/plain; charset=UTF-8
>
> Ryan McLean wrote:
> > Under vista64 try right clicking and running as admin. I am guessing
the
> > installer doesn't have the "vista elevate permissions
code" iirc this is
> > set in the manifest file.
>
> It rather seems like this is a peculiarity of the WinPE environment,
> which makes sense. I don't have time to maintain my own Win64
> cross-compiler (it was way too much of a pain with the Win32 compiler,
> which I fortunately don't have to worry about anymore since the Fedora
> MinGW project takes care of it), but presumably there will be a 64-bit
> MinGW available reasonably soon at which point I'll start building a
> syslinux64.exe by default.
>
> -hpa
>
> --
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel. I don't speak on their behalf.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Sat, 23 May 2009 19:36:09 -0500
> From: sritej s <sritejv at gmail.com>
> Subject: [syslinux] PXEboot trouble with Soekris 4826
> To: syslinux at zytor.com
> Message-ID:
> <86a295980905231736h33a876cby7df0c72a732d46b9 at
mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hello Everyone,
>
> I am having trouble with booting a soekris 4826 board.after setting up my
> tftp,dhcp and web servers ,I log into the board using minicom and type boot
> f0,which doesn't quite work out.
>
> > boot f0
>
> NSC DP83815/DP83816 Fast Ethernet UNDI, v1.03
> Copyright (C) 2002, 2003 National Semiconductor Corporation
> All rights reserved.
>
> Pre-boot eXecution Environment PXE-2.0 (build 082)
> Copyright (C) 1997-2000 Intel Corporation
>
>
> CLIENT MAC ADDR: 00 00 24 C8 C9 60
> CLIENT IP: 192.168.200.3 MASK: 255.255.255.0 DHCP IP: 192.168.200.1
>
> It just stops at this point,doesnt freeze.My dhcp is configured correctly I
> guess but I suspect my tftp is not ,because when I mention an incorrect
> file
> name in the dhcpd.conf file,it immediately reports file not found.There
> must
> be a problem with the file transfer.
>
> My dhcp file is like this
> /etc/dhcpd.conf
> ddns-update-style none;
> # option subnet-mask 255.255.255.0;
> default-lease-time 600;
> max-lease-time 600;
>
> subnet 192.168.200.0 netmask 255.255.255.0 {
> range 192.168.200.2 192.168.200.3;
> # option broadcast-address 10.2.1.31;
> # option routers 10.2.1.1;
> allow booting;
> allow bootp;
>
> next-server 192.168.200.1;
> #filename "/tftpboot/pxelinux.0"; when this statement is
used,file not
> found
> is reported
> filename "pxelinux.0";
> }
>
> I installed tftp server using tft-hpa-0.46 package.Then i made changes to
>
> xinetd.conf file :
>
> defaults
> {
> instances = 60
> log_type = SYSLOG authpriv
> log_on_success = HOST PID
> log_on_failure = HOST
> cps = 25 30
> }
>
> includedir /etc/xinetd.d
>
> service tftp
> {
> disable = no
> socket_type = dgram
> protocol = udp
> wait = yes
> user = root
> server = /usr/sbin/in.tftpd
> server_args = -s /tftpboot
> per_source =11
> cps =100 2
> flags =IPv4
> }
>
> (there are also a few tftp files in the xinetd.d directory).
> My /tftpboot/pxelinux.cfg has the file C0 which is like this:
>
> (I use a USB-serial port connector)
>
> SERIAL 0 19200
> DEFAULT /vmlinuz console=ttys0,19200,n8 initrd=initrd.img ramdisk_size=8192
> root=/dev/ram0
>
> my initrd.img is in the /tftpboot directory and the final images are in the
> /var/www directory.
>
> I use a USB-serial port connector.
>
> Did I miss anything?
>
> Thank you for your time.
> Sritej
>
>
> ------------------------------
>
> Message: 6
> Date: Sun, 24 May 2009 09:56:55 +0200
> From: Stefan Thomanek <stefan at thomanek.eu>
> Subject: [syslinux] Sending UDP packets from comboot
> To: syslinux at zytor.com
> Message-ID: <4A18FDC7.900 at thomanek.eu>
> Content-Type: text/plain; charset=ISO-8859-15; format=flowed
>
> Hi everyone.
>
> I've read through the archives and found a few posts about using the
PXE
> stack, but none of these really helped me.
> What i want to do is: Prompt the user for 2 values, desired hostname and
> a "pin" (just a number) and send this information
> over UDP to my server
> The problem is not the user input but the UDP part.
>
> I've tried to change the code from the post of jesse barker (6.1.2007):
>
> // code start
> s_PXENV_UDP_WRITE args;
>
> memset(&args, 0, sizeof(args));
>
> args.ip = inet_addr("255.255.255.255"); // inet_addr working
here?
> args.gw = inet_addr("0.0.0.0");
> args.src_port = 4711;
> args.dst_port = 4799;
> args.buffer_size = <some sizeof() code>
> args.buffer = <some stuff to put my data in>
>
> memcpy(__com32.cs_bounce, &args, sizeof(args);
>
> inputRegs.es = SEG(__com32.cs_bounce);
> inputRegs.edi.w[0] = OFFS(__com32.cs_bounce);
> inputRegs.eax.w[0] = 0x0009; /* call PXE stack */
> inputRegs.ebx.w[0] = 0x0033; /* PXENV_UDP_WRITE opcode */
>
> __intcall(0x22, &inputRegs, NULL);
> // code end
>
> Could anyone give me a hand on that?
> Or is there any example already where a UDP write is used?
>
>
> Thanks in advance,
>
> -Stefan
>
>
>
> ------------------------------
>
> Message: 7
> Date: Sun, 24 May 2009 11:48:16 +0200 (CEST)
> From: Dag Wieers <dag at wieers.com>
> Subject: Re: [syslinux] Location and name of configuration files
> To: For discussion of Syslinux and tftp-hpa <syslinux at zytor.com>
> Message-ID: <alpine.LRH.2.00.0905241144370.17630 at horsea.3ti.be>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Sat, 23 May 2009, H. Peter Anvin wrote:
>
> > Andrew Yeomans wrote:
> >>
> >> Would it not be more user-friendly and less error-prone if
isolinux
> could
> >> search both sets of directories, namely:-
> >>
> >> /boot/isolinux/isolinux.cfg
> >> /isolinux/isolinux.cfg
> >> /isolinux.cfg
> >> /boot/syslinux/syslinux.cfg
> >> /syslinux/syslinux.cfg
> >> /syslinux.cfg
> >
> > Yes, I'm seriously thinking that having all derivatives fall back
to
> > syslinux.cfg is the right thing to do. It won't happen for 3.81
(it's
> > way too late to make that change), but expect to see it in a future
> release.
>
> Small things like this bring a smile. Things are coming together and I
> like it !
>
> How do derivatives handle unknown keywords ? We may want to change that
> too and look for another mechanism for those errors so they are silenced
> by default ?
>
> Maybe add a debug option to syslinux.cfg to have the derivatives output
> parsing information or something like that (just freewheeling here) in
> case people want to dig into why something is not behaving as expected.
>
> --
> -- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
> [Any errors in spelling, tact or fact are transmission errors]
>
>
>
> ------------------------------
>
> Message: 8
> Date: Sun, 24 May 2009 14:30:29 +0200
> From: "Sebastian Herbszt" <herbszt at gmx.de>
> Subject: [syslinux] menu: alternative config file
> To: <syslinux at zytor.com>
> Message-ID: <0A96876E46654F098B4CF42E6DE1C192 at FSCPC>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> reply-type=original
>
> The menu system allows one to specify an alternative config file and
it's
> also possible to
> specify more than one file. menu.txt got
> "If you specify more than one file, they will all be read, in the
order
> specified."
>
> What is the desired failure mode if one of those files doesn't exist?
>
> com32/menu/menumain.c calls parse_configs() which itself calls
> parse_one_config (readconfig.c).
> parse_one_config() returns -1 if the specified config file is not
> available, but the return code is not
> checked in parse_configs(). The current failure mode is therefore
"ignore".
> If this is by design it might
> be worth mentioning it in menu.txt.
>
> If no config file is found the menu system clears the screen, but
doesn't
> display anything until a key
> is pressed (no "grid", no "press tab key" message,
something's broken
> here?).
>
> - Sebastian
>
>
>
> ------------------------------
>
> Message: 9
> Date: Sun, 24 May 2009 14:56:08 +0200 (CEST)
> From: Dag Wieers <dag at wieers.com>
> Subject: Re: [syslinux] Booting firmware harddisk image with memdisk
> fails
> To: For discussion of Syslinux and tftp-hpa <syslinux at zytor.com>
> Message-ID: <alpine.LRH.2.00.0905241443540.28172 at horsea.3ti.be>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Sat, 23 May 2009, Michael Grundmann wrote:
>
> > Dag Wieers schrieb:
> >> On Sat, 23 May 2009, Michael Grundmann wrote:
> >>
> >> > i did it sucessfully on my t400 with syslinux 3.80 (built
form source
> on
> >> > a
> >> > gentoo machine)
> >>
> >> I don't think the version makes a difference. But is it
possible that
> the
> >> (older) versions of the build tools exposes a bug on certain
hardware ?
> >>
> >> If so, it could be useful to send me your compiled memdisk so I
can
> simply
> >> try to see if it makes a difference on my system.
> >
> > its compiled for x86_64 if that doesnt matter?
>
> Michael send me his memdisk, and I had exactly the same problem. Memdisk
> boots and I get:
>
> ----
> Lenovo Group Limited
>
> Starting PC DOS...
>
>
> ----
>
> and then nothing. While in Qemu it goes into the firmware
> flash application.
>
> Michael has a Thinkpad T400 which worked. The author of the ThinkWiki page
> has a Thinkpad X200 and it worked too. I have a Thinkpad X200s with the
> same BIOS release and it fails.
>
> It fails on my hardware with Michael's memdisk (and with the ones I
> tested) so we can rule out the memdisk build and we can rule out the BIOS
> version.
>
> I can only conclude that it has to do with a BIOS option or hardware
> configuration that triggers a bug in memdisk. I went over a lot of BIOS
> options, and changed some options that should not have any impact, to no
> avail.
>
> Peter, do you have anything worthwhile to add that I can test ?
>
> The harddisk image I am testing comes from the type 4 eltorito ISO at:
>
> http://www-307.ibm.com/pc/support/site.wss/MIGR-70348.html
>
> and can be extracted either with the isobar utility or with a patched
> geteltorito script. (both come packaged with RPMforge)
>
> --
> -- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
> [Any errors in spelling, tact or fact are transmission errors]
>
>
>
> ------------------------------
>
> Message: 10
> Date: Sun, 24 May 2009 05:25:13 -0700 (PDT)
> From: Kim Mik <kimmik999999 at yahoo.co.uk>
> Subject: Re: [syslinux] Location and name of configuration files
> To: For discussion of Syslinux and tftp-hpa <syslinux at zytor.com>
> Message-ID: <372276.83373.qm at web24606.mail.ird.yahoo.com>
> Content-Type: text/plain; charset=utf-8
>
>
> It would also be nice, that syslinux and derivates, will look for a config
> file at the directory where syslinux is installed.
>
> syslinux -d /some/directory/ /dev/sda1
>
> will try to find /some/directory/syslinux.cfg first.
>
> Also a new keyword CD can be handy when you want to make a multiboot
> CD/USB/... from different distro's.
>
> The CD keyword will make the directory that is given after it, the new main
> directory, so you don't need to adapt all relative paths.
>
> $ ls /some/directory/distro1
> boot.msg
> bzImage
> initrd
>
> ==============================> CD /some/directory/distro1
>
> DISPLAY boot.msg
>
> KERNEL bzImage
> APPEND initrd=initrd.gz some parameters
> ==============================>
>
>
>
> $ ls /some/directory/distro2
> boot.msg
>
> bzImage
>
> initrd
>
> ==============================> CD /some/directory/distro2
>
> DISPLAY boot.msg
>
> KERNEL bzImage
> APPEND initrd=initrd.gz some parameters
> ==============================>
>
> Gert Hulselmans
>
>
>
> ----- Original Message ----
> From: H. Peter Anvin <hpa at zytor.com>
> To: For discussion of Syslinux and tftp-hpa <syslinux at zytor.com>
> Sent: Sunday, 24 May, 2009 1:34:41
> Subject: Re: [syslinux] Location and name of configuration files
>
> Andrew Yeomans wrote:
> >
> > Would it not be more user-friendly and less error-prone if isolinux
could
> > search both sets of directories, namely:-
> >
> > /boot/isolinux/isolinux.cfg
> > /isolinux/isolinux.cfg
> > /isolinux.cfg
> > /boot/syslinux/syslinux.cfg
> > /syslinux/syslinux.cfg
> > /syslinux.cfg
> >
> > And similarly syslinux could do the same but with the syslinux.cfg
files
> > first. That would make it possible to have a single .iso file that was
> easy
> > to copy across to a USB drive, without manually changing it. And would
> also
> > support different config files in the same .iso image for syslinux and
> > isolinux, if there was a good reason to have them different.
> >
> > I've just spotted that isohybrid also helps towards the aim of a
single
> > image for CD and USB; however a dd-able image is not so easy to use if
> you
> > don't want to overwrite existing data. So supporting additional
locations
> > and names would still be useful.
> >
>
> Yes, I'm seriously thinking that having all derivatives fall back to
> syslinux.cfg is the right thing to do. It won't happen for 3.81
(it's
> way too late to make that change), but expect to see it in a future
> release.
>
> -hpa
>
> --
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel. I don't speak on their behalf.
>
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>
>
>
>
>
>
> ------------------------------
>
> Message: 11
> Date: Sun, 24 May 2009 10:57:54 -0400
> From: "Miller, Shao" <Shao.Miller at yrdsb.edu.on.ca>
> Subject: Re: [syslinux] PXEboot trouble with Soekris 4826
> To: "For discussion of Syslinux and tftp-hpa" <syslinux at
zytor.com>
> Message-ID:
> <F0E5F8699DE1364584CDB894E997135513784B20 at
YRDSB5.YRDSB.YRDSB.NET>
> Content-Type: text/plain; charset="us-ascii"
>
> Good day Sritej,
>
> In regards to your PXE-booting challenge, I have a few thoughts:
> - I don't see a problem with using just "pxelinux.0" in your
dhcpd.conf
> file; it's probably the right thing to do
> - I wonder if you actually manage to download PXELINUX and see it report
> anything. I'm not clear on if you were saying that your challenge
> disappears if you use the DHCP filename response "pxelinux.0"
> - Tools like tcpdump and Wireshark can help to see exactly what's
> happening on the network, and may be revealing
> - /tftpboot/ filesystem permissions might be worth checking
> - Manually using a TFTP client (Linux/BSD/Windows/DOS) and attempting to
> download from your TFTP service can be a good test for TFTP
> functionality
>
> I hope some of these thoughts help you out!
>
> - Shao Miller
>
> -----Original Message-----
> From: syslinux-bounces at zytor.com [mailto:syslinux-bounces at zytor.com]
On
> Behalf Of sritej s
> Sent: Saturday, May 23, 2009 20:36
> To: syslinux at zytor.com
> Subject: [syslinux] PXEboot trouble with Soekris 4826
>
> Hello Everyone,
>
> I am having trouble with booting a soekris 4826 board.after setting up
> my
> tftp,dhcp and web servers ,I log into the board using minicom and type
> boot
> f0,which doesn't quite work out.
>
> > boot f0
>
> NSC DP83815/DP83816 Fast Ethernet UNDI, v1.03
> Copyright (C) 2002, 2003 National Semiconductor Corporation
> All rights reserved.
>
> Pre-boot eXecution Environment PXE-2.0 (build 082)
> Copyright (C) 1997-2000 Intel Corporation
>
>
> CLIENT MAC ADDR: 00 00 24 C8 C9 60
> CLIENT IP: 192.168.200.3 MASK: 255.255.255.0 DHCP IP: 192.168.200.1
>
> It just stops at this point,doesnt freeze.My dhcp is configured
> correctly I
> guess but I suspect my tftp is not ,because when I mention an incorrect
> file
> name in the dhcpd.conf file,it immediately reports file not found.There
> must
> be a problem with the file transfer.
>
> My dhcp file is like this
> /etc/dhcpd.conf
> ddns-update-style none;
> # option subnet-mask 255.255.255.0;
> default-lease-time 600;
> max-lease-time 600;
>
> subnet 192.168.200.0 netmask 255.255.255.0 {
> range 192.168.200.2 192.168.200.3;
> # option broadcast-address 10.2.1.31;
> # option routers 10.2.1.1;
> allow booting;
> allow bootp;
>
> next-server 192.168.200.1;
> #filename "/tftpboot/pxelinux.0"; when this statement is
used,file not
> found
> is reported
> filename "pxelinux.0";
> }
>
> I installed tftp server using tft-hpa-0.46 package.Then i made changes
> to
>
> xinetd.conf file :
>
> defaults
> {
> instances = 60
> log_type = SYSLOG authpriv
> log_on_success = HOST PID
> log_on_failure = HOST
> cps = 25 30
> }
>
> includedir /etc/xinetd.d
>
> service tftp
> {
> disable = no
> socket_type = dgram
> protocol = udp
> wait = yes
> user = root
> server = /usr/sbin/in.tftpd
> server_args = -s /tftpboot
> per_source =11
> cps =100 2
> flags =IPv4
> }
>
> (there are also a few tftp files in the xinetd.d directory).
> My /tftpboot/pxelinux.cfg has the file C0 which is like this:
>
> (I use a USB-serial port connector)
>
> SERIAL 0 19200
> DEFAULT /vmlinuz console=ttys0,19200,n8 initrd=initrd.img
> ramdisk_size=8192
> root=/dev/ram0
>
> my initrd.img is in the /tftpboot directory and the final images are in
> the
> /var/www directory.
>
> I use a USB-serial port connector.
>
> Did I miss anything?
>
> Thank you for your time.
> Sritej
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>
>
>
> ------------------------------
>
> Message: 12
> Date: Sun, 24 May 2009 11:09:01 -0400
> From: "Miller, Shao" <Shao.Miller at yrdsb.edu.on.ca>
> Subject: Re: [syslinux] Booting firmware harddisk image with memdisk
> fails
> To: "For discussion of Syslinux and tftp-hpa" <syslinux at
zytor.com>
> Message-ID:
> <F0E5F8699DE1364584CDB894E997135513784B26 at
YRDSB5.YRDSB.YRDSB.NET>
> Content-Type: text/plain; charset="us-ascii"
>
> Good day Dag and Michael,
>
> In regards to you challenge MEMDISK-booting an HDD image extracted from
> an .ISO image, I'm curious:
> - I know all MEMDISK options were tried at one point; did that include
> "raw"?
> - Are you specifying c= h= s= geometry for the HDD image? If so, how
> are you determining the correct c= h= s= to pass?
> - If you use the HDD with QEmu as an _actual_ HDD, does that work?
>
> qemu -hda foo.hdd -boot c
>
> - If you give QEmu some other HDD image, then try booting QEmu and doing
> the MEMDISK thing with the extracted image, does that work? I know you
> said it works in QEmu, so I am asking if it is because QEmu has no other
> HDDs in your test, or if changing that parameter changes the test's
> success
>
> Good luck!
>
> - Shao Miller
>
> -----Original Message-----
> From: syslinux-bounces at zytor.com [mailto:syslinux-bounces at zytor.com]
On
> Behalf Of Dag Wieers
> Sent: Sunday, May 24, 2009 08:56
> To: For discussion of Syslinux and tftp-hpa
> Subject: Re: [syslinux] Booting firmware harddisk image with memdisk
> fails
>
> On Sat, 23 May 2009, Michael Grundmann wrote:
>
> > Dag Wieers schrieb:
> >> On Sat, 23 May 2009, Michael Grundmann wrote:
> >>
> >> > i did it sucessfully on my t400 with syslinux 3.80 (built
form
> source on
> >> > a
> >> > gentoo machine)
> >>
> >> I don't think the version makes a difference. But is it
possible
> that the
> >> (older) versions of the build tools exposes a bug on certain
> hardware ?
> >>
> >> If so, it could be useful to send me your compiled memdisk so I
can
> simply
> >> try to see if it makes a difference on my system.
> >
> > its compiled for x86_64 if that doesnt matter?
>
> Michael send me his memdisk, and I had exactly the same problem. Memdisk
>
> boots and I get:
>
> ----
> Lenovo Group Limited
>
> Starting PC DOS...
>
>
> ----
>
> and then nothing. While in Qemu it goes into the firmware
> flash application.
>
> Michael has a Thinkpad T400 which worked. The author of the ThinkWiki
> page
> has a Thinkpad X200 and it worked too. I have a Thinkpad X200s with the
> same BIOS release and it fails.
>
> It fails on my hardware with Michael's memdisk (and with the ones I
> tested) so we can rule out the memdisk build and we can rule out the
> BIOS
> version.
>
> I can only conclude that it has to do with a BIOS option or hardware
> configuration that triggers a bug in memdisk. I went over a lot of BIOS
> options, and changed some options that should not have any impact, to no
>
> avail.
>
> Peter, do you have anything worthwhile to add that I can test ?
>
> The harddisk image I am testing comes from the type 4 eltorito ISO at:
>
> http://www-307.ibm.com/pc/support/site.wss/MIGR-70348.html
>
> and can be extracted either with the isobar utility or with a patched
> geteltorito script. (both come packaged with RPMforge)
>
> --
> -- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
> [Any errors in spelling, tact or fact are transmission errors]
>
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>
>
>
> ------------------------------
>
> Message: 13
> Date: Sun, 24 May 2009 18:05:24 +0200 (CEST)
> From: Dag Wieers <dag at wieers.com>
> Subject: Re: [syslinux] Booting firmware harddisk image with memdisk
> fails
> To: For discussion of Syslinux and tftp-hpa <syslinux at zytor.com>
> Message-ID: <alpine.LRH.2.00.0905241759340.28172 at horsea.3ti.be>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Sun, 24 May 2009, Miller, Shao wrote:
>
> > Good day Dag and Michael,
> >
> > In regards to you challenge MEMDISK-booting an HDD image extracted
from
> > an .ISO image, I'm curious:
> > - I know all MEMDISK options were tried at one point; did that include
> > "raw"?
>
> Yes.
>
> > - Are you specifying c= h= s= geometry for the HDD image? If so, how
> > are you determining the correct c= h= s= to pass?
>
> No, I was planning to look if for Qemu the C/H/S was the same as for my
> BIOS. I would think it is the same though. Since it is the same image and
> the same memdisk. And it works within Qemu and it works for others :)
>
> > - If you use the HDD with QEmu as an _actual_ HDD, does that work?
> >
> > qemu -hda foo.hdd -boot c
>
> It does not contain a bootloader. What works is:
>
> qemu -kernel /boot/memdisk -initrd /boot/6duj08uc.img
>
> > - If you give QEmu some other HDD image, then try booting QEmu and
doing
> > the MEMDISK thing with the extracted image, does that work? I know
you
> > said it works in QEmu, so I am asking if it is because QEmu has no
other
> > HDDs in your test, or if changing that parameter changes the
test's
> > success
>
> I tried with a USB stick as well as my built-in SD reader and an 16GB SDHC
> card and it fails there too. Both do work within Qemu.
>
> And the same image works with memdisk on someone else's X200 and T400,
> while it fails on my X200s. So there is something fishy going on.
>
> BTW I reported it also on ThinkWiki and there are others having the same
> problem, so it is not just me either :)
>
> http://www.thinkwiki.org/wiki/Talk:BIOS_update_without_optical_disk
>
> --
> -- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
> [Any errors in spelling, tact or fact are transmission errors]
>
>
>
> ------------------------------
>
> Message: 14
> Date: Sun, 24 May 2009 12:20:56 -0400
> From: "Miller, Shao" <Shao.Miller at yrdsb.edu.on.ca>
> Subject: Re: [syslinux] Booting firmware harddisk image with memdisk
> fails
> To: "For discussion of Syslinux and tftp-hpa" <syslinux at
zytor.com>
> Message-ID:
> <F0E5F8699DE1364584CDB894E997135513784B48 at
YRDSB5.YRDSB.YRDSB.NET>
> Content-Type: text/plain; charset="us-ascii"
>
> What about the following test?:
>
> qemu -hda foo.hdd -boot c
>
> where foo.hdd is a small blank image that underwent the following steps:
> - Formatted as FAT from within QEmu itself (maybe a DOS floppy as -fda)
> - SYSLINUX installed
> - A small syslinux.cfg file which boots MEMDISK and the firmware HDD
> image
> - MEMDISK copied to the partition
> - The firmware image copied to the partition
>
> In this case, QEmu would have an HDD attached. I'm curious as to
> whether or not that would work.
>
> My QEmu (0.9.0) demands an -hda parameter when using -kernel, but I
> didn't see one in your QEmu command-line. Is it possible that your
QEmu
> is newer and uses the -initrd param as an alias for -hda in the case of
> -kernel? I have no idea at the moment.
>
> It would still be good to know the correct geometry of the HDD image.
> If you can boot the image from the .ISO and get a DOS CLI (maybe by
> hitting F8 really quickly as PC-DOS loads!) then you could perhaps run a
> DOS util to find the geometry. Such utils might be GRUB4DOS or
> PartitionMagic or something else.
>
> Also, if these are thin clients without HDDs, or if you want to have
> some fun, you could SAN-boot the firmware image using gPXE's AoE or
> iSCSI support! Heh.
>
> - Shao Miller
>
> -----Original Message-----
> From: syslinux-bounces at zytor.com [mailto:syslinux-bounces at zytor.com]
On
> Behalf Of Dag Wieers
> Sent: Sunday, May 24, 2009 12:05
> To: For discussion of Syslinux and tftp-hpa
> Subject: Re: [syslinux] Booting firmware harddisk image with memdisk
> fails
>
> On Sun, 24 May 2009, Miller, Shao wrote:
>
> > Good day Dag and Michael,
> >
> > In regards to you challenge MEMDISK-booting an HDD image extracted
> from
> > an .ISO image, I'm curious:
> > - I know all MEMDISK options were tried at one point; did that include
> > "raw"?
>
> Yes.
>
> > - Are you specifying c= h= s= geometry for the HDD image? If so, how
> > are you determining the correct c= h= s= to pass?
>
> No, I was planning to look if for Qemu the C/H/S was the same as for my
> BIOS. I would think it is the same though. Since it is the same image
> and
> the same memdisk. And it works within Qemu and it works for others :)
>
> > - If you use the HDD with QEmu as an _actual_ HDD, does that work?
> >
> > qemu -hda foo.hdd -boot c
>
> It does not contain a bootloader. What works is:
>
> qemu -kernel /boot/memdisk -initrd /boot/6duj08uc.img
>
> > - If you give QEmu some other HDD image, then try booting QEmu and
> doing
> > the MEMDISK thing with the extracted image, does that work? I know
> you
> > said it works in QEmu, so I am asking if it is because QEmu has no
> other
> > HDDs in your test, or if changing that parameter changes the
test's
> > success
>
> I tried with a USB stick as well as my built-in SD reader and an 16GB
> SDHC
> card and it fails there too. Both do work within Qemu.
>
> And the same image works with memdisk on someone else's X200 and T400,
> while it fails on my X200s. So there is something fishy going on.
>
> BTW I reported it also on ThinkWiki and there are others having the same
>
> problem, so it is not just me either :)
>
> http://www.thinkwiki.org/wiki/Talk:BIOS_update_without_optical_disk
>
> --
> -- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
> [Any errors in spelling, tact or fact are transmission errors]
>
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>
>
>
> ------------------------------
>
> Message: 15
> Date: Sun, 24 May 2009 18:58:20 +0200 (CEST)
> From: Dag Wieers <dag at wieers.com>
> Subject: Re: [syslinux] Booting firmware harddisk image with memdisk
> fails
> To: For discussion of Syslinux and tftp-hpa <syslinux at zytor.com>
> Message-ID: <alpine.LRH.2.00.0905241849560.28172 at horsea.3ti.be>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Sun, 24 May 2009, Miller, Shao wrote:
>
> > What about the following test?:
> >
> > qemu -hda foo.hdd -boot c
> >
> > where foo.hdd is a small blank image that underwent the following
steps:
> > - Formatted as FAT from within QEmu itself (maybe a DOS floppy as
-fda)
> > - SYSLINUX installed
> > - A small syslinux.cfg file which boots MEMDISK and the firmware HDD
> > image
> > - MEMDISK copied to the partition
> > - The firmware image copied to the partition
> >
> > In this case, QEmu would have an HDD attached. I'm curious as to
> > whether or not that would work.
>
> I am not sure how that makes a difference as doing it with a real device.
> Wit Qemu it works, I really do not see a point unless you want to find a
> case where it does not work with Qemu ?
>
> The problem is the BIOS settings or my specific Thinkpad hardware and I
> fail to see how tests with Qemu will resolve any of that since all my
> tests in Qemu worked fine.
>
>
> > My QEmu (0.9.0) demands an -hda parameter when using -kernel, but I
> > didn't see one in your QEmu command-line. Is it possible that
your QEmu
> > is newer and uses the -initrd param as an alias for -hda in the case
of
> > -kernel? I have no idea at the moment.
>
> My Qemu is newer and have seperate -kernel and -initrd options that work
> fine.
>
>
> > It would still be good to know the correct geometry of the HDD image.
> > If you can boot the image from the .ISO and get a DOS CLI (maybe by
> > hitting F8 really quickly as PC-DOS loads!) then you could perhaps run
a
> > DOS util to find the geometry. Such utils might be GRUB4DOS or
> > PartitionMagic or something else.
>
> Right, but the HDD image has almost no tools and I am not interested to
> ruin yet another blank CD for this. (I needed one to flash my SDD too
> because memdisk failed)
>
>
> > Also, if these are thin clients without HDDs, or if you want to have
> > some fun, you could SAN-boot the firmware image using gPXE's AoE
or
> > iSCSI support! Heh.
>
> Right, I would like to do another test with PXE, because in previous tests
> where it failed to boot using memdisk (those from 2004 and 2005) it always
> worked on the same hardware using pxelinux and even isolinux if I remember
> correctly (the archives hold this information).
>
> memdisk would always fail from local disk or USB sticks. When using Linux
> or BSD images instead of DOS the kernel provided more information related
> to the disk. So I think it is being triggered by something BIOS/disk
> related.
>
> But instead of doing all my tests again and copying the information from
> the screen like I did years ago I would like to know what I can do to help
> debug this without doing more tests and spending more time...
>
> Nobody ever helped me in the past with this issue (and lots of people have
> reported it). Just look for the archives for memdisk and you will find
> dozens unresolved messages with the same symptoms.
>
> --
> -- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
> [Any errors in spelling, tact or fact are transmission errors]
>
>
>
> ------------------------------
>
> Message: 16
> Date: Sun, 24 May 2009 14:02:04 -0400
> From: "Miller, Shao" <Shao.Miller at yrdsb.edu.on.ca>
> Subject: Re: [syslinux] Booting firmware harddisk image with memdisk
> fails
> To: "For discussion of Syslinux and tftp-hpa" <syslinux at
zytor.com>
> Message-ID:
> <F0E5F8699DE1364584CDB894E997135513784B88 at
YRDSB5.YRDSB.YRDSB.NET>
> Content-Type: text/plain; charset="us-ascii"
>
> Sorry Dag, I actually have no idea if this problem unit actually has an
> HDD, as I couldn't be bothered to look it up, so I was assuming that it
> did, and trying to get your QEmu test to mimic the hardware more
> closely. Techincally, QEmu + PXELINUX would have been the most accurate
> mimcry of the scenario, even beyond the test I suggested. Instead,
I'll
> download the thing and report the correct geometry and any other
> findings. - Shao
>
> -----Original Message-----
> From: syslinux-bounces at zytor.com [mailto:syslinux-bounces at zytor.com]
On
> Behalf Of Dag Wieers
> Sent: Sunday, May 24, 2009 12:58
> To: For discussion of Syslinux and tftp-hpa
> Subject: Re: [syslinux] Booting firmware harddisk image with memdisk
> fails
>
> On Sun, 24 May 2009, Miller, Shao wrote:
>
> > What about the following test?:
> >
> > qemu -hda foo.hdd -boot c
> >
> > where foo.hdd is a small blank image that underwent the following
> steps:
> > - Formatted as FAT from within QEmu itself (maybe a DOS floppy as
> -fda)
> > - SYSLINUX installed
> > - A small syslinux.cfg file which boots MEMDISK and the firmware HDD
> > image
> > - MEMDISK copied to the partition
> > - The firmware image copied to the partition
> >
> > In this case, QEmu would have an HDD attached. I'm curious as to
> > whether or not that would work.
>
> I am not sure how that makes a difference as doing it with a real
> device.
> Wit Qemu it works, I really do not see a point unless you want to find a
>
> case where it does not work with Qemu ?
>
> The problem is the BIOS settings or my specific Thinkpad hardware and I
> fail to see how tests with Qemu will resolve any of that since all my
> tests in Qemu worked fine.
>
>
> > My QEmu (0.9.0) demands an -hda parameter when using -kernel, but I
> > didn't see one in your QEmu command-line. Is it possible that
your
> QEmu
> > is newer and uses the -initrd param as an alias for -hda in the case
> of
> > -kernel? I have no idea at the moment.
>
> My Qemu is newer and have seperate -kernel and -initrd options that work
>
> fine.
>
>
> > It would still be good to know the correct geometry of the HDD image.
> > If you can boot the image from the .ISO and get a DOS CLI (maybe by
> > hitting F8 really quickly as PC-DOS loads!) then you could perhaps run
> a
> > DOS util to find the geometry. Such utils might be GRUB4DOS or
> > PartitionMagic or something else.
>
> Right, but the HDD image has almost no tools and I am not interested to
> ruin yet another blank CD for this. (I needed one to flash my SDD too
> because memdisk failed)
>
>
> > Also, if these are thin clients without HDDs, or if you want to have
> > some fun, you could SAN-boot the firmware image using gPXE's AoE
or
> > iSCSI support! Heh.
>
> Right, I would like to do another test with PXE, because in previous
> tests
> where it failed to boot using memdisk (those from 2004 and 2005) it
> always
> worked on the same hardware using pxelinux and even isolinux if I
> remember
> correctly (the archives hold this information).
>
> memdisk would always fail from local disk or USB sticks. When using
> Linux
> or BSD images instead of DOS the kernel provided more information
> related
> to the disk. So I think it is being triggered by something BIOS/disk
> related.
>
> But instead of doing all my tests again and copying the information from
>
> the screen like I did years ago I would like to know what I can do to
> help
> debug this without doing more tests and spending more time...
>
> Nobody ever helped me in the past with this issue (and lots of people
> have
> reported it). Just look for the archives for memdisk and you will find
> dozens unresolved messages with the same symptoms.
>
> --
> -- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
> [Any errors in spelling, tact or fact are transmission errors]
>
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>
>
>
> ------------------------------
>
> Message: 17
> Date: Sun, 24 May 2009 11:18:26 -0700
> From: "H. Peter Anvin" <hpa at zytor.com>
> Subject: Re: [syslinux] Sending UDP packets from comboot
> To: For discussion of Syslinux and tftp-hpa <syslinux at zytor.com>
> Message-ID: <4A198F72.2050302 at zytor.com>
> Content-Type: text/plain; charset=UTF-8
>
> Stefan Thomanek wrote:
> > Hi everyone.
> >
> > I've read through the archives and found a few posts about using
the PXE
> > stack, but none of these really helped me.
> > What i want to do is: Prompt the user for 2 values, desired hostname
and
> > a "pin" (just a number) and send this information
> > over UDP to my server
> > The problem is not the user input but the UDP part.
> >
> > I've tried to change the code from the post of jesse barker
(6.1.2007):
> >
> > // code start
> > s_PXENV_UDP_WRITE args;
> >
> > memset(&args, 0, sizeof(args));
> >
> > args.ip = inet_addr("255.255.255.255"); // inet_addr working
here?
>
> Yes, that should be an inet address.
>
> > args.gw = inet_addr("0.0.0.0");
> > args.src_port = 4711;
>
> For what it's worth, Syslinux itself uses port numbers between 49152
and
> 57343.
>
> > args.dst_port = 4799;
> > args.buffer_size = <some sizeof() code>
> > args.buffer = <some stuff to put my data in>
>
> For the buffer you have to be a bit careful... the buffer is in 16-bit
> segment-offset format, so you need to copy your data into the bounce
> buffer, and then use SEG() and OFFS() to generate pointers to the data.
>
> > memcpy(__com32.cs_bounce, &args, sizeof(args);
> >
> > inputRegs.es = SEG(__com32.cs_bounce);
> > inputRegs.edi.w[0] = OFFS(__com32.cs_bounce);
> > inputRegs.eax.w[0] = 0x0009; /* call PXE stack */
> > inputRegs.ebx.w[0] = 0x0033; /* PXENV_UDP_WRITE opcode */
> >
> > __intcall(0x22, &inputRegs, NULL);
> > // code end
> >
> > Could anyone give me a hand on that?
> > Or is there any example already where a UDP write is used?
> >
>
> What is it you're having problems with? What you have above seems
> reasonably complete.
>
> --
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel. I don't speak on their behalf.
>
>
>
> ------------------------------
>
> Message: 18
> Date: Sun, 24 May 2009 11:22:59 -0700
> From: "H. Peter Anvin" <hpa at zytor.com>
> Subject: Re: [syslinux] Location and name of configuration files
> To: For discussion of Syslinux and tftp-hpa <syslinux at zytor.com>
> Message-ID: <4A199083.2050006 at zytor.com>
> Content-Type: text/plain; charset=UTF-8
>
> Kim Mik wrote:
> > It would also be nice, that syslinux and derivates, will look for a
> config file at the directory where syslinux is installed.
> >
> > syslinux -d /some/directory/ /dev/sda1
> >
> > will try to find /some/directory/syslinux.cfg first.
> >
>
> This is surprisingly difficult given the structure of (V)FAT.
>
> > Also a new keyword CD can be handy when you want to make a multiboot
> CD/USB/... from different distro's.
> >
> > The CD keyword will make the directory that is given after it, the new
> main directory, so you don't need to adapt all relative paths.
>
> The infamous "change directory" problem. It's a lot harder
than you
> think, because doing it the obvious way loses track of the config file.
>
> Making it a directive (as opposed to an option to the CONFIG statement)
> makes is almost impossible to do (because filenames are stored, and you
> just changed the meaning of them all.) Doing it together with CONFIG is
> probably doable, but I have been way too busy to do it right. Gene Cumm
> (I believe) did a patch doing the straightforward bit, but the
> subtleties never got dealt with.
>
> At this point I'm inclined to let any of that wait until liu's
rewrite
> of the filesystem code in C is done.
>
> -hpa
>
> --
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel. I don't speak on their behalf.
>
>
>
> ------------------------------
>
> Message: 19
> Date: Sun, 24 May 2009 11:29:46 -0700
> From: "H. Peter Anvin" <hpa at zytor.com>
> Subject: Re: [syslinux] Sending UDP packets from comboot
> To: For discussion of Syslinux and tftp-hpa <syslinux at zytor.com>
> Message-ID: <4A19921A.9000204 at zytor.com>
> Content-Type: text/plain; charset=UTF-8
>
> H. Peter Anvin wrote:
> >
> >> args.gw = inet_addr("0.0.0.0");
> >> args.src_port = 4711;
> >
> > For what it's worth, Syslinux itself uses port numbers between
49152 and
> > 57343.
> >
> >> args.dst_port = 4799;
>
> Oh yes, you need to use htons() on these, I'm pretty sure.
>
> -hpa
>
> --
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel. I don't speak on their behalf.
>
>
>
> ------------------------------
>
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>
>
> End of Syslinux Digest, Vol 74, Issue 24
> ****************************************
>
Reasonably Related Threads
- [PATCH] memdisk: Fix "might be used uninitialized" warnings
- MEMDISK issue with OptiPlex GX280,620
- [PATCH] memdisk: Use boot_lba logic for booting an offset within the di
- [PATCH] ifmemdsk.c32: Allow boot options based on presence of MEMDISK
- [PATCH] doc: document mBFT and "safe hook"