Best posts made by Piotr86PL

I’m currently testing init.xz images built by myself using the partclone-0320 branch. In addition, these images have, for my part, added these two commits of mine from github that fix bugs with BTRFS (https://github.com/FOGProject/fos/pull/47 https://github.com/FOGProject/fos/pull/45). The whole thing was built using Buildroot 2022.02.5, which fixes bugs related to udev (https://github.com/FOGProject/fos/issues/46). I know it’s too many changes to treat my experience as relevant to the addition of this particular partclone version, but I think it’s worth sharing anyway.

The FOG server on which this custom init.xz runs is based on Fedora 36 (/images on XFS), the latest (at the time of writing this) development version of FOG, compiled kernel 5.15.71, and an updated version of UDPcast to 20200328 (the latest does not work with FOG). This server, runs in production, so there are 30 images restored each day, and sometimes more (mostly Windows 10 and Ubuntu). But it happens to image other computers that have other systems, such as Fedora 36 Workstation with the BTRFS file system. I mainly use Multicast restore (computers in the school computer lab), but sometimes I need to restore one computer and I use Unicast.

The previous FOG server was based on Debian 10 (/images on EXT4), FOG 1.5.9 and the latest official kernel and init.xz. The situation has changed dramatically after the migration.

On the old system, using Unicast I was getting speeds of around 7-8GB/min (for both restore and capture). With Multicast, this speed increased to 12GB/min.

After I built the server on Fedora, I used init.xz from the partclone-0320 branch without patches and the official 5.15.68 kernel and the speed increased to 14GB/min using both Multicast and Unicast. The capture speed went up to 9GB/min. After changing init.xz to the current one, the speeds have not changed, but at least I can safely restore the BTRFS file system without any errors.

I don’t know how much of this is due to Partclone 3.20 and how much is due to migrating the system to Fedora with XFS, but I can say that so far Partclone 3.20 is running very stably and hasn’t crashed yet. And I have already restored images based on NTFS, XFS, EXT4 and BTRFS. If I only notice any flaws with the operation of the whole thing I will describe them. But so far I have no complaints about my system. If it continues to perform as well as it does now I will migrate the FOGs in other computer labs to what I am using in this particular one.

@george1421

Now with a browser go to http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00 That will display the text behind the iPXE menu. On that page search for default. That will be the section that is called when the timeout happens and boots from the local hard drive. By changing globally the exit modes for both bios and uefi to exit, it should put the exit command in the iPXE Menu script.

And it is putting the exit command in the iPXE Menu script

choose --default fog.local --timeout 5000 target && goto ${target}
:fog.local
exit || goto MENU

I’ve tried to mess with the embedded script itself and I found that if I replace

:netboot
chain tftp://${next-server}/default.ipxe ||
prompt --key s --timeout 10000 Chainloading failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

with this

chain tftp://${next-server}/default.ipxe || echo Chainloading failed

and try to “Boot from Hard Drive” using “EXIT” method, it is WORKING! The “Chainloading failed” is not echoing back to me. But if I write this like that

chain tftp://${next-server}/default.ipxe || 
echo Chainloading failed

the “Chainloading failed” is echoing back to me. So I guess the issue here is not with the chain command but with the syntax.

Apparently

command || command

is not the same as

command ||
command

So I’ve tried to leave this “prompt” command but in this manner:

:chainloadfailed
prompt --key s --timeout 10000 Chainloading failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

:netboot
chain tftp://${next-server}/default.ipxe || goto chainloadfailed

And now it works! When I use EXIT by clicking “Boot from Hard Drive”, iPXE is correctly exiting. And if I rename default.ipxe on my server to something else (to simulate failed chainloading), the “Chainloading failed, hit ‘s’ (…)” message is appering so I guess that the core of this issue is incorrect syntax in iPXE script, and the solution is to write this like I did.

Straight away I say that if I write it like this (in one line)

:netboot
chain tftp://${next-server}/default.ipxe || prompt --key s --timeout 10000 Chainloading failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

the script is not working, beacuse it is dropping me straight to iPXE shell, so the better solution is to write this like this:

:chainloadfailed
prompt --key s --timeout 10000 Chainloading failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

:netboot
chain tftp://${next-server}/default.ipxe || goto chainloadfailed

So I guess, we’ve solved this mistery. Next-server variable is working - I’ve tried to echo it and it echoed IP address of my FOG server, by the way.

@sebastian-roth
As it turns out, this topic is a bit complicated.

The “r8169” driver built into the kernel supports the following Realtek chips:
RTL8169 Gigabit Ethernet
RTL8168 Gigabit Ethernet
RTL8101 Fast Ethernet
RTL8125 2.5GBit Ethernet

Whereas the “r8168” driver provided by Realtek only supports:
RTL8168
RTL8111

And installing r8168 REQUIRES removing r8169 from the kernel. Therefore, in order to maintain functionality, I was forced to integrate into the kernel not only r8168 from Realtek, but also other drivers provided by Realtek. These drivers are:
r8101 - support for RTL8101 and related chipsets
r8125 - support for RTL8125 and related chipsets
r8169 - support for RTL8169 and related chipsets (DO NOT MISS THE KERNEL DRIVER!!! These are not the same drivers)

Only by integrating these four drivers can the integrated r8169 driver be replaced while maintaining support for all chips. And removing the integrated r8169 driver is required - as I mentioned.

I can provide a patch file that I use to compile modified kernels (the patch completely swaps the integrated r8169 for these 5 drivers mentioned earlier).

Versions I use:
r8101 - 1.037.01
r8125 - 9.010.01
r8168 - 8.050.03
r8169 - 6.031.00 (recall, this is also the name of the Realtek driver, which currently has nothing to do with the one built into the kernel)

There is one more important thing!
The Realtek drivers r8101 and r8168 have a function called “mdio_real_read” in the r8101_n.c and r8168_n.c files. This function is not set as “static” so the linker throws an error if you integrate these two drivers in the kernel. You need to make small modifications and add “static” in both files to these functions (r8125 already has static added). My patch already contains this modification.

Here you are right. Partclone shows the speed of writing to the disk, not the speed of downloading the image from the server. I wouldn’t look for the increase in write speed in improving the network parameters either, but more in the storage parameters of my machine. I switched /images to XFS and on top of that I made sure that in Fedora, no unnecessary background services were running. I also forgot to add that I tweaked the parameters of the machine itself - from 6 cores to 12 and from 8GB of RAM to 12GB. Previously, the machine may simply not have been able to keep up with writes and reads from the array.

I also don’t rule out that changes to the kernel and init also had an impact on the speed increase. It is likely that the SPECULATION MITIGATIONS option may have had some bearing on the matter. The iperf tests showed, full 1Gbps speed from the FOG server to the FOS, both with the old setup and the new one. So by saying that the server setup matters, I’m referring specifically to the server’s hardware configuration and disk configuration. I’ve made too many changes to the FOG to say unequivocally what specifically caused such an increase in speed - I’m no less pleased that I was able to squeeze out something more. I am happy with what I have and am unlikely to try to get more. The important thing for me is that the current speeds are stable and nothing has crashed yet.

Of course - the more variety the better the test results will be. I will slowly start to deploy my kernels and inits in other computer labs at school, where there is also diversity in computers and configurations, so I will know from the lab supervisors if something on their hardware does not work.

Funny thing, because there are still some issues with each lab having a different hardware configuration, but at least now it’s useful for FOG testing.