Re: [gentoo-user] CPU you selected does not support x86-64 instruction set
On Tuesday, December 15, 2020 8:08:46 AM CET bobwxc wrote: > 在 2020/12/15 下午2:59, the...@sys-concept.com 写道: > > On 12/14/2020 11:50 PM, J. Roeleveld wrote: > >> On Tuesday, December 15, 2020 7:17:57 AM CET the...@sys-concept.com wrote: > >>> On 12/14/2020 06:21 PM, the...@sys-concept.com wrote: > By mistake on new installation I untar wrong: stage-3 x86_64 instead > of > i686 > > during kernel compiling I got: > cc1: error: CPU you selected does not support x86-64 instruction set > > Is it possible to untar new stage-3 (i686) over current one, or I need > to delete all the folders? > >>> > >>> After selecting stage-3 (i686) I still get the same error message when > >>> trying to compile kernel: > >>> > >>> CC scripts/mod/empty.o > >>> cc1: error: CPU you selected does not support x86-64 instruction set > >>> make[1]: *** [scripts/Makefile.build:266: scripts/mod/empty.o] Error 1 > >>> make: *** [Makefile:1137: prepare0] Error 2 > >>> > >>> The CPU I have: > >>> AMD FX(tm)-8150 Eight-Core Processor > >> > >> Isn't this a 64-bit CPU? > >> If you boot using a 64bit live-image (the gentoo-admin ISO as an > >> example), you should be able to actually use 64bit. > >> > >> -- > >> Joost > > > > I'm confused as well, setting from make.conf on this CPU with previous > > kernel was: > > CHOST="x86_64-pc-linux-gnu" > > As Joost says, maybe you can try boot from a 64bit install image to test > that. > > If you can, you may re-install your system to use 64bit. > > Only a little chance that your cpu has some problem with x64 module. I did a fresh install last weekend and using the 64-bit version from: https://www.gentoo.org/downloads/ actually worked. I copied it to a USB-stick using dd: # dd if=...path...toiso of=/dev/ Took a little bit (as USB-stick is old...) -- Joost
Re: [gentoo-user] CPU you selected does not support x86-64 instruction set
在 2020/12/15 下午2:59, the...@sys-concept.com 写道: On 12/14/2020 11:50 PM, J. Roeleveld wrote: On Tuesday, December 15, 2020 7:17:57 AM CET the...@sys-concept.com wrote: On 12/14/2020 06:21 PM, the...@sys-concept.com wrote: By mistake on new installation I untar wrong: stage-3 x86_64 instead of i686 during kernel compiling I got: cc1: error: CPU you selected does not support x86-64 instruction set Is it possible to untar new stage-3 (i686) over current one, or I need to delete all the folders? After selecting stage-3 (i686) I still get the same error message when trying to compile kernel: CC scripts/mod/empty.o cc1: error: CPU you selected does not support x86-64 instruction set make[1]: *** [scripts/Makefile.build:266: scripts/mod/empty.o] Error 1 make: *** [Makefile:1137: prepare0] Error 2 The CPU I have: AMD FX(tm)-8150 Eight-Core Processor Isn't this a 64-bit CPU? If you boot using a 64bit live-image (the gentoo-admin ISO as an example), you should be able to actually use 64bit. -- Joost I'm confused as well, setting from make.conf on this CPU with previous kernel was: CHOST="x86_64-pc-linux-gnu" As Joost says, maybe you can try boot from a 64bit install image to test that. If you can, you may re-install your system to use 64bit. Only a little chance that your cpu has some problem with x64 module. -- bobwxc OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-user] CPU you selected does not support x86-64 instruction set
On 12/14/2020 11:50 PM, J. Roeleveld wrote: > On Tuesday, December 15, 2020 7:17:57 AM CET the...@sys-concept.com wrote: >> On 12/14/2020 06:21 PM, the...@sys-concept.com wrote: >>> By mistake on new installation I untar wrong: stage-3 x86_64 instead of >>> i686 >>> >>> during kernel compiling I got: >>> cc1: error: CPU you selected does not support x86-64 instruction set >>> >>> Is it possible to untar new stage-3 (i686) over current one, or I need >>> to delete all the folders? >> >> After selecting stage-3 (i686) I still get the same error message when >> trying to compile kernel: >> >> CC scripts/mod/empty.o >> cc1: error: CPU you selected does not support x86-64 instruction set >> make[1]: *** [scripts/Makefile.build:266: scripts/mod/empty.o] Error 1 >> make: *** [Makefile:1137: prepare0] Error 2 >> >> The CPU I have: >> AMD FX(tm)-8150 Eight-Core Processor > > Isn't this a 64-bit CPU? > If you boot using a 64bit live-image (the gentoo-admin ISO as an example), > you > should be able to actually use 64bit. > > -- > Joost I'm confused as well, setting from make.conf on this CPU with previous kernel was: CHOST="x86_64-pc-linux-gnu"
[gentoo-user] Re: CPU you selected does not support x86-64 instruction set
On 15/12/2020 03:21, the...@sys-concept.com wrote: By mistake on new installation I untar wrong: stage-3 x86_64 instead of i686 during kernel compiling I got: cc1: error: CPU you selected does not support x86-64 instruction set Is it possible to untar new stage-3 (i686) over current one, or I need to delete all the folders? Your problem is somewhere else. Your CPU is 64-bit, as are all desktop CPUs made in the last 15 years.
Re: [gentoo-user] CPU you selected does not support x86-64 instruction set
On Tuesday, December 15, 2020 7:17:57 AM CET the...@sys-concept.com wrote: > On 12/14/2020 06:21 PM, the...@sys-concept.com wrote: > > By mistake on new installation I untar wrong: stage-3 x86_64 instead of > > i686 > > > > during kernel compiling I got: > > cc1: error: CPU you selected does not support x86-64 instruction set > > > > Is it possible to untar new stage-3 (i686) over current one, or I need > > to delete all the folders? > > After selecting stage-3 (i686) I still get the same error message when > trying to compile kernel: > > CC scripts/mod/empty.o > cc1: error: CPU you selected does not support x86-64 instruction set > make[1]: *** [scripts/Makefile.build:266: scripts/mod/empty.o] Error 1 > make: *** [Makefile:1137: prepare0] Error 2 > > The CPU I have: > AMD FX(tm)-8150 Eight-Core Processor Isn't this a 64-bit CPU? If you boot using a 64bit live-image (the gentoo-admin ISO as an example), you should be able to actually use 64bit. -- Joost
Re: [gentoo-user] CPU you selected does not support x86-64 instruction set
在 2020/12/15 下午2:33, the...@sys-concept.com 写道:
On 12/14/2020 11:17 PM, the...@sys-concept.com wrote:
On 12/14/2020 06:21 PM, the...@sys-concept.com wrote:
By mistake on new installation I untar wrong: stage-3 x86_64 instead of
i686
during kernel compiling I got:
cc1: error: CPU you selected does not support x86-64 instruction set
Is it possible to untar new stage-3 (i686) over current one, or I need
to delete all the folders?
After selecting stage-3 (i686) I still get the same error message when
trying to compile kernel:
CC scripts/mod/empty.o
cc1: error: CPU you selected does not support x86-64 instruction set
make[1]: *** [scripts/Makefile.build:266: scripts/mod/empty.o] Error 1
make: *** [Makefile:1137: prepare0] Error 2
The CPU I have:
AMD FX(tm)-8150 Eight-Core Processor
make.conf
COMMON_FLAGS="-march=native -O2 -pipe"
#COMMON_FLAGS="-O2 -march=i686 -pipe"
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
FCFLAGS="${COMMON_FLAGS}"
FFLAGS="${COMMON_FLAGS}"
CPU_FLAGS_X86="mmx mmxext sse sse2 sse3"
SOLVED:
One need to disable "64-bit kernel" in the root of the menuconfig.
AMD FX-8150 should support x86-64 according to the it data, very confused.
--
bobwxc
OpenPGP_signature
Description: OpenPGP digital signature
Re: [gentoo-user] CPU you selected does not support x86-64 instruction set
On 12/14/2020 11:17 PM, the...@sys-concept.com wrote:
> On 12/14/2020 06:21 PM, the...@sys-concept.com wrote:
>>
>> By mistake on new installation I untar wrong: stage-3 x86_64 instead of
>> i686
>>
>> during kernel compiling I got:
>> cc1: error: CPU you selected does not support x86-64 instruction set
>>
>> Is it possible to untar new stage-3 (i686) over current one, or I need
>> to delete all the folders?
>
> After selecting stage-3 (i686) I still get the same error message when
> trying to compile kernel:
>
> CC scripts/mod/empty.o
> cc1: error: CPU you selected does not support x86-64 instruction set
> make[1]: *** [scripts/Makefile.build:266: scripts/mod/empty.o] Error 1
> make: *** [Makefile:1137: prepare0] Error 2
>
> The CPU I have:
> AMD FX(tm)-8150 Eight-Core Processor
>
> make.conf
> COMMON_FLAGS="-march=native -O2 -pipe"
> #COMMON_FLAGS="-O2 -march=i686 -pipe"
> CFLAGS="${COMMON_FLAGS}"
> CXXFLAGS="${COMMON_FLAGS}"
> FCFLAGS="${COMMON_FLAGS}"
> FFLAGS="${COMMON_FLAGS}"
> CPU_FLAGS_X86="mmx mmxext sse sse2 sse3"
SOLVED:
One need to disable "64-bit kernel" in the root of the menuconfig.
Re: [gentoo-user] CPU you selected does not support x86-64 instruction set
On 12/14/2020 06:21 PM, the...@sys-concept.com wrote:
>
> By mistake on new installation I untar wrong: stage-3 x86_64 instead of
> i686
>
> during kernel compiling I got:
> cc1: error: CPU you selected does not support x86-64 instruction set
>
> Is it possible to untar new stage-3 (i686) over current one, or I need
> to delete all the folders?
After selecting stage-3 (i686) I still get the same error message when
trying to compile kernel:
CC scripts/mod/empty.o
cc1: error: CPU you selected does not support x86-64 instruction set
make[1]: *** [scripts/Makefile.build:266: scripts/mod/empty.o] Error 1
make: *** [Makefile:1137: prepare0] Error 2
The CPU I have:
AMD FX(tm)-8150 Eight-Core Processor
make.conf
COMMON_FLAGS="-march=native -O2 -pipe"
#COMMON_FLAGS="-O2 -march=i686 -pipe"
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
FCFLAGS="${COMMON_FLAGS}"
FFLAGS="${COMMON_FLAGS}"
CPU_FLAGS_X86="mmx mmxext sse sse2 sse3"
Re: [gentoo-user] CPU you selected does not support x86-64 instruction set
On 12/14/2020 09:38 PM, J. Roeleveld wrote: > On 15 December 2020 02:21:22 CET, the...@sys-concept.com wrote: >> >> By mistake on new installation I untar wrong: stage-3 x86_64 instead >> of >> i686 >> >> during kernel compiling I got: >> cc1: error: CPU you selected does not support x86-64 instruction set >> >> Is it possible to untar new stage-3 (i686) over current one, or I need >> to delete all the folders? > > To avoid any leftover files causing issues, I would start over. > > -- > Joost You are correct, it is easier to start over.
Re: [gentoo-user] CPU you selected does not support x86-64 instruction set
On 15 December 2020 02:21:22 CET, the...@sys-concept.com wrote: > >By mistake on new installation I untar wrong: stage-3 x86_64 instead >of >i686 > >during kernel compiling I got: >cc1: error: CPU you selected does not support x86-64 instruction set > >Is it possible to untar new stage-3 (i686) over current one, or I need >to delete all the folders? To avoid any leftover files causing issues, I would start over. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[gentoo-user] CPU you selected does not support x86-64 instruction set
By mistake on new installation I untar wrong: stage-3 x86_64 instead of i686 during kernel compiling I got: cc1: error: CPU you selected does not support x86-64 instruction set Is it possible to untar new stage-3 (i686) over current one, or I need to delete all the folders?
Re: [gentoo-user] OT: DVI-D / HDMI / VGA adaptors
On 12/14/20 10:55 AM, Walter Dnes wrote: I ordered a Dell XPS 8940 which arrived in October, but life got in the way, and I'm only now getting around to setting it up. First thing I noticed today is that Dell "had the courage to remove the VGA port" . It has HDMI and Displayport. I've got two monitors for my PCs. My main one has VGA/DVI/HDMI/Displayport inputs. But I want to attach the XPS 8940 to the older monitor, which only has VGA and DVI-D. I use the older monitor for setup/install and to keep the "hot backup" machine up-to-date. What are my options? For the main machine I'll buy an HDMI cable. Are there adapters that'll push HDMI computer output into a monitor VGA or DVI-D input? That way I can buy an HDMI cable plus an adaptor, rather than a new monitor. If your old monitor has DVI-D there's a plethora of HDMI to DVI-D cords out there. We use a lot of them where I work. Dan
Re: [gentoo-user] Upgrade an old system
在 2020/12/15 上午3:38, the...@sys-concept.com 写道: I'm having similar problem as "n952162" upgrading an old (last updated 1.8-year ago) It sync OK, updated the profile. Looking instruction on this page: https://wiki.gentoo.org/wiki/Upgrading_Gentoo root #mv /usr/portage /usr/portage.latest root #tar xjpf /path/to/portage-20090720.tar.bz2 -C /usr root #emerge --update --oneshot portage but that portage "portage-20090720.tar.bz2" seems old; what is the latest one? go to the http://www.gentoo.org/downloads/mirrors/ and find a mirror, the snapshots will have lastest portage. Like https://gentoo.osuosl.org/snapshots/portage-latest.tar.bz2 It always update. And update a old system may cause a log of problems, be careful. -- bobwxc OpenPGP_0x36E94EABB53E516B.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-user] Upgrade an old system
On 14/12/2020 22:35, Neil Bothwick wrote: On Mon, 14 Dec 2020 15:18:19 -0700, the...@sys-concept.com wrote: Moving forward like a snail. Unmerged portage to local directory and running: ./portage-portage-3.0.12/bin/emerge -1 portage gives me two blockers: [blocks B ] Probably not. It looks like you need to update python, try iirc, gentoolkit is an add-on that helps with portage. As such it would be safe to remove ... Read the handbook and see if it *recommends* installing gentoolkit. If it does (as I seem to remember), it isn't *necessary* and can be removed. Cheers, Wol
Re: [gentoo-user] nouveau: gr: failed to load firmware "gr/sw_nonctx"
On 12/14/2020 02:03 AM, Michael wrote: > On Monday, 14 December 2020 00:27:03 GMT the...@sys-concept.com wrote: >> On 12/13/2020 04:44 PM, Michael wrote: >>> On Sunday, 13 December 2020 18:52:51 GMT the...@sys-concept.com wrote: I have "nouveau" build into kernel but it doesn't work: Fom dmesg: nouveau :08:00.0: NVIDIA GP107 (137000a1) nouveau :08:00.0: gr: failed to load firmware "gr/sw_nonctx" nouveau :08:00.0: gr: failed to load gr/sw_nonctx nouveau :08:00.0: DRM: failed to create kernel channel, -22 [snip] >> >> Both had same output, so why one kernel was working the other didn't? > > Were both of these kernels installed with a corresponding correctly > functioning initramfs, which had all the requisite files (including -- > firmware) to boot with, or only one of them did? > > Without an initramfs you will need to specify and build any requisite > firmware > blobs in the kernel image itself, so they are available to the system as it > boots up. Since I was able to make "nvidia" work I abandon fighting with installing/enabling "nouveau" Originally I wanted to have it as a backup switching between these two (just in case) but it is not an easy project.
[gentoo-user] Re: update fails, but I don't see why
On 2020-12-14, antlists wrote: > What I would do is find out whatever -march fits the oldest chip, and > then set that for all the machines. Especially if, as you say, they're > all AMD the chances are the newer chips will be a superset of the old, FWIW, that's not always the case. Instructions sometiems go away from one CPU generation to the next. -- Grant
Re: [gentoo-user] OT: DVI-D / HDMI / VGA adaptors
On 14/12/2020 18:55, Walter Dnes wrote: But I want to attach the XPS 8940 to the older monitor, which only has VGA and DVI-D. I use the older monitor for setup/install and to keep the "hot backup" machine up-to-date. What are my options? For the main machine I'll buy an HDMI cable. Are there adapters that'll push HDMI computer output into a monitor VGA or DVI-D input? That way I can buy an HDMI cable plus an adaptor, rather than a new monitor. I've got an HDMI-to-VGA so I can drive an old projector from a new laptop. Works great. BEWARE - IT'S ONE-WAY. You need a different adaptor for VGA-to-HDMI, if you want to drive a new monitor from an old PC. Cheers, Wol
Re: [gentoo-user] Re: update fails, but I don't see why
On 14/12/2020 12:55, n952162 wrote: On 12/14/20 11:17 AM, Wols Lists wrote: On 14/12/20 08:51, Dale wrote: If you are able, maybe you can compile the bigger packages on a faster system? If it is a option, it may help. If I have multiple similar machines, I create a shared a shared local repository. Then I run emerge with the settings (can't remember what they are) "use binary if it's there, create binary". That way, especially the big ones, only get built on one machine. Oh man! That would be wonderful. How similar do they need to be? All my x86 machines are currently AMD, I think, but probably from different generations. What I would do is find out whatever -march fits the oldest chip, and then set that for all the machines. Especially if, as you say, they're all AMD the chances are the newer chips will be a superset of the old, so by compiling for the oldest it *should* (famous last words) work everywhere. Cheers, Wol
Re: [gentoo-user] nouveau: gr: failed to load firmware "gr/sw_nonctx"
On Monday, 14 December 2020 19:30:32 GMT Neil Bothwick wrote: > On Mon, 14 Dec 2020 10:07:37 +, Michael wrote: > > > This shows that you have 20201022-r3 installed but eix says the latest > > > available is 20201022-r2 so you have a version it thinks is not in the > > > tree. > > > > > > Did you run eix-update after syncing? > > > > Just sync'ed and on the mirror I used there is no 20201022-r2 version: > Exactly, but eix was saying there was, and no -r3, probably because you > hadn't run eix-update. > > > $ eix linux-firmware > > [I] sys-kernel/linux-firmware > > See, it's all fine now. Heh! This package was always alright for me. It was Thelma the OP I was trying to help with my observation. :-) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Upgrade an old system
On Mon, 14 Dec 2020 15:18:19 -0700, the...@sys-concept.com wrote:
> Moving forward like a snail.
> Unmerged portage to local directory and running:
> ./portage-portage-3.0.12/bin/emerge -1 portage
>
> gives me two blockers:
> [blocks B ] (" [blocks B ] <=dev-lang/python-2.7.18-r3:2.7
> ("<=dev-lang/python-2.7.18-r3:2.7" is blocking
> dev-lang/python-exec-2.4.6-r2)
>
> I can remove app-portage/gentoolkit but is it safe to remove:
> dev-lang/python-2.7.18-r3:2.7
Probably not. It looks like you need to update python, try
emerge -1a portage python:2.7
Or simply
emerge -1ua @system
--
Neil Bothwick
Artificial Intelligence usually beats real stupidity.
pgp0jcDEhIuG4.pgp
Description: OpenPGP digital signature
Re: [gentoo-user] Re: Upgrade an old system
On 12/14/2020 02:55 PM, Grant Edwards wrote: > On 2020-12-14, the...@sys-concept.com wrote: >> I'm having similar problem as "n952162" upgrading an old (last updated >> 1.8-year ago) > > If I were youe, I'd just reinstall after 1.8 years. Updating is going > to take way, way more work. > > -- > Grant I was thinking the same thing. But I'll try first if its possible to upgrade.
Re: [gentoo-user] Upgrade an old system
On 12/14/2020 02:58 PM, Arve Barsnes wrote: > On Mon, 14 Dec 2020 at 22:20, wrote: >> Looking at this directory: >> https://github.com/gentoo/portage/releases/tag/portage-3.0.12 >> >> file: portage-portage-3.0.12.tar.gz has totally different structure >> If I run: tar xzf portage-portage-3.0.12.tar.gz -C /usr >> it will create directory /usr/portage-portage-3.0.12 > > That is a release of the portage *application*, you need snapshots of > the portage *tree*. > > I could find some a year old here: > https://mirrors.sohu.com/gentoo/snapshots/ > > You might need to look for even older ones, but worth a try. > > Regards, > Arve Moving forward like a snail. Unmerged portage to local directory and running: ./portage-portage-3.0.12/bin/emerge -1 portage gives me two blockers: [blocks B ]
[gentoo-user] Re: Upgrade an old system
On 2020-12-14, the...@sys-concept.com wrote: > I'm having similar problem as "n952162" upgrading an old (last updated > 1.8-year ago) If I were youe, I'd just reinstall after 1.8 years. Updating is going to take way, way more work. -- Grant
Re: [gentoo-user] Upgrade an old system
On Mon, 14 Dec 2020 at 22:20, wrote: > Looking at this directory: > https://github.com/gentoo/portage/releases/tag/portage-3.0.12 > > file: portage-portage-3.0.12.tar.gz has totally different structure > If I run: tar xzf portage-portage-3.0.12.tar.gz -C /usr > it will create directory /usr/portage-portage-3.0.12 That is a release of the portage *application*, you need snapshots of the portage *tree*. I could find some a year old here: https://mirrors.sohu.com/gentoo/snapshots/ You might need to look for even older ones, but worth a try. Regards, Arve
Re: [gentoo-user] Upgrade an old system
[snip] emerge --update --oneshot portage !!! All ebuilds that could satisfy ">=app-crypt/openpgp-keys-gentoo-release-20180706" have been masked. !!! One of the following masked packages is required to complete your request: - app-crypt/openpgp-keys-gentoo-release-20200704::gentoo (masked by: EAPI 7) The current version of portage supports EAPI '6'. You must upgrade to a newer version of portage before EAPI masked packages can be installed. (dependency required by "sys-apps/portage-2.3.99-r2::gentoo[rsync-verify,-build]" [ebuild]) (dependency required by "portage" [argument]) I don't even have "app-crypt/openpgp-keys-gentoo-release" installed why is it complaining?
[gentoo-user] X11 specific libs not used/found
Hello, I am trying to install a data visualization package (VisIt) which installs locally, on its own, a qt package (qt-everywhere-src-5.14.2). The config output says: [snip] X11 specific: XLib . no XCB Xlib . no EGL on X11 ... no [snip] XCB: Using system-provided XCB libraries .. no XCB XKB .. yes XCB XInput ... yes Native painting (experimental) ... no GL integrations: GLX Plugin . no EGL-X11 Plugin . no which indicates that later during install of the whole package, some XCB files are not found. I have installed libX11, and xorg-x11. Apparently some libx11-dev package is needed but I don't seem to find it in Gentoo. Any help appreciated. Thanks, -- Valmor
[gentoo-user] Re: OT: DVI-D / HDMI / VGA adaptors
On 2020-12-14, Walter Dnes wrote: > But I want to attach the XPS 8940 to the older monitor, which only has > VGA and DVI-D. I use the older monitor for setup/install and to keep > the "hot backup" machine up-to-date. What are my options? For the main > machine I'll buy an HDMI cable. Are there adapters that'll push HDMI > computer output into a monitor VGA or DVI-D input? In my experience, HDMI->DVI-D is pretty much foolproof. I'd probably go with a cable like this: https://www.amazon.com/gp/product/B014I8UQJY/ or, if you want to introduce an extra failure point, you can stick an adapter like below on the monitor and use a standard HDMI cable https://www.amazon.com/Rankie-Adapter-2-Pack-Gold-Plated-Converter/ I've done both of the above multiple times with 100% success. OTOH, I've had spotty luck with display-port -> DVI adapters. The ones I have work OK with an NVidia video card's DP outputs, but not with the DP output on my Intel i5 motherboard. -- Grant
Re: [gentoo-user] Upgrade an old system
On 12/14/2020 12:52 PM, Arve Barsnes wrote: > On Mon, 14 Dec 2020 at 20:38, wrote: >> but that portage "portage-20090720.tar.bz2" seems old; what is the >> latest one? > > They're generated every day, so pick your poison. Notice it mentions > updating the portage tree 3-4 months at a time, so just pick some > dates at reasonable intervals from your starting point. > > Regards, > Arve Looking at this directory: https://github.com/gentoo/portage/releases/tag/portage-3.0.12 file: portage-portage-3.0.12.tar.gz has totally different structure If I run: tar xzf portage-portage-3.0.12.tar.gz -C /usr it will create directory /usr/portage-portage-3.0.12 emerge --update --oneshot portage can not fine it as it is looking for /usr/portage
Re: [gentoo-user] OT: DVI-D / HDMI / VGA adaptors
On 14 December 2020 19:55:42 CET, Walter Dnes wrote: > I ordered a Dell XPS 8940 which arrived in October, but life got in >the way, and I'm only now getting around to setting it up. First thing >I noticed today is that Dell "had the courage to remove the VGA port" >. It has HDMI and Displayport. I've got two monitors for my PCs. >My main one has VGA/DVI/HDMI/Displayport inputs. > > But I want to attach the XPS 8940 to the older monitor, which only has >VGA and DVI-D. I use the older monitor for setup/install and to keep >the "hot backup" machine up-to-date. What are my options? For the >main >machine I'll buy an HDMI cable. Are there adapters that'll push HDMI >computer output into a monitor VGA or DVI-D input? That way I can buy >an HDMI cable plus an adaptor, rather than a new monitor. Yes, I use one from Startech without any issues. Comes with HDMI, DVI and VGA output for a mini DP port. I use it as well to connect the laptop to my tv. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] Upgrade an old system
On Mon, 14 Dec 2020 at 20:38, wrote: > but that portage "portage-20090720.tar.bz2" seems old; what is the > latest one? They're generated every day, so pick your poison. Notice it mentions updating the portage tree 3-4 months at a time, so just pick some dates at reasonable intervals from your starting point. Regards, Arve
[gentoo-user] Upgrade an old system
I'm having similar problem as "n952162" upgrading an old (last updated 1.8-year ago) It sync OK, updated the profile. Looking instruction on this page: https://wiki.gentoo.org/wiki/Upgrading_Gentoo root #mv /usr/portage /usr/portage.latest root #tar xjpf /path/to/portage-20090720.tar.bz2 -C /usr root #emerge --update --oneshot portage but that portage "portage-20090720.tar.bz2" seems old; what is the latest one?
Re: [gentoo-user] OT: DVI-D / HDMI / VGA adaptors
On Mon, 14 Dec 2020 13:55:42 -0500, Walter Dnes wrote:
> I ordered a Dell XPS 8940 which arrived in October, but life got in
> the way, and I'm only now getting around to setting it up. First thing
> I noticed today is that Dell "had the courage to remove the VGA port"
> . It has HDMI and Displayport. I've got two monitors for my PCs.
> My main one has VGA/DVI/HDMI/Displayport inputs.
My five year old Dell laptop only has mni-displayport. It's not a new
decision.
> But I want to attach the XPS 8940 to the older monitor, which only has
> VGA and DVI-D. I use the older monitor for setup/install and to keep
> the "hot backup" machine up-to-date. What are my options? For the main
> machine I'll buy an HDMI cable. Are there adapters that'll push HDMI
> computer output into a monitor VGA or DVI-D input? That way I can buy
> an HDMI cable plus an adaptor, rather than a new monitor.
You can buy various adaptors from Amazon. I have one with
mini-displayport input and multiple outputs - VGS, DVI and HDMI.
--
Neil Bothwick
... if (pot.coffee == EMPTY) { programmer->brain = OFF };
pgpqwnNy6yokd.pgp
Description: OpenPGP digital signature
Re: [gentoo-user] nouveau: gr: failed to load firmware "gr/sw_nonctx"
On Mon, 14 Dec 2020 10:07:37 +, Michael wrote: > > This shows that you have 20201022-r3 installed but eix says the latest > > available is 20201022-r2 so you have a version it thinks is not in the > > tree. > > > > Did you run eix-update after syncing? > > Just sync'ed and on the mirror I used there is no 20201022-r2 version: Exactly, but eix was saying there was, and no -r3, probably because you hadn't run eix-update. > > $ eix linux-firmware > [I] sys-kernel/linux-firmware See, it's all fine now. -- Neil Bothwick "Designing pages in HTML is like having sex in a bathtub. If you don't know anything about sex, it won't help to know a lot about bathtubs." pgpL9m7pDUMLu.pgp Description: OpenPGP digital signature
[gentoo-user] OT: DVI-D / HDMI / VGA adaptors
I ordered a Dell XPS 8940 which arrived in October, but life got in the way, and I'm only now getting around to setting it up. First thing I noticed today is that Dell "had the courage to remove the VGA port" . It has HDMI and Displayport. I've got two monitors for my PCs. My main one has VGA/DVI/HDMI/Displayport inputs. But I want to attach the XPS 8940 to the older monitor, which only has VGA and DVI-D. I use the older monitor for setup/install and to keep the "hot backup" machine up-to-date. What are my options? For the main machine I'll buy an HDMI cable. Are there adapters that'll push HDMI computer output into a monitor VGA or DVI-D input? That way I can buy an HDMI cable plus an adaptor, rather than a new monitor. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] Re: update fails, but I don't see why
On Monday, 14 December 2020 12:55:33 GMT n952162 wrote: > On 12/14/20 11:17 AM, Wols Lists wrote: > > On 14/12/20 08:51, Dale wrote: > >> If you are able, maybe you can compile the bigger packages on a faster > >> system? If it is a option, it may help. > > > > If I have multiple similar machines, I create a shared a shared local > > repository. Then I run emerge with the settings (can't remember what > > they are) "use binary if it's there, create binary". > > > > That way, especially the big ones, only get built on one machine. > > > > Cheers, > > Wol > > Oh man! That would be wonderful. How similar do they need to be? All > my x86 machines are currently AMD, I think, but probably from different > generations. It depends on the different instruction sets between the CPUs. You could try compiling one package as a test with the existing $COMMON_FLAGS on the fast host and emerge '--buildpkg y', or '--buildpkgonly', then emerge it as a binary on the slow host with '--usepkgonly y'. If the binary package does not emerge/run on the slow host, then you can try again, but use COMMON_FLAGS="-march" instead of "-march=native" to compile it on the fast host. The same binary package could then be installed on all slow hosts. signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: grub-install: warning: File system `ext2' doesn't support embedding.
On 2020-12-14, the...@sys-concept.com wrote: > On 12/13/2020 09:05 PM, Grant Edwards wrote: >> On 2020-12-14, the...@sys-concept.com wrote: >> >>> I removed "vfat" boot partition and created/change it to ext2 >>> >>> But now when i try to install grub: >>> >>> grub-install /dev/nvme0n1p2 >>> Installing for i386-pc platform. >>> grub-install: warning: File system `ext2' doesn't support embedding. >>> grub-install: warning: Embedding is not possible. GRUB can only be >>> installed in this setup by using blocklists. However, blocklists are >>> UNRELIABLE and their use is discouraged.. >>> grub-install: error: will not proceed with blocklists. >>> >>> Is it something that is going to create problem? >> >> If you want to install grub in an ext2 partition, you'll need to use >> the --force option to get grub2 to use blocklists. After you've done >> that, you need to make the critical file immutable so that it can't be >> altered or moved: >> >> # chattr +i /boot/grub/i386-pc/core.img >> >> If you ever need to update grub, you'll have to unlock that file using >> 'chattr -i'. > > I don't think so. I'm sorry I screwed up and answered the question you asked. Won't happen again. > I just tried made typo. > Instead of running: > grub-install /dev/nvme0n1 > > I did: > grub-install /dev/nvme0n1p2 Which told Grub to install in a partition (which is evidently an ext2 filesystem). To do that, you have to use the --force option. For that to be reliably you have to make the core.img file immutable after you do the installation.
Re: [gentoo-user] Re: update fails, but I don't see why
On 12/14/20 11:17 AM, Wols Lists wrote: On 14/12/20 08:51, Dale wrote: If you are able, maybe you can compile the bigger packages on a faster system? If it is a option, it may help. If I have multiple similar machines, I create a shared a shared local repository. Then I run emerge with the settings (can't remember what they are) "use binary if it's there, create binary". That way, especially the big ones, only get built on one machine. Cheers, Wol Oh man! That would be wonderful. How similar do they need to be? All my x86 machines are currently AMD, I think, but probably from different generations.
Re: [gentoo-user] how to control "forcefsck"
On Monday, 14 December 2020 01:21:34 GMT the...@sys-concept.com wrote: > On 12/13/2020 05:56 PM, the...@sys-concept.com wrote: > > After running in "/" directory: > > touch forcefsck > > > > The file is gone now, but every time I reboot the system the root > > partition goes into force check: > > > > fstab: > > /dev/nvme0n1p4 / ext4noatime 0 1 > > If I'm not mistaken it should be: > > tune2fs -c -1 /dev/nvme0n1p4 > > but why was the setting reset when I run "touch forcefsck" Use 'tune2fs -l /dev/nvme0n1p4' to see what settings the fs superblock contains and in particular check the 'Maximum mount count' and 'Check interval' values. These can be set to your liking. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] [SOLVED] fsck.fat 4.1 - File system couldn't be fixed [SOLVED]
On Monday, 14 December 2020 06:07:40 GMT the...@sys-concept.com wrote: > On 12/13/2020 06:33 AM, Victor Ivanov wrote: > [snip] > > > Out of curiosity, do you have the "sys-fs/dosfstools" package installed? > > > > This is the package that provides the fsck.fat binary. It's not a > > dependency of commonly installed system packages so unless you install > > it manually it's probably missing which might explain why fsck is > > exiting with an error code. > > > > - Victor > > Yes, I had this packaged installed, but it did not help. I got hit by > this bug. I'm surprised that it hasn't been discovered earlier. We don't know for sure this was either a fsck bug, or a corrupt ESP vfat fs. We know some kernel couldn't complete its booting process. There could be many other extraneous reasons for it, like missing kernel drivers, missing firmware, incomplete initramfs (if one was being used at the time). There's a difference between troubleshooting a problem patiently until the root cause is established and resolved, Vs trying different things as fast as possible to boot a system. Reverting to old(er) working paradigms, e.g. legacy BIOS and /boot with ext2 fs is not a solution to the original problem, proof of a bug with fsck, proof of a corrupt VFAT, or unsuitability of using an ESP. However, it soon got the PC booting again, so at least it satisfied that objective (booting, sooner). :-) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] nouveau: gr: failed to load firmware "gr/sw_nonctx"
On Monday, 14 December 2020 08:36:03 GMT Neil Bothwick wrote:
> On Sun, 13 Dec 2020 17:32:12 -0700, the...@sys-concept.com wrote:
> > > It means the version you have installed is no longer in the tree. You
> > > should update to the latest.
> >
> > Something is wrong, I just --sync and reinstall linux-firmware but the
> > output is still the same:
> >
> > eix linux-firmware
> > [?] sys-kernel/linux-firmware
> >
> > Available versions: 20200316^bsd 20200421^bsd 20200519^bsd
> >
> > 20200619^bsd 20200721^bsd 20200817^bsd 20200918^bsd 20201022-r2^bstd
> > ***l^bstd {initramfs +redistributable savedconfig
> > unknown-license} Installed versions: 20201022-r3^
> > 20201022-r3^bst(05:30:05 PM 12/13/2020)(redistributable -initramfs
> > -savedconfig -unknown-license)
>
> This shows that you have 20201022-r3 installed but eix says the latest
> available is 20201022-r2 so you have a version it thinks is not in the
> tree.
>
> Did you run eix-update after syncing?
Just sync'ed and on the mirror I used there is no 20201022-r2 version:
$ eix linux-firmware
[I] sys-kernel/linux-firmware
Available versions: 20200316^bsd 20200421^bsd 20200519^bsd 20200619^bsd
20200721^bsd 20200817^bsd 20200918^bsd 20201022-r3^bstd ***l^bstd
{initramfs +redistributable savedconfig unknown-license}
Installed versions: 20201022-r3^bst(08:50:57 26/11/20)(redistributable -
initramfs -savedconfig -unknown-license)
Homepage:https://git.kernel.org/?p=linux/kernel/git/firmware/
linux-firmware.git
Description: Linux firmware files
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] [SOLVED] fsck.fat 4.1 - File system couldn't be fixed [SOLVED]
On Monday, 14 December 2020 05:41:46 GMT Thomas Mueller wrote: > Excerpt from Michael: > > Right, on UEFI MoBos the ESP partition used by the UEFI firmware to locate > > and run *.EFI executables must be FAT32. Such .EFI executables stored on > > the ESP may be OS boot managers/loaders, or other UEFI compatible > > applications. The boot manager loaded by UEFI is then left to its own > > mechanisms (boot loader and fs drivers) to load whatever fs the kernel > > image resides on. > > Is it necessary for the ESP to be FAT32, as opposed to FAT16 or FAT12? Looking again at the UEFI firmware specification it states "... encompasses FAT32 for a system partition, and FAT12 or FAT16 for removable media" and that the "variant of EFI FAT to use is defined by the size of the media". So, there is no *must use FAT32* as such in the specification, although it can be inferred from the way it is written that a system partition, defined as "a contiguous grouping of sectors on the disk", will use FAT32. On removable devices (diskettes) the partition is defined to be the entire media and space limitations apply. Other removable devices may have more space and a call will be made accordingly. I suppose if you have an ESP no larger than 16 MiB (4K clusters) and you can fit all your boot manager/OS loader files in there, you would use FAT12. > What happens if the ESP is formatted FAT12 or FAT16? I expect it would/should be read by the UEFI firmware and is suitable for space limited systems. Most PC installations have GBs of space on their disks, so avoiding FAT32 wouldn't make much sense. > In some cases, ESP might be small enough that FAT32 would not be > appropriate, especially when there is only one OS installation on the disk. > > That would be the case on many MS-Windows or Mac computers, and also other > OSes when installed on a USB stick. > > Tom Right, but a USB stick is probably considered "removable media" and its space could be deemed as limited. I loosely recall AppleMac boot partitions being ~200MB and MSWindows ~300MB, but don't have a machine to hand to check right now. For most use cases even with multiple OSs installed, that's probably enough space to fit FAT32. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: update fails, but I don't see why
On 14/12/20 08:51, Dale wrote: > If you are able, maybe you can compile the bigger packages on a faster > system? If it is a option, it may help. If I have multiple similar machines, I create a shared a shared local repository. Then I run emerge with the settings (can't remember what they are) "use binary if it's there, create binary". That way, especially the big ones, only get built on one machine. Cheers, Wol
Re: [gentoo-user] [SOLVED] fsck.fat 4.1 - File system couldn't be fixed [SOLVED]
On 14/12/20 05:41, Thomas Mueller wrote: > Excerpt from Michael: > >> Right, on UEFI MoBos the ESP partition used by the UEFI firmware to locate >> and >> run *.EFI executables must be FAT32. Such .EFI executables stored on the >> ESP >> may be OS boot managers/loaders, or other UEFI compatible applications. The >> boot manager loaded by UEFI is then left to its own mechanisms (boot loader >> and fs drivers) to load whatever fs the kernel image resides on. > > Is it necessary for the ESP to be FAT32, as opposed to FAT16 or FAT12? > > What happens if the ESP is formatted FAT12 or FAT16? > I think the spec actually says it must comply with a specific version of the FAT definition. Not sure which version, but that does specify all three FAT layouts, so all three are acceptable. Look at mjg's blog for more detail, I guess. That protects against updates to the spec making incompatible changes, but doesn't protect against clueless manufacturers not following the spec - "works with Windows" is so often the de-facto spec. Cheers, Wol
Re: [gentoo-user] nouveau: gr: failed to load firmware "gr/sw_nonctx"
On Monday, 14 December 2020 00:27:03 GMT the...@sys-concept.com wrote: > On 12/13/2020 04:44 PM, Michael wrote: > > On Sunday, 13 December 2020 18:52:51 GMT the...@sys-concept.com wrote: > >> I have "nouveau" build into kernel but it doesn't work: > >> > >> Fom dmesg: > >> > >> nouveau :08:00.0: NVIDIA GP107 (137000a1) > >> nouveau :08:00.0: gr: failed to load firmware "gr/sw_nonctx" > >> nouveau :08:00.0: gr: failed to load gr/sw_nonctx > >> nouveau :08:00.0: DRM: failed to create kernel channel, -22 > >> > >> grep -i nouveau .config > >> CONFIG_DRM_NOUVEAU=y > >> # CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT is not set > >> CONFIG_NOUVEAU_DEBUG=5 > >> CONFIG_NOUVEAU_DEBUG_DEFAULT=3 > >> # CONFIG_NOUVEAU_DEBUG_MMU is not set > >> CONFIG_DRM_NOUVEAU_BACKLIGHT=y > > > > I've never used NVIDIA cards with Gentoo, but in firmware terms you need > > to > > specify in your kernel what firmware you want installed in it. Have a > > look at> > > this guide: > > https://wiki.gentoo.org/wiki/Nouveau/en > > > > and this: > > https://wiki.gentoo.org/wiki/Linux_firmware > > > > You'll need to add the firmware the video card asks for here: > > > > Device Drivers ---> > > > > Generic Driver Options ---> > > > > Firmware loader ---> > > > >-*- Firmware loading facility > >() Build named firmware blobs into the kernel binary <== > > > > In this instance your card NVIDIA GP107 should need '/lib/firmware/nvidia/ > > gp107', so the respective entry for it in the kernel config ought to be: > > > > CONFIG_EXTRA_FIRMWARE="nvidia/gp107" > > > > Someone more clued up on these cards can correct me or add to it. > > Thank you, but I've managed to install "nvidia" following: > https://wiki.gentoo.org/wiki/NVIDIA/nvidia-drivers > > What confused me is the output from two kernels: > > linux-5.4.80-gentoo-r1 > was installed with: genkernel --menuconfig all > and "nouveau" was working OK on that kernel: > > grep CONFIG_EXTRA_FIRMWARE ../linux-5.4.80-gentoo-r1/.config showing: > CONFIG_EXTRA_FIRMWARE="" > > The one below was compiled manually: > grep CONFIG_EXTRA_FIRMWARE ../linux-5.4.72-gentoo/.config > CONFIG_EXTRA_FIRMWARE="" > > Both had same output, so why one kernel was working the other didn't? Were both of these kernels installed with a corresponding correctly functioning initramfs, which had all the requisite files (including -- firmware) to boot with, or only one of them did? Without an initramfs you will need to specify and build any requisite firmware blobs in the kernel image itself, so they are available to the system as it boots up. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: update fails, but I don't see why
n952162 wrote: > > On 12/14/20 4:54 AM, Grant Edwards wrote: >> On 2020-12-13, n952162 wrote: >>> On 12/13/20 9:18 AM, Neil Bothwick wrote: Nearly 2 months, quite a long time in Gentoo update terms. >>> Okay, is the solution then to re-install? >> That's _a_ solution, and might be less work. >> >> But, if you're not going to update more regularly, you're probably >> going to keep running into situations like this. They will require a >> methodical approach, a good understanding of how portage works, and >> will end up taking up more of your time that would updating once a >> week. >> >> -- >> Grant >> >> > > One thing about frequent updating... I thought I was following the > advice here by developing a procedure to update at the start of every > month. When I did that, llvm, rust, clang, firefox, and thunderbird > would rebuild every time, for an average of 4 to 8 hours a piece. If > those things - or their dependencies - are triggered that often, then > it's likely I'll be building them almost every week instead of every > month. > > > > I run unstable on Firefox and it seems to update here about every two weeks or so. It does vary tho. If you run stable, it may not update as often. If build times are a problem, there is a binary version available. I'm not sure what the default settings are for it tho. It seems rust updates about once a month but it to varies a bit. I'm almost certain I run unstable on it as well. For llvm, it goes a while without a update. I show one in May, one in July, one is September and the last one in November. About every other month it seems. It seems we perceive some packages to update more often than they do. I guess we remember having to wait for them more than we do small packages. This is where genlop -t comes in. It will tell you the compile time and shows dates it was done. I used to swear that OOo was updated every week. It took some looking to figure out, it just seemed that way. If you are able, maybe you can compile the bigger packages on a faster system? If it is a option, it may help. Dale :-) :-)
Re: [gentoo-user] Re: update fails, but I don't see why
On Mon, 14 Dec 2020 07:54:55 +0100, n952162 wrote: > One thing about frequent updating... I thought I was following the > advice here by developing a procedure to update at the start of every > month. When I did that, llvm, rust, clang, firefox, and thunderbird > would rebuild every time, for an average of 4 to 8 hours a piece. If > those things - or their dependencies - are triggered that often, then > it's likely I'll be building them almost every week instead of every > month. The more frequently you update, the fewer packages will need to be emerged on each update. Although frequent updates may mean more work overall, they break it into small chunks that are easy to manage, and can also avoid the long lists of warning messages like you have been seeing. -- Neil Bothwick This message has been cruelly tested on sweet little furry animals. pgpeRCwDnb6Vb.pgp Description: OpenPGP digital signature
Re: [gentoo-user] nouveau: gr: failed to load firmware "gr/sw_nonctx"
On Sun, 13 Dec 2020 17:32:12 -0700, the...@sys-concept.com wrote:
> > It means the version you have installed is no longer in the tree. You
> > should update to the latest.
> >
>
> Something is wrong, I just --sync and reinstall linux-firmware but the
> output is still the same:
>
> eix linux-firmware
> [?] sys-kernel/linux-firmware
> Available versions: 20200316^bsd 20200421^bsd 20200519^bsd
> 20200619^bsd 20200721^bsd 20200817^bsd 20200918^bsd 20201022-r2^bstd
> ***l^bstd {initramfs +redistributable savedconfig
> unknown-license} Installed versions: 20201022-r3^
> 20201022-r3^bst(05:30:05 PM 12/13/2020)(redistributable -initramfs
> -savedconfig -unknown-license)
This shows that you have 20201022-r3 installed but eix says the latest
available is 20201022-r2 so you have a version it thinks is not in the
tree.
Did you run eix-update after syncing?
--
Neil Bothwick
Never ask a geek why, just nod your head and slowly back away
pgpptsPhmNcu6.pgp
Description: OpenPGP digital signature
[gentoo-user] [SOLVED] No logging output to tty12
On Sun, Dec 13, 2020 at 11:16:05AM +, Nuno Silva wrote > On 2020-12-12, Walter Dnes wrote: > > > I used to get stuff going to tty12, e.g.when attaching a USB drive, > > etc. My recent fresh install doesn't have this output. What am I doing > > wrong? > > Have you installed something for syslog? In my installs, I think it is > syslog-ng that does this. Thanks; that was my problem. I had installed "sysklogd" but not "syslog-ng". Installing and starting "syslog-ng" now has the messages coming up. I've also added it to default level in rc-update. -- Walter Dnes I don't run "desktop environments"; I run useful applications
