e4rat - reduce boot time (into X) by some 50% for ext4

smartass · 2011-04-24 18:22:03

@flamelab & kyla: The documentation suggests that once you change something in such a way that a different set of files (changing to a different DE would certainly be the case, changing the theme may not be so drastic) would be loaded during boot and initial DE loading, then re-profiling (this word was used for the readahead project) makes sure that the new files get loaded and the old files that don't have to be loaded anymore can be dropped.
However, if the files change their physical location on the drive during an upgrade, you may want to reallocate them again using e4rat-realloc. Theoretically, if the set of loaded files hasn't changed, you should be able to reallocate them using the old startup.log without running e4rat-collect again.
Bottom line: If you don't change your startup habits through the year and don't update, there is no need to re-profile.

kyla · 2011-04-25 01:26:43

Thanks!

TheGrudge · 2011-04-25 11:30:04

I can confirm this weird behavior, too.
my synaptic touchpad (Macbook Pro 4) is going crazy (or maybe some other component, not sure exactly). For example I move the Macbook (bend it up, down), the cursor moved up / down, too!
When I use the mouse, the cursor jumps back to the middle of the screen all the time!!
This is so annoying...

I deinstalled e4rat and all files I could find with locate, removed the GRUB boot entry, but still I get this weird behaviour... I need to reboot at least 3 times to fix this.
Why is e4rat causing such issues? I don't understand it... are some config files broken? Would it help to reinstall all packages with

pacman -S $(pacman -Qq | grep -v "$(pacman -Qmq)"

I really don't understand this, but it seems I'm not the only one with this "touchpad problem".

simunic · 2011-04-25 13:28:39

TheGrudge wrote:

I can confirm this weird behavior, too.
my synaptic touchpad (Macbook Pro 4) is going crazy (or maybe some other component, not sure exactly). For example I move the Macbook (bend it up, down), the cursor moved up / down, too!
When I use the mouse, the cursor jumps back to the middle of the screen all the time!!
This is so annoying...
I deinstalled e4rat and all files I could find with locate, removed the GRUB boot entry, but still I get this weird behaviour... I need to reboot at least 3 times to fix this.
Why is e4rat causing such issues? I don't understand it... are some config files broken? Would it help to reinstall all packages with
pacman -S $(pacman -Qq | grep -v "$(pacman -Qmq)"
I really don't understand this, but it seems I'm not the only one with this "touchpad problem".

Can you try downgrading udev to 166-2? Maybe the issue is due to udev and not to e4rat. I had a similar problem and it was fixed downgrading. You can see the bug topic here: https://bbs.archlinux.org/viewtopic.php?pid=921315

TheGrudge · 2011-04-25 15:08:27

Yes, downgrading udev seems to do the trick for me as well.
But I updated udev 3 days ago, no problems. They just occur when I used e4rat the first time yesterday... weird.

Mountainjew · 2011-04-25 15:43:30

Didn't notice any difference while using this in Openbox, but in KDE it drastically cut down the time from splash scren to usable desktop

Cdh · 2011-04-27 09:32:36

I think the touchpad not working bug is maybe not related at all but rather this:
https://bugs.archlinux.org/task/23916

edit:
For me

# udevadm trigger --subsystem-match=input

activates the touchpad when it doesn't work. I have put it in rc.local and will see if it works.

Last edited by Cdh (2011-04-27 16:04:57)

smartass · 2011-04-27 16:04:35

Yeah, downgrading to udev 166 solves the problem for me.
Now we either have to wait for the 168 version (which is already available upstream BTW) to be packed, or build it ourself.
Well, since I have my "sandbox" installation, I'll build 168 and report back.

UPDATE: ok, udev 168 works! I've just built it using makepkg, it was pretty easy (I mean, easier than I thought, because I was expecting some trouble after rebuilding an internal part of my OS - so Linux FTW!).
UPDATE2: Well, udev 168 worked only once just when I installed it, after reboot it fails again.

However, Cdh's trick works. Just curious, how did you come up with this solution Cdh?

Last edited by smartass (2011-04-30 19:21:46)

smartass · 2011-05-01 18:19:00

Don't look at this as bumpin', I'm just making sure that people get updated news, because editing posts doesn't seem to get into RSS, so I'm posting this in a new post, there are some updates above in previous posts to check out too.

So, in the end downgrading to 166 is so far the only easy solution. Cdh's trick works, but has to be redone for each Xserver instance (and I suspect for any other touchpad aware instance).

I wonder if the fact that 168 didn't fix it means that udev has a different structure and a lot of thing will have to be revised....Oh well

Last edited by smartass (2011-05-01 18:20:00)

Burning_aces · 2011-05-03 18:51:34

twitch@localhost:~$e4rat-collect -k
Cannot read pid from file /dev/.e4rat-collect.pid: No such file or directory
Cannot dump log messages: /dev/kmsg: Permission denied
Discard 1 unwritten log message(s).

root@localhost:/home/twitch#  e4rat-collect -k
Cannot read pid from file /dev/.e4rat-collect.pid: No such file or directory

That was what I got when I ran the collect thing, I followed all that it said in the wiki.I ran it as root just for the sake of it. I waited 2 minutes each time, and this is the third time with the same error messages
My kernel command line is: Kernel command line: root=/dev/disk/by-uuid/61855236-613b-4468-9194-fd3d3d844242 ro acpi_brightness=vendor noapic quiet fastboot rootdelay=1 ipv6.disable=1 logo.nologo init=/sbin/e4rat-collect
Hopefully some one can help me out

smartass · 2011-05-03 19:11:54

My guess is the 'fastboot' or/and 'rootdelay=1' parameter, because e4rat may have some issues with udev.
If e4rat-collect does its magic for you, you most likely won't need those parameters anyway

And I suppose you have pure ext4 partitions, or at least upgraded with extents applied. Just to be sure.

Burning_aces · 2011-05-04 03:08:20

smartass wrote:

My guess is the 'fastboot' or/and 'rootdelay=1' parameter, because e4rat may have some issues with udev.
If e4rat-collect does its magic for you, you most likely won't need those parameters anyway
And I suppose you have pure ext4 partitions, or at least upgraded with extents applied. Just to be sure.

yeah they are pure ext4, straight from arch install
*wonders how long he has had this arch install for*
Okay, I'll remove the rootdelay=1 and check and then fastboot if it still doesnt fix it. Thanks.
Removed it and didn't fix, I won't worry about it for now..

Last edited by Burning_aces (2011-05-04 03:26:35)

smartass · 2011-05-04 18:17:27

Ok, new development!
After the latest update of udev, kernel and e4rat itself(unfortunately I did it all in a huge bunk, so can't tell what fixed it) everything is working again, I mean the synaptics.

On the other hand, I also receive the same error as Burning_aces when I issue 'e4rat-collect -k', BUT pgrep shows that the process actually did terminate and I checked the startup.log and it was a new file. So Burning_aces, check with pgrep next time you give it a try, most likely it's just a bug in a exception handling function

Haptic · 2011-05-05 04:18:40

Is there anything you have to do after every update?

smartass · 2011-05-05 11:09:33

@Haptic: as I stated a few posts back (hmm, maybe you could have read them before asking ), depends on what you update. If the update results in a different set of files to be preloaded, you may want to re-profile. Or if they just change place on the HDD, you may want to reallocate them again.
So check your startup.log and compare it to what files you updated.

Haptic · 2011-05-05 12:54:32

I meant updating e4rat, not other packages.

smartass · 2011-05-06 13:22:17

Well, this is my view, but I'm not acquainted with the internal structure of the tools, so don't take it too seriously:
If you update only e4rat, the reallocated files shouldn't change their physical place, so you don't have to redo that part again (unless the previous version of e4rat reallocated them badly).
I don't think the structure of startup.log file will change, because it's pretty simple. However, if the new update introduces some new cool algorithms for collecting info, you may want to redo that part. The configuration file may change, just keep an eye on it.
And preloading gets done each boot so unless the location of the executable changes, the kernel parameter can be left the same. I expect the preloading part to be the most worked on, so even if it gets updated, you'll notice the next boot

Bottom line: Unless the configuration/initialization files change, there isn't much reason to redo the whole process, except for the case when some really useful feature is added.

All what I've said presumes that the toolchain(collect>realloc>preload) remains the same.

broken pipe · 2011-05-07 18:28:24

can someone confirm, that it works with an ext4 volume which resides in a lvm? i always get i kernel panic when i try e4rat-collect

ChoK · 2011-05-08 23:13:59

@Burning_aces

fastboot was a 2.6.29 only kernel parameter because it was unstable, see here http://lkml.indiana.edu/hypermail/linux … 02402.html . Everything has been merged by default in 2.6.30, more relevant stuff here http://www.h-online.com/open/news/item/ … 41921.html .

toad · 2011-05-09 05:42:59

@ broken pipe
No, I don't think anyone has tried it but I don't see any reason why it shouldn't work across LVM (at least that is what the dev said all these weeks ago). As for your issue, I suggest you go to the project website and mail the your bug.

bwat47 · 2011-06-11 01:04:18

Just tried this on my machine, very impressed. Laptop with 5400rpm drive. X/GDM load far sooner. All my most use apps launch way faster on cold boot than they did before (I am using preload). The biggest difference was libreoffice, which opens like instantly now.

Haptic · 2011-06-11 02:51:56

Can someone explain further in detail about using both systemd and e4rat? I don't understand the wiki when it says, "If you need to specify another PID 1, such as /bin/systemd, you can change this in /etc/e4rat.conf by setting the init parameter and uncommenting the line."

What am I supposed to edit it to?

WorMzy · 2011-06-11 03:12:52

Haptic wrote:

Can someone explain further in detail about using both systemd and e4rat? I don't understand the wiki when it says, "If you need to specify another PID 1, such as /bin/systemd, you can change this in /etc/e4rat.conf by setting the init parameter and uncommenting the line."
What am I supposed to edit it to?

It means that you need to open up /etc/e4rat.conf for editing (e.g. sudo nano /etc/e4rat.conf), then uncomment line 29 by removing the ";", and then change the part after "init" to the path to the systemd binary (/bin/systemd).

Unfortunately, this doesn't seem to work correctly for me. e4rat chains into systemd, which launches SLIM, which I enter my credentials into, which launches openbox-session.. which hangs. The only way out after that is a REISUB.

I'll look through the topic tomorrow and see if this has been covered, it's too tired to read through seven pages right now.

Cdh · 2011-06-11 07:52:05

I have slim autologin to xfce and it works with e4rat + systemd.

WorMzy · 2011-06-12 02:14:54

Perhaps it only works with autologins? Or maybe there's something in my openbox installation that simply doesn't agree with it. I always get that hang after logging in, but once the two minutes have passed openbox-session finishes launching, tint2, wbar, etc all load up and the system runs as normal. startup.log still gets generated, so I'll just run with that for now; it should still (hopefully) have a beneficial effect on my boot up time.

Arch Linux

#151 2011-04-24 18:22:03

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#152 2011-04-25 01:26:43

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#153 2011-04-25 11:30:04

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#154 2011-04-25 13:28:39

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#155 2011-04-25 15:08:27

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#156 2011-04-25 15:43:30

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#157 2011-04-27 09:32:36

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#158 2011-04-27 16:04:35

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#159 2011-05-01 18:19:00

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#160 2011-05-03 18:51:34

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#161 2011-05-03 19:11:54

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#162 2011-05-04 03:08:20

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#163 2011-05-04 18:17:27

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#164 2011-05-05 04:18:40

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#165 2011-05-05 11:09:33

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#166 2011-05-05 12:54:32

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#167 2011-05-06 13:22:17

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#168 2011-05-07 18:28:24

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#169 2011-05-08 23:13:59

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#170 2011-05-09 05:42:59

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#171 2011-06-11 01:04:18

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#172 2011-06-11 02:51:56

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#173 2011-06-11 03:12:52

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#174 2011-06-11 07:52:05

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#175 2011-06-12 02:14:54

Re: e4rat - reduce boot time (into X) by some 50% for ext4

Board footer