similar to: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage

Well, it seems to be about time to have this conversation again. A rough overview of the previous thread and requirements is: 1. bzImage would not be a bare ELF file, but it would contain an ELF header+file within it 2. We need some way to add extra ELF notes into that ELF file 3. We use a "paravirtualized" bootloader type, with some other field to determine which

Well, it seems to be about time to have this conversation again. A rough overview of the previous thread and requirements is: 1. bzImage would not be a bare ELF file, but it would contain an ELF header+file within it 2. We need some way to add extra ELF notes into that ELF file 3. We use a "paravirtualized" bootloader type, with some other field to determine which

I've updated the patches at http://ozlabs.org/~rusty/paravirt/?mf=33ba6c4fce13;path=/ to carve out the basic shape of how I see all this fitting together. These patches implement an initial set of Xen paravirt ops, as well as adapting head.S to set up a Xen-specific entrypoint. The head.S code does absolutely minimal setup, and then calls xen_start_kernel(). This installs the Xen

I started with Vivek's ELF bzImage patch from Oct last year, mashed it to apply to hpa's new setup/boot code. This patch does a couple of things, which would probably be better split into multiple patches: 1. Glue an ELF header onto the front of bzImage. This is a real ELF header at the front of the file. Breaks akpm's laptop, apparently, but it works for me. 2.

I started with Vivek's ELF bzImage patch from Oct last year, mashed it to apply to hpa's new setup/boot code. This patch does a couple of things, which would probably be better split into multiple patches: 1. Glue an ELF header onto the front of bzImage. This is a real ELF header at the front of the file. Breaks akpm's laptop, apparently, but it works for me. 2.

Hi, Today I replaced grub(1) with syslinux on my laptop, after rebooting to syslinux and selecting kernel I got massive freeze along with colorful output to screen - http://i.imgur.com/lFjFc.jpg I think I tried everything, even doing esc and writing after boot: /bzImage-3.1.0, after enter I had the same freeze with the same screen artefacts. How I installed extlinux: mkdir /boot/extlinux

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

Hi I'm having problems PXE-booting a Sun-Blade 100x. As the subject line says, booting stops during "Loading /bzimage...." Broadcom UNDI PXE-2.1 (build 082) v6.2.11 Copyright (C) 2000-2003 Broadcom Corporation Copyright (C) 1997-2000 Intel Corporation All rights reserved. CLIENT MAC ADDR: 00 03 BA 44 4F F4 GUID: 00000000 0000 0000 0000 000000000000 CLIENT IP: 10.148.11.21 MASK:

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

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: important Hi, I set the severity to important as it seems that current xen tools does not allow to load amd64 Debian kernel in DomU. I also put the debian-kernel ML in CC as I'm not sure the problem comes from xen tools or the kernel itself. Here is my configuration: Hypervisor: xen-hypervisor-3.2-1-amd64 3.2.1-2

OK, here's another go-around. This patch leaves the bzImage itself unmodified, but it changes the payload into an ELF file. That is, the 32-bit decompression/relocation+compressed kernel is now a properly formed ELF file. One thing that fell out of this is that code32_start end up being a pointer to the ELF header rather than an entrypoint. Rather than reproducing Vivek's (?) hack of

OK, here's another go-around. This patch leaves the bzImage itself unmodified, but it changes the payload into an ELF file. That is, the 32-bit decompression/relocation+compressed kernel is now a properly formed ELF file. One thing that fell out of this is that code32_start end up being a pointer to the ELF header rather than an entrypoint. Rather than reproducing Vivek's (?) hack of

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.

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 series: 1. Updates the boot protocol to version 2.07 2. Clean up the existing build process, to get rid of tools/build and make the linker do more heavy lifting 3. Make the bzImage payload an ELF file. The bootloader can extract this as a naked ELF file by skipping over boot_params.setup_sects worth of 16-bit setup code. 4. Update the boot_params to 2.07, and update the

This series: 1. Updates the boot protocol to version 2.07 2. Clean up the existing build process, to get rid of tools/build and make the linker do more heavy lifting 3. Make the bzImage payload an ELF file. The bootloader can extract this as a naked ELF file by skipping over boot_params.setup_sects worth of 16-bit setup code. 4. Update the boot_params to 2.07, and update the

This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which adds fields to specify the hardware subarchitecture and some