Mailing List Archive

Chris Adams wrote:
> I have discovered that the JUNOS DHCP server in Juniper J-series routers
> doesn't support setting the next-server IP address field (I have filed a
> bug report with Juniper and they are working on it). Instead, it puts
> the "boot server" in the sname field, which PXELINUX currently ignores.
>
> Here's a simple patch (vs. 3.36) that will take an IP string in the
> field. My assembly is pretty rusty, and I couldn't quite figure out how
> to use the DNS resolver, so it doesn't handle a hostname. This does
> work for me with an IP string.

You have no guarantee that sname is an IP string; in fact, in the
typical case it will not be.

I don't think this patch is safe.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Once upon a time, H. Peter Anvin <hpa@zytor.com> said:
> Chris Adams wrote:
> >I have discovered that the JUNOS DHCP server in Juniper J-series routers
> >doesn't support setting the next-server IP address field (I have filed a
> >bug report with Juniper and they are working on it). Instead, it puts
> >the "boot server" in the sname field, which PXELINUX currently ignores.
> >
> >Here's a simple patch (vs. 3.36) that will take an IP string in the
> >field. My assembly is pretty rusty, and I couldn't quite figure out how
> >to use the DNS resolver, so it doesn't handle a hostname. This does
> >work for me with an IP string.
>
> You have no guarantee that sname is an IP string; in fact, in the
> typical case it will not be.
>
> I don't think this patch is safe.

Well, it doesn't try to parse a null string, and it only saves the
resulting IP if parse_dotquad says it succeeded. How can that not be
safe?
--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Chris Adams wrote:
> Once upon a time, H. Peter Anvin <hpa@zytor.com> said:
>> Chris Adams wrote:
>>> I have discovered that the JUNOS DHCP server in Juniper J-series routers
>>> doesn't support setting the next-server IP address field (I have filed a
>>> bug report with Juniper and they are working on it). Instead, it puts
>>> the "boot server" in the sname field, which PXELINUX currently ignores.
>>>
>>> Here's a simple patch (vs. 3.36) that will take an IP string in the
>>> field. My assembly is pretty rusty, and I couldn't quite figure out how
>>> to use the DNS resolver, so it doesn't handle a hostname. This does
>>> work for me with an IP string.
>> You have no guarantee that sname is an IP string; in fact, in the
>> typical case it will not be.
>>
>> I don't think this patch is safe.
>
> Well, it doesn't try to parse a null string, and it only saves the
> resulting IP if parse_dotquad says it succeeded. How can that not be
> safe?

Hm. I guess the Right Thing is too parse this as a DNS name or IP
address if and only if siaddr is zero. There is no way to get the
source address of the DHCP reply from the PXE stack, so the ultimate
fallback is not available.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

H. Peter Anvin wrote:
> Chris Adams wrote:
>> Once upon a time, H. Peter Anvin <hpa@zytor.com> said:
>>> Chris Adams wrote:
>>>> I have discovered that the JUNOS DHCP server in Juniper J-series routers
>>>> doesn't support setting the next-server IP address field (I have filed a
>>>> bug report with Juniper and they are working on it). Instead, it puts
>>>> the "boot server" in the sname field, which PXELINUX currently ignores.
>>>>
>>>> Here's a simple patch (vs. 3.36) that will take an IP string in the
>>>> field. My assembly is pretty rusty, and I couldn't quite figure out how
>>>> to use the DNS resolver, so it doesn't handle a hostname. This does
>>>> work for me with an IP string.
>>> You have no guarantee that sname is an IP string; in fact, in the
>>> typical case it will not be.
>>>
>>> I don't think this patch is safe.
>> Well, it doesn't try to parse a null string, and it only saves the
>> resulting IP if parse_dotquad says it succeeded. How can that not be
>> safe?
>
> Hm. I guess the Right Thing is too parse this as a DNS name or IP
> address if and only if siaddr is zero. There is no way to get the
> source address of the DHCP reply from the PXE stack, so the ultimate
> fallback is not available.
>
Hmmh,

"sname" is -- according to RFC2131 -- an _optional_ null terminated string
which can really be _anything_.

Furthermore the fact that "pxelinux" is loaded, _although_ "next-server"
hasn't been set, indicates that not only the router software is broken
but also the client's PXE-ROM.
<quote source="RFC2131">
DHCP clarifies the interpretation of the 'siaddr' field as the
address of the server to use in the next step of the client's
bootstrap process. A DHCP server may return its own address in the
'siaddr' field, if the server is prepared to supply the next
bootstrap service (e.g., delivery of an operating system executable
image). A DHCP server always returns its own address in the 'server
identifier' option.
</quote>

So why should "pxelinux" compensate for so many mistakes?

Last but not least, imagine the case that someone has configured
a DHCP/TFTP server to supply a a lot of different boot files to
different clients (by scope and/or hardware address), while
the "next-server" statement is configured globally.

For maintenenance reasons this "someone" disables the "next-server"
statement to prevent ALL clients from net booting.

Now, all those "meaning-well" PXE-ROMs and possibly "pxelinux"
wouldn't believe what they were told, but instead use "clever
tricks" to figure out, what this "someone" must have really meant ...

:-) Axel

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Dyks, Axel (XL) wrote:
>
> So why should "pxelinux" compensate for so many mistakes?
>

Well, there is the philosophy of being liberal in what you accept
(conservative in what you send). Another way to put it is "because it
can." If it can, which isn't guaranteed.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

H. Peter Anvin wrote:
> Dyks, Axel (XL) wrote:
>> So why should "pxelinux" compensate for so many mistakes?
>>
>
> Well, there is the philosophy of being liberal in what you accept
> (conservative in what you send). Another way to put it is "because it
> can." If it can, which isn't guaranteed.
>

Wouldn't it make more sense then -- in case that siaddr is empty --
to add code for the "Server Identifier" option to "parse_dhcp_options"?

Code Len Address
+-----+-----+-----+-----+-----+-----+
| 54 | 4 | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+

This value does neither need parsing nor DNS lookup.

I think this has already been requested ...

Axel

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Dyks, Axel (XL) wrote:
> H. Peter Anvin wrote:
>> Dyks, Axel (XL) wrote:
>>> So why should "pxelinux" compensate for so many mistakes?
>>>
>> Well, there is the philosophy of being liberal in what you accept
>> (conservative in what you send). Another way to put it is "because it
>> can." If it can, which isn't guaranteed.
>>
>
> Wouldn't it make more sense then -- in case that siaddr is empty --
> to add code for the "Server Identifier" option to "parse_dhcp_options"?
>
> Code Len Address
> +-----+-----+-----+-----+-----+-----+
> | 54 | 4 | a1 | a2 | a3 | a4 |
> +-----+-----+-----+-----+-----+-----+
>
> This value does neither need parsing nor DNS lookup.
>
> I think this has already been requested ...
>

Probably should be added as third priority.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

H. Peter Anvin wrote:
> Dyks, Axel (XL) wrote:
>> H. Peter Anvin wrote:
>>> Dyks, Axel (XL) wrote:
>>>> So why should "pxelinux" compensate for so many mistakes?
>>>>
>>> Well, there is the philosophy of being liberal in what you accept
>>> (conservative in what you send). Another way to put it is "because it
>>> can." If it can, which isn't guaranteed.
>>>
>> Wouldn't it make more sense then -- in case that siaddr is empty --
>> to add code for the "Server Identifier" option to "parse_dhcp_options"?
>>
>> Code Len Address
>> +-----+-----+-----+-----+-----+-----+
>> | 54 | 4 | a1 | a2 | a3 | a4 |
>> +-----+-----+-----+-----+-----+-----+
>>
>> This value does neither need parsing nor DNS lookup.
>>
>> I think this has already been requested ...
>>
>
> Probably should be added as third priority.
>

Priority settings did arrive a little late ...

BTW, what are you refering to as "third priority"?
Having _any_ workaround for missing "next-server" or
using option 54 for this purpose?

Anyway. It hasn't been too difficult, to add this feature to "pxelinux.asm".
So I've attached a patch (against 3.36 which happens to be the version I'm currently
using) and a small screenshot that demonstrates the new feature at work.

In case you'll like it, I would create a patch against head in "git".
It might also make sense to skip the additional diagnostic messages,
if size matters ...

Cheers,
Axel

Dyks, Axel (XL) wrote:
>
> Priority settings did arrive a little late ...
>
> BTW, what are you refering to as "third priority"?
> Having _any_ workaround for missing "next-server" or
> using option 54 for this purpose?
>

I mean, the right thing to do is probably, in order:

1. Use siaddr
2. Use sname
3. Use option 54.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

H. Peter Anvin wrote:
> Dyks, Axel (XL) wrote:
>> Priority settings did arrive a little late ...
>>
>> BTW, what are you refering to as "third priority"?
>> Having _any_ workaround for missing "next-server" or
>> using option 54 for this purpose?
>>
>
> I mean, the right thing to do is probably, in order:
>
> 1. Use siaddr
> 2. Use sname
> 3. Use option 54.
>
Hmmh,

I've created the attached patch against 3.52 (git), fixed a few of my bugs,
and experimented a little bit with different "server-name" values (ISC dhcpd).

While the "server-name" value is an _optional_ string value which is empty
by default, the "server-identifer" value which is equivalent to the
"dhcp-server-identifier" option is not recommended to be set under
normal circumstances, because it overrides the _default_value_ which is the
first IP address associated with the physical network interface on which
the request arrived.

<quote `man dhcpd.conf`>

The server-identifier statement

server-identifier hostname;

The server-identifier statement can be used to define the value that is sent in the DHCP Server Identifier
option for a given scope. The value specified must be an IP address for the DHCP server, and must be
reachable by all clients served by a particular scope.

The use of the server-identifier statement is not recommended - the only reason to use it is to force a
value other than the default value to be sent on occasions where the default value would be incorrect. The
default value is the first IP address associated with the physical network interface on which the request
arrived.

The usual case where the server-identifier statement needs to be sent is when a physical interface has more
than one IP address, and the one being sent by default isn't appropriate for some or all clients served by
that interface. Another common case is when an alias is defined for the purpose of having a consistent IP
address for the DHCP server, and it is desired that the clients use this IP address when contacting the
server.

Supplying a value for the dhcp-server-identifier option is equivalent to using the server-identifier state-
ment.

The server-name statement

server-name name ;

The server-name statement can be used to inform the client of the name of the server from which it is boot-
ing. Name should be the name that will be provided to the client.
</quote>

>From this follows that option 54 is ALWAYS send and _guaranteed_ to be an IP address,
whereas "sname" isn't set by default, and if it's set, then one shouldn't expect it
to be an IP address or a resolveable DNS name.

Furthermore it seems
* a wrong "server-identifier" prevents my (vmware) PXE-ROM to load pxelinux in case that
"next-server" is missing

* if "next-server" is set, then receiving a wrong "server-identifier" doesn't stop my
PXE-ROM to load pxelinux

* missing "next-server" and having both "server-identifer" and "server-name" set to
IP addresses results in my PXE-ROM to use the "server-identifier"

In other words:

* "sname" is ignored by my PXE-ROM entirely
* "next-server" is prefered over "server-identifier" (option 54), i. e. "server-identifier"
is used as fallback when "next-server" is empty.

To me it seems that the best way to "mimic" the "liberal" behavior of my PXE-ROM
(possibly many PXE-ROMs), would be to handle "option 54" with 2nd priority (after siaddr)
and forget about "sname" entirely.

Furthermore it would compensate for the changed behavior of "ISC dhcpd" which used to
set "next-server" to "server-identifier" in case that "next-server" hasn't been
specified.

Cheers,
Axel

Once upon a time, H. Peter Anvin <hpa@zytor.com> said:
> I mean, the right thing to do is probably, in order:
>
> 1. Use siaddr
> 2. Use sname
> 3. Use option 54.

I've done some more digging, and it appears that the PXE BIOS in the
computers I'm testing with do not look at the sname field. They do look
at option 54 ("server-identifier" in Juniper JUNOS). It would probably
be more "correct" then to duplicate that and use (siaddr, option 54) and
ignore sname (since that is what it looks like the PXE BIOS does).

--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Chris Adams wrote:
> Once upon a time, H. Peter Anvin <hpa@zytor.com> said:
>> I mean, the right thing to do is probably, in order:
>>
>> 1. Use siaddr
>> 2. Use sname
>> 3. Use option 54.
>
> I've done some more digging, and it appears that the PXE BIOS in the
> computers I'm testing with do not look at the sname field. They do look
> at option 54 ("server-identifier" in Juniper JUNOS). It would probably
> be more "correct" then to duplicate that and use (siaddr, option 54) and
> ignore sname (since that is what it looks like the PXE BIOS does).
>

Right, if we can't get the PXE stack to boot in the first place using
sname, then we should just ignore it.

OK, option 54 as a fallback it is.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Hi,

Any luck on fixing the floppy disk access problem or is it only affecting
me?

_________________________________________________________________
Txt a lot? Get Messenger FREE on your mobile.
https://livemessenger.mobile.uk.msn.com/

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Chris Adams wrote:
> Once upon a time, H. Peter Anvin <hpa@zytor.com> said:
>> I mean, the right thing to do is probably, in order:
>>
>> 1. Use siaddr
>> 2. Use sname
>> 3. Use option 54.
>
> I've done some more digging, and it appears that the PXE BIOS in the
> computers I'm testing with do not look at the sname field. They do look
> at option 54 ("server-identifier" in Juniper JUNOS). It would probably
> be more "correct" then to duplicate that and use (siaddr, option 54) and
> ignore sname (since that is what it looks like the PXE BIOS does).

Seems like a (at least) pointwise convergence ...

I've attached two versions of a "next-server-fallback" patch.
A "verbose" one that makes "pxelinux talk about the reason for falling back",
and a "silent" one. The later is -- of course -- much smaller and
does not require to increase LATEBSS_START in "layout.inc".

Axel

Op 29-06-2007 om 15:11 schreef Desmond Boyd:
> Hi,
>
> Any luck on fixing the floppy disk access problem
> or is it only affecting me?

Test reports of newer versions then 3.36,
such as the recent released 3.50, are welcome.


Geert Stappers
Annoyed about a thread posting not belonging in the thread.

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Op 29-06-2007 om 16:19 schreef Dyks, Axel (XL):
>
> I've attached two versions of a "next-server-fallback" patch.
> A "verbose" one that makes "pxelinux talk about the reason for falling back",
> and a "silent" one. The later is -- of course -- much smaller and
> does not require to increase LATEBSS_START in "layout.inc".

IMnsHO we should go for the verbose one,
because it says that gaps are being filled.
Gaps that could exsit on purpose.


Cheers
Geert Stappers

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Geert Stappers wrote:
> Op 29-06-2007 om 16:19 schreef Dyks, Axel (XL):
>> I've attached two versions of a "next-server-fallback" patch.
>> A "verbose" one that makes "pxelinux talk about the reason for falling back",
>> and a "silent" one. The later is -- of course -- much smaller and
>> does not require to increase LATEBSS_START in "layout.inc".
>
> IMnsHO we should go for the verbose one,
> because it says that gaps are being filled.
> Gaps that could exsit on purpose.
>

Actually I'm going to implement a variant of the quiet one, mostly
because pxelinux is running very low on space and I don't want to add a
whole lot.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

I did all the tests as far as im aware, there listed in the previous posts,
if theres anything else i need to do please let me know.


>From: stappers@stappers.nl (Geert Stappers)
>Reply-To: For discussion of SYSLINUX and tftp-hpa <syslinux@zytor.com>
>To: syslinux@zytor.com
>Subject: Re: [syslinux] syslinux-3.36 Physical Floppy Disk Access Problem
>Date: Fri, 29 Jun 2007 17:41:31 +0200
>
>Op 29-06-2007 om 15:11 schreef Desmond Boyd:
> > Hi,
> >
> > Any luck on fixing the floppy disk access problem
> > or is it only affecting me?
>
>Test reports of newer versions then 3.36,
>such as the recent released 3.50, are welcome.
>
>
>Geert Stappers
>Annoyed about a thread posting not belonging in the thread.
>
>_______________________________________________
>SYSLINUX mailing list
>Submissions to SYSLINUX@zytor.com
>Unsubscribe or set options at:
>http://www.zytor.com/mailman/listinfo/syslinux
>Please do not send private replies to mailing list traffic.
>

_________________________________________________________________
Tell MSN about your most memorable emails! http://www.emailbritain.co.uk/

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

H. Peter Anvin wrote:
> Geert Stappers wrote:
>> Op 29-06-2007 om 16:19 schreef Dyks, Axel (XL):
>>> I've attached two versions of a "next-server-fallback" patch.
>>> A "verbose" one that makes "pxelinux talk about the reason for falling back",
>>> and a "silent" one. The later is -- of course -- much smaller and
>>> does not require to increase LATEBSS_START in "layout.inc".
>> IMnsHO we should go for the verbose one,
>> because it says that gaps are being filled.
>> Gaps that could exsit on purpose.
>>
>
> Actually I'm going to implement a variant of the quiet one, mostly
> because pxelinux is running very low on space and I don't want to add a
> whole lot.
>
Just seen your changes in git.
Much more elegant than what I did!

But it has been real fun to do a little of asm programmming which I used
to do a lot _years_ ago. Looking into all those lines of asm code that
the bootloaders consist of, gave me an insight in how much _work_ it has
been to bring the syslinux project at it's current very mature state.

Thanks,
Axel



_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Op 29-06-2007 om 18:29 schreef Desmond Boyd:
> >From: stappers@stappers.nl (Geert Stappers)
> >Date: Fri, 29 Jun 2007 17:41:31 +0200
> >Op 29-06-2007 om 15:11 schreef Desmond Boyd:
> > > Hi,
> > >
> > > Any luck on fixing the floppy disk access problem
> > > or is it only affecting me?
> >
> >Test reports of newer versions then 3.36,
> >such as the recent released 3.50, are welcome.
>
> I did all the tests as far as im aware, there listed in the previous
> posts, if theres anything else i need to do please let me know.

:-)


Things to do:

- Be aware that you are addressing a community.
- Find common interrests in that community.
- Convert a personal/private problem in a community challenge.
- Be carefull with other peoples time.
- Make good (as is usefull) references to previous postings.
- Reply below the text.
- Keep smiling!


Cheers
Geert Stappers

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Desmond Boyd Wrote:

Hello,

I am using the pxelinux.0 and memdisk files from distribution syslinux-3.36.

I am no longer able to access the real floppy disk drive B: instead I just
get a mirrored copy of the emulated floppy disk A:

The default config file is as follows

label 1
kernel memdisk
append initrd=kd202.img


I was previously using the sysliunx-3.20 distribution which gave me access
to the real floppy disk drive using drive B: with Emulated Floppy Disk as
Drive A:.

Do I need to add any additional switches to the append line to enable the
latest version to enable me to access the real floppy disk drive?


H. Peter Anvin Wrote

That should still work. I don't know why it would be broken for you now.

lease try the intervening versions, including prereleases, so we can
figure out where it broke.


Desmond Boyd Wrote:

As requested, I have tested the distributions listed below to try to isolate
when physical disk drive access for me was lost, results are as follows:

Physical Disk Drive B: OK with Virtual Disk Drive as A:
3.20
3.30
3.31
3.32 Pre1

Physical Disk Drive B: Not Present only Virtual Disks A: and B:
3.35
3.35 Pre1
3.35 Pre2
3.35 Pre3
3.35 Pre4
3.35 Pre5
3.36
3.50

H. Peter Anvin Wrote

It seems to be a problem with memdisk as I also tested each memdisk version
with the latest pxelinux.0, so currently I have in the tftpdroot:

Pxelinux.0 Version 3.50
memdisk Version 3.32

This combination gives me access to the phyical floppy disk b:

Could you also test the various 3.32-preX releases (2 to 8) to narrow
down the failure further?

The most likely failure seems to be between 3.32-pre3 and -pre4:

memdisk: Constrain input drive numbers both by equipment byte and
INT 13h

Apparently on some BIOSes, INT 13h return a bogus number of floppy
drives when the real value is zero (probably because the code
doesn't check the validity bit in the equipment byte.) Do it
ourselves if we need to.

There should be a line when MEMDISK boots up saying something about "INT
13 08", what is that printout?


Desmond Boyd Wrote:

Version 3.32-pre3 Physical Disk Drive B: OK with Virtual Disk Drive as A:
Version 3.32-pre4 Physical Disk Drive B: Not Present only Virtual Disks A:
and B:

INT 13 08 Success, Count = 1, BPT = f000:a137
old int13=f00023cb, int15=f000f859
new int13= 9ec00008, int15=9ec00375

All memory addresses listed on the memdisk info page @ bootup for pre3/pre4
are identical but pre4 does not see the physical floppy disk.

If you need the exact screen information from both versions I can write each
one down unless there is a way to save the boot information with a switch to
the virtual fdd then I can upload the info to a networkshare.


Desmond Boyd Wrote:

Any luck on fixing the floppy disk access problem or is it only affecting
me?


Geert Stappers Wrote:

Test reports of newer versions then 3.36,
such as the recent released 3.50, are welcome.


Geert Stappers
Annoyed about a thread posting not belonging in the thread.


Desmond Boyd Wrote:

I did all the tests as far as im aware, there listed in the previous posts,
if theres anything else i need to do please let me know.

Geert Stappers Wrote:

Things to do:

- Be aware that you are addressing a community.
- Find common interrests in that community.
- Convert a personal/private problem in a community challenge.
- Be carefull with other peoples time.
- Make good (as is usefull) references to previous postings.
- Reply below the text.
- Keep smiling!


Cheers
Geert Stappers


Desmond Boyd Wrote:

I am sorry if i have not posted any previous messages in the correct thread
but this is the first time using this type of email support system. I
thought i had to reply to the thread with the origional topic header to
enable it to be filed correctly.

I have put all previous messages in this email and hope that this is what
you required.

_________________________________________________________________
The next generation of Hotmail is here! http://www.newhotmail.co.uk

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Op 30-06-2007 om 14:13 schreef Desmond Boyd:
<snip what="re-cap[1] of previous posting"/>
> I am sorry if i have not posted any previous messages in the correct thread
> but this is the first time using this type of email support system. I
> thought i had to reply to the thread with the origional topic header to
> enable it to be filed correctly.
>
> I have put all previous messages in this email and hope that this is what
> you required.


Hello Desmond,

Communication is a strange thing.

I even agree with those who say that
communication only exsists to solve mis-communication.

My reason for spending time on this thread is because I care about the
eco-system around the syslinux project. It is a healthy community that
make a software project a good software project.
Caring about the (eco-)system one uses, is worth the effort.

Thanks for the recap/summary/abstract/[1] of the previous posting.


Cheers
Geert Stappers


P.S.

My archive showed indeed that your previous posting didn't get any follow
(yet). Give it some more time. But I can imagion that it needs another
follow-up from your side. My advice is, in the eventual follow-up, to
describe what your setup is, what it should do (what's it's purpose)
and where it breaks. That allows reproduction the problem for community
members who have simular setups, it also allows alternatives to the
same purpose.

[1] I'm sure about the right english word for what I intent to say.

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Geert Stappers wrote:
>
> My archive showed indeed that your previous posting didn't get any follow
> (yet). Give it some more time. But I can imagion that it needs another
> follow-up from your side. My advice is, in the eventual follow-up, to
> describe what your setup is, what it should do (what's it's purpose)
> and where it breaks. That allows reproduction the problem for community
> members who have simular setups, it also allows alternatives to the
> same purpose.
>
> [1] I'm sure about the right english word for what I intent to say.
>

It's also pretty common for me to simply lose track of things and drop
them on the floor. This is especially so for things that are directed
mostly to me as opposed to the overall community. If so, it really
helps to get pinged again later, with context.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.