On 07/12/2010 02:57 AM, David C. Rankin wrote:
I've tried rebuilding the initramfs or whatever you call it with:
Normal Kernel:
/sbin/mkinitcpio -k 2.6.34-ARCH -c /etc/mkinitcpio.conf -g /boot/kernel26.img
Fallback Kernel:
/sbin/mkinitcpio -k 2.6.34-ARCH -c /etc/mkinitcpio.conf -g
/boot/kernel26-fallback.img -S autodetect
and each time it completes successfully. But then it will either boot once OK,
then fail to boot the very next time I try to boot the box -- or -- it will
never boot. It looks like it is blowing up on the loading modules line or it
just gets stuck on the setting up UTF-8 mode line. No doubt this bug is also
what is causing compiz to white-screen when I do get one of these new kernels to
boot, but with no logging on during the boot process when it blows up, I'm not
sure what to do.
What say the gurus?
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?? As mentioned in the title on the 2nd boot attempt (and all
subsequent attempts), the boot process either hard-locks when the "Setting up
UTF-8 mode" message is displayed --or-- a kernel NULL Pointer message is
displayed and then I get 3 screens of garbage before the box either locks or a
ctrl+c kills that part of the boot process and booting proceeds until it craters
4-10 steps later.
(Memory can be ruled OUT as a problem, it memtests fine and I'm working from the
same box right now and it will boot the LTS kernel and the opensuse kernel's
fine each and every time)
Moreover, I have 8-10 Arch boxes running 2.6.34.1 happily, but this laptop
exhibits the "boot once then fail" behavior every time. I would like to help
find out what is causing this problem, but I have exhausted my shallow pool of
Arch boot sequence knowledge so I'm looking for some help. Even something as
simple as:
When the boot fails try this ....
What does file XYZ contain?, etc...
I have posted the dmidecode information for the box in case the problem is
related some weird hardware or hardware where a regression has occurred between
2.6.33 and 2.6.34.
I don't know what else to do except wait until the next kernel release and
pray that one will work. All Arch and suse and gparted kernels have worked fine
on the box until the past two 2.6.34 kernels. Somehow just doing nothing and
waiting seems less than scientific and an approach that is unlikely to help Arch
or my present situation.
I don't know if you guys would rather me open a ticket on this one or just
sit-tight and see if we can get some better information here before doing so?
Dunno -- that's why I'm asking...
I'll even take your best swag at this point :p Let me know what the best
way to pursue this on is. Thanks.
--
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com
