Christian,
Sorry you are still having trouble. Lots of people have reported that this
solution has made substantial improvements to their boot time, effectively
fixing this bug for all of them. If you are still experiencing a slow boot
time, it would be best to open a new bug report because you
Tim [2009-12-02 0:52 -]:
Since I don't have karmic-proposed enabled, does that mean installing
this update could break my system?
No, the kernel is already in -updates now, and even if you don't run
that the worst thing that can happen that you get no readahead at all,
and thus no speedup.
On Thu, 2009-11-12 at 22:28 +, Bdopo wrote:
Bootchart after installing the ureadhead from the boot ppa. 4 second
difference.
This is still profiling, make sure you have a /var/lib/ureadahead/*pack
file and reboot again :-)
Scott
--
Scott James Remnant
sc...@ubuntu.com
--
performs
On Fri, 2009-11-13 at 08:35 +, ScottHW wrote:
I've been experiencing significantly slower boot times since upgrading
to Karmic. Too bad, as one of the main features I thought we were going
to look forward to was faster booting.
In Hardy, I was booting in ~0:39
In Jaunty, I was booting
Hi Scott,
On Tue, Nov 10, 2009 at 05:38:14PM -, Scott James Remnant wrote:
hdparm sync of death. I should file a bug about that ;)
- delete /lib/udev/rules.d/85-hdparm.rules
If we don't use the udev rule, what will set the initial power management
policy for the drive? We don't want to
On Thu, 2009-11-12 at 09:21 +, Steve Langasek wrote:
On Tue, Nov 10, 2009 at 05:38:14PM -, Scott James Remnant wrote:
hdparm sync of death. I should file a bug about that ;)
- delete /lib/udev/rules.d/85-hdparm.rules
If we don't use the udev rule, what will set the initial power
On Tue, 2009-11-10 at 19:20 +, FriedChicken wrote:
In case you need it...
Everything in the list has 0 blocks.
What kind of filesystem are you using? Are you using wubi or anything?
Scott
--
Scott James Remnant
sc...@ubuntu.com
--
performs poorly on slow HDD
On Tue, 2009-11-10 at 17:53 +, Ryan wrote:
My before and after hover right around 131s tried remove on *pack, and
did two more reboots. Here's the ureadahead --dump dump in case it is
of any interest.
Actually your boot time is 55s (look at the point on the chart where CPU
and I/O
On Wed, 2009-11-11 at 06:25 +, Farooq wrote:
This attachment contains bootchart graphs for sreadahead and after
applying the patch, for ureadahead. Seems like the upgrade have given 5
seconds boost i.e. it was 70sec for sreadahead and is 65sec with
ureadahead. But overall, it's still very
In case you need it...
Everything in the list has 0 blocks.
What kind of filesystem are you using? Are you using wubi or anything?
XFS on / and ext3 on /boot. No, it's a native installation.
--
performs poorly on slow HDD
https://bugs.launchpad.net/bugs/432089
You received this bug
Jamie Strandboge [2009-11-11 13:54 -]:
Upgrading to the sreadahead in karmic-proposed (in main) pulls in
ureadahead from from universe.
Fixed some hour ago, promoted to main now.
--
performs poorly on slow HDD
https://bugs.launchpad.net/bugs/432089
You received this bug notification
On Wed, 2009-11-11 at 13:58 +, phil wrote:
Yes, it works much better. Thank you Scott!
But I'm still getting more than duble the boot time I had in jaunty if I'm
not mistaken (?).
Attached are bootcharts of the different kernel-versions.
What is my problem? (said one shrink to the
Johan Kiviniemi [2009-11-11 15:49 -]:
I’ve been running the kernel and ureadahead from the ubuntu-boot PPA and
afterwards from karmic-proposed, including the very latest packages it
currently has. It has worked for me all the time without problems.
+1 on my system, for contributing to
On Tue, 2009-11-10 at 06:09 +, pbrufal wrote:
In my system, adding the PPA+ureadahead makes the system 5sec slower :?
I'm using the last kernel (2.6.31-15.49)
80 sec before PPA
85 sec after PPA (tried 6 times)
You didn't attach the before bootchart.
In the after bootchart, the boot
On Tue, 2009-11-10 at 14:25 +, FriedChicken wrote:
After installing ureadahead from proposed booting takes about 10 s
longer.
From the chart, it actually appears a few seconds quicker - but it's
strange that it hasn't made much of a difference for you.
Try removing that
On Tue, 2009-11-10 at 15:42 +, Tyson Williams wrote:
This proposed update did not speed up my system (that uses a SSD).
Ok, SSD gains are in the order of quarter to half a second - it's good
to know it hasn't regressed :p (this update is all about HDD
performance, not SSD)
In all of
On Tue, 2009-11-10 at 16:43 +, tado wrote:
my boot time has decreased a bit, but it is still substantially high.
bootchart says 1:20, my stopwatch says 1:52 till ready desktop.
unfortunately i don't have a bootchart from right before installing, so the
one attached here is from a few
Scott James Remnant [2009-10-15 19:43 -]:
Not that I know of - which kernel are you using?
Just what's in karmic (amd64 2.6.31-14.47-generic), but it's been that
slow for weeks, so it's nothing new.
--
Martin Pitt| http://www.piware.de
Ubuntu Developer
Hernando Torque [2009-10-15 21:17 -]:
@Martin Pitt: Are you referring to the bar in the chart not being red?
I did yes. That, and grub-gdm now taking 85 seconds, where it took
just 50 in jaunty.
Maybe bootchart doesn't represent sreadahead very well, because when put
in foreground you can
On Wed, 2009-10-14 at 21:40 +, Pavel Rojtberg wrote:
in case this bug cant be fix for karmic - are there any plans to revert
to readahead and postpone sreadahead for lynx? It did a good job for
HDDs and these are still used in the majority of the target systems.
In the testing I've been
Scott James Remnant [2009-10-15 17:38 -]:
In the testing I've been able to do, readahead doesn't show any
improvement.
Hm, sreadahead does not do _any_ readahead for me right now. Is that
due to a kernel change which would also break readahead?
Martin
--
Martin Pitt
On Thu, 2009-10-15 at 18:53 +, Martin Pitt wrote:
Scott James Remnant [2009-10-15 17:38 -]:
In the testing I've been able to do, readahead doesn't show any
improvement.
Hm, sreadahead does not do _any_ readahead for me right now. Is that
due to a kernel change which would also
22 matches
Mail list logo
