similar to: Possible to use vanilla 2.6.23.9 kernel as domU kernel?

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

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.

I would suggest putting this syslinux web page info near the top of the man page. I was using debian, which has all the linux images being linux.bin. So, to make my own boot disk, I thought I would just copy bzImage to the floppy as linux.bin. Big mistake, if one does that it will not work, and one gets output like: - 0400 AX:0208 BX:0200 CX:0002 DX:0000 etc. Just renaming

On 10/24/2013 01:09 AM, Christian Hesse wrote: >>> >>> version 6.02-pre5 works, 6.02-pre6 does not. >> >> Struggled with git bisect, but finally succeeded: >> >> 8f470e7bfe75f6401f6c5432988c620b863ad274 is the first bad commit >> commit 8f470e7bfe75f6401f6c5432988c620b863ad274 Author: Matt >> Fleming <matt.fleming at intel.com> Date:

This patch exports to userspace the boot loader ID which has been exported by (b)zImage boot loaders since boot protocol version 2. Tested on i386 and x86-64; as far as I know those are the only architectures which use zImage/bzImage format. -hpa Signed-Off-By: H. Peter Anvin <hpa at zytor.com>

syslinux.doc: "...To bzImage and recent zImage kernels, SYSLINUX 1.30 and higher will identify using the ID byte 0x31. PXELINUX identifies using the ID byte 0x32, and ISOLINUX 0x33. The ID range 0x34-0x3f is reserved for future versions or derivatives of SYSLINUX...." Is this info available after boot in /proc or similar, or is it just something the kernel is told and keeps for

Hello, Yesterday I tried to make my first bootable CD image with ISOLINUX. IT went fairly well, except that when ISOLINUX boots and tries to load my kernel, I get an error message about having "Bad gzip magic number" and then the system is halted. I have tried with 2 different kernel images, one compiled using make zImage and one with make bzImage. I was under the impression that

On Sun, 8 Feb 2015, Ady wrote: ... > There have been discussions and/or reports somewhat related to this > matter during 2013 (Mar-Dec), and reports about failing to boot some > kernels with Syslinux 6.03 (2014Q4). > > The topics involved: > > _ Kernels with no protected-mode code (e.g. grub's kernel lnxboot.img > initrd=core.img) > _ bzImage and zImage files

> On Sat, 7 Feb 2015, Ady via Syslinux wrote: > > Thank you for this meaningful report. Ideally, I would suggest > > performing a similar test (at least with the same kernel built with all > > the above "config_*=y" settings) with official pre-built Syslinux > > versions 4.07 and 3.86 (remembering that all Syslinux-related files, > > including c32

Processing commands for control at bugs.debian.org: > reassign 699381 src:xen 4.0.1-5.5 Bug #699381 {Done: Julien Cristau <jcristau at debian.org>} [src:linux] linux-image-3.7-trunk-amd64: boot fails as xen domU: xc_dom_find_loader: no loader found Bug reassigned from package 'src:linux' to 'src:xen'. No longer marked as found in versions linux/3.7.3-1~experimental.1.

"H. Peter Anvin" <hpa at zytor.com> on Tue, 2013/12/03 20:26: > On 10/24/2013 01:09 AM, Christian Hesse wrote: > >>> > >>> version 6.02-pre5 works, 6.02-pre6 does not. > >> > >> Struggled with git bisect, but finally succeeded: > >> > >> 8f470e7bfe75f6401f6c5432988c620b863ad274 is the first bad commit > >>

Hey folks, this is my first contact to XEN-users list. So please be patient if I missed something. I''ve searched a lot before writing this email. My problem: I do have a non-VT/Pacifica box (an old IBM Laptop). There I''ve got already Xen installed (Dom0, 2.6.18-xen0). Now I''ve tried to use the newest vanilla kernel from Kernel.org (at this time: 2.6.23-rc8). As commonly

> >> > >> >From the perspective of a final user, breaking the prior behavior of > >> directives needs to have very clear advantages. > > > > Reviewing the commit history, I would say that the prior behavior is currently broken. > > > > The ALLOWOPTIONS feature was added in 2004: > >

I pulled down the kernel-2.6.18-53.el5.src.rpm source to build my usual custom kernel (adds NTFS wwrite support) and it does not build. Whether I include the NTFS or just build from the source with no changes (other than make oldconfig and adding the # x86_64 line), I get this error every time: Building modules, stage 2. + mkdir -p /var/tmp/kernel-2.6.18-53.el5.nx-root/usr/lib/debug/boot +

Hi All, I have a custom x86 board (using the AMD SC520 Elan CPU) which I am trying to get Linux running on. This is a true embedded board, not a mini PC / PC-on-a-chip arrangement. It has no disk drives (only DRAM , NOR Flash, some battery backed SRAM, a couple of Realtek 8100B Ethernet chips, LEDs, Hex Switches etc) I chose to use U-Boot as the bootloader as it claimed to already have x86

Thanks all, I did find extlinux in "my syslinux tarball" (I think that I understand my confusion now - I will explain at the end). So, now almost everything is fine...... Clearly my extlinux.conf is working (I can see my output on the console (SAY XXX)) I have a bzImage + rootfs.tar I tried : 0) mount /dev/sda1 /mnt/MyMountForSda1 -->> success 1) cd /mnt/MyMountForSda1

Hello! Xen and related packages (libvirt, virt-install, virt-manager etc) in Upcoming CentOS 5.3 support running and installing Fedora 10 (and Fedora 11) paravirtual domU guest virtual machines. These upstream fixes (new features) make it possible: "RHEL5.3 xen: include support for booting Fedora 10 DomU (i.e. bzImage support)" https://bugzilla.redhat.com/show_bug.cgi?id=457199

I've been working on getting syslinux running for a project I'm working on, and am running into the same problem (roughly) that Julian Picht was having back in March 2003 that he described on this list. To quote his problem... > I have got the Problem that syslinux does not boot my kernel it loads it: > > SYSLINUX 2.02 2003-02-13 Copyright (C) 1994-2003 H. Peter Anvin >