Hello,
I have a bios based 32-bit desktop from the previous decade, with a Fast Ethernet PXE NIC embedded in the mobo.
The desktop is multiboot with GRUB2 entries for my local OSes which I need from time to time. But it is primarily an LTSP thin client (the LTSP server is running on Ubuntu 16.04.3).
PXE booting via the embedded Fast Ethernet NIC was working well and rather fast, but once logged in, the desktop was a bit slow for certain applications (youtube videos would often freeze, etc.).
So I installed a 10 times faster Gigabit PCI NIC (TP-Link TG-3269, based on Realtek RTL8169SC), which doesn't have a PXE ROM.
To compensate for the lack of PXE ROM, I added a GRUB2 entry pointing to ipxe.lkrn, which I downloaded from ipxe.org.
This "works".
The good thing is: once I am done booting with iPXE, the old desktop behaves like a fast 2018 desktop (thanks to the LTSP server being powerful enough and to the Gigabit NIC of the desktop). This is really impressive.
Problem:
To boot the desktop, despite the Gigabit NIC, iPXE takes ~2 minutes to load vmlinuz (~6Mb) and ~8 minutes to load initrd (~36Mb).
The total boot time is over 10min, which is unacceptable in practice.
With the Gigabit NIC, iPXE could arguably take around 0.34s to download vmlinuz and initrd (i.e. almost 2000 times faster).
This is a real pain and this is also very surprising since PXE booting with the old Fast Ethernet NIC is an order of magnitude faster than iPXE booting with the Gigabit NIC.
What I can do?
My investigations:
iPXE prints (while booting) that it is using "RTL8169" (not "RTL8169SC"). Not sure how relevant this is.
I noticed, in the source code of iPXE, that the function:
static int realtek_phy_reset ( struct realtek_nic * )
which is implemented in src/drivers/net/realtek.c, comprises the following comment:
/* Some cards (e.g. RTL8169SC) do not advertise Gigabit by
* default. Try to enable advertisement of Gigabit speeds.
*/
However, since the issue seems to be addressed in iPXE (based on my understanding of the code), I don't know what more to do...
And I assume this would not explain the factor 2000 issue I face: I can't imagine iPXE configuring the NIC at a speed below 10Mbit/s (which would take about 34s, not 10min, to download vmlinuz and initrd).
I read that multi-NIC clients may pose problems to iPXE. But I already deactivated the Fast Ethernet NIC at bios level, it is no longer visible (the system appears to only have the Gigabit NIC) and this does not improve the situation.
I read on forums about real-mode issues in iPXE (which would employ old and buggy memory management techniques?) but this seemed to be in a different context and I am not sure how relevant/correct this is.
If I could easily preload vmlinuz and initrd locally from the HDD of the desktop without compromizing (i.e. without having to completely reconfigure) the rest of the iPXE boot, this could be an option.
I thought of a possible dirty hack (that I would need to investigate further) into:
int imgdownload_string ( const char *uri_string, unsigned long timeout, struct image **image )
so that when I recognize that the uri_string parameter points to my vmlinuz or to my initrd, instead of calling imgdownload I create an image structure and copy the relevant data into it from local copies.
Not sure how easy it is to implement in view of analyzing the image structure, understanding how to fill it so that it looks (to the rest of the program) like it was just downloaded, etc.
But I assume there must be another way.
At that stage I cannot afford to spend days on this while I may be doomed to fail (not in the near future at least), hence my present request for help.
The options I currently exclude:
1 - dropping iPXE and using a PXE gigabit NIC (I don't have one and I now think I need iPXE for other reasons anyway).
2 - dropping any form of PXE and booting the LTSP client locally by copying the LTSP ISO on the old desktop (despite this being advertized as a trivial possibility, it appears to be very tricky to configure, at least for me, and I gave up after a few days of unsuccessful attempts).
Thanks!
