similar to: Bug#512900:

Package: xen-hypervisor-3.2-1-amd64 Version: 3.2.1-2 Severity: grave Current xen hypervisor don't support Intel Core 2 Duo T9400 processor. Processor supports Intel (R) Virtualization Technology. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28.1 (SMP w/2 CPU cores; PREEMPT) Locale:

Package: xen-hypervisor-3.2-1-i386 Version: 3.2-1 Severity: critical Tags: security Justification: DoS of entire system regardless of privilege When running the exploit listed in bug 464953 [1], Xen's memory state becomes corrupted and the hypervisor eventually crashes, taking all of the domU's with it. As such, this breaks operational behaviour, so I have marked this as critical. [1]

Do you mind explaining why this bug was downgraded from grave (which had a justification) to normal? -- C'est avec les pierres de la loi qu'on a b?ti les prisons, et avec les briques de la religion, les bordels. - Blake, William -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size:

Hi, Has anyone actually successfully completed an upgrade from 3.0.4 to 3.2 using tar balls? Ive tried various ways but everytime the compile is complete the system just constantly reboots. Ive managed to upgrade fine from other version like 3.0.1 etc but 3.1 and 3.2 are just a nightmare. Ive spent hours on this and am getting nowhere fast. If anyone has any tips they would be

Package: xen-utils-3.2-1 Version: 3.2.1-2 Severity: grave Justification: renders package unusable qemu-dm sends out this: - supported machines are: pc Standard PC (default) isapc ISA-only PC - instead of: - Supported machines are: xenfv Xen Fully-virtualized PC (default) xenpv Xen Para-virtualized PC - this renders any tries to use HVM fail. -- System Information:

Package: xen-hypervisor-3.2-1-amd64 Version: 3.2.1-2 Severity: serious After noting that this version supposedly loads bzImage kernels: | xen-3 (3.2.1-2) unstable; urgency=low | | * Use e2fslibs based ext2 support for pygrub. (closes: #476366) | * Fix missing checks in pvfb code. | See CVE-2008-1952. (closes: #487095) | * Add support for loading bzImage files. (closes: #474509) | *

Package: xen-utils-3.2-1 Version: 3.2.1-2 Severity: grave I tried to start an HVM guest to setup Windows 2003 64 bits entreprise R2, and I spent a long time figuring out that there is no /usr/lib/xen folder by default, and this is where Xen is searching for it's file when using HVM, VNC and all. Doing a simple symlink with ln -s /usr/lib/xen-3.2.1 /usr/lib/xen made it working, if it's not

I know it's totally unsupported and probably even a stupid question to ask considering that it's a topic that is nowhere to be discussed in the wiki, but I hope that someone with more clue could help me. I need to deploy on several machines (laptop) running vista 64 bit an old 16 bit accounting /groupware/calendar application, which is, of course, custom, proprietary and no longer

Package: xen-system-amd64 Version: 4.6.0-1 Severity: grave Justification: renders package unusable Dear Maintainer, I installed fresh from ALPHA5, no UEFI, with two disks. Each disk got a partition for /boot and one for /, joined each by RAID 1. Then I just installed "xen-system-amd64", nothing more. After rebooting, selecting on grub to boot XEN, it hangs on mdadm: no devices

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,

Hi, first of all, apologies if this isn't the right mailing list but it was the best I could find. If you know a better mailing list, please tell me. Today I tried to defrag one of my filesystems. It's a 3.5T large filesystem that has 6 software-raids in the bottom and then merged together using lvm. I was running ext3 but removed the journal flag with thor:~# tune2fs -O ^has_journal

Hi all, I would like to get my system to work with IOMMU. (The long-term goal is VGA passthru.) System is as follows: CPU: Core 2 Duo E6600 MB: Foxconn G9657MA-8EKRS2H (w. latest bios: 631F1P61) Virtualization support is enabled in BIOS. (These is only one option.) Hypervisor: xen 4.0.0 from Debian, AMD64 Xen config: iommu=verbose output of xen dmesg is attached. HVM domains work (lasd tried

Am considering a new laptop, and I wonder if anyone here can share their Xen experiences with the newest Core 2 Duo CPUs, ref http://www.intel.com/products/processor/core2duo/specifications.htm The list at http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors doesn''t include any Core 2 Duos. Does that mean that people have had problems, or is the wiki just not up to date? I gather

from my googling around, it doesn't look there is a single motherboard that supports core 2 duo and works without patches or tweaks. is that true? the main thing we want is: core 2 duo support 4g of 800mhz (or better) ram sata gig ether with pxe boot we can live without pata or usb for a while. we've tried intel 965 and asus p5b based boards with various levels of ease of install,

Hi, I've installed CentOS5.2 on an INTEL Core 2 Duo (Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz), 4 GB RAM (MemTotal: 4072176 kB) and my system gets sevarel minutes to startup, specially on udev daemon. Once the system is UP, every command I run gets 100% CPU and every is very slowly at the point yum -y update never ends. The system installed by default this kernel 2.6.18-53.el5PAE.

Package: xen Severity: grave Tags: security Please see http://www.openwall.com/lists/oss-security/2012/07/26/4 Cheers, Moritz

Hello, On the Intel Core 2 Duo processor based systems, we have the option of installing either x86_64 or the i386 distribution. I would like to know your experiences with the x86_64 port. How does it compare with the i386 distribution in terms of stability, reliability and performance ? How significant are the performance benefits gained by using the x86_64 linux instead of i386 on the same

Hi all, Fewer days ago a CentOS box server suffered a manual and unexpected reset (too large to explain: there are silly people in everywhere). The result was the system did not mount de root (/) partition and the boot process was stopped. I repair it easily: boot from LiveCD (Knoppix in my case), umount root partition and pass the e2fsck utility. Because of that I've used several fs tools

Package: xen-unstable Version: N/A Severity: grave xen-unstable is not suitable for a release. Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, "Day of the Dove", stardate unknown -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc:

Package: xen-hypervisor-3.0.3-1-amd64 Version: 3.0.3-0-2 Severity: grave Justification: renders package unusable This bug looks to be tracked in upstream: http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=762 Mailing list discussion here: http://lists.xensource.com/archives/html/xen-bugs/2006-11/msg00030.html -- System Information: Debian Release: 4.0 APT prefers testing APT policy: