Red Hat Bugzilla – Bug 169157
2.6.12-1.1456_FC4xen0 fails to boot (2nd Case)
Last modified: 2007-11-30 17:11:14 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Description of problem:
I apologize if this should not be a different bug report (it is very similiar to Bug# 168048, I know), however, I am using an even later build than those posted by Rik, -1.1454 I believe. So I thought I'd play it safe. Additionally, the previous poster seems to get further in the process than I do.
The initial reboot of the system after installing the Xen kernel does not complete. The loading process appears to encounter an error right after scrubbing free memory, and a reboot is initiated. This process just continues in a loop of rebooting.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Fresh download, "Server" install of FC4. Iso's from http://download.fedora.redhat.com/pub/fedora/linux/core/4/i386/iso/
2. Modify /mnt/etc/selinux/config so that SELINUX=disabled
3. yum install xen
4. yun install kernel-xen0 kernel-xenU
5. Modify /boot/grub/grub.conf so that default=0
6. Shutdown -r now
Actual Results: Upon the initial reboot after installing xen and initial GRUB configuration, xen starts to load, gets as far as the line that says "Scrubbing Free memory....".
As soon as this finishes, it barfs, and prints what looks like a bunch of stack info lines, all beginning with "(XEN)", and then hangs on a message saying Domain0 shutting down, and then that a manual reboot is necessary.
If I add the "noreboot" to xen's params (to give time to read output), the same situation occurs but it just hangs/freezes after printing the "Scrubbing Free.... Done." line.
Expected Results: I would assume that the xen0 finishes loading and then passes loading to the linux kernel. It never gets this far.
Grub.conf contents (contains version numbers, params, etc.):
# grub.conf generated by anaconda
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
# initrd /initrd-version.img
title Fedora Core (2.6.12-1.1456_FC4xen0)
kernel /xen.gz noreboot
module /vmlinuz-2.6.12-1.1456_FC4xen0 ro root=/dev/VolGroup00/LogVol00
title Fedora Core (2.6.11-1.1369_FC4smp)
kernel /vmlinuz-2.6.11-1.1369_FC4smp ro root=/dev/VolGroup00/LogVol00
title Fedora Core-up (2.6.11-1.1369_FC4)
kernel /vmlinuz-2.6.11-1.1369_FC4 ro root=/dev/VolGroup00/LogVol00
Hi, i'd like to pitch in and say that I've just undergone an update to
kernel-xen0-2.6.12-1.1456 and am experiencing exactly the same problem as you.
I was running a perfectly successful 1398 kernel before the update. What really
baffled me was that even trying to boot the 1398 kernel no longer works now. It
had been working for a quite a while before that...rock solid!
I havn't got a clue what's been affected by the upgrade but I will check back if
I find anything out.
Hi, Jon here again...been having a dig around and removed xen-2-20050823,
replaced it with xen-2-20050522 (base package) and was able to boot the xen0
I made sure there was no xen.gz before i reinstalled the old version. xen.gz was
created by this older package so maybe it's something to do with this image.
To recap then...it seems as if this problem is related to the installation of
the updated xen package rather than the kernel or initrd, maybe more
specifically the xen.gz that is provided.
I'm just going to set up my virtual machines and let you know how I get on.
Hi again, another update...the trick of using the xen base package only works
with kernel 1398 xen0 on my system instead of the latest xen0 kernel so you'll
have to track back with kernel versions to see which ones work with the xen base
Watch this space...
Just got all my virtual servers up and running ok. Kernel-xen0-2.6.12-1.1398
xen-2-20050522. Ones before 1456 and above mine may work but I havn't checked yet!
Check back soon...
I am having this exact same issue using a fresh install of FC4 which I built
yesterday for the purpose of testing xen. This is with the 2.6.12-1.1456xen0
kernel as well.
I feel, that I have exactly the same Problem.
I have a vanilla Install of FC4, and after an "up2date".
After installing and configuring Xen, I runn into a loop of booting.
title Fedora Core (2.6.12-1.1456_FC4xen0)
module /vmlinuz-2.6.12-1.1456_FC4xen0 ro root=/dev/VolGroup00/LV_ROOT init 3
-- I've never tested XEN before "up2date" ---
I have tested xen-3.0-0.20050912.fc4.i386.rpm down loaded from
http://people.redhat.com/riel with kernel at 1456 level. The
kernel at 1454 level packed with xen-3.0 just did not boot at all. xen-3.0
solved this problem in any way but runs too slow and boot of xen0 kernel stopes
at starting ntpd.
So, the symptom has been changed but xen0 does not complete booting.
I think the summary should be updated to reflect the fact the relevant kernel is
2.6.12-1.1456_FC4xen0 and not 2.6.12-1.1447_FC4xen0. I am also suffering from
this bug, but only under 1456.
I completely agree- I apologize for that. It was definitely a typo, I (the
original poster) am also dealing with 1456. I don't know where I got 1447,
probably from reading the other bug report.
I myself have been tied up in other projects, and have not yet had a chance to
continue work on my Xen problem, but hope to soon. I will post any developments.
Have we yet heard anything from one of the (Redhat/Xen/Fedora)developers yet?
I've managed to boot successfully using 1456 in FC4 and this Xen RPM:
1447 was working for me but no later packages
But I have now booted off the packages here (can't tell whether it is slow or
not as another comment reported):
Whereas I could not from the yum installed 12-1.1456 and the new 13-1.1526
This problem occours also with the latest kernel (kernel-xen0-2.6.13-1.1526_FC4)
installed; maybe the console's output can give you some more info (note that
also with the kernel option dom0_mem set to 262144 the result is the same)
_ __ _____ ___ _ _
\ \/ /___ _ __ |___ / / _ \ __| | _____ _____| |
\ // _ \ '_ \ |_ \| | | |__ / _` |/ _ \ \ / / _ \ |
/ \ __/ | | | ___) | |_| |__| (_| | __/\ V / __/ |
/_/\_\___|_| |_| |____(_)___/ \__,_|\___| \_/ \___|_|
University of Cambridge Computer Laboratory
Xen version 3.0-devel (email@example.com) (gcc version 4.0.1 20050727
(Red Hat 4.0.1-5)) Tue Aug 23 14:57:59 EDT 2005
(XEN) Physical RAM map:
(XEN) 0000000000000000 - 00000000000a0000 (usable)
(XEN) 00000000000f0000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 000000004ffe0000 (usable)
(XEN) 000000004ffe0000 - 000000004ffe8000 (ACPI data)
(XEN) 000000004ffe8000 - 000000004fff0000 (ACPI NVS)
(XEN) 000000004fff0000 - 0000000050000000 (reserved)
(XEN) 00000000fec00000 - 0000000100000000 (reserved)
(XEN) System RAM: 1279MB (1310208kB)
(XEN) Xen heap: 10MB (10632kB)
(XEN) PAE disabled.
(XEN) found SMP MP-table at 000fb280
(XEN) DMI 2.3 present.
(XEN) Using APIC driver default
(XEN) ACPI: RSDP (v000 IBM ) @ 0x000fe030
(XEN) ACPI: RSDT (v001 IBM M51SL 0x00000001 IBM 0x00000000) @ 0x4ffe0000
(XEN) ACPI: FADT (v001 IBM M51SL 0x00000001 IBM 0x00000000) @ 0x4ffe014b
(XEN) ACPI: ASF! (v016 IBM 0x01000000 0x00000000) @ 0x4ffe0030
(XEN) ACPI: MADT (v001 IBM M51SL 0x00000001 IBM 0x00000000) @ 0x4ffe00e3
(XEN) ACPI: DSDT (v001 IBM M51SL 0x00001000 MSFT 0x0100000d) @ 0x00000000
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 15:2 APIC version 20
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base)
(XEN) IOAPIC: apic_id 1, version 17, address 0xfec00000, GSI 0-15
(XEN) ACPI: IOAPIC (id[0x02] address[0xfec01000] gsi_base)
(XEN) IOAPIC: apic_id 2, version 17, address 0xfec01000, GSI 16-31
(XEN) ACPI: IOAPIC (id[0x03] address[0xfec02000] gsi_base)
(XEN) IOAPIC: apic_id 3, version 17, address 0xfec02000, GSI 32-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) Enabling APIC mode: Flat. Using 3 I/O APICs
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) Initializing CPU#0
(XEN) Detected 1999.848 MHz processor.
(XEN) Using scheduler: Simple EDF Scheduler (sedf)
(XEN) CPU: Trace cache: 12K uops, L1 D cache: 8K
(XEN) CPU: L2 cache: 512K
(XEN) CPU: Hyper-Threading is disabled
(XEN) CPU0: Intel(R) Pentium(R) 4 CPU 2.00GHz stepping 07
(XEN) Total of 1 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN) ..TIMER: vector=0x31 pin1=2 pin2=-1
(XEN) ..MP-BIOS bug: 8254 timer not connected to IO-APIC
(XEN) ...trying to set up timer (IRQ0) through the 8259A ... failed.
(XEN) ...trying to set up timer as Virtual Wire IRQ... works.
(XEN) Platform timer is 1.193MHz PIT
(XEN) Brought up 1 CPUs
(XEN) mtrr: v2.0 (20020519)
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Xen-ELF header found:
(XEN) Panic on CPU 0:
(XEN) Domain 0 allocation is too small for kernel image.
(XEN) Reboot in five seconds...
(XEN) Reboot disabled on cmdline: require manual reset
Same with Dell PE 850 and PE 2650. No amount of memory is enough but some is too
much. Tried also with
but no boot. Kernel: kernel-xen0-2.6.13-1.1526_FC4.
So, I guess I have to try with kernel <=1456...
Also having issues with this version, previous version caused a hang while
loading dom0 kernel image, right after ide detect phase. Hardware is AMD
Thunderbird, whitebox VIA chipset mb.
none of the kernels/xen combinations boote for me, except xen-unstable daily
snaps from their website itself.
However, I just tried riel's combination of xen and kernel rpms and they work
for me as well!
I have tried to install the xen from the unstable source on 1456 kernel and have
succeded to boot up xen0 but have some difficulty to bring up xenU. It seems the
problem is not in the kernel but xen it self.
I have since been able to successfully boot using the rpms from Rik's webpage.
I get the 'too small for kernel image' with Rik's test Xen package and with the
latest FC4 update kernel:
# rpm -q xen
# rpm -q kernel-xen0
22.214.171.124-1454_FC4 is from Rik's test RPMs and works. 1.1526 is the latest FC4
update and gives the dreaded error:
(XEN) Panic on CPU 0:
(XEN) Domain 0 allocation is too small for kernel image.
Same problem on our IBM Netfinity servers.
(In reply to comment #18)
> I get the 'too small for kernel image' with Rik's test Xen package and with
> latest FC4 update kernel:
> # rpm -q xen
> # rpm -q kernel-xen0
> 1.1526 is the latest FC4
> update and gives the dreaded error:
> (XEN) Panic on CPU
> (XEN) Domain 0 allocation is too small for kernel
> (XEN) ****************************************
(In reply to comment #16)
> I have tried to install the xen from the unstable source on 1456 kernel and have
> succeded to boot up xen0 but have some difficulty to bring up xenU. It seems the
> problem is not in the kernel but xen it self.
I finally succeded to bring up xenU and now running fine though, the point is
the kernels for xen0 and xenU are 2.6.12. I am interested in what happens if I
use the latest unstable xen with 1456 xen0 and xenU. It will be truble some
work to install though, I will try tomorrow.
(In reply to comment #20)
> (In reply to comment #16)
> > I have tried to install the xen from the unstable source on 1456 kernel and have
> > succeded to boot up xen0 but have some difficulty to bring up xenU. It seems the
> > problem is not in the kernel but xen it self.
> I finally succeded to bring up xenU and now running fine though, the point is
> the kernels for xen0 and xenU are 2.6.12. I am interested in what happens if I
> use the latest unstable xen with 1456 xen0 and xenU. It will be truble some
> work to install though, I will try tomorrow.
I have tried above configuration. The conclusion is, the kernel is the cause of
With the latest unstable xen.gz, I have tried 1456 kernel and 1526 for the xen0
kernel. The result were the same as #12 in this thread. Only the 2.6.12 kernel
runs fine but higher. I have tried Rik's xen kernel also with the same fault.
It seems the patchs for the kernel are not complete for xen.
For walkarownd, use Fedora core 4 base level or compile xen from the source so
far if you really need xen to run on your machine. I took the later one even
though the kernel down grade occures. It runs fine so far.
Same problem with kernel-xen0-2.6.13-1.1526_FC4 on Microtel computer with 3GHz
This problem still exists for all the 2.6.13 update released kernels. "Domain 0
allocation is too small for kernel image." Tested on builds 1524, 1526, and
1532. Last working kernel for me (after the xen update from Rik) was 2.6.12-1.1456.
This bug has been fixed in Fedora Core 5 rawhide Xen images.