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 -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
