info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[gentoo-user] CPU you selected does not support x86-64 instruction set
205 views
Skip to first unread message
John Blinka
May 4, 2016, 10:00:05 AM5/4/16
to
Hello, Gentooers:
I have a new Dell 17 5759 with core i5-6200U skylake cpu on which I'm trying to dual boot windows 10 and gentoo. All the rest of my gentoo hardware is much older, so this new laptop introduces 2 technologies new to me: uefi and 64 bit kernels.
So, a 64 bit sysrescuecd kernel does run on this box, and its /proc/cpuinfo tells me that it does indeed have a core i5-6200U cpu which, per Google, does support the x86-64 instruction set. I believe I've told the kernel make system that I want a 64 bit kernel and that the cpu I want to run it on supports the x86-64 instruction set. Not trusting my kernel config knowledge, I've tried letting clean kernel installations produce a 64 bit kernel configuration for me via make defconfig and genkernel, both of which appear to be attempting 64 bit configurations. All of these attempts fail the same way. I've tried all of this on gentoo-sources-4.4.6 and -4.1.15-r1.
I installed gentoo using the x86 handbook and a recent sysrescuecd usb drive. The install was unremarkable except for trying to build a 64 bit kernel. No matter what I do, the kernel build fails very early with the message:
kernel/bounds.c:1:0 error: CPU you selected does not support x86-64 instruction set.
Looking at bounds.c does not enlighten me.
I've tried specifying a 64 bit kernel in various ways:
setting CONFIG_64BIT=y and CONFIG_X86_64=y via make menuconfig,
make defconfig, which claims it uses an x86_64_defconfig, and sets the 2 configuration variables above to "y",
and genkernel, which says it's getting arch-specific config.sh from /usr/share/genkernel/arch/x86_64/config.sh, which also sets the 2 variables above to "y".
Any help would be greatly appreciated. Thanks!
John Blinka
Michael Mol
May 4, 2016, 11:40:04 AM5/4/16
to
install on x86_64 hardware.
https://wiki.gentoo.org/wiki/Handbook:AMD64
More importantly, you should be booted into a 64-bit environment. That means
using a 64-bit live image for your initial boot, and using an amd64 stage3.
EFI has similar requirements; you'll need to be booted via EFI in the first
place in order to set up the bootloader properly; your firmware won't make the
necessary hardware calls available to register your bootloader if you're not
booted in EFI mode.
HTH.
--
:wq
John Blinka
May 4, 2016, 12:10:04 PM5/4/16
to
On Wed, May 4, 2016 at 11:31 AM, Michael Mol <mik...@gmail.com> wrote:
You should use the AMD64 handbook, not the x86 handbook, if you're trying to
install on x86_64 hardware.
https://wiki.gentoo.org/wiki/Handbook:AMD64
More importantly, you should be booted into a 64-bit environment. That means
using a 64-bit live image for your initial boot, and using an amd64 stage3.
EFI has similar requirements; you'll need to be booted via EFI in the first
place in order to set up the bootloader properly; your firmware won't make the
necessary hardware calls available to register your bootloader if you're not
booted in EFI mode.
HTH
I had read similar thoughts about booting into a 64 bit environment before posting and had gone to some effort to figure out whether the sysrescuecd kernel was, in fact, 64 bit. Its /proc/config.gz seemed to indicate 64 bit, as did uname -a. But I really don't know if there is a definitive way of determining whether a running kernel is 64 or 32 bit.
I was booted via EFI, so that part of my installation process was correct.
I never thought to look in the AMD64 handbook. Thanks for the suggestion - will give it a try.
John
Ron Farrer
May 4, 2016, 12:40:03 PM5/4/16
to
On Wed, May 4, 2016 at 9:08 AM, John Blinka <john....@gmail.com> wrote:
>
> I had read similar thoughts about booting into a 64 bit environment before
> posting and had gone to some effort to figure out whether the sysrescuecd
> kernel was, in fact, 64 bit. Its /proc/config.gz seemed to indicate 64 bit,
> as did uname -a. But I really don't know if there is a definitive way of
> determining whether a running kernel is 64 or 32 bit.
Generally, 'uname -m' should report x86_64 for 64-bit (amd64) and i686
>
> I had read similar thoughts about booting into a 64 bit environment before
> posting and had gone to some effort to figure out whether the sysrescuecd
> kernel was, in fact, 64 bit. Its /proc/config.gz seemed to indicate 64 bit,
> as did uname -a. But I really don't know if there is a definitive way of
> determining whether a running kernel is 64 or 32 bit.
for 32-bit (x86). While it is possible to have a 64-bit kernel and
32-bit userland, the reverse is not possible. So another check can be
'file /sbin/init' which will report as something along the lines of
"/sbin/init: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 2.6.32, stripped"
Regards,
Ron
John Blinka
May 4, 2016, 7:00:04 PM5/4/16
to
On Wed, May 4, 2016 at 12:36 PM, Ron Farrer <canutet...@gmail.com> wrote:
Generally, 'uname -m' should report x86_64 for 64-bit (amd64) and i686
for 32-bit (x86).
uname -m did give x86_64, but...
... another check can be 'file /sbin/init' which will report as something along the lines of
"/sbin/init: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 2.6.32, stripped"
file /sbin/init gave ELF 32-bit LSB...
So I guess my syrescuecd is 32 bits.
Using the amd64 handbook did the trick with the kernel. Now onto learning about uefi. Thanks for your help!
John
John Blinka
May 4, 2016, 7:00:04 PM5/4/16
to
On Wed, May 4, 2016 at 6:51 PM, Neil Bothwick <ne...@digimed.co.uk> wrote:
SystemRescueCd has boot menu options for picking the kernel, just pick
either rescue64 or altker64.
I did try that at least once, but I think I compensated for doing the right thing at that point with making mistakes elsewhere. I'll give it another try now that I have a 64 bit kernel compiled on the target machine. I'll need that to get the uefi environment I need to accomplish uefi booting. Appreciate your reminding me!
John
Neil Bothwick
May 4, 2016, 7:00:04 PM5/4/16
to
On Wed, 4 May 2016 12:08:22 -0400, John Blinka wrote:
> I had read similar thoughts about booting into a 64 bit environment
> before posting and had gone to some effort to figure out whether the
> sysrescuecd kernel was, in fact, 64 bit. Its /proc/config.gz seemed to
> indicate 64 bit, as did uname -a. But I really don't know if there is
> a definitive way of determining whether a running kernel is 64 or 32
> bit.
> I had read similar thoughts about booting into a 64 bit environment
> before posting and had gone to some effort to figure out whether the
> sysrescuecd kernel was, in fact, 64 bit. Its /proc/config.gz seemed to
> indicate 64 bit, as did uname -a. But I really don't know if there is
> a definitive way of determining whether a running kernel is 64 or 32
> bit.
SystemRescueCd has boot menu options for picking the kernel, just pick
either rescue64 or altker64.
--
either rescue64 or altker64.
Neil Bothwick
OK Scotty, NOW! Detonate and energize! I mean.......
Helmut Jarausch
May 5, 2016, 3:00:03 AM5/5/16
to
Hi,
I had this just yesterday. The libraries of the SystemRescueCD are not
64 bits.
So, you have to proceed as follows.
Boot RescueCD with the alternative 64 bit kernel (and select the option
to load all files into memory)
mkdir /oroot
... mount the partition where you installed Gentoo on /oroot
mount --bind /proc /oroot/proc
mount --rbind /dev /oroot/dev
chroot /oroot /bin/bash
env-update
source /etc/profile
... and now you are in business
e.g.
cd /usr/src/linux-????
make menuconfig or oldconfig
make -j8
make install
make modules modules_install
Don't forget to install grub while you are in this chroot environment.
Then, exit from the chroot environment and reboot.
Good luck
I had this just yesterday. The libraries of the SystemRescueCD are not
64 bits.
So, you have to proceed as follows.
Boot RescueCD with the alternative 64 bit kernel (and select the option
to load all files into memory)
mkdir /oroot
... mount the partition where you installed Gentoo on /oroot
mount --bind /proc /oroot/proc
mount --rbind /dev /oroot/dev
chroot /oroot /bin/bash
env-update
source /etc/profile
... and now you are in business
e.g.
cd /usr/src/linux-????
make menuconfig or oldconfig
make -j8
make install
make modules modules_install
Don't forget to install grub while you are in this chroot environment.
Then, exit from the chroot environment and reboot.
Good luck
Neil Bothwick
May 5, 2016, 5:00:03 AM5/5/16
to
On Thu, 05 May 2016 09:53:23 +0100, Peter Humphrey wrote:
> Also, grub is a total failure on this box: it just isn't detected. So I
> use gummiboot instead. It's also far, far easier to manage if you have
> more than one kernel to choose from, and it saves you having to learn
> all that baroquery. Frankly, I'm glad to see the back of grub-2.
I'd go so far to say that the main reason to use UEFI is to be free of
GRUB. gummiboot/bootctl is so much nicer, even if it is now part of
systemd's plans for World domination ;-)
--
Neil Bothwick
Women live longer than men because they have so many clothes that they
wouldn't be caught dead in.
> Also, grub is a total failure on this box: it just isn't detected. So I
> use gummiboot instead. It's also far, far easier to manage if you have
> more than one kernel to choose from, and it saves you having to learn
> all that baroquery. Frankly, I'm glad to see the back of grub-2.
I'd go so far to say that the main reason to use UEFI is to be free of
GRUB. gummiboot/bootctl is so much nicer, even if it is now part of
systemd's plans for World domination ;-)
--
Neil Bothwick
Women live longer than men because they have so many clothes that they
wouldn't be caught dead in.
Peter Humphrey
May 5, 2016, 5:00:03 AM5/5/16
to
with. That means, if his system is like mine, having the CD inserted before
starting, prodding <DEL> or whatever until the BIOS screen comes up, then
picking the optical drive in UEFI mode, then booting that.
Then the option to load all files into RAM is not available.
Also, grub is a total failure on this box: it just isn't detected. So I use
gummiboot instead. It's also far, far easier to manage if you have more than
one kernel to choose from, and it saves you having to learn all that
baroquery. Frankly, I'm glad to see the back of grub-2.
Rgds
Peter
John Blinka
May 5, 2016, 11:10:04 AM5/5/16
to
Appreciate all the commentary on sysrescuecd/uefi/booting. You anticipated my needs - almost at that point in the install. I will definitely try gummiboot.
John0 new messages