Bug#627169: Keepalived To-header patch
Hello, I noticed this same problem, and I wrote a patch for keepalived to implement To-header. The patch is here: http://sourceforge.net/mailarchive/attachment.php?list_name=keepalived-develmessage_id=20120928122744.GR8912%40reaktio.netcounter=1 And the keepalived-devel mailinglist thread about the patch/feature: http://sourceforge.net/mailarchive/forum.php?thread_name=20130124075242.GI8912%40reaktio.netforum_name=keepalived-devel -- Pasi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695056: [Xen-devel] [Pkg-xen-devel] Bug#695056: xen - Missing support for XZ compressed bzimage kernels
On Tue, Dec 04, 2012 at 10:12:16AM +, Ian Campbell wrote: On Tue, 2012-12-04 at 09:51 +, Jan Beulich wrote: On 04.12.12 at 10:33, Ian Campbell i...@hellion.org.uk wrote: On Mon, 2012-12-03 at 19:47 +0100, Bastian Blank wrote: Package: src:xen Version: 4.1.3-4 Severity: serious The bzimage loader used in both libxc and the hypervisor lacks XZ support. Debian kernels since 3.6 are compressed with XZ and can't be loaded. Support for XZ compression was added in changeset 23002:eb64b8f8eebb somewhere last year. Indeed. Jan this would be a good candidate for a future 4.1.x I think (it was already in 4.2.0). Hmm, I'm not really convinced - we're at 4.1.4 (I'm looking towards an RC2 followed by a release within the next days), and doing a feature addition like this in a .5 stable release looks questionable to me in the context of how we managed stable updates in the past. But I'm open to be outvoted of course... My thinking was that it is a reasonably self contained patch (most of the code is the new files) and without it people won't be able to use 4.1.x with their distro kernels at all, so it's something between a bug fix and a new feature. If distros are going to be backporting it anyway they may as well all get it from us. +1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657014: [Pkg-xen-devel] Bug#657014: Bug#657014: Wheezy, Squeeze and Ubuntu server 11.10 has missing boot option to Xen
On Mon, Jan 23, 2012 at 06:26:29PM +0100, Erik Hjelmås wrote: When installing xen-linux-system on a new Dell R810 server, Wheezy, Squeeze and Ubuntu server 11.10 all boot fine when booted directly into the standard kernel, but when booting through Xen (after installing the package xen-linux-system) the boot process hangs as soon as Xen passes control to the Dom0 kernel: Gave up waiting for root device etc and it gives me Busybox, but it is also frozen, so there's no other option that reboot. This might be the same issue as #649923. But please could you provide full console logs so we can verify. If you are able to try the patch in that bug or perhaps a backported 4.1 hypervisor that would also be potentially interesting. its the same behaviour on both squeeze (4.0) and wheezy (4.1) since everything freezes on boot, I dont have any logs other than the attached screenshot at the time it freezes (or is something logged this early in the boot process by Xen? I can reboot without Xen and inspect other logs) Please set up a serial console so you can capture the full boot messages from both Xen hypervisor and dom0 kernel. In your case you can also use the SOL (Serial Over LAN), provided by the iDRAC management processor. http://wiki.xen.org/xenwiki/XenSerialConsole After several days of troubleshooting it turns out that adding dom0_mem option (e.g. dom0_mem=8192M) to the multiboot line of /etc/grub.d/20_linux_xen FIXES THE PROBLEM ! maybe this has to be fixed in the package? That file is provided by grub, not the hypervisor but I don't think that fix will work since a) really it is a workaround not a fix and b) it is not really possible to determine what is the right number to use for any given system. I agree, my solution is a workaround and not at fix I first suspected that there was a problem with the initramfs so I added the megasas driver to /etc/initramfs/modules and updated initramfs. This resulted in a Cannot allocate memory error (when trying to load the megasas driver) at the same stage in the boot process. And since Busybox is not able to run either, Xen seems to not give any memory available to the Dom0 kernel when it passes control to it in the boot process. Meaning the Dom0 kernel fails immediately since I guess accessing the root devices is one of the first things it tries to do. I will attempt install squeeze and wheezy on a different older server (Dell R900), during the next couple of days to see of the same error pops up, and Ill look for more log data then , I assume you have already installed all the latest BIOS/firmware updates etc? -- Pasi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628912: [Pkg-xen-devel] Bug#628912: Bug#628912: Bug#628912: xenconsoled and xenstored stopping unhandled by init script
On Sun, Dec 11, 2011 at 01:12:58PM +, Ian Campbell wrote: I thought xenconsoled was restartable, the upstream init scripts certainly do so. Yes, xenconsoled is restartable. (And earlier you even had to restart it every now and then, because it had a bug where it got stuck and thus also made PV domUs stuck waiting for domU console output). -- Pasi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640500: [Pkg-xen-devel] Bug#640500: Bug#640500: xen-hypervisor-4.0-amd64: xend invokes oomkiller and reboots machine when creating DomU's
On Tue, Sep 06, 2011 at 12:54:32AM +0800, Thomas Goirand wrote: That means 8704 MB of memory is used. Over the last couple of days, I've experienced that when creating two VM's with 512 MB RAM, the oom-killer is invoked. This should not happen because Dom0 can shrink and because the machine should not restart when it is out of memory. This is a production Xen host, which is becomming a liability, because it's so unpredictable. Current Dom0 kernel: Linux arbiter 2.6.32-5-xen-amd64 Hi, I wouldn't recommend to just let your dom0 shrink. Set it directly to a much lower memory footprint, something like 512 MB of RAM, so that the Linux kernel sees directly that it doesn't have so much memory to deal with, and it will not allocate too big buffers and so on. Here's how to do this with the Squeeze grub: echo # Start dom0 with less RAM GRUB_CMDLINE_XEN_DEFAULT=\dom0_mem=512M\ /etc/default/grub Then either run update-grub2 or dpkg-reconfigure grub-pc (and of course reboot...). If you do that, I'm sure your troubles will go away. You shouldn't be running big software in the dom0 anyway. I always done that because of habits from running older Xen (since 2.0.7), and because I've seen issues with the dom0 ballooning out. To me, ballooning the memory of dom0 is more a desktop feature than for a server. I believe this bug should be closed, because that's not really an issue with Xen (but more with the way the Linux dom0 kernel works). I'll let Bastian decide though. Thomas Goirand (zigo) Related link / dom0_mem: http://wiki.xen.org/xenwiki/XenBestPractices -- Pasi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636594: [Pkg-xen-devel] Bug#636594: Acknowledgement (xen: VM restarting too fast. Refusing to restart to avoid loops.)
On Thu, Aug 04, 2011 at 04:34:04PM +0400, ?? wrote: By the way seems to me problem independs from kernel. I've installed 2.6.39 kernel and tried to start domain with xl create and it is the same problem. When i try to start domain with xm i get error: Error: Device 768 (vbd) could not be connected. Path closed or removed during hotplug add: backend/vbd/2/768 state: 1 Upstream Linux 2.6.39 kernel does NOT yet have xen-blkback driver! On 3.0.0 with xm i don't see such error. It works like xl. .. and Linux 3.0.0 adds xen-blkback, so that's why it works with 3.0.0. More info here: http://wiki.xen.org/xenwiki/XenParavirtOps And: http://wiki.xensource.com/xenwiki/Linux_30_bugs And: http://wiki.xen.org/xenwiki/XenCommonProblems -- Pasi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608253: [Pkg-xen-devel] Release notes addition for Xen support in Debian
On Thu, Dec 30, 2010 at 12:40:32AM +0800, Thomas Goirand wrote: Thanks. Indeed, there was some possible confusion. Patched accordingly. Please find the new patch attached to this email. See below for one more comment.. Thomas Goirand (zigo) --- release-notes/en/upgrading.dbk.orig 2010-12-29 17:15:03.0 +0800 +++ release-notes/en/upgrading.dbk2010-12-30 00:37:17.0 +0800 @@ -1349,6 +1349,32 @@ /para /section +section id=xen-upgrades +titleXen upgrades/title +para +If you installed Xen on Lenny, the kernel booted by grub-legacy per +default was the one providing a Xen hypervisor and dom0 support. This +behavior changed with GRUB 2 in Squeeze: the non-Xen kernel will +boot per default. If you need Xen and expect to boot with it by default, +find further configuration hints at: +http://wiki.debian.org/Xen#Installationandconfiguration +/para +para +Upgrades from Lenny will not automatically install Xen version 4.0. Instead +you need to install Xen 4.0 and a corresponding dom0 kernel explicitly. See +the wiki page for instructions on how to set up the Xen hypervisor and dom0 +kernel under Squeeze. +/para +para +Be aware that, if you run a pvops kernel for your domU, like the Xen kernel +2.6.32 of Squeeze, your domU won't be able to use (for example) sda1 as a +device name for its hard drive. This naming scheme has been removed from Xen +upon request of the mainline kernel maintainers. Instead you should use (as +a corresponding example) xvda1, which will always work, including when running +Lenny 2.6.26 forward ported Xen patch. +/para +/section Actually the sd* naming hasn't been removed from *Xen* itself, just from the pvops (upstream kernel.org) Linux kernel xen-blkfront driver! -- Pasi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586772: [Pkg-xen-devel] Bug#586772: xen-utils-4.0: No block tap backends available
On Wed, Oct 20, 2010 at 03:26:11PM -0400, Keith Russell wrote: Package: xen-utils-4.0 Version: 4.0.1-1 Severity: normal Due to license issues this version of Xen does not include the blktap2 backend (tapdisk2) and associated utilities (vhd-util, etc.). The decision was made to disable the blktap v1 kernel module (the default is now blktap2). As a result we can't use any tap devices which means worse performance than previousl. Since blktap1 was available in lenny this could be looked on as a regression. Please consider either adding blktap2 or reinstating the blktap1 kernel module. I thought there was no real licensing issue. I recall some patches on xen-devel about that. -- Pasi -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-xen-686 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xen-utils-4.0 depends on: ii e2fslibs1.41.12-2ext2/ext3/ext4 file system librari ii iproute 20100519-3 networking and traffic control too ii libc6 2.11.2-6 Embedded GNU C Library: Shared lib ii libncurses5 5.7+20100313-4 shared libraries for terminal hand ii libxenstore3.0 4.0.1-1 Xenstore communications library fo ii python-support 1.0.10 automated rebuilding support for P ii python2.5 2.5.5-8 An interactive high-level object-o ii udev163-1/dev/ and hotplug management daemo ii xen-utils-common4.0.0-1 XEN administrative tools - common ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages xen-utils-4.0 recommends: ii bridge-utils 1.4-5 Utilities for configuring the Linu ii libc6-xen 2.11.2-6 Embedded GNU C Library: Shared lib ii xen-hypervisor-4.0-i386 [xen- 4.0.1-1The Xen Hypervisor on i386 Versions of packages xen-utils-4.0 suggests: pn xen-docs-4.0 none (no description available) -- no debconf information ___ Pkg-xen-devel mailing list pkg-xen-de...@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-xen-devel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600241: [Pkg-xen-devel] Bug#600241: Xen Hypervisor can only boot if acpi=off parameter is used.
On Thu, Oct 14, 2010 at 06:41:20PM -0300, Daniel Requena wrote:
Package: xen-hypervisor-4.0-amd64
Version: 4.0.1-1
Hardware specs:
Dell PowerEdge R410
32GB RAM DDR3
1TB RAID-1 HD (Perc H200 RAID controller)
Processor: 2 - Intel XeonE5620 2.4Ghz 12M Cache Turbo HT 1066MHz
SO: Debian Squeeze
last update: 14/10/2010
uname -a: Linux spo-r1-u4 2.6.32-5-xen-amd64 #1 SMP Fri Sep 17 22:00:48
UTC 2010 x86_64 GNU/Linux
At boot, xen-hypervisor is loaded normally, but when it tries to load
linux kernel it freezes. There is no screen output and after a few
seconds, the server reboots.
However, the problem doesn't happen if acpi=off parameter is used on
grub xen-hypervisor entry OR if the virtualization flags are disabled on
the BIOS.
Using the acpi=off parameters Xen is not able to detect the 16 cores
(8 fisical with hyperthread), only 8 cores. If the virtualization flags
are disabled all the 16 cores are detect.
You should use a serial console (or SOL) and capture the full boot messages
(and errors) from Xen and from dom0 Linux kernel.
Use These options for Xen hypervisor (xen.gz):
dom0_mem=1024M loglvl=all guest_loglvl=all sync_console console_to_ring
com1=115200,8n1 console=com1 lapic=debug apic_verbosity=debug apic=debug
iommu=off
Fix the com1 stuff to match your serial/SOL setup.
And these parameters for the dom0 Linux kernel (vmlinuz):
console=hvc0 earlyprintk=xen nomodeset initcall_debug debug loglevel=10
For more information:
http://wiki.xensource.com/xenwiki/XenSerialConsole
-- Pasi
Xen grub entry:
menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-xen-amd64 and XEN
4.0-amd64' --class debian --class gnu-linux --class gnu --class os
--class xen {
insmod part_msdos
insmod ext2
set root='(hd0,msdos2)'
search --no-floppy --fs-uuid --set 935213fd-c3c6-49ad-b818-a3b67704c585
echo'Loading Linux 2.6.32-5-xen-amd64 ...'
multiboot/xen-4.0-amd64.gz placeholder acpi=off module
/vmlinuz-2.6.32-5-xen-amd64 placeholder root=/dev/mapper/main-root ro
quiet
echo'Loading initial ramdisk ...'
module/initrd.img-2.6.32-5-xen-amd64
}
___
Pkg-xen-devel mailing list
pkg-xen-de...@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-xen-devel
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595490: [Pkg-xen-devel] Bug#595490: [xen-hypervisor-4.0-i386] Booting up the Xen Dom0 fails with an error in i387.c:159.
On Fri, Sep 10, 2010 at 03:30:48PM +0300, Alex Morega wrote: I get the same error, with versions 4.0.1~rc5-1, 4.0.1~rc6-1 and 4.0.1-1 of xen-hypervisor-4.0-amd64. I'd like to provide a more complete log dump but I don't know how. So you need to set up a serial console to get the console dump. General instructions: http://wiki.xensource.com/xenwiki/XenSerialConsole pvops dom0 specific: http://wiki.xensource.com/xenwiki/XenParavirtOps Please paste your current grub.conf/grub.cfg so we can verify it's ok. -- Pasi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571634: [Pkg-xen-devel] Bug#571634: bridge loosing connection
On Mon, Sep 06, 2010 at 10:31:28AM +0200, Jochen Demmer wrote: Hi, I'm not sure but I think I suffer under the same problem with a bit different setup with squeeze testing and xen 4.0rc5. In fact I'm using bridges in the dom0 and the connections to the domU get lost sporadically. In don't see where's a solution to the problem... Is it now a bug? When it's an iptables bug, where's the corresponding bug in the iptables bugtracker and what exactly is iptables doing wrong. You stated ...but as the syslog message clearly indicates this rule works perfectly when the traffic is bridged. I'm using bridges but it's not working obviously. I don't really see any errors in the log below. Have you tried using different kernel in the domU? If network is fine from dom0, then this sounds like a bug in the domU kernel. What kernel are you running in the domU? -- Pasi /etc/network/interfaces auto br0 allow-hotplug br0 iface br0 inet static address 10.100.200.20 netmask 255.255.255.0 dns-nameservers 10.100.200.3 gateway 10.100.200.3 bridge_ports eth0 allow-hotplug br1 auto br1 iface br1 inet manual bridge_ports eth1 This is my logs: Sep 6 09:47:14 elise kernel: [71970.564974] br1: port 2(vif1.1) entering disabled state Sep 6 09:47:14 elise kernel: [71970.578040] br1: port 2(vif1.1) entering disabled state Sep 6 09:47:14 elise kernel: [71970.718785] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. Sep 6 09:47:14 elise kernel: [71970.718797] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. Sep 6 09:47:14 elise kernel: [71970.718803] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. Sep 6 09:47:14 elise kernel: [71970.724864] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. Sep 6 09:47:14 elise kernel: [71970.724874] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. Sep 6 09:47:15 elise kernel: [71970.871846] br0: port 2(vif1.0) entering disabled state Sep 6 09:47:15 elise kernel: [71970.890073] br0: port 2(vif1.0) entering disabled state Sep 6 09:47:15 elise kernel: [71971.010275] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. Sep 6 09:47:15 elise kernel: [71971.010286] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. Sep 6 09:47:15 elise kernel: [71971.016391] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. Sep 6 09:47:17 elise kernel: [71972.912040] device vif3.0 entered promiscuous mode Sep 6 09:47:17 elise kernel: [71972.915898] br0: port 2(vif3.0) entering learning state Sep 6 09:47:17 elise kernel: [71972.948656] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. Sep 6 09:47:17 elise kernel: [71972.953266] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. Sep 6 09:47:17 elise kernel: [71972.953273] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. Sep 6 09:47:17 elise kernel: [71972.986255] device vif3.1 entered promiscuous mode Sep 6 09:47:17 elise kernel: [71972.990441] br1: port 2(vif3.1) entering learning state Sep 6 09:47:17 elise kernel: [71973.011096] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. Sep 6 09:47:17 elise kernel: [71973.011102] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. Sep 6 09:47:17 elise kernel: [71973.016383] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. Sep 6 09:47:17 elise kernel: [71973.016392] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. Sep 6 09:47:17 elise kernel: [71973.016398] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is
Bug#573210: [Pkg-xen-devel] Bug#573210: xen-hypervisor-3.2-1-amd64: Xen domU sometimes hogs CPU and doesn't respond
On Tue, Mar 09, 2010 at 08:18:54PM +0100, Ondrej Kunc wrote: Package: xen-hypervisor-3.2-1-amd64 Version: 3.2.1-2 Severity: normal *** Please type your report below this line *** Hi, Recently I've experienced some crashes of Xen domU (also debian Lenny, running same kernel as dom0 (linux-image-2.6.26-xen-amd64)). At xm top that domain appears as running, but hogs all CPUs, because this problem has appeared on two identic servers (Supermicro X7SBi, QC Xeon, 8G DDR II). I think that problem cannot be in hardware. We were running this configuration on some other servers with core2 duo processor (only dualcore) and there this problem never appeared. I've saved a core-dump of affected domU, but it's really big(1,1GB), so I'll not attach it to bugreport, but it is available for debugging. Thanks for potential interest in debugging. Hello, It's this problem: http://moblog.wiredwings.com/index.php?url=archives/20090227/Lennys-Xen-Kernel-2.6.26-Causes-DomU-Freezes.html I tried getting debug info (stack traces) of the crashed guest here: http://lists.xensource.com/archives/html/xen-devel/2010-03/msg00281.html but it'd need more investigations and actual debugging.. -- Pasi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573210: [Pkg-xen-devel] Bug#573210: Bug#573210: xen-hypervisor-3.2-1-amd64: Xen domU sometimes hogs CPU and doesn't respond
On Thu, Mar 11, 2010 at 11:21:28PM +0200, Pasi Kärkkäinen wrote: On Tue, Mar 09, 2010 at 08:18:54PM +0100, Ondrej Kunc wrote: Package: xen-hypervisor-3.2-1-amd64 Version: 3.2.1-2 Severity: normal *** Please type your report below this line *** Hi, Recently I've experienced some crashes of Xen domU (also debian Lenny, running same kernel as dom0 (linux-image-2.6.26-xen-amd64)). At xm top that domain appears as running, but hogs all CPUs, because this problem has appeared on two identic servers (Supermicro X7SBi, QC Xeon, 8G DDR II). I think that problem cannot be in hardware. We were running this configuration on some other servers with core2 duo processor (only dualcore) and there this problem never appeared. I've saved a core-dump of affected domU, but it's really big(1,1GB), so I'll not attach it to bugreport, but it is available for debugging. Thanks for potential interest in debugging. Hello, It's this problem: http://moblog.wiredwings.com/index.php?url=archives/20090227/Lennys-Xen-Kernel-2.6.26-Causes-DomU-Freezes.html I tried getting debug info (stack traces) of the crashed guest here: http://lists.xensource.com/archives/html/xen-devel/2010-03/msg00281.html but it'd need more investigations and actual debugging.. Btw the workaround should be to use only a single vcpu per each guest.. Having multiple vcpus for the domU running the 2.6.26-2-xen kernel causes problems. -- Pasi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566012: [Pkg-xen-devel] Bug#566012: xen-hypervisor-3.2-1-i386: Another crash. Is this a hypervisor-problem, or is this the kernel?
On Mon, Jan 25, 2010 at 09:14:48AM +0100, Vincent van Adrighem wrote: Package: xen-hypervisor-3.2-1-i386 Version: 3.2.1-2 Followup-For: Bug #566012 Just had another crash. I got the output from a serial console. The kernel doesn't say anything though. You could try two things: - Update the Xen hypervisor, but keep the same dom0 kernel - Update the dom0 kernel, but keep the same hypervisor To find out where the bug is.. Btw do you have dom0_mem= option set for xen.gz in grub.conf? -- Pasi (XEN) traps.c:1996:d6 Domain attempted WRMSR 0400 from : to :. (XEN) traps.c:1996:d6 Domain attempted WRMSR 0404 from :00018000 to :. (XEN) traps.c:1996:d6 Domain attempted WRMSR 0408 from :0080 to :. (XEN) traps.c:1996:d6 Domain attempted WRMSR 040c from :007e to :. (XEN) domain.c:586:d6 Attempt to change CR4 flags 0660 - 0620 (XEN) traps.c:1996:d6 Domain attempted WRMSR 0400 from : to :. (XEN) traps.c:1996:d6 Domain attempted WRMSR 0404 from :00018000 to :. (XEN) traps.c:1996:d6 Domain attempted WRMSR 0408 from :0080 to :. (XEN) traps.c:1996:d6 Domain attempted WRMSR 040c from :007e to :. (XEN) traps.c:1996:d6 Domain attempted WRMSR 0400 from : to :. (XEN) domain_crash_sync called from entry.S (ff188600) (XEN) Domain 0 (vcpu#0) crashed on cpu#0: (XEN) [ Xen-3.2-1 x86_32p debug=n Not tainted ] (XEN) CPU:0 (XEN) EIP:0061:[c01013a7] (XEN) EFLAGS: 0246 CONTEXT: guest (XEN) eax: ebx: 0001 ecx: edx: c0389fc8 (XEN) esi: edi: ebp: esp: c0389fbc (XEN) cr0: 8005003b cr4: 06f0 cr3: 00be0ca0 cr2: b7f1fd10 (XEN) ds: 007b es: 007b fs: 00d8 gs: ss: 0069 cs: 0061 (XEN) Guest stack trace from esp=c0389fbc: (XEN)c0105f52 c04ea8c2 2270 0020 (XEN)c01028ab c0102810 0020 c14b5000 c038f88b c03ac580 00020800 (XEN) c038f5c3 c038f5cb c038f5d3 c0102374 c010263c c01027c8 c0102981 (XEN)c0102fd7 c0102ff8 c0103480 c0103520 c0103609 c0103a81 c0103b3d c0103bfa (XEN)c0103c59 c0103d03 c01042f9 c010430c c0104332 c010433f c01043db c0104999 (XEN)c0104a5c c010506c c01050ec c01051bc c0105ebf c0105eff c0105f58 c0106238 (XEN)c0106323 c010664a c0106a80 c0106be4 c039453d c0394546 c0108085 c0108093 (XEN)c0108108 c0108116 c0395faf c0395fc2 c01085ef c0108679 c010934c c0109547 (XEN)c0109572 c010957b c010985d c0109865 c010a3ae c010a425 c010a434 c010a468 (XEN)c010a4a2 c010a4ab c010a4b4 c02c5fb1 c02c6155 c02c61ac c02c61cc c02c6392 (XEN)c02c6456 c02c687e c03962cb c03962d3 c02c6da5 c0396429 c0396432 c039643b (XEN)c0396444 c0396453 c039645c c039646b c0396474 c02c6e85 c02c6eee c02c7051 (XEN)c02c70c7 c02c7121 c02c7127 c02c7365 c02c73ab c02c7423 c02c7433 c02c74af (XEN)c02c74c3 c02c75d0 c02c75e1 c02c75e8 c02c7767 c02c79f6 c02c7bdd c02c7c2e (XEN)c02c7cce c02c7cd3 c02c7ce1 c02c7e14 c02c7e29 c02c807e c02c80cb c02c8153 (XEN)c02c8174 c02c825b c02c826a c02c8279 c02c829a c02c82a9 c010b59e c010b5c7 (XEN)c010b5ef c010bbad c010bbe0 c010bc47 c010bc9d c010bccf c010bd07 c010bd91 (XEN)c010be10 c010be59 c010c0e7 c039753b c039755e c039798f c010ce93 c010de56 (XEN)c039867c c03986a3 c0398797 c0398a78 c010e3f9 c010f656 c010fec4 c0110fb9 (XEN)c0110fc3 c0ba c0c4 c01116a8 c0111a69 c0111ab0 c0111b39 c0111cba (XEN) Domain 0 crashed: rebooting machine in 5 seconds. These crashes occor about once every few days. If there is any more info I can give, please tell. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-xen-686 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash xen-hypervisor-3.2-1-i386 depends on no packages. Versions of packages xen-hypervisor-3.2-1-i386 recommends: ii xen-utils-3.2-1 3.2.1-2XEN administrative tools Versions of packages xen-hypervisor-3.2-1-i386 suggests: pn xen-docs-3.2 none (no description available) -- no debconf information ___ Pkg-xen-devel mailing list pkg-xen-de...@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-xen-devel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534880: SLES11 Xen patches
Hello, Debian Lenny linux-image-2.6.26-2-xen uses an early snapshot of Novell SLES11 patches, so I guess someone would have to go through the SLES11 kernel-xen patches and see what has changed.. I believe SLES11 Xen patches have numerous bugfixes compared to what is in Lenny. ftp://ftp.suse.com/pub/projects/kernel/kotd/SLE11_BRANCH/src/ http://www.gitorious.org/opensuse/kernel-source/commits/SLE11_BRANCH -- Pasi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563605: linux-image-2.6.32-trunk-amd64: Intel VT flags missing on Q45 chipset
On Mon, Jan 04, 2010 at 12:39:00AM +, Jonathan Wiltshire wrote: Package: linux-2.6 Version: 2.6.32-3 Severity: normal I don't seem to have the CPU flags for Intel virtualisation from the processor to run KVM, Xen and friends. I double-checked the BIOS and virtualisation is enabled (it's a Q45 chipset with a Core2Duo E7400 processor, and a recent BIOS). I'm happy to include other information or try things if you direct me, since my kernel experience is limited. I did wonder if I needed to load a module. Have you enabled VT in the BIOS? Sometimes you need to completely power off the computer (disconnect the power cable) after enabling VT in the BIOS, efore the VT setting gets enabled for real. Also, Xen can run PV guests without VT. Xen needs VT only for HVM guests (aka Windows). KVM needs VT for all guests. -- Pasi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536175: [Pkg-xen-devel] Bug#536175: Bug#536175: Bug#536176: xen-utils-3.4: trying xen-3.4 once breaks xen-3.2 (?)
On Sun, Jul 12, 2009 at 09:51:08PM +0200, Bastian Blank wrote: On Sat, Jul 11, 2009 at 09:30:05PM +0800, Thomas Goirand wrote: Bastian Blank wrote: I refuse to maintain the security-hog called qemu for the next stable release, so it can only come from a different source package. What's your suggestion? What source package? Could the normal package qemu be used for the job, or is there too many patches? It should be built from the qemu source package eventually, but for now its impossible due to the patches. Should a different source package be built out of the the xen-3.4.0.tar.gz just for qemu? This should be a possible solution for now. Was there progress on this? While I understand that you don't want to maintain it (and you are giving a good reason for it), a big number of users will still need HVM support in Xen, and wont understand why Debian doesn't do it. Sure, but I don't even have a machine were I can test this. My only machine with VMX is my notebook, which does not work with current Xen. A solution has to be found, and it's unclear what you are suggesting here. Sure. But I'm currently seeing a change in the attitude of the user crowd. Bugs exists always, but I only started to get insulted by bug reporters because I do things different then they think it should be done. I'm sorry if I insulted you, or others. That was not the point. -- Pasi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520641: [Pkg-xen-devel] Bug#520641: Cannot create HVM domain
On Fri, Jul 10, 2009 at 10:39:42AM +0100, Richard Kettlewell wrote: Romain Francoise wrote: This happens when there's not enough free memory to compensate the memory overhead of domain creation, xend balloons down dom0 by 2MB to work around this, but sometimes it's not enough. Freeing more memory manually, or disabling ballooning of dom0 altogether (a good idea in any case) fixes it. Sorry, freeing more memory where and how? It's a 4GB machine with 960MB allocated to the current (PV) guests. I have only the vaguest idea of what ballooning means (something to do with controlling the memory available to domains?), and no idea why it might be a bad idea or how to turn it off. If any of this is documented anywhere then I must have missed some important piece of documentation! First of all, have you limited the amount of memory dom0 has? in grub.conf, add dom0_mem= parameter for xen.gz. This way dom0 only has the specified amount of memory (512 MB for example), and the rest is available for other domains.. then you don't need to balloon the memory at all when creating more domains/guests. xm info should display the rest of the memory as free after you specify dom0_mem parameter for xen hypervisor. -- Pasi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536175: [Pkg-xen-devel] Bug#536175: Bug#536175: Bug#536176: xen-utils-3.4: trying xen-3.4 once breaks xen-3.2 (?)
On Thu, Jul 09, 2009 at 12:11:33AM +0300, Pasi Kärkkäinen wrote: On Wed, Jul 08, 2009 at 11:34:18PM +0300, Pasi Kärkkäinen wrote: On Wed, Jul 08, 2009 at 04:38:10PM +0200, Csillag Kristof wrote: We should move this to this thread (#536175), because the other bug report (#536176) is about a different issue. Pasi Kärkkäinen wrote: On Wed, Jul 08, 2009 at 04:10:31PM +0200, Bastian Blank wrote: On Wed, Jul 08, 2009 at 04:19:39PM +0300, Pasi Kärkkäinen wrote: Uhm, that's really weird. What was the reason for disabling Xen HVM support? It's removing half of the Xen functionality in Debian.. Xen upstream decided to move the patches in qemu upstream. So this needs to be built from qemu in the future, but this is not nearly ready. Oh, it's about ioemu-remote stuff. You could also include a tarball of qemu-xen tree (or whatever the correct tree is) if that helps? Actually I don't think you should build the upstream qemu for xen 3.4.0. Xen 3.4.0 uses it's own version of qemu, not the upstream qemu, afaik. If I understand this correctly, as a default Xen 3.4 hg/mercurial source tree [1] uses 'ioemu-remote', which means the Xen version of Qemu (qemu-xen) is developed on a separate git tree [2]. The official Xen 3.4.0 release tarball [3] contains embedded copy of this ioemu-remote qemu-xen tree on tools/ioemu-qemu-xen directory, so the release tarball can be built without internet/git access. For example Fedora's Xen 3.4.0 source RPM contains the xen-3.4.0.tar.gz release tarball, and they build the included ioemu, just like in earlier Xen releases. That is the correct way to do it. -- Pasi [1] http://xenbits.xen.org/xen-3.4-testing.hg [2] http://xenbits.xen.org/git-http/qemu-xen-3.4-testing.git [3] http://bits.xensource.com/oss-xen/release/3.4.0/xen-3.4.0.tar.gz -- Pasi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536176: [Pkg-xen-devel] Bug#536176: xen-utils-3.4: trying xen-3.4 once breaks xen-3.2 (?)
On Wed, Jul 08, 2009 at 01:28:18AM +0200, Csillag Kristof wrote: Package: xen-utils-3.4 Version: 3.4.0-1 Severity: critical Justification: breaks unrelated software After installing xen-utils-3.4 besides my existing xen-3.2 system, I could not start xend-3.2 anymore. The message I was getting is this: Failed to initialize dom0 state. As far as I know, xen 3.2 and 3.4 are supposed to be able to live peacefully on the same system. (The hypervisor and the utils are in differently named packages.) However, after the first experiment with 3.4 (which failed because of a different bug), I could not go back to xen 3.2. I rebooted to the correct hypervisor, and ran the current version of tools, but it did not work any more. (I did not have time to track down the reason this time.) This causes quite a problem, since the new 3.4 version can not be considered a drop-in replacement of the older 3.2 (HVM support is disabled, for example), so this caused a sesiour problem, at least for me. What do you mean with HVM support is disabled? Xen 3.4.0 definitely supports HVM guests. -- Pasi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536176: [Pkg-xen-devel] Bug#536176: xen-utils-3.4: trying xen-3.4 once breaks xen-3.2 (?)
On Wed, Jul 08, 2009 at 01:42:40PM +0200, Csillag Kristof wrote: Pasi Kärkkäinen wrote: What do you mean with HVM support is disabled? Xen 3.4.0 definitely supports HVM guests. Xen does, but the current debian package does not seem to. The changelog says so: xen-3 (3.4.0-1) unstable; urgency=low [...] * Remove ioemu for now. (closes: #490409, #496367) [...] ...and if I try to create a HVM guest: in /var/log/xen/qemu-dm-domain_name: --- failed to set up fds or execute dm /usr/lib/xen-3.4/bin/qemu-dm: ['OSError: [Errno 2] No such file or directory\n'] and indeed, /usr/lib/xen-3.4/bin/qemu-dm is missing. (The same binary exists in the xen-utils-3.2 package) * * * So, it seems to me that HVM support is disabled in the current package. FWIW, I consider the fact that this information is hidden in the changelog a bug. (Therefore I created #536175 ), but this is a separate issue. mailto:536...@bugs.debian.org Uhm, that's really weird. What was the reason for disabling Xen HVM support? It's removing half of the Xen functionality in Debian.. -- Pasi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536176: [Pkg-xen-devel] Bug#536176: Bug#536176: xen-utils-3.4: trying xen-3.4 once breaks xen-3.2 (?)
On Wed, Jul 08, 2009 at 04:10:31PM +0200, Bastian Blank wrote: On Wed, Jul 08, 2009 at 04:19:39PM +0300, Pasi Kärkkäinen wrote: Uhm, that's really weird. What was the reason for disabling Xen HVM support? It's removing half of the Xen functionality in Debian.. Xen upstream decided to move the patches in qemu upstream. So this needs to be built from qemu in the future, but this is not nearly ready. Oh, it's about ioemu-remote stuff. You could also include a tarball of qemu-xen tree (or whatever the correct tree is) if that helps? Thanks for the reply. -- Pasi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536175: [Pkg-xen-devel] Bug#536175: Bug#536176: xen-utils-3.4: trying xen-3.4 once breaks xen-3.2 (?)
On Wed, Jul 08, 2009 at 04:38:10PM +0200, Csillag Kristof wrote: We should move this to this thread (#536175), because the other bug report (#536176) is about a different issue. Pasi Kärkkäinen wrote: On Wed, Jul 08, 2009 at 04:10:31PM +0200, Bastian Blank wrote: On Wed, Jul 08, 2009 at 04:19:39PM +0300, Pasi Kärkkäinen wrote: Uhm, that's really weird. What was the reason for disabling Xen HVM support? It's removing half of the Xen functionality in Debian.. Xen upstream decided to move the patches in qemu upstream. So this needs to be built from qemu in the future, but this is not nearly ready. Oh, it's about ioemu-remote stuff. You could also include a tarball of qemu-xen tree (or whatever the correct tree is) if that helps? Actually I don't think you should build the upstream qemu for xen 3.4.0. Xen 3.4.0 uses it's own version of qemu, not the upstream qemu, afaik. Redhat has been working on (sending patches) making it _possible_ to use upstream qemu, but Xen project is not atm supporting/testing that. -- Pasi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536175: [Pkg-xen-devel] Bug#536175: Bug#536176: xen-utils-3.4: trying xen-3.4 once breaks xen-3.2 (?)
On Wed, Jul 08, 2009 at 11:34:18PM +0300, Pasi Kärkkäinen wrote: On Wed, Jul 08, 2009 at 04:38:10PM +0200, Csillag Kristof wrote: We should move this to this thread (#536175), because the other bug report (#536176) is about a different issue. Pasi Kärkkäinen wrote: On Wed, Jul 08, 2009 at 04:10:31PM +0200, Bastian Blank wrote: On Wed, Jul 08, 2009 at 04:19:39PM +0300, Pasi Kärkkäinen wrote: Uhm, that's really weird. What was the reason for disabling Xen HVM support? It's removing half of the Xen functionality in Debian.. Xen upstream decided to move the patches in qemu upstream. So this needs to be built from qemu in the future, but this is not nearly ready. Oh, it's about ioemu-remote stuff. You could also include a tarball of qemu-xen tree (or whatever the correct tree is) if that helps? Actually I don't think you should build the upstream qemu for xen 3.4.0. Xen 3.4.0 uses it's own version of qemu, not the upstream qemu, afaik. If I understand this correctly, as a default Xen 3.4 hg/mercurial source tree [1] uses 'ioemu-remote', which means the Xen version of Qemu (qemu-xen) is developed on a separate git tree [2]. The official Xen 3.4.0 release tarball [3] contains embedded copy of this ioemu-remote qemu-xen tree on tools/ioemu-qemu-xen directory, so the release tarball can be built without internet/git access. [1] http://xenbits.xen.org/xen-3.4-testing.hg [2] http://xenbits.xen.org/git-http/qemu-xen-3.4-testing.git [3] http://bits.xensource.com/oss-xen/release/3.4.0/xen-3.4.0.tar.gz -- Pasi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#390862: Etch/testing missing PAE kernel for xen; important for compatibility
On Fri, Dec 15, 2006 at 12:22:04AM -0800, Steve Langasek wrote: On Tue, Dec 12, 2006 at 03:46:37PM +0200, Pasi Kärkkäinen wrote: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390862 Is there anything that could be done with this, at this (late) point? If we can't do anything anymore, then etch will be released with non-pae xen kernel, that cannot be used with fedora/rhel xen kernels.. which means you cannot use debian dom0 and fedora/rhel domU, and not another way around either. It also makes debian xen unusable with many bigger servers.. I would be inclined to allow such a change given the importance of being able to run Xen guests of multiple OSes on a single server, but actually making the necessary changes is up to the maintainers. Would be nice to get a statement from the kernel maintainers.. please comment. -- Pasi -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
Bug#390862: -bigmem version of xen kernels is really needed
So.. is there anything to do about this? -- Pasi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390862: [Pkg-xen-devel] Re: Bug#390862: -bigmem version of xen kernels is really needed
On Tue, Dec 12, 2006 at 02:18:01PM +0200, Pasi Kärkkäinen wrote: On Tue, Dec 12, 2006 at 12:54:31PM +0300, Nikita V. Youshchenko wrote: What about idea not to *add* pae versions of xen kernels, but to *replace* non-pae versions with pae versions? Rationale: - not increase in archive size or linux-2.6 package build time, - this will improve compatimility with other distros (consider scenario when running FC or RHEL in domU; these distros do ship only pae xen kernels, according to http://lists.alioth.debian.org/pipermail/pkg-xen-devel/2006-December/000998.html) http://fedoraproject.org/wiki/FedoraXenQuickstartFC6 Any x86_64, or ia64 CPU is supported for running para-virtualized guests. To run i386 guests requires a CPU with the PAE extension. So FC6 is PAE only, and latest update to FC5 also switched to PAE xen kernel. RHEL5 will be PAE only too. I don't know what Suse uses.. https://www.redhat.com/archives/rhelv5-beta-list/2006-December/msg00068.html the decision to only support PAE capable hosts was made at the end of the FC5 cycle. The majority (if not all) of server in customer datacenters/environments are PAE capable today and the only edge case for non-PAE support would have been older laptops which do not yet have PAE capable processors. It also would have been an additional burden for QA/QE to test/certify older non-PAE capable servers. As the use case for Xen is certainly geared towards servers and not laptops this made a lot of sense. -- Pasi ^ . . Linux /-\ Choice.of.the .Next.Generation.
Bug#390862: [Pkg-xen-devel] Re: Bug#390862: -bigmem version of xen kernels is really needed
On Tue, Dec 12, 2006 at 12:54:31PM +0300, Nikita V. Youshchenko wrote: What about idea not to *add* pae versions of xen kernels, but to *replace* non-pae versions with pae versions? Rationale: - not increase in archive size or linux-2.6 package build time, - this will improve compatimility with other distros (consider scenario when running FC or RHEL in domU; these distros do ship only pae xen kernels, according to http://lists.alioth.debian.org/pipermail/pkg-xen-devel/2006-December/000998.html) http://fedoraproject.org/wiki/FedoraXenQuickstartFC6 Any x86_64, or ia64 CPU is supported for running para-virtualized guests. To run i386 guests requires a CPU with the PAE extension. So FC6 is PAE only, and latest update to FC5 also switched to PAE xen kernel. RHEL5 will be PAE only too. I don't know what Suse uses.. -- Pasi - pae kernels are ok for any x86 machines; slowdown caused by enabling pae on machines with less than 3.%G of memory, if any at all, is hardly measurable on machines where using xen makes sence (anyone using xen on Pentium-I with 128M of ram?) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301960: grub installation fails with HP Smart Array 6i (cciss) using rc3 2.6 installer
Package: installation-reports Debian-installer-version: rc3 for i386 from cdimage.debian.org uname -a: Linux testi 2.6.8-2-386 #1 Mon Jan 24 03:01:58 EST 2005 i686 unknown Date: Tue 29 Mar 2005 12:30 Method: Booted from rc3/i386 CD, and ran linux26 installer. Machine: HP Proliant DL380 G4 server Processor: Intel Xeon 3,2 GHz 1MB Memory: 2 GB ECC Root Device: HP Smart Array 6i / cciss partition 2 (/dev/cciss/c0d0p2) Root Size/partition table: Disk /dev/cciss/c0d0: 35139 cylinders, 255 heads, 32 sectors/track Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls#blocks Id System /dev/cciss/c0d0p1 * 0+ 31 32-257008+ 83 Linux /dev/cciss/c0d0p2 32 517 4863903795 83 Linux /dev/cciss/c0d0p3518 760 2431951897+ 83 Linux /dev/cciss/c0d0p4761 882 122 9799655 Extended /dev/cciss/c0d0p5761+882 122-979933+ 82 Linux swap Output of lspci and lspci -n: :00:00.0 Host bridge: Intel Corp. Server Memory Controller Hub (rev 0c) :00:02.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port A0 (rev 0c) :00:06.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port C0 (rev 0c) :00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1 (rev 02) :00:1d.1 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #2 (rev 02) :00:1d.2 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3 (rev 02) :00:1d.3 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #4 (rev 02) :00:1d.7 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev c2) :00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge (rev 02):00:1f.1 IDE interface: Intel Corp. 82801EB/ER (ICH5/ICH5R) Ultra ATA 100 Storage Controller (rev 02) :01:03.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) :01:04.0 System peripheral: Compaq Computer Corporation Integrated Lights Out Controller (rev 01) :01:04.2 System peripheral: Compaq Computer Corporation Integrated Lights Out Processor (rev 01) :02:00.0 PCI bridge: Intel Corp. PCI Bridge Hub A (rev 09) :02:00.2 PCI bridge: Intel Corp. PCI Bridge Hub B (rev 09) :03:01.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 10) :03:01.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 10) :04:03.0 RAID bus controller: Compaq Computer Corporation Smart Array 64xx (rev 01) :05:00.0 PCI bridge: Intel Corp. PCI Bridge Hub A (rev 09) :05:00.2 PCI bridge: Intel Corp. PCI Bridge Hub B (rev 09) :00:00.0 0600: 8086:3590 (rev 0c) :00:02.0 0604: 8086:3595 (rev 0c) :00:06.0 0604: 8086:3599 (rev 0c) :00:1d.0 0c03: 8086:24d2 (rev 02) :00:1d.1 0c03: 8086:24d4 (rev 02) :00:1d.2 0c03: 8086:24d7 (rev 02) :00:1d.3 0c03: 8086:24de (rev 02) :00:1d.7 0c03: 8086:24dd (rev 02) :00:1e.0 0604: 8086:244e (rev c2) :00:1f.0 0601: 8086:24d0 (rev 02) :00:1f.1 0101: 8086:24db (rev 02) :01:03.0 0300: 1002:4752 (rev 27) :01:04.0 0880: 0e11:b203 (rev 01) :01:04.2 0880: 0e11:b204 (rev 01) :02:00.0 0604: 8086:0329 (rev 09) :02:00.2 0604: 8086:032a (rev 09) :03:01.0 0200: 14e4:1648 (rev 10) :03:01.1 0200: 14e4:1648 (rev 10) :04:03.0 0104: 0e11:0046 (rev 01) :05:00.0 0604: 8086:0329 (rev 09) :05:00.2 0604: 8086:032a (rev 09) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [O] Config network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[O] Install boot loader:[E] Reboot: [O] Comments/Problems: Grub installation fails. The error from third console (alt+f3) is: file /boot/grub/stage1 not read correctly When installing with 2.4 kernel (the default) grub installs OK and works OK. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
