Bug Reports, Requests, HowTo's about Tiny PXE Server

The report by RuiPaz is interesting, and may well explain the issue, though I am not too sure this applies to glendon00's case.

I mean, if it is correct that for whatever reason the actual hardware is set to 10 Mb, the result should rather be a "continuous" (though slow) loading/transfer, not the "bursts" followed by long periods of inactivity described.

 

@glendon00

You can try using the actual etherboot floppy via grub4dos (or other bootmanager) to test differnt PXE booting without fiddling with the actual ROM (until you are sure that the modified PXE works). as long as thse machines have some kind of "local" storage.

 

Wonko

Great idea!  'll work on that.

 

Thanks,

 

Glen

Also, in my case with the three 'slow' machines, they are only slow with sanboot+http.  Other methods work at the same speed as the 'fast' machines.

Sanboot is best for use with iSCSI or AoE.

HTTP is best for use load image to RAM.

There have been multiple report of slow sanboot+http.

 

Stick to UDP for now, you should achieve good enough performances.

 

"Simplest" setup (or MS setup) :

pxeboot.com->bootmgr->bcd->boot.wim->winload

Tweak your BCD for best performance over UDP (google RamDiskTFTPBlockSize).

Sanboot is best for use with iSCSI or AoE.

HTTP is best for use load image to RAM.

Got it!  I'm just getting started on this phase of learning TPS and all that goes with it.  I was hoping that sanboot+http would be the 'easy' answer to booting Windows PE and similar ISO images.  But wimboot isn't so hard to set up after all.  Now I just have to figure out how to fix all those Windows errors that crop up after the initial loading is completed.  Sigh...  Does it ever end?  Nah, how boring!

There have been multiple report of slow sanboot+http.

 

Stick to UDP for now, you should achieve good enough performances.

 

"Simplest" setup (or MS setup) :

pxeboot.com->bootmgr.exe->bcd->winload

Tweak your BCD for best performance over UDP (google RamDiskTFTPBlockSize).

By UDP, do you mean the method you just outlined?  I know what UDP means from a networking point of view, but never heard it used with reference to a PXE boot/load methodology.

 

I'll go check out that idea on tweaking BCD/UDP.

 

Thanks,

 

Glen

I think erwan was possibly referring to this - http://www.mistyrebo...e_bcd.htm#speed



Misty

P.s. If you are also experimenting with wimboot then the following page may be useful - http://www.mistyrebo...npe_wimboot.htm

 

@erwan.l:

This may not be the correct place to post this.  If not, I apologize.  Still finding my way around.

 

In any event, if you release a new version of Tiny PXE Server, I would ask a great favor.  Is there any way to fix the user interface so that everything is displayed on screen at a resolution of 800x600?  I am legally blind (less than 20/400) and find it extremely difficult to work at higher resolutions.  TPS hides some of the information I need to see when running at 800x600.

 

And thanks for making TPS and supporting it.  I am much more comfortable working in the Windows world than I am in the Linux realm.  And there is nothing as simple to get up and running as TPS with all the bells and whistles needed to get things done.  A great package, one to be proud of creating.

 

Thanks,

 

Glen

 

 

This is the right place to post, you are contributing to this thread, thanks for that.

 

I have uploaded a new version : on screen with height <=600, a scrollbar will appear when you push the "other" button.

Let me know if it makes it easier for you to use.

 

Regards,

Erwan

I think erwan was possibly referring to this - http://www.mistyrebo...e_bcd.htm#speed



Misty

P.s. If you are also experimenting with wimboot then the following page may be useful - http://www.mistyrebo...npe_wimboot.htm

 

This is exactly what I was looking for but could only recall part of it : as always, you came with the exact detail, thanks for that

 

I would recommend ramdisktftpblocksize=16384 - In most environements (except vmware), that should increase significantly performances.

A few posts ago, UNDI vs PXE drivers was discussed.

 

Here below a nice explanations (take from here).

 

What are the differences between the different PXE files? Filenames

• ipxe has drivers native to the ipxe project. Those drivers are handled from the iPXE developers.
• undionly uses the "undi" stack made by the manufacturer of the NIC.

Universal Network Device Interface (UNDI) is an application programming interface (API) for network interface cards (NIC) used by the Preboot Execution Environment (PXE) protocol.

When chainloading iPXE from PXE, iPXE can use this API (instead of loading a hardware driver). This way, you're getting support for network controllers that are not natively supported by iPXE. Some network controllers have improved performance when using the UNDI driver over the vendor specific iPXE driver.

To use the UNDI driver, select the UNDI driver (undionly) when generating the iPXE ROM. (e.g. make bin/undionly.kpxe EMBED=embedscriptname) 

Extensions

More info can be referenced here: 

1. .pxe is an image designed to be chain loaded, unloading both the underlying PXE and UNDI code sections. This is ultimately the goal, but there's not enough information to allow this to actually work flawlessly every time. It uses, purely, the drivers from the iPXE information. One of the benefits is the codebase for the drivers are handled by the iPXE developers. So, in theory and given enough time, all NICs could potentially be supported.
   • .pxe is an image designed to be chain loaded, unloading both the underlying PXE and UNDI code sections. 
2. .kpxe unloads just the pxe stack and is the normal file we want in use as it seems to be the best between pxe/chaining I can find without flashing roms.
   • .kpxe is a PXE image that keeps UNDI loaded and unloads PXE 
3. .kkpxe keeps both undi and pxe stacks in place. kkpxe works best for buggy hardware. Only recommended if you're having weird issues with the undionly.kpxe
   • .kkpxe is a PXE image that keeps PXE+UNDI loaded and return to PXE (instead of int 18h). 
4. .kkkpxe is only used to generate the ipxelinux.0 file. This is only used in conjunction with the syslinux project. When gpxe was the developed software of this type the file was called gpxelinux.0 which can usually be built with modern syslinux.

More information on this can be found on the ipxe forum thread located 

Undi and iPXE Stack

The UNDI driver is a generic driver that works on network cards that have a vendor UNDI ROM. The ROM contains driver code that is supposed to conform to the PXE/UNDI specification. iPXE can load the UNDI driver and use it instead of a native driver.

Depending on the iPXE image type, UNDI support works as follows:

• undionly.kpxe is loaded from a vendor PXE stack and uses UNDI on the network card that it was booted from.

• All-driver (ipxe) or undi images can load the UNDI for PCI network cards. The network boot ROM must be enabled in the BIOS in order for the UNDI ROM to be visible to iPXE. Note that only the first network card is supported with UNDI since multiple instances of UNDI is unreliable and cannot be supported.

Why write native drivers if UNDI works with every network card?

• iPXE is an open source PXE stack and provides UNDI services. iPXE cannot be used as an option ROM without a native driver.

• UNDI is slow because iPXE must switch CPU modes when calling it.

• UNDI ROMs can be buggy or violate the PXE specification. Native drivers are known to work with iPXE and can be fixed if there is a bug since they are part of the iPXE codebase.

• Enabling the network boot ROM in the BIOS is not always possible or desirable.

@erwan.l
I've started to dip my toes into the world of PXE again after a work inforced break - my own Tiny PXE Server guide has proved quiet useful - this was the reason I was able to find the ramdisktftpblocksize info!

Thanks for the explanation of UNDI vs PXE drivers.

@everyone
My current experiments are with iSCSI. It proved relatively straightforward installing Windows 8.1 to an iSCSI target by running Tiny PXE Server in ProxyDHCP mode with kernsafe iStorageServer (with a free licence) as iSCSI target - using ipxe.pxe as the PXE boot file (filename=ipxe.pxe in config.ini).

I've been increasingly frustrated with similar attempts to network install/boot Windows via iSCSI when using Tiny PXE Server in DHCP mode - my test system is a Thinkpad X61 (client) linked to a Thinkpad X200 (server) via a crossover cable. After lots of frustration I re-read erwan'l's blog - the trick was to use ipxe-undionly.kpxe instead of ipxe.pxe.

Seems strange that ipxe.pxe works with a ProxyDHCP setup, but fails in a DHCP setup.

Regards,

Misty

Edit - the information crossed out above later proved to be incorrect - see post #517

This is exactly what I was looking for but could only recall part of it : as always, you came with the exact detail, thanks for that

 

I would recommend ramdisktftpblocksize=16384 - In most environements (except vmware), that should increase significantly performances.

Thanks!  Working on it tonight and tomorrow as time and other duties permit.

I think erwan was possibly referring to this - http://www.mistyrebo...e_bcd.htm#speed



Misty

P.s. If you are also experimenting with wimboot then the following page may be useful - http://www.mistyrebo...npe_wimboot.htm

Very useful links!  Thank you very much.  Just in my first scan I have a much clearer idea of what is going on and maybe how to solve some issues.  Lots to chew on here.

 

Have a great day, and thanks again for your work on MistyPE.

 

Glen

This is the right place to post, you are contributing to this thread, thanks for that.

 

I have uploaded a new version : on screen with height <=600, a scrollbar will appear when you push the "other" button.

Let me know if it makes it easier for you to use.

 

Regards,

Erwan

Yes, the GUI it could be better e.g. as Tftpd32 which interface is more flexible.

 

I think that the edit boxes in TPS are too wide and have a large distances.

Yes, the GUI it could be better e.g. as Tftpd32 which interface is more flexible.
 
I think that the edit boxes in TPS are too wide and have a large distances.

Whilst it might not be pretty, it's functional and does the job - very well!

My only complaint about the project is trying to find out which version I'm using - a date in addition to the numbering system in use would be welcome - I seem to recall multiple version 1.0.0.19 builds for example.

Not normally a problem, however when trying to tidy up my backups at home I stumbled across multiple versions of TinyPXE server and had to create checksums to compare versions.

Misty

P.s. I use the config file for all settings anyway - I only use the GUI to check they are applied properly.

...@everyone
My current experiments are with iSCSI. It proved relatively straightforward installing Windows 8.1 to an iSCSI target by running Tiny PXE Server in ProxyDHCP mode with kernsafe iStorageServer (with a free licence) as iSCSI target - using ipxe.pxe as the PXE boot file (filename=ipxe.pxe in config.ini).

I've been increasingly frustrated with similar attempts to network install/boot Windows via iSCSI when using Tiny PXE Server in DHCP mode - my test system is a Thinkpad X61 (client) linked to a Thinkpad X200 (server) via a crossover cable. After lots of frustration I re-read erwan'l's blog - the trick was to use ipxe-undionly.kpxe instead of ipxe.pxe.

Seems strange that ipxe.pxe works with a ProxyDHCP setup, but fails in a DHCP setup...

After more experiments I have traced this iSCSI issue to a problem with iStorageServer. When first installed everything seems to run fine, on rebooting the system and using the exact same settings I received the following error message -

Could not open SAN device: Connection reset (http://ipxe.org/0f0a6039)

Restarting iStorageServer resolved this issue. In future I will disable the service at startup (tools > Service Settings... > iSCSI Service (tab) > disable "Auto start iSCSI service after windows startup") - then make sure the service is started from the iStorageServer console (using the "Start" button) before attempting to PXE boot any clients.

SANHOOK now appears to be working with the following ipxe files specified as the boot file -
* ipxe.kpxe
* ipxe.pxe
* undionly.kpxe

Regards,

Misty

 

Erwan - I am deeply moved that you would make this change at my request, and so quickly.  Thank you so very much.

 

I just downloaded and extracted version 1.0.0.20 and gave it a try.  Maybe I got the wrong file but so far I can't see any difference.  In 800x600 resolution I can see only down to the Option 17 line, and the text box is slightly truncated at the bottom.

 

When I run it at 1024x768 I can see the full screen down to the "Other" line.  Clicking "Other" expands down to Option 66, but cuts off the lower part of that line just a bit.

 

If I click "Other" again to close the expanded section then the screen is truncated to half way down the "Bootfile" section, with only the "Filename" line showing fully.  The next line (alternate filename) is showing just the top fraction of the text windows.

 

In no case did a scrollbar appear.

 

I am running TPS on Windows XP Pro, X32.  Video is Mobile Intel 4 Series Express Chipset.

 

In previous use of TPS 1.0.0.19 on different systems I had the same results as above.

 

Did I download the correct version?

 

Thanks,

 

Glen

 

 

 

 

Hi Glendon00,

 

You should see something like the below.

 

If detect a screen height inferior or equal to 600, when you push the "other" button TPS will add a toolbar to the right allowing you to scroll in the main form.

 

If it does not work at your side it could be :

Whilst it might not be pretty, it's functional and does the job - very well!

My only complaint about the project is trying to find out which version I'm using - a date in addition to the numbering system in use would be welcome - I seem to recall multiple version 1.0.0.19 builds for example.

Not normally a problem, however when trying to tidy up my backups at home I stumbled across multiple versions of TinyPXE server and had to create checksums to compare versions.

Misty

P.s. I use the config file for all settings anyway - I only use the GUI to check they are applied properly.

 

Hi Misty,

 

Me not changing the zip file name (i.e including the build/version and/or datetime) is a PITA.

 

But as many web sites point to my hosting place, i cannot change the zip file or else all remote sites would have a broken link.

I could use reboot.pro to host these files and update the meta informations there but I had many issues in the past : could not upload anymore, etc ...

 

I will add a meta file to the zip package to mitigate that versioning issue.

 

Regards,

Erwan

the zip file now contains a file named pxesrv.nfo with the below details :

January 21 , 2017 - 12:27:08
CRC32: DFF6328B
MD5: 4BC85E2DD7D4E5D91D6A38A5217EF0E7
SHA-1: 877F129E62EF644E5233B49C17B93F9998091215

the zip file now contains a file named pxesrv.nfo with the below details :

January 21 , 2017 - 12:27:08
CRC32: DFF6328B
MD5: 4BC85E2DD7D4E5D91D6A38A5217EF0E7
SHA-1: 877F129E62EF644E5233B49C17B93F9998091215

And you cannot §@ç#ing add at the beginning a simple human readable line *like*:

Tiny PXE Server version x.yz

can't you? 
And since I am at it and already in grumpy mode , would it be a too d@mn simple idea to better the resolution autodetection stuff by removing it and adding instead an explicit command line parameter *like* /lowres or /maxv=600 ?
 
The issue about your (wrong) method of naming the files all the same creates IMHO an issue only because there isn't *somwhere*  a repository with the files properly named and from where an older verison can be retrieved.
 
So you can have a place (the one linked by all other sites) where you always have the "latest" version senselessly named pxesrv.zip, and *some other place* where you can have a directory with pxesrv_1.001.zip, pxesrv_1.002.zip, pxesrv_1.003.zip, etc.
 

Wonko

Yes, the GUI it could be better e.g. as Tftpd32 which interface is more flexible.

 

I think that the edit boxes in TPS are too wide and have a large distances.

 

Hi Reboot12,

 

Indeed, I would reduce the width of the textboxes but the width of the form is not too much of an issue today (the height is).

As for the height of the textbox, it is as small (21 pixels) as the current font allows me.

I would have to minimize the font if I wanted these textboxes to be smaller in height.

 

About large distances, you mean from one textbox to another? It is 4 pixels today.

I could probably save about 30 pixels by respacing all textboxes by 2 pixels but the whole form would still not fix in 600 pixels height.

 

Any ideas/feedback welcome thus.

 

And to be clear : my objective is not to mimic tftpd32 - TinyPXE Server is my baby and therefore inherits my defects ... and qualities 

 

The philosophy of Tiny PXE Server is that all fits in one screen while remaining as simple as possible : "click and play".

One should normally not have to expand the lower part of the screen to pxe boot unless one has specific needs.

 

Regards,

Erwan

And you cannot §@ç#ing add at the beginning a simple human readable line *like*:
can't you? 
And since I am at it and already in grumpy mode , would it be a too d@mn simple idea to better the resolution autodetection stuff by removing it and adding instead an explicit command line parameter *like* /lowres or /maxv=600 ?
 
The issue about your (wrong) method of naming the files all the same creates IMHO an issue only because there isn't *somwhere*  a repository with the files properly named and from where an older verison can be retrieved.
 
So you can have a place (the one linked by all other sites) where you always have the "latest" version senselessly named pxesrv.zip, and *some other place* where you can have a directory with pxesrv_1.001.zip, pxesrv_1.002.zip, pxesrv_1.003.zip, etc.
 

Wonko

 

Hi Wonko,

 

You should not be grumpy on a sunday

 

NFO file has been updated based on your feedback.

 

The parameter (command line or ini file) to deal with low resolutions is a good idea : I might go for it.

I'll wait for Glendon00's feeback to see how it goes for him.

 

About keeping previous versions, that means I would have to maintain a repository (web page, etc) and I dont have time enough currently for that.

My principle : the latest available version should always be the version you want (i.e the best version).

I know it goes against development principles but I assume this position even if I have to make the good people grumpy out there 

 

Regards,

Erwan

Hi Reboot12,

 

Any ideas/feedback welcome thus.

 

And to be clear : my objective is not to mimic tftpd32 - TinyPXE Server is my baby and therefore inherits my defects ... and qualities 

 

The philosophy of Tiny PXE Server is that all fits in one screen while remaining as simple as possible : "click and play".

One should normally not have to expand the lower part of the screen to pxe boot unless one has specific needs.

 

Regards,

Erwan

OK, TPS is your baby but why can not it be like this?:

 new_tps.png   10.69KB   0 downloads

All fits in one screen

OK, TPS is your baby but why can not it be like this:

new_tps.png

All fits in one screen

 

I personally think it looks ugly like that i.e unbalanced.

And it then "throws" too much informations at the user as some of these informations are not needed to boot : I want optional fields to remain hidden.

 

What I could do is rather than expand vertically (and therefore beyond 600 pixels) is to expand horizontally.

Expanding vertically was probably a bad idea to start with.