Prev: email client: POP vs. POP3 differences
Next: About Interrupt Problem in RHEL-5
From: D Yuniskis on 7 Jun 2010 17:58
Hi,

I want to use some surplus PC's to hack together a
"test network". Rather than preparing disk/floppy
images, it's a lot easier to just deploy the sample
executables from a single server.

PXE *seems* like an ideal candidate.

Is it just:
- BOOTPc/DHCPc to fetch a filename and server name for
the image
- TFTPc to fetch the image
- "jump" to start of downloaded image

(i.e., thereafter, I am at liberty to do whatever I
want -- NFS mount some remote filesystem, create my
own local namespace, blink lights, make disk noises,
etc.)
From: Przemek Klosowski on 7 Jun 2010 21:48
On Mon, 07 Jun 2010 14:58:19 -0700, D Yuniskis wrote:

> I want to use some surplus PC's to hack together a "test network".
> Rather than preparing disk/floppy images, it's a lot easier to just
> deploy the sample executables from a single server.
>
> PXE *seems* like an ideal candidate.
>
> Is it just:
> - BOOTPc/DHCPc to fetch a filename and server name for
> the image
> - TFTPc to fetch the image
> - "jump" to start of downloaded image
>
> (i.e., thereafter, I am at liberty to do whatever I want

Essentially correct, although you glossed over the details in the third
point. PXE specifies what's in the fetched image and how it is loaded and
activated. You create it just so that it contains a bootable sector, and
a initial RAMdisk image.
From: D Yuniskis on 8 Jun 2010 17:19
Hi Przemek,

Przemek Klosowski wrote:
> On Mon, 07 Jun 2010 14:58:19 -0700, D Yuniskis wrote:
>
>> I want to use some surplus PC's to hack together a "test network".
>> Rather than preparing disk/floppy images, it's a lot easier to just
>> deploy the sample executables from a single server.
>>
>> PXE *seems* like an ideal candidate.
>>
>> Is it just:
>> - BOOTPc/DHCPc to fetch a filename and server name for
>> the image
>> - TFTPc to fetch the image
>> - "jump" to start of downloaded image
>>
>> (i.e., thereafter, I am at liberty to do whatever I want
>
> Essentially correct, although you glossed over the details in the third
> point. PXE specifies what's in the fetched image and how it is loaded and
> activated. You create it just so that it contains a bootable sector, and
> a initial RAMdisk image.

Ah, so PXE shoehorns under the traditional BIOS, in a sense
(i.e., wants the BIOS to think it has just read the boot
sector off a *real* disk)?

Does it *enforce* this? Or, does it hand-off to some BIOS function
that *expects* this?

Thx,
--don
From: Przemek Klosowski on 10 Jun 2010 23:42
On Tue, 08 Jun 2010 14:19:22 -0700, D Yuniskis wrote:
>> point. PXE specifies what's in the fetched image and how it is loaded
>> and activated. You create it just so that it contains a bootable
>> sector, and a initial RAMdisk image.
>
> Ah, so PXE shoehorns under the traditional BIOS, in a sense (i.e., wants
> the BIOS to think it has just read the boot sector off a *real* disk)?
>
> Does it *enforce* this? Or, does it hand-off to some BIOS function that
> *expects* this?

I'm not sure if I understand what you are asking. You need both the
traditional BIOS (to initialize the CPU/chipset/memory/peripherals) and
the PXE BIOS (to do the networking magic). The details may vary; I think
the most common case is that the PXE part is just another code path in
the BIOS functionally equivalent to the disk boot sector reading code.
The complication in PXE is that it has an elaborate fallback scheme for
fetching the boot image, from the most specific image pathname
constructed with the specific MAC address of the target to less and less
specific ones.
From: D Yuniskis on 13 Jun 2010 17:07
Hi Przemek,

Przemek Klosowski wrote:
> On Tue, 08 Jun 2010 14:19:22 -0700, D Yuniskis wrote:
>>> point. PXE specifies what's in the fetched image and how it is loaded
>>> and activated. You create it just so that it contains a bootable
>>> sector, and a initial RAMdisk image.
>> Ah, so PXE shoehorns under the traditional BIOS, in a sense (i.e., wants
>> the BIOS to think it has just read the boot sector off a *real* disk)?
>>
>> Does it *enforce* this? Or, does it hand-off to some BIOS function that
>> *expects* this?
>
> I'm not sure if I understand what you are asking. You need both the
> traditional BIOS (to initialize the CPU/chipset/memory/peripherals) and
> the PXE BIOS (to do the networking magic). The details may vary; I think

Yes, I'm not worried about the BIOS/PXE part of the thing.
That's all in place already.

Rather, my recent question was regarding what (if any)
constraints PXE imposes on the actual *image* that it
fetches. For example, it *could* want the image to
look like a DOS executable (I am not claiming that is
the case) with the appropriate signatures, etc.

Or, it could just expect a checksum (which it verifies?)
and then it *trustingly* "jumps" to the first instruction
expected to reside at the load location, etc.

In other words, do I have to do anything special to
*build* a loadable image that PXE will "bless"?

> the most common case is that the PXE part is just another code path in
> the BIOS functionally equivalent to the disk boot sector reading code.

Your earlier description seemed to suggest that.

> The complication in PXE is that it has an elaborate fallback scheme for
> fetching the boot image, from the most specific image pathname
> constructed with the specific MAC address of the target to less and less
> specific ones.

Ah, that's not a problem -- many X Terminals have similar
contortions.

In this case, I will control *all* of the images available so
I can force a particular node to fetch a particular image.
 | 
Pages: 1
Prev: email client: POP vs. POP3 differences
Next: About Interrupt Problem in RHEL-5