[arch-general] kernel26-2.6.34.1 - won't boot - stuck at "Setting up UTF-8 mode" or craters with kernel NULL pointer

Isaac Dupree ml at isaac.cedarswampstudios.org
Tue Jul 13 15:10:31 EDT 2010


On 07/13/10 10:26, David C. Rankin wrote:
> Can anyone think of the possible mechanism that would cause a kernel to
> boot once after rebuilding the initramfs, but then be corrupt for every
> boot thereafter??

Do you rebuild the initramfs on 2.6.32?

Do you let the machine sit for a minute, shut-down, between each boot?

Yes, I can think of a mechanism.  I'll tell it by example:  My machine 
has a built-in webcam that the OS has to upload firmware to on every 
boot.  Sometimes when I boot it ends up in a screwed-up state somehow 
(so the webcam doesn't work), and sometimes rebooting doesn't help: 
shutting down and waiting a few minutes sometimes helps: booting into 
MacOSX then shutting down also can change things a bit, often for the 
better (after all this hardware and OSX were made for each other).  I 
believe it has some sort of volatile memory that decays randomly and 
slowly when not powered (like RAM does).  I guess that when it boots 
with its memory containing partly corrupted firmware, it causes some 
kind of trouble depending on the exact state of the memory that 
interferes with just fixing it by uploading new firmware.

That's an example of how something could possibly persist across 
reboots.  Maybe if you build on 2.6.32, the actual effect is that you 
were just booted into a good kernel that initialized some piece of 
hardware into some reasonable state, and this state is likely to persist 
across a reboot, but 2.6.34 screws up the state such that the next boot 
of 2.6.34 doesn't like it but 2.6.32 is a good enough kernel to 
nevertheless re-initialize it properly.  (It could be non-volatile 
memory too, and the randomness could be part of linux boot process being 
nondeterministic as it is)

Or...maybe the explanation is entirely different.

-Isaac


More information about the arch-general mailing list