similar to: Bug#519149: xen-3: does not really load bzImage kernels.

Processing commands for control at bugs.debian.org: > severity 519149 important Bug#519149: xen-3: does not really load bzImage kernels. Severity set to `important' from `serious' > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)

Hi, There are a couple of open bugs against Xen-3 with patches which directly impact my efforts to have Debian Installer work in a Xen guest domain for Lenny. ?In both cases the relevant fixes are already committed in upstream Xen and I've been rebuilding and using the Debian packages with them without problems. First is #476366 which is a pygrub issue that prevents booting a guest using

Processing commands for control at bugs.debian.org: > reassign 474509 xen-3 Bug#474509: xen: Please enable support for loading bzImages with v2.08 of the x86 bootloader protocol Warning: Unknown package 'xen' Bug reassigned from package `xen' to `xen-3'. > -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator

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: 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. Bastian -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990,

This implements a loader for version 2.07 boot protocol bzImage format files. This allows a single bzImage kernel file to boot either native from a normal bootloader (grub, etc), or paravirtualized under Xen. These bzImages have two changes to make this possible: 1. There's a new field for the bootloader to tell the booted kernel what kind of environment its coming up under. We

This implements a loader for version 2.07 boot protocol bzImage format files. This allows a single bzImage kernel file to boot either native from a normal bootloader (grub, etc), or paravirtualized under Xen. These bzImages have two changes to make this possible: 1. There's a new field for the bootloader to tell the booted kernel what kind of environment its coming up under. We

This implements a loader for version 2.07 boot protocol bzImage format files. This allows a single bzImage kernel file to boot either native from a normal bootloader (grub, etc), or paravirtualized under Xen. These bzImages have two changes to make this possible: 1. There's a new field for the bootloader to tell the booted kernel what kind of environment its coming up under. We

Hi William, Please could you provide some more details of the failure since this functionality works for me both with the Debian packages and upstream and I don't recall any additional patches upstream. Are there any messages in the logs? Particularly /var/log/xen/xend* and /var/log/xen/domain-builder-ng.log. Which kernel are you trying to load? The standard Lenny -686-bigmem kernel

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:

Processing commands for control at bugs.debian.org: > reopen 474509 Bug#474509: xen: Please enable support for loading bzImages with v2.08 of the x86 bootloader protocol 'reopen' may be inappropriate when a bug has been closed with a version; you may need to use 'found' to remove fixed versions. Bug reopened, originator not changed. > thanks Stopping processing here.

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]

reopen 487095 reopen 487097 thanks Hi, since you thought it's necessary to complain to me about this bug report on IRC I'm replying to this bug now as well. > On Thu, Jun 19, 2008 at 04:56:54PM +0200, Thomas Bl?sing wrote: > > CVE-2008-1943[0]: > > | Buffer overflow in the backend of XenSource Xen Para Virtualized Frame > > | Buffer (PVFB) 3.0 through 3.1.2 allows

Jeremy Fitzhardinge <jeremy@goop.org> writes: > Eric W. Biederman wrote: >> All it does is set a flag that tells a bootloader. >> "Hey. I can run when loaded a non-default address, and this is what >> you have to align me to." >> >> All relocation processing happens in the kernel itself. >> > > Is it possible to decompress and

Jeremy Fitzhardinge <jeremy@goop.org> writes: > Eric W. Biederman wrote: >> All it does is set a flag that tells a bootloader. >> "Hey. I can run when loaded a non-default address, and this is what >> you have to align me to." >> >> All relocation processing happens in the kernel itself. >> > > Is it possible to decompress and

Hello list, Since a few months I get the following error after I have recompiled Xen from hg, xen-4.1-stable or xen-unstable: ERROR Invalid kernel: xc_dom_probe_bzimage_kernel: kernel is not a bzImage This comes from domU''s that are configured to use pv-grub. As a workaround I do have a working pvgrub-x86_64.gz from an earlier compile so I''m using that without problems.

Hi, What the the size limit of booting bzImage file with syslinux ? I have tested different sized bzImage files, and when the files are small <800K, they work with syslinuz, but at some size larger they fail to work. This was the same problem loadlin1.6 had, but loadlin1.6c fixes the issue, and I can boot bzImage sizes up to 1.5Meg with loadlin, but syslinux fails. Can you confirm this

On Wed, Mar 19, 2014 at 4:16 PM, Mau Z <zmau1962 at gmail.com> wrote: > Hi, > > I am wondering how to implement the following customer's requirement : > The system is a stand alone embedded system with no operator (with Linux). > There is one SSD for the system's usage (and that is where the system loads > from). > > The requirement is to have a duplication of

On 03/19/2014 01:30 PM, Gene Cumm wrote: > On Wed, Mar 19, 2014 at 4:16 PM, Mau Z <zmau1962 at gmail.com> wrote: >> Hi, >> >> I am wondering how to implement the following customer's requirement : >> The system is a stand alone embedded system with no operator (with Linux). >> There is one SSD for the system's usage (and that is where the system loads

On Mar 19, 2014 5:22 PM, "H. Peter Anvin" <hpa at zytor.com> wrote: > Or we could make the Linux loader (load_linux.c) throw an error on a bad > CRC, which is probably a good idea anyway. Then the ONERROR option can > be used for the fallback. > > -hpa Sounds like an excellent idea. Should linux.c32 get an override option (in case of a non-compliant