file /boot/vmlinuz-2.6.24-gentoo-r8 reports as x86 binary

notageek · # file /boot/vmlinuz-2.6.24-gentoo-r8

Hello,

First I'm not sure if this "issue" has been reported before and has been discussed, I couldn't find anything related to this (maybe I don't know what to search for).

The issue is I'm installing Gentoo using the stage 3 tarball installation on my AMD64 PC, I'm pretty sure I downloaded the correct amd64 live CD, and I've also downloaded the correct amd64 tarball and portage.

So during the kernel compilation I noticed that its entering arch/x86/kernel (or something similar, I'm not at the box right now) folder, which is not what I want. I checked again by running the following command (in chroot environment) on the compiled kernel (located in /mnt/gentoo/boot) which reports its a x86 binary.

Sadako · Posted: Fri Jun 06, 2008 7:00 am Post subject:

file reports the current kernel I'm running as "Linux kernel x86 boot executable RO-rootFS, swap_dev 0x1, Normal VGA", and it is definitely a 64-bit kernel.

Things have changed since 2.6.24, a lot of i386 and x86_64 stuff has been combined into x86, and the kernel bzImage found under arch/x86_64 is actually just a symlink to the one in arch/x86.

grep your config for CONFIG_X86_64 just to be on the safe side, though.
_________________
"You have to invite me in"

Neo2 · Apprentice Joined: 25 Sep 2006 Posts: 224 Location: Italy

Well, entering the x86 architecture folder is normal for kernel compilation, even if you're compiling a 64 bit kernel. This is because some code gets shared between the two versions to avoid having a duplicate parallel folder tree and to minimize the cost of code-writing. That code is compiled as 64bit code, there should be no need to worry.
About file reports, I've done a quick test and discovered the same fact. Probably it is due to the fact that just before the kernel start a routine is called to verify that the CPU has 64bit instruction support. If it has, everything goes well and the kernel boots up normally. Instead, in the case it doesn't find 64bit support, kernel boot process stops after very few lines and something like "You're trying to run a 64bit kernel on a 32bit architecture. Please reboot and choose a different kernel" is printed to the user. My guess is that since the routine has to be 32bit code (else it won't be properly executed on 32bit machines) file just reads the executable header of that first routine, thus reporting x86 binary.
I think you're getting the same reports as I am:

notageek · Posted: Fri Jun 06, 2008 8:13 am Post subject:

Hmm... its been a while since I compiled a kernel, last kernel I compiled was a 2.6.18.x vanilla kernel, I vaguely remember it entering x86_64 folder, maybe things have changed in 2.6.24 now.

Thank you for your reply, this does clear up a bit.

@Hopeless : I'll post the output when I'm at the box.

@Neo2 : Yes the output is similar to what I get.

notageek · Posted: Fri Jun 06, 2008 1:35 pm Post subject:

avendesora · Posted: Sun Jun 08, 2008 9:52 am Post subject:

It's actually even worse than that on x86. The very first part of the boot sequence is 16bit code :-)

Even the most modern x86 cpus start up in 16bit mode, and the kernel has to do all the work to get
to 32bit first then 64bit modes.

It does indeed check along the way that the target is appropriate for the current cpu and prints out
nice messages if not, but the fact that it does go through those mode switches is because it has no
choice on this cpu plateform.

The early startup code is in header.S in x86/boot, and in other files under that depending on 32/64 target.