3.1+ kernels unbootable

I understand this mailing list is not a support list. But I am curious as to what could make the Linux kernel non-bootable from 3.1+ kernels?

My 3.0 kernel boots just fine with my current system.

You might like to try
a/ describing your current system in more detail.
b/ describe what actually happens when you try to boot a 3.1+ kernel.
It is rare that absolutely nothing happens.
Also describe the provenance of these 3.1+ kernels (do you compile yourself, or get them from a distro or....)

NeilBrown

Quoted 8 lines · On Wed, 25 Apr 2012 13:21:22 +1000 NeilBrown <[email protected]> wrote:

You might like to try
a/ describing your current system in more detail.
b/ describe what actually happens when you try to boot a 3.1+ kernel.
It is rare that absolutely nothing happens.
Also describe the provenance of these 3.1+ kernels (do you compile yourself, or get them from a distro or....)

NeilBrown

Thanks Neil. I use standard x86_64 Intel CPU system with 2.0GB DDRII RAM on a Gigabyte GA-8VM800PMD-775-RH motherboard.

This happens on both Ubuntu and Fedora kernels. And in fact, any kernel 3.1 or above. It's not only very odd, but also very annoying.

I get to the boot screen and when I select ENTER to boot into the system, my screen goes black and then the system reboots. It's definitely a kernel issue as anything (as mentioned already) with kernel 3.0 or below works just fine.

You have a couple of options here.

One is to use git-bisect to narrow down where the breakage is. This means building about a dozen or a score of kernels and testing each one and then trying again. If you are happy building your own kernels and have an afternoon to spare this is probably a good idea. There should be plenty of instruction on the web about how to do this but if you cannot find any feel free to ask.

The other is to try turning features off and debugging on. Many distros have some sort of "fail-safe" boot option which disables things like ACPI and known-problematic drivers... though with it failing so early most drives won't have even tried to run. I'd guess an ACPI problem, but that is largely because I know almost nothing about ACPI so it is easy to blame it. So try adding "acpi=off" to the boot args.

Linux has a thing called 'early_printk' which allows messages to be displayed even before the normal drivers are loaded. I don't know much about enabling that on an x86 system (I use it a lot on ARM though). You need it enabled when the kernel is compiled, and you need a boot arg to enable it too. Maybe if you manage to enable that you might get some message printed.

Or maybe there is some other much more useful thing you can try and someone else will chime in soon and tell me I don't know what I'm talking about and explain in detail the right way so solve this problem - that would be awesome.

NeilBrown

Quoted 30 lines · On Wed, 25 Apr 2012 14:44:52 +1000 NeilBrown <[email protected]> wrote:

You have a couple of options here.

One is to use git-bisect to narrow down where the breakage is.  This means building about a dozen or a score of kernels and testing each one and then trying again.  If you are happy building your own kernels and have an afternoon to spare this is probably a good idea. There should be plenty of instruction on the web about how to do this but if you cannot find any feel free to ask.

The other is to try turning features off and debugging on. Many distros have some sort of "fail-safe" boot option which disables things like ACPI and known-problematic drivers... though with it failing so early most drives won't have even tried to run.  I'd guess an ACPI problem, but that is largely because I know almost nothing about ACPI so it is easy to blame it.  So try adding "acpi=off" to the boot args.

Linux has a thing called 'early_printk' which allows messages to be displayed even before the normal drivers are loaded.  I don't know much about enabling that on an x86 system (I use it a lot on ARM though).  You need it enabled when the kernel is compiled, and you need a boot arg to enable it too.  Maybe if you manage to enable that you might get some message printed.

Or maybe there is some other much more useful thing you can try and someone else will chime in soon and tell me I don't know what I'm talking about and explain in detail the right way so solve this problem - that would be awesome.

Quoted 1 line

NeilBrown

I have tried all ACPI disabled options and also all safe-mode options, among many other modes. Nothing has worked.

Now that Ubuntu 12.04 has gone gold, I might try the latest kernel in that and see if anything has changed.