Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Dale]

Mark Knecht wrote:
>
>
> On Fri, Jun 28, 2024 at 2:41 PM Dale  > wrote:
> 
> > Doing that was actually not much trouble.  I booted, changed
> something just in case it rebooted and went back for some reason but
> would change something on the screen.  Usually, I change the page on
> the KDE welcome screen to like page 4 or something.  If it were to
> restart the GUI or anything, it would go back to page 1.  Anyway, once
> booted, I'd go do something else for a while.  Then when I came back,
> shutdown, change port and repeat.
> >
> > To Micheal's point tho, I suspect the boot media I'm using is slow
> enough, loading from a USB stick instead of a m.2 drive, that it also
> is able to get the info needed, most likely from the monitor, and work
> like it should.  This could literally be a system that is just going
> to fast.  By the time the monitor gets the request, the computer has
> already moved on except for those rare occasions where it works.
> >
> > I have a 2.5" SSD drive.  I actually mounted it in the system
> already just not hooked up to power or data cables.  I could install
> Kubuntu on that easily.  If I get the steam up, I just may do that. 
> Between working on this new build, my sis-n-law being sick, I just had
> to much going on for to long.  Just a bit ago I walked up a very steep
> hill to take watermelons in the house for her.  I can walk up faster
> than I can drive up.  No other powered vehicle I can use.  Car and
> feet is all I got.  Still, that walk up the hill and carrying
> watermelons up the steps took my energy level down a few more
> notches.  Thank goodness for my meds.  At least my back isn't so angry
> at me.
> >
> > I just hope this new monitor works out of the box, and doesn't get
> damaged in shipping.  ;-)
> >
> > Dale
> >
> > :-)  :-)
> >
> > P. S.  I'm pretty sure the recent upgrade put my main rig on KDE6. 
> I had some clashes with lxqt or something to the point I uninstalled
> it, did the KDE update and then added lxqt? back.  I still had to work
> out some issues.  So far, it is working OK.  No problems or anything
> except for losing my weather thingy on the bottom panel.  I'm sure
> that will be updated soon.  May do the same on the new rig if I get
> time.  Not that I can test it or anything tho.  LOL
>
> My point about putting KDE on a drive and really running it is that
> you can install all the non-standard drivers, which NVidia is part of,
> which I'm not sure is totally supported when running in the Try It
> mode from boot media. Once installed and booted from the SSD then
> really use the system and figure out what's going on with these ports.
> There is still a small possibility in my mind that this is something
> about Quadro cards which were designed for a different market and that
> possibly haven't been as well tested in the consumer or Gentoo arena. 
>
> You have a lot going on so ask questions if you need me. I'm always
> lurking around somewhere.
>
> Cheers,
> Mark

I got up a little steam.  I hooked up the SSD drive and installed
Kubuntu which went very fast.  It seems all those SSD type drives are
really fast.  Anyway, when I booted up the first time, it went straight
to KDE and it was like it should be, resolution, plasma and all. 
Kubuntu isn't half bad.  I just like a source based distro.  Since it
uses the nouveau drivers tho, I'm not to surprised it worked.  If they
had worked this well on Gentoo, I would have used them.  Thing was awful
tho. 

I'll search around and see if I can figure out how to switch to nvidia
drivers.  I figured out how to install the software to install
software.  That sounds weird.  :/  Anyway, I found the nvidia drivers
but wasn't sure what to do after they were installed.  There is no
xorg.conf file. 

I also tried to get some log info, all I found was Xorg and sddm.  We
agree that sddm is working.  The Xorg file looked like one I posted from
something else.  Not sure it would help to post that monster. 

That's the update for now.  May work on it more later on. 

Dale

:-)  :-) 

Re: [gentoo-user] Eliminating unwanted linux-firmware blobs.

[Eli Schwartz]

On 6/28/24 6:31 PM, Peter Humphrey wrote:
> On Friday, 28 June 2024 20:32:11 BST Tsukasa Mcp_Reznor wrote:
> 
>> Remove the date.so it becomes
>> /etc/portage/savedconfig/sys-kernel/linux-firmware then it applies to all
>> of them and not the specified version.
>>
>> Hope that helps
> 
> It certainly does. I wish I'd known that years ago: it would have saved me an 
> awful lot of renaming.


The elog message states:


 * Your configuration for sys-kernel/linux-firmware-20240610-r1 has been
saved in
 * "/etc/portage/savedconfig/sys-kernel/linux-firmware-20240610-r1" for
your editing pleasure.
 * You can edit these files by hand and remerge this package with
 * USE=savedconfig to customise the configuration.
 * You can rename this file/directory to one of the following for
 * its configuration to apply to multiple versions:
 * ${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/
 * [${CTARGET}|${CHOST}|""]/${CATEGORY}/[${PF}|${P}|${PN}]


I admit that this is a bit hard to analyze...


-- 
Eli Schwartz


OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Eliminating unwanted linux-firmware blobs.

[Peter Humphrey]

On Friday, 28 June 2024 20:32:11 BST Tsukasa Mcp_Reznor wrote:

> Remove the date.so it becomes
> /etc/portage/savedconfig/sys-kernel/linux-firmware then it applies to all
> of them and not the specified version.
> 
> Hope that helps

It certainly does. I wish I'd known that years ago: it would have saved me an 
awful lot of renaming.

-- 
Regards,
Peter.

Re: [gentoo-user] bashrc and setting PS1 variable heads up.

[Dale]

Peter Humphrey wrote:
> On Friday, 28 June 2024 08:32:44 BST Dale wrote:
>
>> I did a major upgrade and found out I had a lot of config files to
>> update.  I performed those updates, while losing some of my settings. 
>> Anyway, I figured out how to set the alias variables.  Simple enough. 
>> Create a file and list them in the file.  The PS1 is different because
>> it usually determines if a user is root or not and gives a different
>> prompt.  That requires a little bit of scripting, which most know is a
>> huge weak point for me. 
> I thought the proper place to define aliases was in /etc/profile.d/
> profile_aliases.sh. That's where I have mine, anyway.
>
> PS1 is set in /etc/bash/bashrc.d/10-gentoo-color.bash, as you say. I change 
> the prompt colours in there, in the case of the little rescue system I have 
> on 
> each machine. That's so that I can see which system I'm logged-on to (I 
> maintain the rescue system by chrooting into it from the main system, and 
> it's 
> far too easy to make mistakes without that precaution).
>


Way back when I first wanted to change mine, it was done in bashrc. 
According to searches, lots of people change it there but lots also do
it in other places, some in user directories.  Personal preference I
guess. 

Mostly, I wanted to give a heads up to those who set it the way I do and
that there is a clash if set in another file.  When I couldn't login at
all, I got kinda worried.  It made several things start acting weird. 
If a person sees the post and knows to check if that file exists, then
it could save someone else some issues.  At first, I couldn't understand
the reason it wasn't working.  I think when I ran dispatch-update, that
really started something.  One of the files updated was bashrc.  It
seems the way history is stored changed.  I gotta read up on that
again.  Sounds like it records commands as they are ran now instead of
when you logout.  I'm not sure.  I kinda had other issues to deal with
at the time.  ;-)  If so, that could be a good thing given I use Konsole
and sometimes have 7, 8 or more tabs open doing different things.  I'd
like them all recorded not just the last tab I close. 

I do wish someone would create a wiki page that shows the different ways
to do this sort of things with the new way being included.  Some may
want to do it my way but some may want to do it your way or some other
way for various reasons.  Right now, I don't see anything that details
this sort of thing on the wiki.  Maybe my search terms was bad but one
of them was bashrc. 

Time to wash dishes and heat up supper.  Gotta throw some coal in the
firebox.  Build up some steam.  -_O

Dale

:-)  :-) 

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Mark Knecht]

On Fri, Jun 28, 2024 at 2:41 PM Dale  wrote:

> Doing that was actually not much trouble.  I booted, changed something
just in case it rebooted and went back for some reason but would change
something on the screen.  Usually, I change the page on the KDE welcome
screen to like page 4 or something.  If it were to restart the GUI or
anything, it would go back to page 1.  Anyway, once booted, I'd go do
something else for a while.  Then when I came back, shutdown, change port
and repeat.
>
> To Micheal's point tho, I suspect the boot media I'm using is slow
enough, loading from a USB stick instead of a m.2 drive, that it also is
able to get the info needed, most likely from the monitor, and work like it
should.  This could literally be a system that is just going to fast.  By
the time the monitor gets the request, the computer has already moved on
except for those rare occasions where it works.
>
> I have a 2.5" SSD drive.  I actually mounted it in the system already
just not hooked up to power or data cables.  I could install Kubuntu on
that easily.  If I get the steam up, I just may do that.  Between working
on this new build, my sis-n-law being sick, I just had to much going on for
to long.  Just a bit ago I walked up a very steep hill to take watermelons
in the house for her.  I can walk up faster than I can drive up.  No other
powered vehicle I can use.  Car and feet is all I got.  Still, that walk up
the hill and carrying watermelons up the steps took my energy level down a
few more notches.  Thank goodness for my meds.  At least my back isn't so
angry at me.
>
> I just hope this new monitor works out of the box, and doesn't get
damaged in shipping.  ;-)
>
> Dale
>
> :-)  :-)
>
> P. S.  I'm pretty sure the recent upgrade put my main rig on KDE6.  I had
some clashes with lxqt or something to the point I uninstalled it, did the
KDE update and then added lxqt? back.  I still had to work out some
issues.  So far, it is working OK.  No problems or anything except for
losing my weather thingy on the bottom panel.  I'm sure that will be
updated soon.  May do the same on the new rig if I get time.  Not that I
can test it or anything tho.  LOL

My point about putting KDE on a drive and really running it is that you can
install all the non-standard drivers, which NVidia is part of, which I'm
not sure is totally supported when running in the Try It mode from boot
media. Once installed and booted from the SSD then really use the system
and figure out what's going on with these ports. There is still a small
possibility in my mind that this is something about Quadro cards which were
designed for a different market and that possibly haven't been as well
tested in the consumer or Gentoo arena.

You have a lot going on so ask questions if you need me. I'm always lurking
around somewhere.

Cheers,
Mark

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Dale]

Mark Knecht wrote:
>
>
> On Thu, Jun 27, 2024 at 10:18 PM Dale  > wrote:
> >
> > Mark Knecht wrote:
> >
> >
> >
> > On Thu, Jun 27, 2024 at 4:01 PM Dale  > wrote:
> > 
> > >
> > > I think the rig and video card are fine.  I did try a different
> card and version of nvidia drivers once tho.  Same thing.  At first, I
> tried the nouveau drivers.  All the bootable media uses that driver. 
> When I tried it on my install, it was very slow and the mouse pointer
> was very jerky.  It was horrible.  I removed those drivers and
> installed nvidia.  Sadly, things got worse.
> > >
> > > I'll boot into Kubuntu again and see what info it has.  The ones I
> attached tho is all there was. Either it doesn't have those files or
> the files were blank.  I think Xorg and messages was all there was.
> > >
> > > I'm out of steam.  May boot Kubuntu and let it sit while I nap. 
> It worked for several minutes last time tho.  It seemed to work fine. 
> Very fast too, unlike on my install.
> > >
> >
> > Yeah, I can hear the frustration and weariness in your writing.
> However I know you are up to fixing this.
> >
> > One additional experiment you can do, and I suspect Kubuntu passes
> every time, is boot the machine with the monitor plugged into each
> port one at a time. Do complete power downs between each boot. If
> Kubuntu comes up it will really tell you a stable, tested OS has
> solved these problems. If it doesn't then that's good info also.
> >
> > I think possibly you purchased a Quadro adapter? I don't know how
> popular those are amongst this crowd but they have been very popular
> in business settings. That might make a bigger difference in terms of
> the nvidia driver vs the Open Source one.
> >
> > Good luck with your machine,
> > Mark
> >
> >
> >
> > I admit, I'm thinking about unplugging the thing and sticking it in
> the closet.  If nothing else, I'm tired of walking around this huge
> thing.  I was hoping to have switched long ago.  Usually, I look
> forward and even get excited to build a new rig.  This time, with the
> lacking slots of the original mobo and having to go way down power
> wise, I just want to make sure I have a working computer if something
> happens to my main rig.  There's not a whole lot to get excited
> about.  Having it not work, well, that doesn't help.  Poor Michael is
> trying to help but this thing is weird.  With every reboot, it does
> something differently.
> >
> > On the Kubuntu test.  I started with what the bracket shows as port
> 1.  I then went through each port until I got to port 4.  I rebooted
> in between each switch.  Even unplugged the monitor.  It worked every
> time.  During the booting of the image tho, there was several seconds
> where the screen went weird.  It had these horizontal lines on it that
> looked like stair steps.  I've seen this type of thing on other boot
> media even with my main rig and the NAS box.  It's like the image is
> in the process of loading drivers or something.  Anyway, once it came
> up tho, rock solid.
> >
> > I checked the nvidia website three times now.  Still, I wonder, am I
> using the wrong driver?  Would the wrong driver even load without a
> nasty message somewhere that is obvious?  The Nvidia website shows this:
> >
> >
> > Version:                     550.90.07
> > Release Date:             2024.6.4
> > Operating System:     Linux 64-bit
> > Language:                 English (US)
> > File Size:                   293.33 MB
> >
> > I tried that series and the earlier version as well.  Hard to
> believe that both versions would fail the same way due to a bug.  If
> someone wants to double check, Nvidia Quadro P1000 is the info.  Even
> if the selection tool is wrong, it shows up under supported products,
> for both desktops and laptops.
> >
> > I may try to the Nouveau driver thing again.  Instead of building it
> into the kernel, I may try the tree version.  Maybe it will work
> better than the one in the kernel.  One can hope.  Right now, I'm
> trying to sort through a massive update on my main rig.  Something
> broke eix.  o_O  I managed to update the config files.  Broke my
> prompt tho.  I need a hammer.  :/
> >
> > Dale
> >
> > :-)  :-)
>
> Good morning Dale,
>    OK, thanks for indulging me on the Kubuntu testing. Based on my
> understanding of the results - basically everything 'worked' but some
> of the reactions were slow - I'd say don't worry about that when
> running from boot media. I've seen a little of that myself, but it's
> never been a problem on a real install. To me it's good news that the
> Kubuntu install worked fine with all your monitors on any port you
> tried. That's GOOD news. No need to change hardware.
>
>    I know you love your disk space. I wonder if you have a partition
> somewhere that you could just install Kubuntu, install the NVidia
> drivers, get the machine updated and then study why Kubuntu has your
> hardware nailed and Gentoo doesn't? O

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Dale]

Michael wrote:
> On Thursday, 27 June 2024 23:52:25 BST Dale wrote:
>> Michael wrote:
>>> [snip ...]
>>> [30.345] (II) modeset(0): [DRI2]   DRI driver: nouveau  <== Not nvidia
>>> ==
>>>
>>> [snip ...]
>>> [30.295] (II) modeset(0): Output DP-1 disconnected
>>> [30.295] (II) modeset(0): Output DP-2 disconnected
>>> [30.295] (II) modeset(0): Output DP-3 disconnected
>>> [30.295] (II) modeset(0): Output DP-4 connected
>>>
>>> What does it take to connect the cable on the FIRST port of the video
>>> card?
>> This reply may be a little odd.  I wrote some then went back and tried
>> some stuff and added info to it.  Trying to make it make sense. 
> My apologies, I didn't meant to add to your frustration.  Working with a 
> headless system is no fun when you expect to run a desktop on this thing!

I didn't take it that way.  I learned long ago that text doesn't convey
emotion very well.  I take things in the best possible way unless there
is no other way to read it.  I've just never had this much trouble
getting a computer to work.  Things have improved a lot and mostly, they
just work without much help from us.  Generally, if the correct drivers
are in the kernel and the right packages are installed, it works.  Like
magic.  Usually without a config file even. 


>
> I was just making a remark on the fact the card detects the monitor as being 
> connected to DFP-3 or DFP-5 when using the proprietary nvidia driver, but the 
> DP-4 when you used the open source nouveau driver.
>

I've noticed that the port numbers keep changing too.  I don't
understand why since the card should assign those but it is changing. 
It changes even when all I do is reboot. 


>>> At first, when it really wouldn't work, I had it on the bottom port.  At
>> some point we thought that was the last port, #4 or DP-3 in the logs,
>> and not the first port.  I moved it to the top port which is #1, we
>> thought.  It's still on that port but that port did work once and
>> resulted in "solved" being added to the subject line.  I just double
>> checked.  It is plugged in the top port.  Unless the bottom port is #1
>> like I originally thought, then it should be on port #1.  I did a search
>> and found a image that shows it puts the port number on the metal
>> bracket.  I removed the card so I could see the numbers.  The bottom
>> port is number 1 like I originally thought.  So, I had it in the right
>> port to begin with, which wasn't working either.  I'll put it back on
>> what the metal bracket says is port #1, or bottom port.  I booted up,
>> started DM, correct resolution but no plasma and background is black. 
>> Still not a functional desktop.  Partially works tho.  Time to reboot. 
>> On reboot, sddm and KDE are low resolution.  It does have a background
>> image and plasma is working.  Keep in mind, all I did is reboot.  I
>> didn't change any config file or run any commands.  Reboot again.  This
>> time, correct resolution but no plasma.  Again, all I did was reboot. 
>> No changes to anything at all.  As you can see, each time I reboot, it
>> is like rolling dice.  I suspect if I keep rebooting it will eventually
>> do the black screen and power the monitor off. 
> It seems to me the card is probing the monitor to find out what settings it 
> prefers/will work with.  This probing of the driver scrolls through a number 
> of potential Modelines, but if the monitor does not respond in a timely 
> manner 
> with its preferred resolution and frequency you get a broken result.
>
> Here are some hypotheses of mine, in absence of more concrete evidence.  The 
> old box is slower and the initialisation process takes longer.  In this 
> longer 
> processing time the monitor responds with its EDID and what not.  The card 
> receives it in a timely fashion and sets the driver accordingly.
>
> With your new box things happen faster on the PC side, but not on the monitor 
> side.  Two times out of three the synchronisation between driver and monitor 
> fails and you end up with reports of EDID not found and monitor shown as 
> disconnected in your Xorg.0.log.
>
> Having the monitor plugged in any port on the card, first or last, should not 
> make a difference, but if milli/nano-seconds count then it /might/ make a 
> difference, assuming the ports are tried sequentially by the driver.  Hence I 
> had suggested stick with the first port.  Some user reports on the interwebs 
> mentioned it, so I thought it is worth trying it.
>
> What else worth trying is  to set fixed directives for the "Monitor" section 
> in your xorg config file, or capture the EDID table into a file and feed it 
> to 
> the driver.  The former ought to work, the latter may not if the EDID itself 
> is buggy, but that's a problem to solve later if it even exists.  Either way, 
> setting explicit directives for the monitor Modeline(s) and preferred 
> resolution/frequency ought to take auto-probing out of the equation.
>

And to me, that all makes sense.  This n

[gentoo-user] Re: Eliminating unwanted linux-firmware blobs.

[Grant Edwards]

On 2024-06-28, Tsukasa Mcp_Reznor  wrote:

> Remove the date.so it becomes 
> /etc/portage/savedconfig/sys-kernel/linux-firmware
> then it applies to all of them and not the specified version.

Yes, that's the clue I was missing.

--
Grant

Re: [gentoo-user] Eliminating unwanted linux-firmware blobs.

[Tsukasa Mcp_Reznor]

Remove the date.so it becomes 
/etc/portage/savedconfig/sys-kernel/linux-firmware
then it applies to all of them and not the specified version.

Hope that helps


From: Grant Edwards 
Sent: Friday, June 28, 2024 12:17 PM
To: gentoo-user@lists.gentoo.org
Subject: [gentoo-user] Eliminating unwanted linux-firmware blobs.

Is there any graceful way to handle the elimination of unwanted
linux-firmware blobs when doing an update?

I believe I understand the process as outlined at
https://wiki.gentoo.org/wiki/Linux_firmware:

 1. install/upgrade sys-kernel/linux-firmware
 2. edit /etc/portage/savedconfig/sys-kernel/linux-firmware-ddmm
 3. re-emerge sys-kernel/linux-firmware with the savedcofnig USE flag

I've tried that a few times, but it's rather annoying to have to do
that every time linux-firmware gets updated.

AFAICT, the list of three or four blobs that I actually need on a
specific machine never changes.

It seems like there ought to be a way to configure that required
firmware list and have the emerge -u "just work", but I can't find
it. Have I missed something?

Yes, I know...
  Disk space is cheap.
  Premature optimization ...
  etc.

It still annoys me.

--
Grant

Re: [gentoo-user] Eliminating unwanted linux-firmware blobs.

[Waldo Lemmer]

On Fri, Jun 28, 2024, 18:28 Vitaliy Perekhovy  wrote:

> On Fri, Jun 28, 2024 at 04:17:23PM -, Grant Edwards wrote:
> > Is there any graceful way to handle the elimination of unwanted
> > linux-firmware blobs when doing an update?
> >
> > I believe I understand the process as outlined at
> > https://wiki.gentoo.org/wiki/Linux_firmware:
> >
> >  1. install/upgrade sys-kernel/linux-firmware
> >  2. edit /etc/portage/savedconfig/sys-kernel/linux-firmware-ddmm
> >  3. re-emerge sys-kernel/linux-firmware with the savedcofnig USE flag
> >
> > I've tried that a few times, but it's rather annoying to have to do
> > that every time linux-firmware gets updated.
> >
> > AFAICT, the list of three or four blobs that I actually need on a
> > specific machine never changes.
> >
> > It seems like there ought to be a way to configure that required
> > firmware list and have the emerge -u "just work", but I can't find
> > it. Have I missed something?
> >
> > Yes, I know...
> >   Disk space is cheap.
> >   Premature optimization ...
> >   etc.
> >
> > It still annoys me.
> >
> > --
> > Grant
>
> Save your firmware list in
> /etc/portage/savedconfig/sys-kernel/linux-firmware
> That's it.
>
> --
> Best regards,
> Vitaliy Perekhovy
>

After every update to sys-kernel/linux-firmware, you may get the following
output:

 * IMPORTANT: config file
'/etc/portage/savedconfig/sys-kernel/linux-firmware-20240610' needs
updating.
 * See the CONFIGURATION FILES and CONFIGURATION FILES UPDATE TOOLS
 * sections of the emerge man page to learn how to update config files.

It's a good idea to compare this file to your current file to see if any
firmware blobs have gotten updates. However, it's important to then discard
this file by choosing `z` in dispatch-conf.

Regards,
Waldo

>

Re: [gentoo-user] Eliminating unwanted linux-firmware blobs.

[Vitaliy Perekhovy]

On Fri, Jun 28, 2024 at 04:17:23PM -, Grant Edwards wrote:
> Is there any graceful way to handle the elimination of unwanted
> linux-firmware blobs when doing an update?
> 
> I believe I understand the process as outlined at
> https://wiki.gentoo.org/wiki/Linux_firmware:
> 
>  1. install/upgrade sys-kernel/linux-firmware
>  2. edit /etc/portage/savedconfig/sys-kernel/linux-firmware-ddmm
>  3. re-emerge sys-kernel/linux-firmware with the savedcofnig USE flag
> 
> I've tried that a few times, but it's rather annoying to have to do
> that every time linux-firmware gets updated.
> 
> AFAICT, the list of three or four blobs that I actually need on a
> specific machine never changes.
> 
> It seems like there ought to be a way to configure that required
> firmware list and have the emerge -u "just work", but I can't find
> it. Have I missed something?
> 
> Yes, I know...
>   Disk space is cheap.
>   Premature optimization ...
>   etc.
> 
> It still annoys me.
> 
> --
> Grant

Save your firmware list in /etc/portage/savedconfig/sys-kernel/linux-firmware
That's it.

-- 
Best regards,
Vitaliy Perekhovy


signature.asc
Description: PGP signature

[gentoo-user] Eliminating unwanted linux-firmware blobs.

[Grant Edwards]

Is there any graceful way to handle the elimination of unwanted
linux-firmware blobs when doing an update?

I believe I understand the process as outlined at
https://wiki.gentoo.org/wiki/Linux_firmware:

 1. install/upgrade sys-kernel/linux-firmware
 2. edit /etc/portage/savedconfig/sys-kernel/linux-firmware-ddmm
 3. re-emerge sys-kernel/linux-firmware with the savedcofnig USE flag

I've tried that a few times, but it's rather annoying to have to do
that every time linux-firmware gets updated.

AFAICT, the list of three or four blobs that I actually need on a
specific machine never changes.

It seems like there ought to be a way to configure that required
firmware list and have the emerge -u "just work", but I can't find
it. Have I missed something?

Yes, I know...
  Disk space is cheap.
  Premature optimization ...
  etc.

It still annoys me.

--
Grant

Re: [gentoo-user] bashrc and setting PS1 variable heads up.

[Peter Humphrey]

On Friday, 28 June 2024 08:32:44 BST Dale wrote:

> I did a major upgrade and found out I had a lot of config files to
> update.  I performed those updates, while losing some of my settings. 
> Anyway, I figured out how to set the alias variables.  Simple enough. 
> Create a file and list them in the file.  The PS1 is different because
> it usually determines if a user is root or not and gives a different
> prompt.  That requires a little bit of scripting, which most know is a
> huge weak point for me. 

I thought the proper place to define aliases was in /etc/profile.d/
profile_aliases.sh. That's where I have mine, anyway.

PS1 is set in /etc/bash/bashrc.d/10-gentoo-color.bash, as you say. I change 
the prompt colours in there, in the case of the little rescue system I have on 
each machine. That's so that I can see which system I'm logged-on to (I 
maintain the rescue system by chrooting into it from the main system, and it's 
far too easy to make mistakes without that precaution).

-- 
Regards,
Peter.

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Mark Knecht]

On Thu, Jun 27, 2024 at 10:18 PM Dale  wrote:
>
> Mark Knecht wrote:
>
>
>
> On Thu, Jun 27, 2024 at 4:01 PM Dale  wrote:
> 
> >
> > I think the rig and video card are fine.  I did try a different card
and version of nvidia drivers once tho.  Same thing.  At first, I tried the
nouveau drivers.  All the bootable media uses that driver.  When I tried it
on my install, it was very slow and the mouse pointer was very jerky.  It
was horrible.  I removed those drivers and installed nvidia.  Sadly, things
got worse.
> >
> > I'll boot into Kubuntu again and see what info it has.  The ones I
attached tho is all there was. Either it doesn't have those files or the
files were blank.  I think Xorg and messages was all there was.
> >
> > I'm out of steam.  May boot Kubuntu and let it sit while I nap.  It
worked for several minutes last time tho.  It seemed to work fine.  Very
fast too, unlike on my install.
> >
>
> Yeah, I can hear the frustration and weariness in your writing. However I
know you are up to fixing this.
>
> One additional experiment you can do, and I suspect Kubuntu passes every
time, is boot the machine with the monitor plugged into each port one at a
time. Do complete power downs between each boot. If Kubuntu comes up it
will really tell you a stable, tested OS has solved these problems. If it
doesn't then that's good info also.
>
> I think possibly you purchased a Quadro adapter? I don't know how popular
those are amongst this crowd but they have been very popular in business
settings. That might make a bigger difference in terms of the nvidia driver
vs the Open Source one.
>
> Good luck with your machine,
> Mark
>
>
>
> I admit, I'm thinking about unplugging the thing and sticking it in the
closet.  If nothing else, I'm tired of walking around this huge thing.  I
was hoping to have switched long ago.  Usually, I look forward and even get
excited to build a new rig.  This time, with the lacking slots of the
original mobo and having to go way down power wise, I just want to make
sure I have a working computer if something happens to my main rig.
There's not a whole lot to get excited about.  Having it not work, well,
that doesn't help.  Poor Michael is trying to help but this thing is
weird.  With every reboot, it does something differently.
>
> On the Kubuntu test.  I started with what the bracket shows as port 1.  I
then went through each port until I got to port 4.  I rebooted in between
each switch.  Even unplugged the monitor.  It worked every time.  During
the booting of the image tho, there was several seconds where the screen
went weird.  It had these horizontal lines on it that looked like stair
steps.  I've seen this type of thing on other boot media even with my main
rig and the NAS box.  It's like the image is in the process of loading
drivers or something.  Anyway, once it came up tho, rock solid.
>
> I checked the nvidia website three times now.  Still, I wonder, am I
using the wrong driver?  Would the wrong driver even load without a nasty
message somewhere that is obvious?  The Nvidia website shows this:
>
>
> Version: 550.90.07
> Release Date: 2024.6.4
> Operating System: Linux 64-bit
> Language: English (US)
> File Size:   293.33 MB
>
> I tried that series and the earlier version as well.  Hard to believe
that both versions would fail the same way due to a bug.  If someone wants
to double check, Nvidia Quadro P1000 is the info.  Even if the selection
tool is wrong, it shows up under supported products, for both desktops and
laptops.
>
> I may try to the Nouveau driver thing again.  Instead of building it into
the kernel, I may try the tree version.  Maybe it will work better than the
one in the kernel.  One can hope.  Right now, I'm trying to sort through a
massive update on my main rig.  Something broke eix.  o_O  I managed to
update the config files.  Broke my prompt tho.  I need a hammer.  :/
>
> Dale
>
> :-)  :-)

Good morning Dale,
   OK, thanks for indulging me on the Kubuntu testing. Based on my
understanding of the results - basically everything 'worked' but some of
the reactions were slow - I'd say don't worry about that when running from
boot media. I've seen a little of that myself, but it's never been a
problem on a real install. To me it's good news that the Kubuntu install
worked fine with all your monitors on any port you tried. That's GOOD news.
No need to change hardware.

   I know you love your disk space. I wonder if you have a partition
somewhere that you could just install Kubuntu, install the NVidia drivers,
get the machine updated and then study why Kubuntu has your hardware nailed
and Gentoo doesn't? Once you've installed Kubuntu there are just a few
commands to update the machine to current levels and because you're good
with dual boot I don't foresee it being a big problem for you. Create a
100GB partition - or use some partition you can reuse in the future -
install Kubuntu, runit, and eve

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Michael]

On Thursday, 27 June 2024 23:52:25 BST Dale wrote:
> Michael wrote:

> > [snip ...]
> > [30.345] (II) modeset(0): [DRI2]   DRI driver: nouveau  <== Not nvidia
> > ==
> > 
> > [snip ...]
> > [30.295] (II) modeset(0): Output DP-1 disconnected
> > [30.295] (II) modeset(0): Output DP-2 disconnected
> > [30.295] (II) modeset(0): Output DP-3 disconnected
> > [30.295] (II) modeset(0): Output DP-4 connected
> > 
> > What does it take to connect the cable on the FIRST port of the video
> > card?
> 
> This reply may be a little odd.  I wrote some then went back and tried
> some stuff and added info to it.  Trying to make it make sense. 

My apologies, I didn't meant to add to your frustration.  Working with a 
headless system is no fun when you expect to run a desktop on this thing!

I was just making a remark on the fact the card detects the monitor as being 
connected to DFP-3 or DFP-5 when using the proprietary nvidia driver, but the 
DP-4 when you used the open source nouveau driver.


> > At first, when it really wouldn't work, I had it on the bottom port.  At
> some point we thought that was the last port, #4 or DP-3 in the logs,
> and not the first port.  I moved it to the top port which is #1, we
> thought.  It's still on that port but that port did work once and
> resulted in "solved" being added to the subject line.  I just double
> checked.  It is plugged in the top port.  Unless the bottom port is #1
> like I originally thought, then it should be on port #1.  I did a search
> and found a image that shows it puts the port number on the metal
> bracket.  I removed the card so I could see the numbers.  The bottom
> port is number 1 like I originally thought.  So, I had it in the right
> port to begin with, which wasn't working either.  I'll put it back on
> what the metal bracket says is port #1, or bottom port.  I booted up,
> started DM, correct resolution but no plasma and background is black. 
> Still not a functional desktop.  Partially works tho.  Time to reboot. 
> On reboot, sddm and KDE are low resolution.  It does have a background
> image and plasma is working.  Keep in mind, all I did is reboot.  I
> didn't change any config file or run any commands.  Reboot again.  This
> time, correct resolution but no plasma.  Again, all I did was reboot. 
> No changes to anything at all.  As you can see, each time I reboot, it
> is like rolling dice.  I suspect if I keep rebooting it will eventually
> do the black screen and power the monitor off. 

It seems to me the card is probing the monitor to find out what settings it 
prefers/will work with.  This probing of the driver scrolls through a number 
of potential Modelines, but if the monitor does not respond in a timely manner 
with its preferred resolution and frequency you get a broken result.

Here are some hypotheses of mine, in absence of more concrete evidence.  The 
old box is slower and the initialisation process takes longer.  In this longer 
processing time the monitor responds with its EDID and what not.  The card 
receives it in a timely fashion and sets the driver accordingly.

With your new box things happen faster on the PC side, but not on the monitor 
side.  Two times out of three the synchronisation between driver and monitor 
fails and you end up with reports of EDID not found and monitor shown as 
disconnected in your Xorg.0.log.

Having the monitor plugged in any port on the card, first or last, should not 
make a difference, but if milli/nano-seconds count then it /might/ make a 
difference, assuming the ports are tried sequentially by the driver.  Hence I 
had suggested stick with the first port.  Some user reports on the interwebs 
mentioned it, so I thought it is worth trying it.

What else worth trying is  to set fixed directives for the "Monitor" section 
in your xorg config file, or capture the EDID table into a file and feed it to 
the driver.  The former ought to work, the latter may not if the EDID itself 
is buggy, but that's a problem to solve later if it even exists.  Either way, 
setting explicit directives for the monitor Modeline(s) and preferred 
resolution/frequency ought to take auto-probing out of the equation.


> I did originally try to use the nouveau drivers.  It kinda worked, once
> at least, but the screen was very slow to respond and the mouse was very
> jerky.  It just wasn't good enough for whatever reason.  I recompiled
> the kernel without those drivers and emerged nvidia.

It's your call which drivers you should try to get it to work with first.

Slow GUI response with the nouveau driver would indicate the kernel 
configuration/firmware loading was not 100% when you trying initially, because 
it works fine when you tried it again with Kubuntu's kernel.

People who use Nvidia prefer the nvidia driver in terms of performance, CUDA, 
etc. so you may want to stick with the nvidia driver initially.  In this case, 
walk through this guide and cross-check you followed all suggestions in ther

Re: [gentoo-user] bashrc and setting PS1 variable heads up.

[Wols Lists]

On 28/06/2024 08:32, Dale wrote:

Also, some software can add files to the bashrc.d directory too.  I'm
not sure what added the gentoo-color file but I also found a file for
kitty that I installed recently.  If I remove kitty, it removes the file
too.  From what I've read, this is why it is changing to a directory.
It gives software a place to change these settings and be removed if the
software is removed.


The other BIGGY here, is that by separating out all the little changes 
for eg kitty, your personal preferrences, etc etc into little files on 
their own rather than one big monolith, you don't suddenly get 
etc-update or whatever moaning "/etc/bashrc has changed, do you want the 
old one, new one, or merge changes".


I've still got my original /etc/postfix.cf file because it's been so 
mangled with local changes I daren't touch it ...


I think systemd is the big driver here - it was a design aim of systemd 
to put default configuration in one place, local system over-rides in a 
second, and user over-rides in a third. I'm sure other software beat 
systemd to it, but systemd said "you *WILL* do this", and once they 
enforced it, everybody started doing it. Makes sense ...


Cheers,
Wol

[gentoo-user] bashrc and setting PS1 variable heads up.

[Dale]

Howdy,

I did a major upgrade and found out I had a lot of config files to
update.  I performed those updates, while losing some of my settings. 
Anyway, I figured out how to set the alias variables.  Simple enough. 
Create a file and list them in the file.  The PS1 is different because
it usually determines if a user is root or not and gives a different
prompt.  That requires a little bit of scripting, which most know is a
huge weak point for me. 

I tried setting PS1 by copying the part of the old bashrc file and
putting it in a file in the bashrc.d directory.  It went sideways
quick.  Sometimes it wouldn't log me in at all.  It acted like I typed
in a bad password.  Then I used grep -r to see if there was a clash in
setting PS1.  Turns out, there is.  If you want to set your prompt to
something other than the default, look and see if you have a file named
gentoo-color.bash in the bashrc.d directory.  You may want to use grep
-r in case PS1 is in another file too.  If you have that file tho, set
the PS1 variable in it.  If not, it causes issues.  The issue seems to
depend on what it is reading first and last. 

I figure most set this in a bashrc file in the user directory they want
it to apply too.  It seems tho that bash is moving to a new way.  Sort
of like portage did when package.* files became directories.  I kinda
like the change really.  If I want to change a alias, I change the alias
file.  Easy to find, nothing to remember which is good for me, and it
kinda organizes things.  Also easy to remove if no longer needed. 

Also, some software can add files to the bashrc.d directory too.  I'm
not sure what added the gentoo-color file but I also found a file for
kitty that I installed recently.  If I remove kitty, it removes the file
too.  From what I've read, this is why it is changing to a directory. 
It gives software a place to change these settings and be removed if the
software is removed. 

I just wanted to post this as a heads up for those who don't know about
the change.  Not being able to login was a bit nerve wrecking.  o_O

Dale

:-)  :-)