How to turn a functioning laptop into something useless

[Michal Jaegermann]

That turns out to be really simple.  Just "upgrade" a working F8
installation to F10 and that solves that right away.

The laptop in question is a rather old Acer TravelMate 230 with
"Intel Mobile Intel(R) Celeron(R) CPU 2.00GHz" and Intel
82845G/GL[Brookdale-G]/GE graphics.  Works with F8 quite nicely
(save some non-critical quibbles).

The first indication of coming problems was an upgrade time.
In a text mode, to save some memory, it took around 12 hours.
Not sure exactly how long as I left it to run overnight and found
sitting at "Reboot" screen this morning.  I tried to check what
was happening before this reboot but that turned out to be
impossible.  Shell command were just hanging and that was it.
On one of consoles I found grub wailing something about "wrong
device", while there is only one disk in this setup, but it was
also non-responsive.  I could only reboot.  The fact that I had to
hit "OK" buttons too many times at the beginning of an anaconda run
should have been an alarm bell.

There were some hints for a length of this operation but later
turned out that they could be way off in any case.  I know for sure
that after eight hours it still had a waaay to go.

An attempt to boot this fresh F10 on it ended up with a screen
filled out entirely with "GRUB " strings and scrolling really fast.
I allowed anaconda to take a default action and rewrite my boot
sector.  A serious mistake.

A rescue boot and reinstallation of grub allowed to boot at last.
That got promptly stuck after 

input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio4/input/input7 kjournald starting.

showed up on my screen.  That should be followed by

EXT3-fs: mounted filesystem with ordered data mode.
udevd version 127 started

I believe but nothing of that sort ever showed up.  Adding
'nomodeset' to kernel parameters allowed to squeeze past that
hurdle.

A little bit further one runs into "Could not detect stabilization,
waiting 10 seconds".  So far I have seen that on every single
machine I tried, be that i386 or x86_64.  That little ditty
immediately blews out of the water any supposed boot time gain from
changing to upstart and/or plymouth (not that I have really noticed
anywhere any; quite the opposite so far and that without those "10
seconds").

After I managed to get a shell prompt at last something started to
clarify.  Rather quickly I discovered that my system clock is
running at roughly 1/3rd speed, with /proc/cpuinfo looking quite
normal, so I was loosing wall clock time at an amazing rate.
Apparently also my interrupts were going at times nowhere as a
machine was getting into a cathatonic state every few keystrokes
with quite long lasting "blackouts".  Moreover upgrade logs written
in /root/ by anaconda are obviously incomplete.

dmesg now had some extra info - like this:

* The chipset may have PM-Timer Bug. Due to workarounds for a bug,
* this clock source is slow. If you are sure your timer does not have
* this bug, please use "acpi_pm_good" to disable the workaround
HPET not enabled in BIOS. You might try hpet=force boot option

Nothing of that sort was needed before touching F10.  Apparently my
chipset does not have that "PM-Timer Bug".  With both "acpi_pm_good"
and "hpet=force", and one is not enough, it looks like that at last
I stopped loosing time.  Not so good with interrupts.  A boot
sequence prints: "Starting udev: " and sits there with nothing
happening.  I think that if you will wait long enough, in an order
of 20 minutes, then it will possibly boot.  At least to level 1.  A
full boot would likely take much longer.  Another way to speed
things up is to sit by the keyboard and press repeatedly some keys.
Maybe this will help although no guarantees.  Apparently better
right away before a machine will decide to doze off.  ACPI events,
generated by hitting on a power on/off key, seems to be at times,
although not always, preferable.   That is, presumably, why I was
unable to check anything in anaconda before a reboot.  The same key
hitting is required when shutting down or you may wait for a very
long time before anything will happen.  This is clearly
unacceptable.

I did not try yet to experiment with various possible 'clocksource=...' 
options.  Any ideas?  Something else?  Some secret i8042....
handshake is necessary?

Add to that X server immediately crashing like this:
https://bugzilla.redhat.com/show_bug.cgi?id=474540
and we are in a full "fun" mode.

I did not see yet an upgrade in such bad shape and I did not touch
yet, for obvious reasons, suspend and hibernate.  Those were broken
by F8 too but eventually I got them going and on F8 kernel did not
require any extra options save a / file system location.

I am afraid that a disk on this laptop is too small to allow for
"parallel" installations of F8 and F10.  The box will be needed
pretty soon for work purposes so if I will not find rather quickly
how to get it going with F10 I will have to revert it to the
previous state.  Big sigh but yes, I have this option.

   Michal