Page 1 of 1

boot time idea

Posted: Sat Mar 08, 2008 5:48 pm
by mweber26
I had an idea, I don't know if it's a good one or even possible, but here goes anyway.

I just changed over my minimyth configuration to download everything over http instead of tftp and my boot time dropped drastically (2-3 times faster). But now, almost half of the boot time is spend grabbing rootfs for the initial ramdisk (still over tftp obviously). So now my question/thought.

Is it possible to create a much smaller initial rootfs that only does the basic configuration to setup the network enough so that the real rootfs can be downloaded then remounted in the initial ones place. This would allow the download to be very fast over http. Also for people still using tftp, I woudn't thin that there would be too much extra delay.

Any thoughts?


Posted: Sat Mar 08, 2008 9:08 pm
by Pablo
When I first added support for retrieving configuration files using HTTP, I looked into this. I found an easier way to do this, and it is what I use.

If you switch from using PXELINUX to using gPXE, then you can fetch everything after the PXE loader using HTTP rather than TFTP. However, doing this is somewhat involved.

First, follow the instructions for PXE chainloading.

Second, create a gpxe script that will be run by the gPXE loader. This script will fetch your kernel and rootfs, and boot. Here is a copy of my script

Code: Select all

kernel http://tftp.home/minimyth/minimyth-0.20.2-41b2/kernel ro root=/dev/ram0 ramdisk_size=96000 BOOT_IMAGE=/minimyth-0.20.2-41b2/k
ernel initrd=/minimyth-0.20.2-41b2/rootfs MM_MINIMYTH_BOOT_URL=http://tftp.home/minimyth/
initrd http://tftp.home/minimyth/minimyth-0.20.2-41b2/rootfs
It contains four lines, the shebang, the kernel line, the initrd line and the boot command. The kernel line contains three options that are not needed for booting but are needed to fool/assist MiniMyth: BOOT_IMAGE, initrd and MM_MINIMYTH_BOOT_URL. BOOT_IMAGE and initrd are present when booting using PXELINUX or SYSLINUX and the MiniMyth init script expects them, so we provide them. MM_MINIMYTH_BOOT_URL causes MiniMyth to fetch minimyth.conf from the HTTP server. Note, I share my [...]/tftpboot directory as http://tftp.home/ and I place all my MiniMyth related files in the directory [...]/tftpboot/minimyth.

Third, put the script on your TFTP server. I put mine in the file
[...]/tftpboot/minimyth/gftp/{hostname} whereas the file created in step is located at [...]/tftpboot/minimyth/undionly.kpxe

Fourth, configure your DHCP server so that gPXE can find the script on HTTP server. To do this, I added the following to my DHCP server configuration

Code: Select all

if exists gpxe.bus-id {
    filename "http://tftp.home/minimyth/gpxe/myth-parents";
Well, now that the cat is out of the bag, I suppose I should create some real documentation for this and make the MiniMyth init scripts support it without the hacks in the gpxe script.

Posted: Sat Mar 08, 2008 10:28 pm
by mweber26
Very nice! I will try it.

Posted: Sat Mar 08, 2008 11:01 pm
by mweber26
Everything worked great. I'm at 1:20 for power on to myth usable. Of which about 30 sec is power on/bios/pxe boostrapping stuff.

Your instructions were exact. The only thing i had to change was in the gPXE script i had to add MM_NETWORK_INTERFACE=eth0 because for the last few revs of minimyth, it will no longer autodetect the network interface.

Posted: Sun Mar 09, 2008 1:15 am
by Pablo
It is odd that network interface auto-detection is failing. However, MiniMyth's habit of failing rather than defaulting to 'eth0' is overkill. I have changed it so that it defaults to 'eth0' when it fails to find a network interface.

Since others are now using gPXE booting, I am making some changes. I have changed MiniMyth so that it does not require BOOT_IMAGE or initrd options, assuming that your kernel is minimyth-{mm_version}/kernel and your root file system is minimyth-{mm_version}/rootfs. If BOOT_IMAGE and initrd are set, then it continues to use them. In addition, I have changed MiniMyth so that it does not require MM_MINIMYTH_BOOT_URL, assuming that the MM_MINIMYTH_BOOT_URL={protocol}://{path}/ when the DHCP filename option is {protocol}://{path}/{some_dir}/{some_file}. If the filename does not start with {protocol}://, then MiniMyth continues to use the old method for determining MM_MINIMYTH_BOOT_URL.

Posted: Mon Mar 10, 2008 1:40 pm
by zeptic
mweber26 wrote:Everything worked great. I'm at 1:20 for power on to myth usable. Of which about 30 sec is power on/bios/pxe boostrapping stuff.
How long did it take before you switched to gPXE?

Posted: Wed Mar 12, 2008 6:08 pm
by MythLegend
Thought that I'd like to speed up my boot time, but have not been able to get this method to work either with my SP8000 front end or a VirtualBox machine, although both don't work in different ways !

On the SP8000, the boot process does not get very far, basically get to see the lines:


when powering on and then reboots !

When trying it with Virtual Box, get a lot further, loads gPXE 0.9.3, get the boot from message:
Booting from filename "" OK
but fails at loading the kernel:

This is obviously another problem (I guess a VirtualBox one), does anybody else use virtual machines for trying out new minimyth releases ?

One other thought, having built the undionly.kpxe on the backend server, will this be OK to use on a different front end, or does it contain anything machine specific ?


Posted: Wed Mar 12, 2008 6:41 pm
by MythLegend
OK, looking at this site:

I think I need a different image for the type of network card in each frontend, so :

for the SP8000, lspci gives
00:12.0 VT6102 Rhine-II rev 78

choosing "via-rhine-old" to generate the rom image file works.

Posted: Wed Mar 12, 2008 7:49 pm
by Pablo
For flashing your boot ROM, you need a different image for each card. However, for chain booting from PXE, the UNDI boot loader. I have included the UNDI boot loader in the gpxe-minimyth-{version}.tar.bz2. I have called ti gpxe.0 rather than using the name it builds as (undionly.kpxe) so that the name better parallels the PXELINUX boot loader name. I use the included boot loader on my VIA EPIA SP8000E and it works.


Posted: Wed Mar 12, 2008 8:00 pm
by Synergy
In my continuing quest for every ounce of speed, I gave gpxe a shot. On my system, it's slower.

Using blootube-wide (the big one) I posted in 1:26 to the main menu using gPXE.

Using pxelinux, I hit it in less than 1:10.

It would appear that at least on my systems (Dual core A64s running on Gigabit), the additional time to chainload gpxe and redhcp kill any advantages of http over tftp. If I REALLY went after it, I'd burn the eeprom with gpxe, but it's not worth it for me.

NFSboot is still faster than either ramdisk.

I don't reboot that often so this isn't a huge deal for me, but I had to try it.

I put this out there just so people don't think it's going to be the holy grail. I'm sure it does help some people, I just didn't see any improvement significant enough to get around the chainload time.