date:20201213


On 12/14/20 1:04 AM, Michael wrote:


If you're running a stable system then you should not *need* to define a
particular python version or python target manually in your USE preferences
configuration and you should not need to add python or any lib packages in
general, in your '/var/lib/portage/world' file.

Portage will take care of python for itself and for any packages which have
python as a dependency.

eselect python list
eselect python update
eselect python cleanup



Ah, I'll investigate update and cleanup, thank you.

Re: [gentoo-user] Re: update fails, but I don't see why




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.

Re: [gentoo-user] update fails, but I don't see why



On 12/13/20 10:39 PM, antlists wrote:

On 13/12/2020 21:02, n952162 wrote:

My problem is I can't find a diagnostic methodology.  The one I most
often hear is, update more often, or trail and error solutions.


Although I haven't yet had the grief of something like this python
thing, I've always found that unmerging everything that clashes (with
care not to break emerge), or *u**pdating everything that will
update*, has always worked for me in the past.



I forgot about that.  That's helped in the past.

Re: [gentoo-user] update fails, but I don't see why



On 12/13/20 10:31 PM, Dale wrote:

I've seen some say
to start at the bottom, then work your way up.  Even with that, it
doesn't help me understand it most times.



It would be cool if the attached vim coloration script would be useful
for somebody.

" vim: tw=0
syn match maskedinstalled "^- [^/]\+/.* (masked by:.*" contains=masked_by
hi maskedinstalled ctermfg=blue
syn match masked_by "(masked by[^)]*)"
hi masked_by ctermfg=black ctermbg=lightblue

syn match section_headers "^!!!.*"
hi section_headers ctermbg=blue ctermfg=white

"syn match slot "^\a\w*-\a\w*/\a\w*\(-\a\w*\)\?:\d\+$"
syn match slot "^\a\w*-\a\w*/\a[0-9A-Za-z_-]*:\d\+$"
hi slot ctermbg=magenta ctermfg=white

syn match offender "  (.*) pulled in by" 
contains=offender_installed,offender_ebuild
hi offender ctermfg=magenta

"  (dev-python/setuptools-36.7.2:0/0::gentoo, installed) pulled in by
"syn match offender_installed "  
(\a\w*-\a\w*/\a\w*-\d\+\.\d\+\.\d\+:\d\+/\d\+::gentoo, installed) .*" contained
"syn match offender_installed "  
(\a\w*-\a\w*/\a\w*-[0-9.]\+\(-r\d\+\)*:\d\+/\d\+::gentoo, installed) .*" 
contained
 syn match offender_installed "  
(\a\w*-\a\w*/\a[0-9A-Za-z_-]*-[0-9.]\+\(_p[0-9]\)\?\(-r\d\+\)*:\d\+/\d\+::gentoo,
 installed) .*" contained
hi offender_installed ctermfg=green

"  (dev-python/setuptools-40.6.3:0/0::gentoo, ebuild scheduled for merge) 
pulled in by
syn match offender_ebuild "  
(\a\w*-\a\w*/\a\w*-[0-9.]\+\(-r[0-9]\+\)\?:\d\+/\d\+::gentoo, ebuild scheduled 
for merge) .*" contained
hi offender_ebuild ctermfg=green ctermbg=yellow

syn match details "^\S*\[[^]]*\] required by .*$" contains=details_list,pkg
syn match details_list "\[.*\]" contained
hi details_list ctermfg=blue

syn match pkg_status "^  ([^:]*[^)]*)" contains=installed,merge
syn match installed "installed" contained
hi installed ctermbg=cyan ctermfg=black
syn match merge "ebuild scheduled for merge"
hi merge ctermbg=cyan ctermfg=blue
syn match pkg "^[^:[]*" contained
hi pkg ctermfg=darkcyan


syn region resolution start="The following keyword changes are necessary to 
proceed:" end="^$"
hi resolution ctermbg=green ctermfg=magenta

syn region caldep start="^Calculating dependencies ( \.)* done!" end="^$" 
contains=assignments
syn match assignments '\w\+="[^\"]*"' contained
hi assignments ctermfg=darkcyan



"[nomerge   ]   dev-libs/libgcrypt-1.8.1:0/20::gentoo  
USE="static-libs -doc" ABI_X86="(64) -32 (-x32)" 
"[ebuild U  ]dev-libs/libgpg-error-1.29::gentoo 
[1.27-r1::gentoo] USE="nls static-libs -common-lisp" ABI_X86="(64) -32 (-x32)" 
874 KiB

syn match dep_nomerge "^\[nomerge...\]\s*.*" 
contains=dep_pkgs,dep_installed,dep_defs
hi dep_nomerge ctermfg=cyan cterm=bold
syn match dep_emerge "^\[ebuild\]\s*.*" 
contains=dep_needed,dep_installed,dep_defs
hi dep_emerge ctermbg=cyan
syn match dep_needed "[a-z_][a-z_0-9-]*/[a-z_][a-z_0-9-]\S*" contained
hi dep_needed ctermbg=blue ctermfg=white
syn match dep_pkgs "[a-z_][a-z_0-9-]*/[a-z_][a-z_0-9-]\S*" contained
hi dep_pkgs ctermfg=blue
syn match dep_installed ".\[[^]]*\]" contained
hi dep_installed ctermbg=green ctermfg=black
syn match dep_defs '\w\+="[^"]*"' contained
hi dep_defs ctermfg=green cterm=bold 

"[blocks B  ] >> Emerging (\d\+ of \d\+) \S\+"
hi emerging ctermfg=darkblue ctermbg=lightblue
syn match installing ">>> Installing (\d\+ of \d\+) \S\+"
hi installing ctermfg=darkgreen ctermbg=lightgreen
syn match failed ">>> Failed to emerge \S\+"
hi failed ctermfg=darkred ctermbg=lightred
syn match failed "Traceback (most recent call last):"


">>> No outdated packages were found on your system.
syn match done ">>> No outdated packages were found on your system."
hi done ctermbg=green ctermfg=black

Re: [gentoo-user] update fails, but I don't see why


That's good.  I'll do that


On 12/13/20 10:40 PM, Dale wrote:

n952162 wrote:

On 12/13/20 10:02 PM, n952162 wrote:

On 12/13/20 9:06 PM, Dale wrote:

Mark Knecht wrote:

On Sun, Dec 13, 2020 at 12:03 PM n952162 mailto:n952...@web.de>> 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?


Personally I wouldn't start with a reinstall.

I'd start with my world file and remove/comment out every
'application' not required to keep the machine running/booting. That
should be nearly everything other than things like grub, your kernels,
hardware drivers, terminals, etc.

NOTE: Just because you comment something out in the world file doesn't
mean it won't run, it just won't get updated or be part of portage's
considerations about what to do.

At that point emerge @world should only be considering, from a build
POV, the stuff you really need.

This python problem everyone is having I cannot help with. Solving
problems like that is why people run Gentoo. With lots of power comes
lots of responsibility. However with all the applications
'unconsidered' you have a chance of getting the really important stuff
built and booting.

If I got that far then I'd start adding apps back in/uncommenting one
or two at a time and see if I could make headway.

I've updated machines that were a year out of date but it took days
and days. If I didn't want to build code every week I decided I
couldn't run Gentoo.

HTH,
Mark

I agree.  I update once a week.  It seems a pretty good balance between
not having to do it to often and not having such drastic changes
that it
makes things hard to work through.

That said, when the tree is in the process of huge changes, it can
create problems even with weekly updates.  Right now, it is python and
the speed it is moving at.  Some versions that have been around for
ages, 2.7, is being removed.  Then python 3.6 is leaving etc etc etc.
Those of us that have been around long enough have seen this with other
packages as well.  Some packages are just hard to upgrade to begin with
and some create circular problems. The longer it goes between updates,
the larger that problem gets to be.  You get two different packages
doing that, you can find yourself running around in circles trying to
get emerge to chew what it can.

While I usually do updates on Sunday evening, I'm considering doing
twice a week, Sunday and Wednesday.  At least until python settles down
a bit. Thing is, I think the worst part may be about over.  I think 2.7
is gone here, I think 3.6 is too.  That's two down.  It seems 3.7 and
above will be around a while but if they start going away soon, I
may do
two updates a week if it starts making updates harder.

Time can be a problem but sometimes it just depends on what packages
have changed and how fast they have changed.  For some systems that
haven't been updated in a while, having to remove python 2.7 and 3.6 in
one go, can cause problems that are hard to get around.  Right now just
isn't a good time to let updates get to far apart.

The only thing that makes some of this survivable, getting help on this
mailing list.  Some people can decode the output of emerge and find a
way to work through it. Some are fairly easy, some not so much.
Sometimes removing/commenting out things in the world file will help.
Sometimes doing @system first helps. Sometimes you just have to update
certain packages in small chunks to get through a upgrade. Finding that
right option sometimes requires help.

Just some thoughts.

Dale

:-)  :-)




My problem is I can't find a diagnostic methodology.  The one I most
often hear is, update more often, or trail and error solutions.

Does all that information in emerge's output point the way to the
problem, and I just have to learn to understand it,  or am I just
wasting my time there?  Are there better tools than log parsing? I know,
there are lots of good tools,  but there needs to be methodology for
using them (like understanding gentoo ;-) )



But commenting stuff out of the world file is at least a path. I'll
start with that tomorrow.






Another option some use, sets.  That way instead of updating world all
in one go, they update sets instead.  Example.  You have several GUIs
installed, KDE, Gnome and maybe even a couple more.  You break those up
into sets for each one.  Most of the time, you may can just update world
all in one go.  At times, it may be easier to update the lighter
desktops first then move to the next until they are all done.  Then
update world which should be a much smaller set of updates since most
updates would already be done.

Quite a few here use sets.  It can work well depending on your setup.
If you do use them, there is people here than can help you work through
issues.  Linkys:

https://wiki.gentoo.org/wiki//etc/portage/sets

https://wiki.gentoo.org/wiki/Package_sets

Last one is about sets already being used.  Good for examples

Re: [gentoo-user] [SOLVED] fsck.fat 4.1 - File system couldn't be fixed [SOLVED]

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.

Re: [gentoo-user] [SOLVED] fsck.fat 4.1 - File system couldn't be fixed [SOLVED]

2020-12-13 Thread Thomas Mueller

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?

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

Re: [gentoo-user] Re: grub-install: warning: File system `ext2' doesn't support embedding.

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'.
> 
> --
> Grant

I don't think so. I just tried made typo.
Instead of running:
grub-install /dev/nvme0n1

I did:
grub-install /dev/nvme0n1p2

It install without any errors.

I've not done any installation for some time, a lot had changed.  It is
a good practice as next PC will be a production PC; so I know to stay
away from "vfat" in boot partition.

[gentoo-user] Re: grub-install: warning: File system `ext2' doesn't support embedding.

2020-12-13 Thread Grant Edwards

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

--
Grant

[gentoo-user] Re: update fails, but I don't see why

2020-12-13 Thread Grant Edwards

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

[gentoo-user] Re: update fails, but I don't see why

2020-12-13 Thread Grant Edwards

On 2020-12-13, Dale  wrote:

> I been using Gentoo for a good long while and most of the time, I still
> can't understand what it spits out onto my screen.

I know what you mean. I've been running Gentoo on mutliple machines
for 20 years now, and I'm still baffled by much of what "emerge"
spews. But, I have developed some heuristics to deal with it. Though
it's frustrating at times, it's still far less frustrating than
Ubuntu, RedHat, SuSe, etc.

It seems like when emerge "highly recommends" running 'emerge
--oneshot portage', emerge will cryptically refuse to do so about half
of the time. :)

--
Grant

Re: [gentoo-user] grub-install: warning: File system `ext2' doesn't support embedding.

On 12/13/2020 08:28 PM, the...@sys-concept.com wrote:
> On 12/13/2020 08:15 PM, 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

Simple mistake it should be:
grub-install /dev/nvme0n1

Re: [gentoo-user] grub-install: warning: File system `ext2' doesn't support embedding.

On 12/13/2020 08:15 PM, 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? 

After rebooting, the system can not find boot disk.

fstab:
/dev/nvme0n1p2  /boot   ext2noauto,noatime  1 2 
/dev/nvme0n1p4  /   ext4noatime 0 1
/dev/nvme0n1p3  noneswapsw  0 0
 
fdisk -l
/dev/nvme0n1p12048   6143   40962M BIOS boot
/dev/nvme0n1p26144 268287 262144  128M EFI System
/dev/nvme0n1p3  26828813168631048576  512M Linux filesystem
/dev/nvme0n1p4 1316864 3907027119 3905710256  1.8T Linux filesystem

Do I need to go to "vfat" for /boot partition?
Why isn't it working?

[gentoo-user] grub-install: warning: File system `ext2' doesn't support embedding.

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?

Re: [gentoo-user] nvidia: loading out-of-tree module taints kernel

2020-12-13 Thread David Haller

Hello,

On Sun, 13 Dec 2020, the...@sys-concept.com wrote:
>dmesg |grep nvidia
> nvidia: loading out-of-tree module taints kernel.
> nvidia: module license 'NVIDIA' taints kernel.
 ^^^
[..]
>Why this error message?  

There is no error.
See 

-dnh

-- 
"The command 'man man' works fine, but 'man woman' produces:
 No manual entry for woman."-- Constantinos Maltezos

Re: [gentoo-user] how to control "forcefsck"

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"

[gentoo-user] how to control "forcefsck"



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

Re: [gentoo-user] nvidia: loading out-of-tree module taints kernel

On 12/13/2020 05:48 PM, the...@sys-concept.com wrote:
> I'm loading nvidia via:  /etc/modules-load.d/video.conf
> 
> but when kernel boots, there is a error message: 
> 
> Failed to load nvidia
> 
> dmesg |grep nvidia
>  nvidia: loading out-of-tree module taints kernel.
>  nvidia: module license 'NVIDIA' taints kernel.
>  nvidia-nvlink: Nvlink Core is being initialized, major device number 246
>  nvidia :08:00.0: vgaarb: changed VGA decodes: 
> olddecodes=io+mem,decodes=none:owns=io+mem
>  nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 
>  455.28  Wed Sep 30 00:58:12 UTC 2020
> [drm] [nvidia-drm] [GPU ID 0x0800] Loading driver
> [drm] Initialized nvidia-drm 0.0.0 20160202 for :08:00.0 on minor 0
> nvidia-smi (1442) used greatest stack depth: 12624 bytes left
> caller _nv000708rm+0x1af/0x200 [nvidia] mapping multiple BARs
> 
> Why this error message?  

and yes, I run:
emerge -1 @module-rebuild

[gentoo-user] nvidia: loading out-of-tree module taints kernel

I'm loading nvidia via:  /etc/modules-load.d/video.conf

but when kernel boots, there is a error message: 

Failed to load nvidia

dmesg |grep nvidia
 nvidia: loading out-of-tree module taints kernel.
 nvidia: module license 'NVIDIA' taints kernel.
 nvidia-nvlink: Nvlink Core is being initialized, major device number 246
 nvidia :08:00.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=none:owns=io+mem
 nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms  
455.28  Wed Sep 30 00:58:12 UTC 2020
[drm] [nvidia-drm] [GPU ID 0x0800] Loading driver
[drm] Initialized nvidia-drm 0.0.0 20160202 for :08:00.0 on minor 0
nvidia-smi (1442) used greatest stack depth: 12624 bytes left
caller _nv000708rm+0x1af/0x200 [nvidia] mapping multiple BARs

Why this error message?

Re: [gentoo-user] nouveau: gr: failed to load firmware "gr/sw_nonctx"

On 12/13/2020 04:33 PM, Neil Bothwick wrote:
> On Sun, 13 Dec 2020 11:52:51 -0700, the...@sys-concept.com wrote:
> 
>> I have "linux-firmware" installed but there is a "?" mark beside it
>>
>> eix linux-firmware
>> [?] sys-kernel/linux-firmware
>> Installed versions:  20201022-r3
>>
> 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^bst(05:30:05 PM 
12/13/2020)(redistributable -initramfs -savedconfig -unknown-license)
 Homepage:
https://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git
 Description: Linux firmware files

Re: [gentoo-user] nouveau: gr: failed to load firmware "gr/sw_nonctx"

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?

Re: [gentoo-user] update fails, but I don't see why

On Sunday, 13 December 2020 21:10:14 GMT n952162 wrote:
> On 12/13/20 10:55 AM, Michael wrote:
> > On Sunday, 13 December 2020 08:57:53 GMT n952162 wrote:

> >> $ sed -n -e '/^\s*#/d' -e '/python3_6/p' /etc/portage/package.use/*
> >> 
> >>> =dev-python/certifi-10001-r1 python_targets_python3_6
> >>> =dev-python/setuptools_scm-4.1.2-r1 python_targets_python3_6
> >>> =dev-python/requests-2.24.0-r1 python_targets_python3_6
> >>> =dev-python/chardet-3.0.4-r1 python_targets_python3_6
> >>> =dev-python/idna-2.10-r1 python_targets_python3_6
> >>> =dev-python/urllib3-1.25.11 python_targets_python3_6
> >>> =dev-python/cryptography-3.2.1 python_targets_python3_6
> >>> =dev-python/cffi-1.14.0-r3 python_targets_python3_6
> >>> =dev-python/pycparser-2.20-r1 python_targets_python3_6
> >>> =dev-python/ply-3.11-r1 python_targets_python3_6
> >>> =dev-python/PySocks-1.7.1-r1 python_targets_python3_6
> >>> =dev-python/pyopenssl-19.1.0-r1 python_targets_python3_6
> >>> =dev-python/setuptools-50.3.0 python_targets_python3_6
> >>> =dev-python/six-1.15.0-r1 python_targets_python3_6
> > 
> > Why had you set up these in your package.use?
> 
> Basically, whenever emerge tells me I need USE variables, I define them.
> 
> It's not clear to me how I should know to override that, for example, to
> say, oh that's not needed anymore.

If you're running a stable system then you should not *need* to define a 
particular python version or python target manually in your USE preferences 
configuration and you should not need to add python or any lib packages in 
general, in your '/var/lib/portage/world' file.

Portage will take care of python for itself and for any packages which have 
python as a dependency.

eselect python list
eselect python update
eselect python cleanup

and running emerge --depclean -v -a

after a new python version arrives should keep your system stable without any 
more clashes, in most cases.  The devs usually do a very good job in leaving 
the stable tree in a ... stable condition.  :-)

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

Re: [gentoo-user] nouveau: gr: failed to load firmware "gr/sw_nonctx"

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.

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

Re: [gentoo-user] update fails, but I don't see why

On Sun, 13 Dec 2020 22:02:44 +0100, n952162 wrote:

> My problem is I can't find a diagnostic methodology.  The one I most
> often hear is, update more often, or trail and error solutions.

Neither of which is a diagnostic methodology.

> Does all that information in emerge's output point the way to the
> problem, and I just have to learn to understand it,

Yes. The output is there for a reason, work though it carefully. Most
importantly, try to fix one problem at a time. The number f new threads
you have started with different problems show how not doing that can lead
to even more confusion.

-- 
Neil Bothwick

If you don't pay your exorcist, you get repossessed.

pgpbjhIl3mMa4.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] update fails, but I don't see why

On Sun, 13 Dec 2020 19:58:40 +0100, n952162 wrote:

> > Nearly 2 months, quite a long time in Gentoo update terms.

> Okay, is the solution then to re-install?

Reinstalling is never a solution, just a way to run away from the
problem, until it happens again.

The solution is to work through the issues and update your system, then
don't leave it so long next time.

-- 
Neil Bothwick

A bit of tolerance is worth a megabyte of flaming. -- Henry Spencer

pgpPVxv1o9idA.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] nouveau: gr: failed to load firmware "gr/sw_nonctx"

On Sun, 13 Dec 2020 11:52:51 -0700, the...@sys-concept.com wrote:

> I have "linux-firmware" installed but there is a "?" mark beside it
> 
> eix linux-firmware
> [?] sys-kernel/linux-firmware
> Installed versions:  20201022-r3
> 
It means the version you have installed is no longer in the tree. You
should update to the latest.


-- 
Neil Bothwick

"RAM DISK is NOT an installation procedure!"


pgpG9QDgQDFMj.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] update fails, but I don't see why

2020-12-13 Thread Walter Dnes

On Sun, Dec 13, 2020 at 11:07:42AM +0100, n952162 wrote
> 
> If rust, llvm, firefox or thunderbird is in that list, I'll go crazy.

  You can "unmerge rust", followed by "emerge rust-bin" as a drop-in
replacement.  The same option is possible with firefox-bin, but
firefox-bin is hard-coded to require pulseaudio, which some people
abhor.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] update fails, but I don't see why

n952162 wrote:
> On 12/13/20 10:55 AM, Michael wrote:
>> On Sunday, 13 December 2020 08:57:53 GMT n952162 wrote:
>>> On 12/13/20 9:18 AM, Neil Bothwick wrote:
 There's a lot to trawl through here, it looks like you haven't updated

>> for quite some time.
> The (compressed) log of  a system and world update from 20. October
> (2020!) is attached.
 Nearly 2 months, quite a long time in Gentoo update terms.
>>> !!!  After 2 months the system can no longer be update-able?
>> A system can be updated and updatable after more than two months, but be
>> prepared for some manual intervention and a staged approach to
>> running emerge.
>
>
> (I just discoved your posting, thank you)
>
> By staged approach, you mean first @system and then @world?  I've just
> realized that doing this doesn't bring anything ;-)
>
>     emerge ... @system @world


That should be emerge ... @system and when you get that done, then do
emerge ... @world.  Sometimes that helps, sometimes not.  When stuck,
it's worth a try. 


>
>
>> Starting with 'eselect news read new' is advisable for any heads up
>> to changes
>> in gentoo, major packages and configuration.
>
>
> Yeah, except I wouldn't know what to do about it.
>

Almost all the time, the news item tells you if you need to do something
and what to do.  If not, it usually contains a link that explains what
is going on and what to do.  Some, maybe most, are also targeted in a
way that they only display IF they affect your system.  Example. 
Something only affects KDE and you don't have anything KDE installed. 
It won't display since it doesn't affect you.  If you do have KDE or
part of KDE installed, then it shows up.


>
>>
>> Also pay attention to any messages on the CLI when you run emerge about
>> packages which are due to be removed from portage, as you will need
>> to take
>> care of these manually in your local or some external 3rd party overlay.
>
>
> You mean, like get them out of my world file?
>
>
>>
>>
 ...

>>     What do
>>
>> grep -r python3_6 /etc/portage
> That showed that the only references are in package.use
 But what does it show. We need the output of commands, not some vague
 reference to them. I suspected there was something in package.use,
 but we
 need to know what. Those references should probably be removed but
 no one
 can say for sure without seeing them.
>>> Oh sorry.  You mentioned
>>>
>>> PYTHON_TARGETS="python3_6"
>>>
>>> and I didn't connect that with USE variables.  Here there are (with
>>> comments
>>> removed)
>> It isn't just USE flags for python-3.6 you may have set up yourself,
>> but USE
>> flags for any python version you have specified.  Under normal
>> circumstances
>> you would not need to specify these yourself and pegging python at a
>> particular version is bound to cause warnings later on, when that python
>> version has been deprecated and is no longer available in portage.
>>
>>
>>> $ sed -n -e '/^\s*#/d' -e '/python3_6/p' /etc/portage/package.use/*
>>>
 =dev-python/certifi-10001-r1 python_targets_python3_6
 =dev-python/setuptools_scm-4.1.2-r1 python_targets_python3_6
 =dev-python/requests-2.24.0-r1 python_targets_python3_6
 =dev-python/chardet-3.0.4-r1 python_targets_python3_6
 =dev-python/idna-2.10-r1 python_targets_python3_6
 =dev-python/urllib3-1.25.11 python_targets_python3_6
 =dev-python/cryptography-3.2.1 python_targets_python3_6
 =dev-python/cffi-1.14.0-r3 python_targets_python3_6
 =dev-python/pycparser-2.20-r1 python_targets_python3_6
 =dev-python/ply-3.11-r1 python_targets_python3_6
 =dev-python/PySocks-1.7.1-r1 python_targets_python3_6
 =dev-python/pyopenssl-19.1.0-r1 python_targets_python3_6
 =dev-python/setuptools-50.3.0 python_targets_python3_6
 =dev-python/six-1.15.0-r1 python_targets_python3_6
>> Why had you set up these in your package.use?
>
>
> Basically, whenever emerge tells me I need USE variables, I define them.
>
> It's not clear to me how I should know to override that, for example, to
> say, oh that's not needed anymore.
>
>

I use eix-test-obsolete to find most of those.  Keep in mind, there may
be times when it says something is redundant when it isn't.  Example.  I
run unstable KDE here.  I have all of KDE listed in package.keyword. 
However, if all of KDE that is installed is stable, it says it is
redundant and can be removed.  However, a week or so later, I'll need
them again when the next unstable release hits the tree.  One has to
think about what goes and what stays. 


>>
>> If you comment them out and re-run emerge are you getting any more
>> warnings/
>> errors?
>
>
> Yes, those are all gone.
>
>
> .
>


Dale

:-)  :-)

Re: [gentoo-user] update fails, but I don't see why

n952162 wrote:
> On 12/13/20 10:02 PM, n952162 wrote:
>> On 12/13/20 9:06 PM, Dale wrote:
>>> Mark Knecht wrote:

 On Sun, Dec 13, 2020 at 12:03 PM 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?
>
 Personally I wouldn't start with a reinstall.

 I'd start with my world file and remove/comment out every
 'application' not required to keep the machine running/booting. That
 should be nearly everything other than things like grub, your kernels,
 hardware drivers, terminals, etc.

 NOTE: Just because you comment something out in the world file doesn't
 mean it won't run, it just won't get updated or be part of portage's
 considerations about what to do.

 At that point emerge @world should only be considering, from a build
 POV, the stuff you really need.

 This python problem everyone is having I cannot help with. Solving
 problems like that is why people run Gentoo. With lots of power comes
 lots of responsibility. However with all the applications
 'unconsidered' you have a chance of getting the really important stuff
 built and booting.

 If I got that far then I'd start adding apps back in/uncommenting one
 or two at a time and see if I could make headway.

 I've updated machines that were a year out of date but it took days
 and days. If I didn't want to build code every week I decided I
 couldn't run Gentoo.

 HTH,
 Mark
>>>
>>> I agree.  I update once a week.  It seems a pretty good balance between
>>> not having to do it to often and not having such drastic changes
>>> that it
>>> makes things hard to work through.
>>>
>>> That said, when the tree is in the process of huge changes, it can
>>> create problems even with weekly updates.  Right now, it is python and
>>> the speed it is moving at.  Some versions that have been around for
>>> ages, 2.7, is being removed.  Then python 3.6 is leaving etc etc etc.
>>> Those of us that have been around long enough have seen this with other
>>> packages as well.  Some packages are just hard to upgrade to begin with
>>> and some create circular problems. The longer it goes between updates,
>>> the larger that problem gets to be.  You get two different packages
>>> doing that, you can find yourself running around in circles trying to
>>> get emerge to chew what it can.
>>>
>>> While I usually do updates on Sunday evening, I'm considering doing
>>> twice a week, Sunday and Wednesday.  At least until python settles down
>>> a bit. Thing is, I think the worst part may be about over.  I think 2.7
>>> is gone here, I think 3.6 is too.  That's two down.  It seems 3.7 and
>>> above will be around a while but if they start going away soon, I
>>> may do
>>> two updates a week if it starts making updates harder.
>>>
>>> Time can be a problem but sometimes it just depends on what packages
>>> have changed and how fast they have changed.  For some systems that
>>> haven't been updated in a while, having to remove python 2.7 and 3.6 in
>>> one go, can cause problems that are hard to get around.  Right now just
>>> isn't a good time to let updates get to far apart.
>>>
>>> The only thing that makes some of this survivable, getting help on this
>>> mailing list.  Some people can decode the output of emerge and find a
>>> way to work through it. Some are fairly easy, some not so much.
>>> Sometimes removing/commenting out things in the world file will help.
>>> Sometimes doing @system first helps. Sometimes you just have to update
>>> certain packages in small chunks to get through a upgrade. Finding that
>>> right option sometimes requires help.
>>>
>>> Just some thoughts.
>>>
>>> Dale
>>>
>>> :-)  :-)
>>>
>>>
>>>
>>
>> My problem is I can't find a diagnostic methodology.  The one I most
>> often hear is, update more often, or trail and error solutions.
>>
>> Does all that information in emerge's output point the way to the
>> problem, and I just have to learn to understand it,  or am I just
>> wasting my time there?  Are there better tools than log parsing? I know,
>> there are lots of good tools,  but there needs to be methodology for
>> using them (like understanding gentoo ;-) )
>>
>>
>
> But commenting stuff out of the world file is at least a path. I'll
> start with that tomorrow.
>
>
>
>


Another option some use, sets.  That way instead of updating world all
in one go, they update sets instead.  Example.  You have several GUIs
installed, KDE, Gnome and maybe even a couple more.  You break those up
into sets for each one.  Most of the time, you may can just update world
all in one go.  At times, it may be easier to update the lighter
desktops first then move to the next until they are all done.  Then
update world which should be a much smaller set of updates since most

Re: [gentoo-user] update fails, but I don't see why

2020-12-13 Thread antlists


On 13/12/2020 21:02, n952162 wrote:

My problem is I can't find a diagnostic methodology.  The one I most
often hear is, update more often, or trail and error solutions.

Although I haven't yet had the grief of something like this python 
thing, I've always found that unmerging everything that clashes (with 
care not to break emerge), or updating everything that will update, has 
always worked for me in the past.



Does all that information in emerge's output point the way to the
problem, and I just have to learn to understand it,  or am I just
wasting my time there?  Are there better tools than log parsing? I know,
there are lots of good tools,  but there needs to be methodology for
using them (like understanding gentoo ;-) )


Isn't that one of the major points of gentoo - that you need to 
understand what you're doing?


One more tip I'll give you. In package.use, a lot of your lines start 
with ">=". That means "any package equal or newer". If you change that 
to "=", it'll fix the current problem, but it'll come back with the next 
upgrade (or not). If you're having troubles upgrading anyway, getting 
rid of the ">" on stuff that's already problematic might make the 
underlying problem easier to understand. Especially if it's python :-)


Cheers,
Wol

Re: [gentoo-user] update fails, but I don't see why

n952162 wrote:
> On 12/13/20 9:06 PM, Dale wrote:
>>
>> I agree.  I update once a week.  It seems a pretty good balance between
>> not having to do it to often and not having such drastic changes that it
>> makes things hard to work through.
>>
>> That said, when the tree is in the process of huge changes, it can
>> create problems even with weekly updates.  Right now, it is python and
>> the speed it is moving at.  Some versions that have been around for
>> ages, 2.7, is being removed.  Then python 3.6 is leaving etc etc etc.
>> Those of us that have been around long enough have seen this with other
>> packages as well.  Some packages are just hard to upgrade to begin with
>> and some create circular problems. The longer it goes between updates,
>> the larger that problem gets to be.  You get two different packages
>> doing that, you can find yourself running around in circles trying to
>> get emerge to chew what it can.
>>
>> While I usually do updates on Sunday evening, I'm considering doing
>> twice a week, Sunday and Wednesday.  At least until python settles down
>> a bit. Thing is, I think the worst part may be about over.  I think 2.7
>> is gone here, I think 3.6 is too.  That's two down.  It seems 3.7 and
>> above will be around a while but if they start going away soon, I may do
>> two updates a week if it starts making updates harder.
>>
>> Time can be a problem but sometimes it just depends on what packages
>> have changed and how fast they have changed.  For some systems that
>> haven't been updated in a while, having to remove python 2.7 and 3.6 in
>> one go, can cause problems that are hard to get around.  Right now just
>> isn't a good time to let updates get to far apart.
>>
>> The only thing that makes some of this survivable, getting help on this
>> mailing list.  Some people can decode the output of emerge and find a
>> way to work through it. Some are fairly easy, some not so much.
>> Sometimes removing/commenting out things in the world file will help.
>> Sometimes doing @system first helps. Sometimes you just have to update
>> certain packages in small chunks to get through a upgrade.  Finding that
>> right option sometimes requires help.
>>
>> Just some thoughts.
>>
>> Dale
>>
>> :-)  :-)
>>
>>
>>
>
> My problem is I can't find a diagnostic methodology.  The one I most
> often hear is, update more often, or trail and error solutions.
>
> Does all that information in emerge's output point the way to the
> problem, and I just have to learn to understand it,  or am I just
> wasting my time there?  Are there better tools than log parsing? I know,
> there are lots of good tools,  but there needs to be methodology for
> using them (like understanding gentoo ;-) )
>
>
>


I been using Gentoo for a good long while and most of the time, I still
can't understand what it spits out onto my screen.  I've seen some say
to start at the bottom, then work your way up.  Even with that, it
doesn't help me understand it most times.  Generally, I do some trial
and error.  If that fails, post to this list including everything I can
that is relevant. 

I think the thing that has helped me the most, good defaults when
updating the system.  I set the -1 emerge option as a default to keep
the world file clean.  After that, the rest is about updating as deep as
I can to keep things as sane as possible.  Sure, it may update things
other options would leave out but it gives me a more stable system. 
It's rare that I have software crash.  It happens but is usually cleared
up with the next upgrade.  I don't have them because of some mismatch
between different versions of software tho.  Doing just a plain emerge
-u world is not near as good as emerge -uUDN world.  Just the -D will
make a big difference.

I posted this before but not sure what thread it was.  This is my
default options from make.conf.  Keep in mind, this links to the real
one in /etc/portage.  I'm still used to the old location.


root@fireball / # cat /etc/make.conf | grep emerge
EMERGE_DEFAULT_OPTS="--with-bdeps y --backtrack=100 --keep-going -v -j5
--quiet-build=n -1 --unordered-display"
root@fireball / #


I haven't adjusted that in a while but may look into it later.  I've
seen a few posts about some new options.  Over the years tho, that has
given me a pretty stable system.  Depending on what packages are getting
updated upstream, one may can wait a month or so between updates.  At
times tho, weekly may be a lot easier.  It reminds me of the old
question; how do you eat a elephant?  One bite at a time is a lot easier
than trying to swallow it whole.  Updating a Gentoo system is sort of
the same way.  It is a lot easier than it was 10 or 15 years ago tho. 

Just some ideas and how I do things.  Your mileage may vary. 

Dale

:-)  :-)

Re: [gentoo-user] update fails, but I don't see why


On 12/13/20 10:02 PM, n952162 wrote:

On 12/13/20 9:06 PM, Dale wrote:

Mark Knecht wrote:


On Sun, Dec 13, 2020 at 12:03 PM n952162 mailto:n952...@web.de>> 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?


Personally I wouldn't start with a reinstall.

I'd start with my world file and remove/comment out every
'application' not required to keep the machine running/booting. That
should be nearly everything other than things like grub, your kernels,
hardware drivers, terminals, etc.

NOTE: Just because you comment something out in the world file doesn't
mean it won't run, it just won't get updated or be part of portage's
considerations about what to do.

At that point emerge @world should only be considering, from a build
POV, the stuff you really need.

This python problem everyone is having I cannot help with. Solving
problems like that is why people run Gentoo. With lots of power comes
lots of responsibility. However with all the applications
'unconsidered' you have a chance of getting the really important stuff
built and booting.

If I got that far then I'd start adding apps back in/uncommenting one
or two at a time and see if I could make headway.

I've updated machines that were a year out of date but it took days
and days. If I didn't want to build code every week I decided I
couldn't run Gentoo.

HTH,
Mark


I agree.  I update once a week.  It seems a pretty good balance between
not having to do it to often and not having such drastic changes that it
makes things hard to work through.

That said, when the tree is in the process of huge changes, it can
create problems even with weekly updates.  Right now, it is python and
the speed it is moving at.  Some versions that have been around for
ages, 2.7, is being removed.  Then python 3.6 is leaving etc etc etc.
Those of us that have been around long enough have seen this with other
packages as well.  Some packages are just hard to upgrade to begin with
and some create circular problems. The longer it goes between updates,
the larger that problem gets to be.  You get two different packages
doing that, you can find yourself running around in circles trying to
get emerge to chew what it can.

While I usually do updates on Sunday evening, I'm considering doing
twice a week, Sunday and Wednesday.  At least until python settles down
a bit. Thing is, I think the worst part may be about over.  I think 2.7
is gone here, I think 3.6 is too.  That's two down.  It seems 3.7 and
above will be around a while but if they start going away soon, I may do
two updates a week if it starts making updates harder.

Time can be a problem but sometimes it just depends on what packages
have changed and how fast they have changed.  For some systems that
haven't been updated in a while, having to remove python 2.7 and 3.6 in
one go, can cause problems that are hard to get around.  Right now just
isn't a good time to let updates get to far apart.

The only thing that makes some of this survivable, getting help on this
mailing list.  Some people can decode the output of emerge and find a
way to work through it. Some are fairly easy, some not so much.
Sometimes removing/commenting out things in the world file will help.
Sometimes doing @system first helps. Sometimes you just have to update
certain packages in small chunks to get through a upgrade. Finding that
right option sometimes requires help.

Just some thoughts.

Dale

:-)  :-)





My problem is I can't find a diagnostic methodology.  The one I most
often hear is, update more often, or trail and error solutions.

Does all that information in emerge's output point the way to the
problem, and I just have to learn to understand it,  or am I just
wasting my time there?  Are there better tools than log parsing? I know,
there are lots of good tools,  but there needs to be methodology for
using them (like understanding gentoo ;-) )




But commenting stuff out of the world file is at least a path. I'll
start with that tomorrow.

Re: [gentoo-user] update fails, but I don't see why


On 12/13/20 10:55 AM, Michael wrote:

On Sunday, 13 December 2020 08:57:53 GMT n952162 wrote:

On 12/13/20 9:18 AM, Neil Bothwick wrote:

There's a lot to trawl through here, it looks like you haven't updated


for quite some time.

The (compressed) log of  a system and world update from 20. October
(2020!) is attached.

Nearly 2 months, quite a long time in Gentoo update terms.

!!!  After 2 months the system can no longer be update-able?

A system can be updated and updatable after more than two months, but be
prepared for some manual intervention and a staged approach to running emerge.



(I just discoved your posting, thank you)

By staged approach, you mean first @system and then @world?  I've just
realized that doing this doesn't bring anything ;-)

    emerge ... @system @world



Starting with 'eselect news read new' is advisable for any heads up to changes
in gentoo, major packages and configuration.



Yeah, except I wouldn't know what to do about it.




Also pay attention to any messages on the CLI when you run emerge about
packages which are due to be removed from portage, as you will need to take
care of these manually in your local or some external 3rd party overlay.



You mean, like get them out of my world file?






...


What do

grep -r python3_6 /etc/portage

That showed that the only references are in package.use

But what does it show. We need the output of commands, not some vague
reference to them. I suspected there was something in package.use, but we
need to know what. Those references should probably be removed but no one
can say for sure without seeing them.

Oh sorry.  You mentioned

PYTHON_TARGETS="python3_6"

and I didn't connect that with USE variables.  Here there are (with comments
removed)

It isn't just USE flags for python-3.6 you may have set up yourself, but USE
flags for any python version you have specified.  Under normal circumstances
you would not need to specify these yourself and pegging python at a
particular version is bound to cause warnings later on, when that python
version has been deprecated and is no longer available in portage.



$ sed -n -e '/^\s*#/d' -e '/python3_6/p' /etc/portage/package.use/*


=dev-python/certifi-10001-r1 python_targets_python3_6
=dev-python/setuptools_scm-4.1.2-r1 python_targets_python3_6
=dev-python/requests-2.24.0-r1 python_targets_python3_6
=dev-python/chardet-3.0.4-r1 python_targets_python3_6
=dev-python/idna-2.10-r1 python_targets_python3_6
=dev-python/urllib3-1.25.11 python_targets_python3_6
=dev-python/cryptography-3.2.1 python_targets_python3_6
=dev-python/cffi-1.14.0-r3 python_targets_python3_6
=dev-python/pycparser-2.20-r1 python_targets_python3_6
=dev-python/ply-3.11-r1 python_targets_python3_6
=dev-python/PySocks-1.7.1-r1 python_targets_python3_6
=dev-python/pyopenssl-19.1.0-r1 python_targets_python3_6
=dev-python/setuptools-50.3.0 python_targets_python3_6
=dev-python/six-1.15.0-r1 python_targets_python3_6

Why had you set up these in your package.use?



Basically, whenever emerge tells me I need USE variables, I define them.

It's not clear to me how I should know to override that, for example, to
say, oh that's not needed anymore.




If you comment them out and re-run emerge are you getting any more warnings/
errors?



Yes, those are all gone.

Re: [gentoo-user] update fails, but I don't see why


On 12/13/20 9:06 PM, Dale wrote:

Mark Knecht wrote:


On Sun, Dec 13, 2020 at 12:03 PM n952162 mailto:n952...@web.de>> 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?


Personally I wouldn't start with a reinstall.

I'd start with my world file and remove/comment out every
'application' not required to keep the machine running/booting. That
should be nearly everything other than things like grub, your kernels,
hardware drivers, terminals, etc.

NOTE: Just because you comment something out in the world file doesn't
mean it won't run, it just won't get updated or be part of portage's
considerations about what to do.

At that point emerge @world should only be considering, from a build
POV, the stuff you really need.

This python problem everyone is having I cannot help with. Solving
problems like that is why people run Gentoo. With lots of power comes
lots of responsibility. However with all the applications
'unconsidered' you have a chance of getting the really important stuff
built and booting.

If I got that far then I'd start adding apps back in/uncommenting one
or two at a time and see if I could make headway.

I've updated machines that were a year out of date but it took days
and days. If I didn't want to build code every week I decided I
couldn't run Gentoo.

HTH,
Mark


I agree.  I update once a week.  It seems a pretty good balance between
not having to do it to often and not having such drastic changes that it
makes things hard to work through.

That said, when the tree is in the process of huge changes, it can
create problems even with weekly updates.  Right now, it is python and
the speed it is moving at.  Some versions that have been around for
ages, 2.7, is being removed.  Then python 3.6 is leaving etc etc etc.
Those of us that have been around long enough have seen this with other
packages as well.  Some packages are just hard to upgrade to begin with
and some create circular problems. The longer it goes between updates,
the larger that problem gets to be.  You get two different packages
doing that, you can find yourself running around in circles trying to
get emerge to chew what it can.

While I usually do updates on Sunday evening, I'm considering doing
twice a week, Sunday and Wednesday.  At least until python settles down
a bit. Thing is, I think the worst part may be about over.  I think 2.7
is gone here, I think 3.6 is too.  That's two down.  It seems 3.7 and
above will be around a while but if they start going away soon, I may do
two updates a week if it starts making updates harder.

Time can be a problem but sometimes it just depends on what packages
have changed and how fast they have changed.  For some systems that
haven't been updated in a while, having to remove python 2.7 and 3.6 in
one go, can cause problems that are hard to get around.  Right now just
isn't a good time to let updates get to far apart.

The only thing that makes some of this survivable, getting help on this
mailing list.  Some people can decode the output of emerge and find a
way to work through it. Some are fairly easy, some not so much.
Sometimes removing/commenting out things in the world file will help.
Sometimes doing @system first helps. Sometimes you just have to update
certain packages in small chunks to get through a upgrade.  Finding that
right option sometimes requires help.

Just some thoughts.

Dale

:-)  :-)





My problem is I can't find a diagnostic methodology.  The one I most
often hear is, update more often, or trail and error solutions.

Does all that information in emerge's output point the way to the
problem, and I just have to learn to understand it,  or am I just
wasting my time there?  Are there better tools than log parsing? I know,
there are lots of good tools,  but there needs to be methodology for
using them (like understanding gentoo ;-) )

Re: [gentoo-user] update fails, but I don't see why

2020-12-13 Thread Arve Barsnes

On Sun, 13 Dec 2020 at 20:52, n952162  wrote:
>
> I have this funny pkg entry in the emerge log:
>
> dev-python/setuptools[python_targets_python2_7(-),-python_single_target_python2_7(-)]
> required by (dev-python/ipaddress-1.0.23:0/0::gentoo, installed) USE=""
> ABI_X86="(64)" PYTHON_TARGETS="python2_7"

Didn't we go over this last week? You need to run a depclean to get
rid of old packages like dev-python/ipaddress which no longer are in
the tree. They were removed exactly because they create problems like
this.

Regards,
Arve

Re: [gentoo-user] update fails, but I don't see why

Mark Knecht wrote:
>
>
> On Sun, Dec 13, 2020 at 12:03 PM 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?
> >
>
> Personally I wouldn't start with a reinstall.
>
> I'd start with my world file and remove/comment out every
> 'application' not required to keep the machine running/booting. That
> should be nearly everything other than things like grub, your kernels,
> hardware drivers, terminals, etc. 
>
> NOTE: Just because you comment something out in the world file doesn't
> mean it won't run, it just won't get updated or be part of portage's
> considerations about what to do.
>
> At that point emerge @world should only be considering, from a build
> POV, the stuff you really need.
>
> This python problem everyone is having I cannot help with. Solving
> problems like that is why people run Gentoo. With lots of power comes
> lots of responsibility. However with all the applications
> 'unconsidered' you have a chance of getting the really important stuff
> built and booting.
>
> If I got that far then I'd start adding apps back in/uncommenting one
> or two at a time and see if I could make headway.
>
> I've updated machines that were a year out of date but it took days
> and days. If I didn't want to build code every week I decided I
> couldn't run Gentoo.
>
> HTH,
> Mark

I agree.  I update once a week.  It seems a pretty good balance between
not having to do it to often and not having such drastic changes that it
makes things hard to work through. 

That said, when the tree is in the process of huge changes, it can
create problems even with weekly updates.  Right now, it is python and
the speed it is moving at.  Some versions that have been around for
ages, 2.7, is being removed.  Then python 3.6 is leaving etc etc etc. 
Those of us that have been around long enough have seen this with other
packages as well.  Some packages are just hard to upgrade to begin with
and some create circular problems. The longer it goes between updates,
the larger that problem gets to be.  You get two different packages
doing that, you can find yourself running around in circles trying to
get emerge to chew what it can. 

While I usually do updates on Sunday evening, I'm considering doing
twice a week, Sunday and Wednesday.  At least until python settles down
a bit. Thing is, I think the worst part may be about over.  I think 2.7
is gone here, I think 3.6 is too.  That's two down.  It seems 3.7 and
above will be around a while but if they start going away soon, I may do
two updates a week if it starts making updates harder. 

Time can be a problem but sometimes it just depends on what packages
have changed and how fast they have changed.  For some systems that
haven't been updated in a while, having to remove python 2.7 and 3.6 in
one go, can cause problems that are hard to get around.  Right now just
isn't a good time to let updates get to far apart. 

The only thing that makes some of this survivable, getting help on this
mailing list.  Some people can decode the output of emerge and find a
way to work through it. Some are fairly easy, some not so much. 
Sometimes removing/commenting out things in the world file will help.
Sometimes doing @system first helps. Sometimes you just have to update
certain packages in small chunks to get through a upgrade.  Finding that
right option sometimes requires help. 

Just some thoughts.

Dale

:-)  :-)

Re: [gentoo-user] update fails, but I don't see why

2020-12-13 Thread cal

On 12/13/20 11:31 AM, n952162 wrote:

On 12/13/20 1:09 AM, Dan Egli wrote:

Have to agree with Neil on this one. You've got a LOT of updates.
World is great, but start with emerge -UDuv @system, after you find
the culprit that is still setting python3_6 as a target. Once the
system emerge is done then you can try world again and hopefully get a
much smaller list. We can help you much better from there.

python3_6 is bad, I've got that now, but lots and lots of packages have
something similar to this:

PYTHON_TARGETS="python3_6 python3_7 python3_8 (-pypy3) -python3_9"

but I have no USE flags set to call for python3_6.

PYTHON_TARGETS is a USE_EXPAND:
https://wiki.gentoo.org/wiki/Project:Python/PYTHON_TARGETS

Some defaults are set by the profile, but this can also be overridden in
package.use. You need to find where PYTHON_TARGETS is including python3_6.

I presumed that
would come from the ebuilds, like this from dev-python/setuptools:

PYTHON_COMPAT=( python2_7 python3_{6,7,8,9} pypy3 )

This is simply specifying which versions of Python setuptools is
compatible with. Which one(s) actually get used is determined by
PYTHON_TARGETS.

Other than the PYTHON_TARGETS=, and this:

dev-python/markupsafe[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?...

I don't see where python3_6 is coming into play.

It is the PYTHON_TARGETS.

Incidently, because I saw python3_9 somewhere, I emerged that, and
selected it:

$ eselect python list
Available Python interpreters, in order of preference:
[1] python3.9
[2] python3.6
[3] python3.8 (fallback)
[4] python3.7 (fallback)
[5] python2.7 (fallback)

but it didn't change anything that I could see.

This only sets the default interpreter (which version of Python is
linked to /usr/bin/python). It does not do anything to the portage
tree, as far as I am aware. Portage Python dependencies should be
controlled with PYTHON_TARGETS.

I can't find out how to make python3.6 fallback. depclean doesn't
remove it.

Depclean doesn't remove it because your PYTHON_TARGETS output above
indicates there are packages still depending on it.

What's particularly frustrating is I can't make out from the log that
there's anything wrong.

Did you try the suggestion from earlier in the thread to try to emerge
in smaller pieces, since your @world update is so large? Portage output
is daunting when 100s of packages are involved, it is easier to start
from a smaller set and work out what's wrong.

I hope my only alternative is not just to reinstall. A reinstall takes
a couple of days of compiling.

This thread has been going since a week ago... at a certain point
reinstalling and letting portage chug through a day of compiling would
be less effort than troubleshooting a broken installation.

On 12/12/2020 3:35 PM, Neil Bothwick wrote:

On Sat, 12 Dec 2020 23:08:15 +0100, n952162 wrote:

I did a --depclean but that didn't help. I'm not seeing where an error
is indicated.

This was done with this still installed:

*/* PYTHON_TARGETS: python3_7

I commented that out and tried again, and after a few USE flag
iterations, I ended up with what seems like the same situation. Log on
request.

There's a lot to trawl through here, it looks like you haven't updated
for quite some time. I'd suggest you try to cut down on the noise by
updating only @system instead of @world.

A quick glance at some of the output suggests that you still have
PYTHON_TARGETS="python3_6" set somewhere. What do

grep -r python3_6 /etc/portage
emerge --info | grep -i python

tell you?

Re: [gentoo-user] update fails, but I don't see why


I have this funny pkg entry in the emerge log:

dev-python/setuptools[python_targets_python2_7(-),-python_single_target_python2_7(-)]
required by (dev-python/ipaddress-1.0.23:0/0::gentoo, installed) USE=""
ABI_X86="(64)" PYTHON_TARGETS="python2_7"

Where does the python2_7 come from?  The ebuild has this:

BDEPEND="dev-python/setuptools[${PYTHON_USEDEP}]"

A recursive grep in /etc/portage doesn't turn up a PYTHON_USEDEP


Question: if I HAVE NOT included a (recommended) USE flag definition
like this, could that be the cause of the python2_7 token, above,
because the default 2.7 isn't overriden?

>=dev-python/docutils-0.16 -python_targets_python2_7

Re: [gentoo-user] update fails, but I don't see why

2020-12-13 Thread Mark Knecht

On Sun, Dec 13, 2020 at 12:03 PM 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?
>

Personally I wouldn't start with a reinstall.

I'd start with my world file and remove/comment out every 'application' not
required to keep the machine running/booting. That should be nearly
everything other than things like grub, your kernels, hardware drivers,
terminals, etc.

NOTE: Just because you comment something out in the world file doesn't mean
it won't run, it just won't get updated or be part of portage's
considerations about what to do.

At that point emerge @world should only be considering, from a build POV,
the stuff you really need.

This python problem everyone is having I cannot help with. Solving problems
like that is why people run Gentoo. With lots of power comes lots of
responsibility. However with all the applications 'unconsidered' you have a
chance of getting the really important stuff built and booting.

If I got that far then I'd start adding apps back in/uncommenting one or
two at a time and see if I could make headway.

I've updated machines that were a year out of date but it took days and
days. If I didn't want to build code every week I decided I couldn't run
Gentoo.

HTH,
Mark

Re: [gentoo-user] update fails, but I don't see why


On 12/13/20 1:09 AM, Dan Egli wrote:

Have to agree with Neil on this one. You've got a LOT of updates.
World is great, but start with emerge -UDuv @system, after you find
the culprit that is still setting python3_6 as a target. Once the
system emerge is done then you can try world again and hopefully get a
much smaller list. We can help you much better from there.



python3_6 is bad, I've got that now, but lots and lots of packages have
something similar to this:

PYTHON_TARGETS="python3_6 python3_7 python3_8 (-pypy3) -python3_9"

but I have no USE flags set to call for python3_6.  I presumed that
would come from the ebuilds, like this from dev-python/setuptools:

PYTHON_COMPAT=( python2_7 python3_{6,7,8,9} pypy3 )

Other than the PYTHON_TARGETS=, and this:

 
dev-python/markupsafe[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?...

I don't see where python3_6 is coming into play.

Incidently, because I saw python3_9 somewhere, I emerged that, and
selected it:

$ eselect python list
Available Python interpreters, in order of preference:
  [1]   python3.9
  [2]   python3.6
  [3]   python3.8 (fallback)
  [4]   python3.7 (fallback)
  [5]   python2.7 (fallback)

but it didn't change anything that I could see.

I can't find out how to make python3.6 fallback.  depclean doesn't
remove it.

What's particularly frustrating is I can't make out from the log that
there's anything wrong.

I hope my only alternative is not just to reinstall.  A reinstall takes
a couple of days of compiling.




On 12/12/2020 3:35 PM, Neil Bothwick wrote:

On Sat, 12 Dec 2020 23:08:15 +0100, n952162 wrote:


I did a --depclean but that didn't help.  I'm not seeing where an error
is indicated.

This was done with this still installed:

   */* PYTHON_TARGETS: python3_7

I commented that out and tried again, and after a few USE flag
iterations, I ended up with what seems like the same situation. Log on
request.

There's a lot to trawl through here, it looks like you haven't updated
for quite some time. I'd suggest you try to cut down on the noise by
updating only @system instead of @world.

A quick glance at some of the output suggests that you still have
PYTHON_TARGETS="python3_6" set somewhere. What do

grep -r python3_6 /etc/portage
emerge --info | grep -i python

tell you?

Re: [gentoo-user] update fails, but I don't see why


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?

[gentoo-user] nouveau: gr: failed to load firmware "gr/sw_nonctx"

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 have "linux-firmware" installed but there is a "?" mark beside it

eix linux-firmware
[?] sys-kernel/linux-firmware
Installed versions:  20201022-r3

Re: [gentoo-user] [SOLVED] fsck.fat 4.1 - File system couldn't be fixed [SOLVED]

On Sun, 13 Dec 2020 15:02:10 +, Victor Ivanov wrote:

> > NOTE:  The UEFI firmware can boot natively linux kernel images without
>  > chainloading some 3rd party Boot Manager's .EFI executable like
>  > GRUB,   
> rEFInd,
>  > syslinux, etc., as long as the EFI stub support has been enabled in
>  >  
> the linux
>  > kernel and 'root=PARTUUID=...' has been added in the built-in kernel
>  >   
> command
>  > line entry.  
> 
> Absolutely! I actually love this aspect about UEFI. It's a brilliant 
> idea, but for some reason I always found it somewhat fiddly. Perhaps
> the lack of being able to alter the kernel command line prior to
> booting has put me off. Though I have to admit, I too am susceptible to
> "old habits die hard" and have always stuck to chainloading GRUB and
> never really thought much about it :)

You can use a minimal boot manager to be able to change kernel parameters
with UEFI.


-- 
Neil Bothwick

Nostalgia isn't what it used to be.


pgp6Fe1wFhY8m.pgp
Description: OpenPGP digital signature

[gentoo-user] Re: No logging output to tty12

2020-12-13 Thread nunojsilva

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. At least in /etc/syslog-ng/syslog-ng.conf, I
see the following:

destination console_all { file("/dev/tty12"); };

-- 
Nuno Silva

Re: [gentoo-user] [SOLVED] fsck.fat 4.1 - File system couldn't be fixed [SOLVED]

2020-12-13 Thread Victor Ivanov

On 13/12/2020 14:17, Michael wrote:

Pre-UEFI /boot on a single partition/filesystem used to be formatted as ext2,
primarily because /boot is a small fs in size, is written to only occasionally
and unless it happened to crash while writing to it not much benefit would be
had by adding the journal of ext3/ext4, while adding a fs overhead for the
journal and making write operations last longer.
...
So, for Linux on conventional installations (Legacy BIOS + separate /boot fs +
spinning disk setups) ext2 is a valid fs choice.  When /boot is part of the /
block device, then the fs type for /boot would necessarily be whatever is
chosen for the / partition, as long as the boot manager has the corresponding
driver to be able to load it.

Well, I don't dispute the validity of ext2 as a choice. Or any other 
filesystem that the bootloader can read really - that's a perfectly 
valid statement.

I was merely 'going further' as a suggestion purely in the sense that in 
this day and age there's hardly any reason to not be using a journaled 
filesystem even for /boot.

As you say, /boot is written to rarely so the overhead of a journal is 
negligible and for all intents and purposes can be ignored completely. 
Disk space itself these days is really not a concern at all (unless on a 
really really archaic machine) - let alone for a small boot partition - 
so that too can be ignored as a contributing factor. Data integrity, on 
the other hand, is far more critical. I have had ext2 fail on me during 
a system crash when updating a kernel back in the days a number of 
times, so I personally did away with ext2 as a /boot filesystem about 
15y ago. Not surprisingly most distros will default to ext3/4 for /boot 
as well. But ultimately, we are free to decide ourselves.

Unfortunately, sometimes guides put the EFI partition mount point to be
a directory within the /boot directory (e.g. /boot/efi) which itself can
be the mount point for the boot partition. This can lead to people
formatting both as vfat or indeed using the EFI partition itself in lieu
of a separate /boot partition. I am not suggesting this is what happened
in your case, but I have seen it happen.

If /boot/efi is a directory (it should be according to the UEFI spec) then as
far as I know directories cannot be formatted with a fs.

Well.. naturally, this isn't what I meant :)

But you can have your boot fs (e.g. vfat/ext[2/3/4]) mounted under 
"/boot" and your EFS partition (vfat) mounted under "/boot/efi". The 
actual EFI directory that you speak of would then be under 
"/boot/efi/EFI". I used this as an example but, naturally, one can use 
any mount point that suits and it doesn't have to be under /boot.

For the sake of the example, perhaps a better choice of naming would 
have been "/boot/efs".

> NOTE:  The UEFI firmware can boot natively linux kernel images without
> chainloading some 3rd party Boot Manager's .EFI executable like GRUB, 
rEFInd,
> syslinux, etc., as long as the EFI stub support has been enabled in 
the linux
> kernel and 'root=PARTUUID=...' has been added in the built-in kernel 
command

> line entry.

Absolutely! I actually love this aspect about UEFI. It's a brilliant 
idea, but for some reason I always found it somewhat fiddly. Perhaps the 
lack of being able to alter the kernel command line prior to booting has 
put me off. Though I have to admit, I too am susceptible to "old habits 
die hard" and have always stuck to chainloading GRUB and never really 
thought much about it :)

> Gentoo is thankfully flexible enough to allow you to make your own 
choices on
> configuring your system.  Whatever works for you best is a valid 
choice to

> make.:-)

This! When people ask why I go through all the pain of using Gentoo and 
literally seeing myself getting older in the mirror while waiting for 
packages to compile (or portage to finish resolving dependencies) I 
always give this as my first argument - you can do whatever you want 
with this distro, it's that flexible... And we all love Gentoo for it

OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-user] [SOLVED] fsck.fat 4.1 - File system couldn't be fixed [SOLVED]

On Sun, 13 Dec 2020 14:17:18 +, Michael wrote:

> Gentoo is thankfully flexible enough to allow you to make your own
> choices on configuring your system.  Whatever works for you best is a
> valid choice to make.  :-)

Whatever works for most other people is a good choice if you may need
support in the future :)


-- 
Neil Bothwick

"Energize!" said Picard and the pink bunny appeared...


pgpUDcyPLAy14.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] [SOLVED] fsck.fat 4.1 - File system couldn't be fixed [SOLVED]

On Sunday, 13 December 2020 07:42:11 GMT the...@sys-concept.com wrote:
> On 12/12/2020 11:00 PM, Victor Ivanov wrote:
> > On 13/12/2020 03:07, the...@sys-concept.com wrote:
> >> if you have UEFI system most likely your "boot" partition is some form
> >> of "vfat"
> > 
> > I strongly disagree with this statement. Most Linux distributions,
> > including Gentoo, advise (or outright default to) having your /boot
> > partition either separate, or having /boot as part of your root
> > filesystem. And this is very sensible indeed.
> > 
> > Personally, I would even go further by saying that /boot should be
> > journaled (e.g. ext4). Most distros do that by default.

Pre-UEFI /boot on a single partition/filesystem used to be formatted as ext2, 
primarily because /boot is a small fs in size, is written to only occasionally 
and unless it happened to crash while writing to it not much benefit would be 
had by adding the journal of ext3/ext4, while adding a fs overhead for the 
journal and making write operations last longer.

VFAT is more fragile than ext2 (in my anecdotal experience) and in addition it 
does not support symlinks (or hard links).  This creates a problem for some 
boot managers, e.g. GRUB.

So, for Linux on conventional installations (Legacy BIOS + separate /boot fs + 
spinning disk setups) ext2 is a valid fs choice.  When /boot is part of the / 
block device, then the fs type for /boot would necessarily be whatever is 
chosen for the / partition, as long as the boot manager has the corresponding 
driver to be able to load it.

With the move from spinning disks to SSDs and problem of block size write 
amplifications cropped up.  Last I looked (on 5.4.80-gentoo-r1) it seems ext2 
still does not support TRIM, while FAT does:

/usr/src/linux $ grep -lr FITRIM fs/ | cut -d/ -f2 | sort | uniq | xargs echo
btrfs compat_ioctl.c ecryptfs ext4 f2fs fat gfs2 hpfs jfs nilfs2 ocfs2 xfs

So, on spinning disks with a legacy BIOS the /boot partition can be on ext2.

On SSDs it makes sense to have /boot on a fs which supports TRIM, e.g. any of 
the above fs.

> > A UEFI set-up only requires the EFI system partition to be vfat. It does
> > not require the kernel or the ramdisk to be on it. GRUB2 can be
> > configured to install only its own EFI-related files on the EFI system
> > partition, then reading the kernel and the grub config file from your
> > /boot partition:
> > 
> >   # grub-install --efi-directory=/path/to/efi --boot-directory=/boot/efi
> > /dev/[nvme...|sd...]
> > 
> > You do not need CSM enabled for this.

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.

NOTE:  The UEFI firmware can boot natively linux kernel images without 
chainloading some 3rd party Boot Manager's .EFI executable like GRUB, rEFInd, 
syslinux, etc., as long as the EFI stub support has been enabled in the linux 
kernel and 'root=PARTUUID=...' has been added in the built-in kernel command 
line entry.

> > Unfortunately, sometimes guides put the EFI partition mount point to be
> > a directory within the /boot directory (e.g. /boot/efi) which itself can
> > be the mount point for the boot partition. This can lead to people
> > formatting both as vfat or indeed using the EFI partition itself in lieu
> > of a separate /boot partition. I am not suggesting this is what happened
> > in your case, but I have seen it happen.

If /boot/efi is a directory (it should be according to the UEFI spec) then as 
far as I know directories cannot be formatted with a fs.

> > Now if you use a different boot loader (e.g. rEFInd) it is up to that
> > bootloader to have relevant support for the filesystem that your /boot
> > partition is using.
> > 
> >> fsck.fat 4.1 (2017-01-24) open: no such file or directory
> >> 
> >> There is a similar related bug filed about it (but I don't know why is
> >> it marked resolved)
> >> https://bugs.gentoo.org/306119
> > 
> > I don't think this issue is related wrt the root cause. But
> > force-checking for filesystem errors certainly revealed the issue for
> > your case: you don't have the fsck.fat binary in your initramfs. As a
> > result, the filesystem checking process fails, the boot process is
> > interrupted prematurely, and you're dropped into a shell to investigate.
> > This is normal behaviour when an error occurs before the boot process
> > switches to the real root.
> > 
> > One option is to disable filesystem checking for vfat - like you did,
> > another is to make sure that the mkfs.fat binary is included in the
> > ramdisk image. I am not sure how the latter would be best achieved with
> > genkernel, perhaps others can advise on this.
> > 
> > - Victor

I have two UEFI systems

Re: [gentoo-user] [SOLVED] fsck.fat 4.1 - File system couldn't be fixed [SOLVED]

2020-12-13 Thread Victor Ivanov


On 13/12/2020 07:42, the...@sys-concept.com wrote:

I was following the Gentoo handbook, maybe I didn't read it correctly
and/or miss the information on alternative setting.  I didn't see any
explanation that I need to have support for "fsck.fat".
I better stay away from any "vfat" format on boot partition, and I don't
see a reason to have initramfs (another complexity).

No worries at all, despite my using Gentoo for the better part of a 
decade I too sometimes do something silly without realising. And you're 
right that this part of the guidebook could be improved to make some 
clarifications.


In any case, I've looked at the fstab on one of my machines and I do 
have dump/pass set to "0 2" for the EFI partition (which is of course 
vfat). I changed that to "1 2" to match your previous setup, though I 
was sceptical if that would make any difference. I created a /forcefsck 
file and managed to reboot just fine which suggests that either:


1) my ramdisk has fsck.fat bundled; or
2) was able to use the binary from the root partition after it was 
mounted read-only


[I could check explicitly, but I'm feeling a bit lazy]

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



OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-user] update fails, but I don't see why


(sorry Neil, that you got directly addressed again, wasn' intentional,
don't know how it happened)

Re: [gentoo-user] update fails, but I don't see why


On 12/13/20 9:18 AM, Neil Bothwick wrote:

On Sun, 13 Dec 2020 08:14:04 +0100, n952162 wrote:

...

There's a lot to trawl through here, it looks like you haven't updated
for quite some time.


The (compressed) log of  a system and world update from 20. October
(2020!) is attached.

Nearly 2 months, quite a long time in Gentoo update terms.



Yes, I see.  I'm updating another machine where I'd done a fresh install
of this:

    stage3-amd64-20201104T214503Z.tar.xz

and I'm updating 175 packages.


If rust, llvm, firefox or thunderbird is in that list, I'll go crazy.

Re: [gentoo-user] update fails, but I don't see why

On Sunday, 13 December 2020 08:57:53 GMT n952162 wrote:
> On 12/13/20 9:18 AM, Neil Bothwick wrote:
> > There's a lot to trawl through here, it looks like you haven't updated
> > 
> >>> for quite some time.
> >> 
> >> The (compressed) log of  a system and world update from 20. October
> >> (2020!) is attached.
> > 
> > Nearly 2 months, quite a long time in Gentoo update terms.
> 
> !!!  After 2 months the system can no longer be update-able?

A system can be updated and updatable after more than two months, but be 
prepared for some manual intervention and a staged approach to running emerge.  
Starting with 'eselect news read new' is advisable for any heads up to changes 
in gentoo, major packages and configuration.

Also pay attention to any messages on the CLI when you run emerge about 
packages which are due to be removed from portage, as you will need to take 
care of these manually in your local or some external 3rd party overlay.

> > ...
> > 
> >>>What do
> >>> 
> >>> grep -r python3_6 /etc/portage
> >> 
> >> That showed that the only references are in package.use
> > 
> > But what does it show. We need the output of commands, not some vague
> > reference to them. I suspected there was something in package.use, but we
> > need to know what. Those references should probably be removed but no one
> > can say for sure without seeing them.
> 
> Oh sorry.  You mentioned
> 
> PYTHON_TARGETS="python3_6"
> 
> and I didn't connect that with USE variables.  Here there are (with comments
> removed)

It isn't just USE flags for python-3.6 you may have set up yourself, but USE 
flags for any python version you have specified.  Under normal circumstances 
you would not need to specify these yourself and pegging python at a 
particular version is bound to cause warnings later on, when that python 
version has been deprecated and is no longer available in portage.

> $ sed -n -e '/^\s*#/d' -e '/python3_6/p' /etc/portage/package.use/*
> 
> >=dev-python/certifi-10001-r1 python_targets_python3_6
> >=dev-python/setuptools_scm-4.1.2-r1 python_targets_python3_6
> >=dev-python/requests-2.24.0-r1 python_targets_python3_6
> >=dev-python/chardet-3.0.4-r1 python_targets_python3_6
> >=dev-python/idna-2.10-r1 python_targets_python3_6
> >=dev-python/urllib3-1.25.11 python_targets_python3_6
> >=dev-python/cryptography-3.2.1 python_targets_python3_6
> >=dev-python/cffi-1.14.0-r3 python_targets_python3_6
> >=dev-python/pycparser-2.20-r1 python_targets_python3_6
> >=dev-python/ply-3.11-r1 python_targets_python3_6
> >=dev-python/PySocks-1.7.1-r1 python_targets_python3_6
> >=dev-python/pyopenssl-19.1.0-r1 python_targets_python3_6
> >=dev-python/setuptools-50.3.0 python_targets_python3_6
> >=dev-python/six-1.15.0-r1 python_targets_python3_6

Why had you set up these in your package.use?

If you comment them out and re-run emerge are you getting any more warnings/
errors?

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

Re: [gentoo-user] update fails, but I don't see why


On 12/13/20 9:18 AM, Neil Bothwick wrote:


There's a lot to trawl through here, it looks like you haven't updated

for quite some time.


The (compressed) log of  a system and world update from 20. October
(2020!) is attached.

Nearly 2 months, quite a long time in Gentoo update terms.



!!!  After 2 months the system can no longer be update-able?



...



   What do

grep -r python3_6 /etc/portage


That showed that the only references are in package.use

But what does it show. We need the output of commands, not some vague
reference to them. I suspected there was something in package.use, but we
need to know what. Those references should probably be removed but no one
can say for sure without seeing them.




Oh sorry.  You mentioned

PYTHON_TARGETS="python3_6"

and I didn't connect that with USE variables.  Here there are (with comments 
removed)

$ sed -n -e '/^\s*#/d' -e '/python3_6/p' /etc/portage/package.use/*

=dev-python/certifi-10001-r1 python_targets_python3_6
=dev-python/setuptools_scm-4.1.2-r1 python_targets_python3_6
=dev-python/requests-2.24.0-r1 python_targets_python3_6
=dev-python/chardet-3.0.4-r1 python_targets_python3_6
=dev-python/idna-2.10-r1 python_targets_python3_6
=dev-python/urllib3-1.25.11 python_targets_python3_6
=dev-python/cryptography-3.2.1 python_targets_python3_6
=dev-python/cffi-1.14.0-r3 python_targets_python3_6
=dev-python/pycparser-2.20-r1 python_targets_python3_6
=dev-python/ply-3.11-r1 python_targets_python3_6
=dev-python/PySocks-1.7.1-r1 python_targets_python3_6
=dev-python/pyopenssl-19.1.0-r1 python_targets_python3_6
=dev-python/setuptools-50.3.0 python_targets_python3_6
=dev-python/six-1.15.0-r1 python_targets_python3_6

Re: [gentoo-user] update fails, but I don't see why