Re: [gentoo-user] CPU you selected does not support x86-64 instruction set

[John Blinka]

On Wed, May 4, 2016 at 6:51 PM, Neil Bothwick  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

Re: [gentoo-user] CPU you selected does not support x86-64 instruction set

[John Blinka]

On Wed, May 4, 2016 at 12:36 PM, Ron Farrer 
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

Re: [gentoo-user] CPU you selected does not support x86-64 instruction set

[Neil Bothwick]

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.

SystemRescueCd has boot menu options for picking the kernel, just pick
either rescue64 or altker64.


-- 
Neil Bothwick

OK Scotty, NOW!  Detonate and energize!  I mean...


pgpCGGP8xoNs_.pgp
Description: OpenPGP digital signature

[gentoo-user] Re: DRM Problem : Radeon HD 7670M

[James]

Neil Bothwick  digimed.co.uk> writes:


> > Therefore, I check the configuration of grub2 and fstab. Then I found
> > that I forgot to modify mount options in fstab.
> > The option of my boot partition was set as noauto. So that I don't use
> > the kernel compiled by myself at all.

> We've all done that. Now I mount /boot as ro in fstab. That way, if I
> forget to remount it before installing a kernel I get an error message
> instead of the kernel just disappearing.



Perhaps a documentation bug should be filed against the handbook or other
gentoo doc explaining some of the security and other approaches
and *why* various approaches are used with mounting strategies for /boot/ is
warranted?

That way, if folks miss it, we can just refer them to the docs and elaborate
a bit. Me, I like to keep lots of kernels around for a variety
of reasons. Maybe in the GSoC effort (Kernelconfig) is a better place to
implement some explanation on the choices of what to do with /boot/ ? [1]


Anyway, I'm glad to hear that all is fine now.

James


[1] https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2016/Ideas/kernelconfig

Re: [gentoo-user] CPU you selected does not support x86-64 instruction set

[Ron Farrer]

On Wed, May 4, 2016 at 9:08 AM, 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.

Generally, 'uname -m' should report x86_64 for 64-bit (amd64) and i686
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

Re: [gentoo-user] CPU you selected does not support x86-64 instruction set

[John Blinka]

On Wed, May 4, 2016 at 11:31 AM, Michael Mol  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

Re: [gentoo-user] CPU you selected does not support x86-64 instruction set

[Michael Mol]

On Wednesday, May 04, 2016 09:58:37 AM John Blinka wrote:
> 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.
> 
> 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".
> 
> 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.
> 
> Any help would be greatly appreciated.  Thanks!

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.

-- 
:wq

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Re: How to stop ls from quoting output

[Nikos Chantziaras]

On 03/05/16 20:07, Daniel Quinn wrote:

Some time ago after an update |ls| started returning output that looked
like this:

|8hOk25T.jpg 'Janeway Wallpaper-iPhone.png' 'Screenshot from 2016-04-06
16-15-15.png' microsoft.png 'Away mission Wallpaper-iPhone.png'
'Screenshot from 2016-03-18 14-29-06.png' 'Screenshot from 2016-04-07
11-29-02.png' gcal.png |

Note that some of the files have a single quote (‘) surrounding them,
and others don’t. [...]

I see that I can just write an alias:

|alias ls="ls --quoting-style=literal" |

But I’d hate to do that if the default is “literal” and there’s some
config installed somewhere that’s changing this. [...]


As mentioned already, it's an upstream default. However, on Gentoo, "ls" 
is already an alias for "ls --color=auto", because the upstream default 
is to now use colors. At least for bash anyway (the alias is set in 
/etc/bash/bashrc).


So I'd say just do:

  alias ls="ls --quoting-style=literal --color=auto"

in your ~/.bashrc and forget about it :-) Or, if you want it 
system-wide, just write that alias in a new file:


  /etc/bash/bashrc.d/aliases

[gentoo-user] CPU you selected does not support x86-64 instruction set

[John Blinka]

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.

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".

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.

Any help would be greatly appreciated.  Thanks!

John Blinka

Re: SOLVED Re: [gentoo-user] ATLAS@home and VirtualBox

[Peter Humphrey]

On Tuesday 03 May 2016 18:47:39 Andrew Savchenko wrote:
> On Tue, 03 May 2016 09:56:29 +0100 Peter Humphrey wrote:

--->8

> > What is the approved method of reading change-logs nowadays?
> 
> If you are using git sync, just go to /usr/portage/sci-misc/boinc
> and run `git log .` there.
> 
> If you are using rsync sync, read end of the ChangeLog file, tail
> -n 50 should do the job. 'equery c boinc' should work too.

Okay, thanks.

> Looks like your problem comes from broken rsync mirror with outdated
> ChangeLog files.

No, I see it now: 'equery c boinc' returns the ChangeLog section that refers 
to the currently installed version, not to any earlier or later ones. If I 
know what later versions are available I can do something like "equery c 
=sci-misc/boinc-7.6.31" but I hadn't done so until just now.

What's happened, I think, is that the init script change introduced into the 
latest version has been silently back-ported to the previous version. That's 
why I didn't see it in the ChangeLog, and it explains why I didn't get it 
during routine updates - only when I uninstalled the package and reinstalled 
it.

A learning point has emerged here: it's dangerous to specify a version in 
package.keywords.

I can't say I'm delighted to have spent three weeks in fruitless bug 
chasing, just because of an undocumented change that had already fixed my 
problem behind my back. At least I understand what's going on now. Thanks 
for your help, Andrew.

-- 
Rgds
Peter

Re: [gentoo-user] Re: DRM Problem : Radeon HD 7670M

[Neil Bothwick]

On Wed, 4 May 2016 13:06:45 +0800, JingYuan Chen wrote:

> I found that I made a big mistake after I installed kernel 4.4.6. My
> laptop still used kernel 4.1.5 to boot. It come as a surprise to me.
> 
> Therefore, I check the configuration of grub2 and fstab. Then I found
> that I forgot to modify mount options in fstab.
> The option of my boot partition was set as noauto. So that I don't use
> the kernel compiled by myself at all.

We've all done that. Now I mount /boot as ro in fstab. That way, if I
forget to remount it before installing a kernel I get an error message
instead of the kernel just disappearing.


-- 
Neil Bothwick

Is that "woof" feed me; "woof" walk me; "woof" there's a burglar? What??


pgp_jhXD_ySS9.pgp
Description: OpenPGP digital signature