hi,

Has anyone done this before?

Care to share your experience? Thanks!

Since it is basically similar to an optimized defrag, I see no reason not to try it out. However, since e4rat-realloc may relocate some of the kernel or initrd blocks (but I'm not certain about that, since those have already been loaded by the time the analysis begins), it's probably a good idea to reinstall lilo after that step.

Looks interesting. I'll probably give it a go and see if it helps. If it succeeds in preloading all the boot files into RAM cache, it's probably just as effective at speeding up boot time as some other, more intrusive methods.

2 members found this post helpful.

Thanks, volkerdi.

I will certainly give it a go and post the results. e4rat seems proven in distro like debian, ubuntu and arch.

Hopefully it doesn't break my system.

I tried compiling it on slackware about a year back and didn't succeed. I think it had something to do with boost libraries. If anyone does get it going, please post a how-to, or preferably a slackbuild.

Same thing here. It doesn't find the boost libraries, even when passed the cmake flag to the library directory.

I think it may require a patch to compile on boost 1.5x. http://sources.gentoo.org/cgi-bin/vi...&diff_format=s

I've not yet tested it myself with audit (I rebuilt my custom kernel with support for it but gotta reboot later on) but I got a patch and some build hints from Archlinux's AUR and prepared a SlackBuild

http://ponce.cc/slackware/testing/e4rat/

https://wiki.archlinux.org/index.php/E4rat

1 members found this post helpful.

@ponce - your slackbuild seems to work in that it compiles with no errors. Many thanks. However the archlinux site describes how to continue with grub, but gives no advice on lilo. If any brainiacs can contribute a bit more info into that quagmire, then we're almost there. Altho' I guess boot-from-suspend trumps all this :-)

@ponce - oops. Possibly a critical flaw somewhere in your script. I can't be 100% certain of this, but I would be surprised if it was not - I just installed the slackbuilt e4rat (as root) and it mucked up the "other" read/exceute permissions on /etc /usr /var and possibly a few others. I had to reboot, as my ordinary just died. The some careful picking and comparing to another machine to fix. I'm up now. All the modification dates on the directories I had to "fix" (with chmod a+rx) were modified in the lat 5 minutes - and the only thing I "su -c"ed for was the e4rat slackbuild. Such is the (willing) price for bleeding edge. :-)

hi Mark, I think you built the package maybe using a wrong umask: I unpacked it here after building and permissions were ok.
check your umask after the su, here is
and you really should use "su -" before launching the *.SlackBuild, so that you operate in a true root login shell: if you don't do that environment variables from your user can interfere with the build, just like it probably happened to you.
see Step 3 of the HOWTO on SBo.

markp@marklap ~ $ su -c "umask"
Password:
0027

:-(

Ok - on a positive note, I have built this, installed it, hacked in the lilo stuff, and I can confirm it does speed up the boot process. I did not time it, but it was noticeably faster. I got an error message about "fuse" having an error, but I tested a sshfs after boot and that worked fine, so I'm not sure if it was related. Here is my lilo steps :

first, run the collect stage with this lilo setting :

image = /boot/vmlinuz-generic-3.2.29
append="acpi_osi=Linux init=/usr/bin/e4rat-collect"
initrd = /boot/initrd.gz
root = /dev/sda1
label = Linuxe4ratcol

(Arch had /sbin, but I think your slackbuild puts it in /usr/bin)

Then run the re-alloc bit from "init 1" as per Arch.

Then put this in lilo, run the config and reboot with it ...

image = /boot/vmlinuz-generic-3.2.29
append="acpi_osi=Linux init=/usr/bin/e4rat-preload"
initrd = /boot/initrd.gz
root = /dev/sda1
label = Linuxe4ratload
read-only

You may need to adjust your image.

Thanks @ponce.

Thanks, pounce!

you are truly awesome

I managed a successful installation with your Slackbuild.

here's a before/after of my boot chart.
my result seems marginal though....

I doubt you will see an amazing difference from the boot. But run the collect process again, setting the time from 120 to say 300 seconds. Then reboot and start X-windows, start Firefox, your email client (mine is Thunderbird), and then a few other programs you often use - do all that within those 300 seconds. Then, do the init 1 and run the re-alloc part again. Then reboot, start X and get into Firefox/Thunderbird/Libre-office etc and THEN you should see a clear difference.

well, it seems to boot faster indeed: got some problems at work because I'm using a raid array and realloc seems not to like it but at home my laptop is happy.

here are the bootcharts (started in rc.S), before and after: it's measured a boot in runlevel 3 with login, startx, LXDE, terminal launch, tmux, ssh, firefox with two tabs and thunderbird (what I use commonly)

http://ponce.cc/stuff/bootcharts/bootchart_before.png
http://ponce.cc/stuff/bootcharts/bootchart_after.png

Well it's "faster" but I'd have expected more improvements. CPU and Disks are not fully used the whole time.

I have a question about boot time: I can understand on a server to avoid too long downtime while rebooting, but on a workstation is it really worth it ? I mean I nearly never boot my systems, and the time of boot is generally so short relative to the whole time passed working in a running session, even on laptops.