Hangs when booting 2.6.9-55.0.2.EL-smp kernel (CentOS 4.5) => Enable PAE

I'm getting the same thing--regular kernel works, SMP one doesn't with CentOS 4.5. I'm using an earlier CentOS kernel, 2.5.9-42. This is with VirtualBox 1.5.4 on 32-bit Ubuntu, underlying processor is Core Duo T2500. I tried a bunch of alternative switches to the boot loader with the SMP kernel:

• pci=noacpi
• noapic
• acpi=off
• noapic acpi=off

That's with the default Virtualbox settings--"Enable ACPI" is on, "Enable I/O APIC" is off. Going back to the default setting where there's nothing passed to the bootloader, I tried all the possibilities there as well:

• ACPI: On, APIC: Off
• ACPI: On, APIC: On
• ACPI: Off, APIC: On
• ACPI: Off, APIC: Off

Couldn't find any combination that worked. Theoretically I could try all the boot loader settings with each of these four but I got worn out poking at random. It's kind of surprising this Linux version isn't compatible.

Is this problem still relevant?

I am running VirtualBox 1.6.2 on a Mac OS X (Leopard) Host, and I get the same hang when booting 2.6.9-67.0.20.ELsmp (CentOS 4.6)). It gets to

Uncompressing Linux.... 0k, booting the kernel

And then never makes any further progress. The non-smp kernel works.

Replying to frank:

Is this problem still relevant?

I can also vouch that this problem is still happening using a fresh install of CentOS. My scenario is the same as "notadoctor" where he was installing 4.6.

Replying to ahmedis:

I did a clean install of a custom CentOS 4.4-based distro. When attempting to boot after the install using the SMP kernel the virtualbox VM hangs at "Uncompressing Linux ... Ok, booting the kernel" In order to boot I had to select the non-SMP kernel.

Hi,

I am using Mac OSX 10.5 On Intel, VirtualBox 1.6.2 Tried installing Oracle Enterprise Linux 2.6.9-67.0.0.0.ELsmp and I am having the same problem.

Is there a solution?

Hi

I'm using recent versions of everything and getting the same error as described above, namely cannot boot using "...ELsmp" kernel but can boot "...EL".

My setup is: PC with Intel Q6600 (Quad-core at 3.0GHz) Windows Vista SP1 32-bit host VirtualBox 1.6.4 Oracle Enterprise Linux 4 update 7 x86 (kernel 2.6.9-78 - from memory) guest

As for previous questions... any solutions, or any diagnostics I can provide?

Tim

Try enabling VT-x in the VM settings.

Also make sure you have enabled VT-x in the BIOS of your system. Should it fail again, please attach the VBox.log of the session.

OK. I've checked every screen in the BIOS and there is nowhere to enable VT-X. I've enabled in the VirtualBox preferences and for the particular VM.

I still get the same result. I'll attach the log

Tim

vbox.log with VT-X enabled in VirtualBox

Thanks for the log. Please could you check if VirtualBox 2.0.2 fixes your problem?

I tried 2.0.2 quickly on the same machine and get the same end result, i.e. it still hangs at the line "Uncompressing Linux... Ok, booting the kernel."

I thought it might help if I tried on another machine - so used the following: * AMD Turion TL-52, 2Gb Ram * Vista Home Premium * VirtualBox 2.0.2 * Oracle Enterprise Linux 4 update 7 (RedHat? 4 update 7)

However, the end result is the same: 1. booting "Enterprise (2.6.9-78.0.0.0.1.ELsmp)" fails with or without VT-x/AMD-V 2. booting "Enterprise-up (2.6.9-78.0.0.0.1.EL)" starts with or without VT-x/AMD-V

VirtualBox 2.0.2 Linux 2.6.9-78...ELsmp log with VT-x disabled

VirtualBox 2.0.2 Linux 2.6.9-78...ELsmp log with VT-x enabled

I am having this same issue. Host is Centos4.4, client is Centos4.7

CentOS (2.6.9-78.ELsmp) fails, CentOS-up (2.6.9-78.EL) works.

For now I will change my boot options in grub.

Mike

Hi all,

Same issue here. With a different configuration.
Host is Windows XP, client is RHEL4-UPD4.

RHEL ES (2.6.9-42.ELsmp) fails, RHEL ES-up (2.6.9-42.EL) works.

Regards,

--
Alex

Hit the same error, Host is Windows XP, client is RHEL4-UPD6.

Kernel 2.6.9-67.ELsmp keeps failing, 2.6.9-67.EL is working.

Same problem here with CentOS 4.6 and Virtual Box 2.1.2. Tried enabling VT-X (after installing CentOS, not before) but no joy.

Note: CentOS 5 works fine for me.

I'm having the same problem with RedHat? Enterprise Linux 4, (2.6.9-55.ELsmp)

Freezes after "Uncompressing Linux... Ok, booting the kernel."

Hyde -- how do you change between .ELsmp and EL versions??

When your system first starts Linux, there will normally be a GRUB box that pops up where you can switch between the two kernel versions. The default will be the SMP one, so you need to press the down arrow, within a few seconds when that pops up, in order to use the regular one.

In order to make that permanent, you'll need to edit /etc/grub.conf and change the "default" value. In a standard configuration you'll have "default=0", change that to "default=1" in order to make the non-SMP kernel that works the default one.

I just tested this all again myself recently against the latest VirtualBox, in the hopes that maybe this was fixed by some other change in the year this has been open. RHEL5/CentoOS5 works fine, as always. The SMP kernel for RHEL4/CentOS4 still won't boot, so no progress for this ticket.

I can confirm that changing to the non-SMP version works as gs1104 has described. A big THANK YOU for pointing this out.

Is this still an issue with VBox 3.0.4?

I have since switched to all my instances to using CentOS 5.3+, which work without issue. I'm afraid I don't have time to test it right now, sorry.

Replying to frank:

Is this still an issue with VBox 3.0.4?

Since the problem has survived many, many updates without change, I would be shocked if it just solved itself suddenly now. If you intend to try and resolve the issue if it's still there, I'll be glad to help with that starting by confirming it's still there. But if this is just another "did it fix itself?" request and no action will be taken if it's still broken, I'm not going to waste my time again to reproduce it just to watch nothing happen in response to that.

gs1104, there is no reason to insult me. No, I don't think that bugs fix themself. So far we were not able to reproduce the problem even if you don't believe that. It might be some difference we are not aware of. If you don't want to give the feedback then fine, but save your breath and keep comments like this for yourself. We do fixes to the VMM with almost every release and often it happens that one fix helps to fix a related problem which is not always obvious. We have a large amount of open bug reports and many users don't give feedback when a bug was fixed. When I ask if a bug is still reproducible then I see at least a chance that the bug is indeed fixed, otherwise I would auto close bugs after 8 weeks of inactivity, believe me.

Frank, I don't think gs1104 was trying to insult you, but at the same time I do agree that he's not being quite fair. The VirtualBox team has done a great job fixing many bugs which are, in retrospect, of significantly greater importance than this one. Just the fact that they would ask about it means they care and are working to support it.

gs1104: Frank & the VirtualBox team are clearly reaching out to the community for help in testing whether these bugs still exist. Given the cost of VirtualBox for us (FREE), they must have limited time / resources with which to test and therefore rely on us for feedback and validation.

Frank: Given the extent to which RHEL4 and its derivatives are being used in the marketplace, I believe this bug does deserve some looking into. I personally don't have time to try again but if there is anyone who can I'm sure it will be extremely beneficial.

I'll check

I'm hosting VirtualBox 3.0.4 on OS X Version 10.5.7. I am trying to guest CentOS 4.6 and it still hangs on boot. The non-smp version still works.

I was only pointing the easily observable fact that this bug has been open for years and we've never seen anything done with it. So far none of us who have reported or re-reported it have seen any feedback about it. Frank, I'm sorry you took that personally because I wasn't trying to single you out or be malicious, I know this is free software and there are other masters to serve in its production. But if you look at your past responses here for a minute, I think it was fair to point out that from this side, it looks like you poke this bug periodically to see if it went away, and if it hasn't nothing else happens. That's not really a good way to accumulate testers.

If the issue here is that you haven't been able to reproduce, as I said I'll be glad to help with that and any other debugging work I can to resolve this. But you have to tell us that's what's going on before we can help--if reproducibility was the sole reason it's still around, I could have been supplying you with logs etc. for years now. You might note I've already contributed more to this thread already than anyone else. I work on a lot of open source projects and am glad to help out whenever I can, but I only do that if I get the impression that someone is going to act on my feedback.

I have just installed the host software on CentOS5.3 with the latest updates as of Friday. Guest OS, RedHat? AS 4.3. Same problem, boot hangs after uncompressing kernel. I am able to boot if I select the non SMP kernel. Running VirtualBox GUI Ver 3.0.4 r50677

Some news: Looking at your VBox.log files I saw that you don't have PAE enabled for these VM. Note that the ELsmp kernel is compiled with CONFIG_HIGHMEM64G=y requiring PAE support! I just verified again that VBox 3.0.4 successfully boots this kernel in software virtualization mode as well as with VT-x enabled (the latter with 2 guest CPUs enabled here).

If you ask why the guest does not complain about the missing PAE support: I would denote this as a bug of that kernel.

Closing as it works here and I assume that all of you did not enable PAE for this kernel. Note that with more than one guest CPUs enabled, the guest might boot slower than with one CPU guest CPU. There are fixes pending for this issue and it is not related to the problem described in this subject.

It's fair to say there's a kernel bug here that should have kicked out the configuration as incompatible, for example in Ubuntu kernels that require it if PAE is missing it produces an error. I doubt that requesting such a check is going to make it very far against RHEL's pretty old V4 kernel at this point.

I just tested against an older VirtualBox install still running 2.1.4, and enabling PAE is all it took to fix the problem on that earlier version too. Since PAE support wasn't available yet when this bug was originally reported (it showed up in 1.6 and the original reports were against 1.5.4), that explains why I didn't find this workaround back then.

Thanks for taking a look at the logs to figure out what was going on here. I know PAE support was listed as experimental for a while there, but now it's been available in VirtualBox for so long I have to wonder why it's not enabled by default yet, to make this class of problem go away. If that's not practical for reasons I just don't know, it might be handy to update the note in the manual that reads "Some operating systems (such as Ubuntu Server) require PAE support from the CPU and cannot be run in a virtual machine without it" to also mention RHEL/CentOS 4.

You are right, PAE was experimental until some releases ago but it should be stable now. We are currently thinking about enabling it by default on all hosts supporting this mode. There might be still performance issues, that is, the (virtual) PAE mode might be slower (or even faster) than non-PAE, we have to check this. Some guests can run in both PAE and non-PAE mode (e.g. Windows) and therefore it could make sense to carefully check if PAE should be made available or not.