Re: kexec: Cannot determine the file type of arch/x86/boot/bzImage

Previous thread: [PATCH] /proc Security Hooks by Max Kellermann on Tuesday, October 16, 2007 - 12:38 pm. (6 messages)

Next thread: [PATCH] Update PowerPC vmemmap code for 1TB segments by Anton Blanchard on Tuesday, October 16, 2007 - 12:57 pm. (1 message)
From: Thomas Meyer
Date: Tuesday, October 16, 2007 - 12:51 pm

Hi.

Look at this:

$ file arch/x86/boot/bzImage (tree 821f3eff7cdb9d6c7076effabd46c96c322daed1)
arch/x86/boot/bzImage: Linux kernel x86 boot executable zImage, version
2.6.23 (thomas@hotzenplotz) #39, RO-rootFS, root_dev 0x803, swap_dev
0x1, Prompt for Videomode

$ file /boot/bzImage-2.6.23
/boot/bzImage-2.6.23: Linux kernel x86 boot executable RO-rootFS,
root_dev 0x803, swap_dev 0x1, Normal VGA

and this:

# kexec -l arch/x86/boot/bzImage
Cannot determine the file type of arch/x86/boot/bzImage

How to solve this error?

mfg
thomas

-

From: Randy Dunlap
Date: Tuesday, October 16, 2007 - 1:06 pm

On Tue, 16 Oct 2007 21:51:13 +0200 Thomas Meyer wrote:



---
~Randy
-

From: yhlu
Date: Tuesday, October 16, 2007 - 2:00 pm

#!/bin/bash
KERNEL_VER=2.6.24_k8.2
CONSOLE=console=uart8250,io,0x3f8,9600n8

./kexec -t bzImage -l bzImage_"$KERNEL_VER" --command-line="apic=debug
acpi.debug_level=0x0000000F pci=routeirq nmi_watchdog=2
ramdisk_size=65536 root=/dev/ram0 rw ip=dhcp $CONSOLE"
--ramdisk=mydisk8_x86_64.gz

YH
-

From: Thomas Meyer
Date: Tuesday, October 16, 2007 - 2:40 pm

$ git bisect good
f77bf01425b11947eeb3b5b54685212c302741b8 is first bad commit
commit f77bf01425b11947eeb3b5b54685212c302741b8
Author: Sam Ravnborg <sam@neptun.(none)>
Date:   Mon Oct 15 22:25:06 2007 +0200

    kbuild: introduce ccflags-y, asflags-y and ldflags-y

    Introduce ccflags-y, asflags-y and ldflags-y so we soon can
    deprecate use of EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS.
    This patch does not touch any in-tree users - thats next round.
    Lets get this committed first and then fix the users of the
    soon to be deprecated variants next.

    The rationale behind this change is to introduce support for
    makefile fragments like:

    ccflags-$(CONFIG_WHATEVER_DEBUG) := -DDEBUG

    As a replacement for the uglier:
    ifeq ($(CONFIG_WHATEVER_DEBUG),y)
            EXTRA_CFLAGS := -DDEBUG
    endif

663bce3c08a0f2e107cecb0b29edc4fe9d5735a0 M      scripts





-

From: Sam Ravnborg
Date: Tuesday, October 16, 2007 - 3:06 pm

Fixed by following patch.
Sorry for the inconvinience.

	Sam

From 7eebb9348655b55553d65fc7cb6cfad292d28dbb Mon Sep 17 00:00:00 2001
From: Sam Ravnborg <sam@neptun.(none)>
Date: Tue, 16 Oct 2007 23:50:33 +0200
Subject: [PATCH] x86: fix boot error introduced by kbuild

x86 uses target specific assignment of EXTRA_AFLAGS,
EXTRA_CFLAGS - this caused troubles with
introducing asflags-y, ccflags-y.

Fixed the target specific assignments in arch/x86/boot/Makefile
and auditted the rest of the kernel for similar usage.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
---
 arch/x86/boot/Makefile |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
index d6ed8e5..e8756e5 100644
--- a/arch/x86/boot/Makefile
+++ b/arch/x86/boot/Makefile
@@ -64,10 +64,10 @@ KBUILD_CFLAGS	:= $(LINUXINCLUDE) -g -Os -D_SETUP -D__KERNEL__ \
 KBUILD_AFLAGS	:= $(KBUILD_CFLAGS) -D__ASSEMBLY__
 
 $(obj)/zImage:  IMAGE_OFFSET := 0x1000
-$(obj)/zImage:  EXTRA_AFLAGS := $(SVGA_MODE) $(RAMDISK)
+$(obj)/zImage:  asflags-y := $(SVGA_MODE) $(RAMDISK)
 $(obj)/bzImage: IMAGE_OFFSET := 0x100000
-$(obj)/bzImage: EXTRA_CFLAGS := -D__BIG_KERNEL__
-$(obj)/bzImage: EXTRA_AFLAGS := $(SVGA_MODE) $(RAMDISK) -D__BIG_KERNEL__
+$(obj)/bzImage: ccflags-y := -D__BIG_KERNEL__
+$(obj)/bzImage: asflags-y := $(SVGA_MODE) $(RAMDISK) -D__BIG_KERNEL__
 $(obj)/bzImage: BUILDFLAGS   := -b
 
 quiet_cmd_image = BUILD   $@
-- 
1.5.2.4

-

From: Randy Dunlap
Date: Tuesday, October 16, 2007 - 2:45 pm

This makes 2 big problems with this patch in the last 1 hour.

Probably time to revert it...

---
~Randy
-

From: Luca Tettamanti
Date: Tuesday, October 16, 2007 - 2:43 pm

Sam, please take a look at this:


I just noticed the same problem when grub refused to load that thing.

The issue is that the build system created a zImage (and not a bzImage);
even passing the target explicitly doesn't solve the problem.

git bisect says:

f77bf01425b11947eeb3b5b54685212c302741b8 is first bad commit
commit f77bf01425b11947eeb3b5b54685212c302741b8
Author: Sam Ravnborg <sam@neptun.(none)>
--- (Ops, you have a problem on you git setup)
Date:   Mon Oct 15 22:25:06 2007 +0200

    kbuild: introduce ccflags-y, asflags-y and ldflags-y

    Introduce ccflags-y, asflags-y and ldflags-y so we soon can
    deprecate use of EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS.
    This patch does not touch any in-tree users - thats next round.
    Lets get this committed first and then fix the users of the
    soon to be deprecated variants next.

    The rationale behind this change is to introduce support for
    makefile fragments like:

    ccflags-$(CONFIG_WHATEVER_DEBUG) := -DDEBUG

    As a replacement for the uglier:
    ifeq ($(CONFIG_WHATEVER_DEBUG),y)
            EXTRA_CFLAGS := -DDEBUG
    endif


I'm building a x86_64 image, using an external directory (O=...) in case
it matters.

Bisect log:

git-bisect start
# bad: [821f3eff7cdb9d6c7076effabd46c96c322daed1] Merge git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild
git-bisect bad 821f3eff7cdb9d6c7076effabd46c96c322daed1
# good: [bbf25010f1a6b761914430f5fca081ec8c7accd1] Linux 2.6.23
git-bisect good bbf25010f1a6b761914430f5fca081ec8c7accd1
# good: [4d5709a7b7d54fc5882d2943a14988a92d48c00a] Merge master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreq
git-bisect good 4d5709a7b7d54fc5882d2943a14988a92d48c00a
# good: [b5869ce7f68b233ceb81465a7644be0d9a5f3dbb] Merge git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched
git-bisect good b5869ce7f68b233ceb81465a7644be0d9a5f3dbb
# good: [11370ee2c1c578a704f47d5513d57274c335db43] [ALSA] hda-codec: Add two new systems to ...
From: Eric W. Biederman
Date: Tuesday, October 16, 2007 - 4:27 pm

Looks like a kbuild error was causing us to build zImage kernels
instead of bzImage kernels on x86 and thus kexec didn't recognize
the format and so refused to boot it.

Eric
-

Previous thread: [PATCH] /proc Security Hooks by Max Kellermann on Tuesday, October 16, 2007 - 12:38 pm. (6 messages)

Next thread: [PATCH] Update PowerPC vmemmap code for 1TB segments by Anton Blanchard on Tuesday, October 16, 2007 - 12:57 pm. (1 message)