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