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

[Dale]

Michael wrote:
> On Sunday, 30 June 2024 23:56:40 BST Dale wrote:
>> Michael wrote:
>>> This is good! :D
>>> Edit the section below by adding the PreferredMode line:
>>>
>>> Section "Monitor"
>>>
>>> Identifier "Monitor0"
>>> VendorName "Unknown"
>>> ModelName  "LG Electronics W2253"
>>> HorizSync   30.0 - 83.0
>>> VertRefresh 56.0 - 61.0
>>> Option "PreferredMode"   "1920x1080_60.00"
>>> Option "DPMS"
>>>
>>> EndSection
>>>
>>> Save it, then check if you get a consistent result when you restart the
>>> DM, or reboot.
>>>
>>> If it is still playing up you need to show the Xorg.0.log while the
>>> monitor is working with the nvidia driver, to see which Modeline it uses
>>> and add this in the "Monitor" section too, above the "PreferredMode"
>>> entry.
>>>
>>> If none of this works reliably, then you have to capture the EDID table
>>> while the monitor is working, save it in a file and set nvidia-settings
>>> to use it hereafter.  However, if you will NOT be using this monitor for
>>> much longer this would be an exercise only to make you feel good for
>>> beating it into submission!  LOL!
>> OK.  First time, it worked.  Second time, it came up but in low res. 
>> Plasma was working to, both times.  So, I opened the Nvidia GUI and told
>> it to safe a new config with it in hi res mostly just to see what it
>> would add if anything.  It did.  The only change I could see was it
>> added metamodes options like this:
>>
>> Section "Screen"
>>
>> # Removed Option "metamodes" "nvidia-auto-select +0+0"
>> Identifier "Screen0"
>> Device "Device0"
>> Monitor"Monitor0"
>> DefaultDepth24
>> Option "Stereo" "0"
>> Option "nvidiaXineramaInfoOrder" "DP-3"
>> Option "metamodes" "1920x1080 +0+0"
>> #Option "metamodes" "1920x1080 +0+0; 1024x768_60 +0+0"
>> Option "SLI" "Off"
>> Option "MultiGPU" "Off"
>> Option "BaseMosaic" "off"
>> SubSection "Display"
>> Depth   24
>> EndSubSection
>> EndSection
>>
>>
>> As you can see, I removed the low res part, don't want that anyway, and
>> it seems to work more often but still fails a lot.  So, I removed the
>> metamodes Nvidia added.  Then it didn't come up at all, sddm or
>> anything, when I restarted DM.  I thought it adding your setting to
>> another section might help.  Guess not.  With the following removed, it
>> seems to do a little better but still can't depend on it to work.
>>
>> Section "Screen"
>> #Option "nvidiaXineramaInfoOrder" "DP-3"
>> #Option "metamodes" "1920x1080 +0+0"
>> #Option "metamodes" "1920x1080 +0+0; 1024x768_60 +0+0"
> You can add back:
>
> Option "metamodes" "1920x1080_60 +0+0"
>

Well, I did a sync and upgrade last night.  I also renamed the config
file so that it shouldn't be seen anymore.  That way when the new
monitor arrives, I don't have a clash with it. 


>> Basically, it is doing like it always has.  Most of the time, it doesn't
>> work.  Sometimes it does.  To be honest tho, I still wonder if it even
>> reads the file.  When I change something, I'd expect something
>> different.  Generally, it doesn't seem to affect anything unless I
>> reboot completely.  Sometimes I'm not sure it does then either.  So, I
>> think this old monitor just has a issue.  Maybe I need to rebuild some
>> more of the power supply or something in case it is providing bad power
>> to the parts that talks to the puter.  Either way, if the new one works,
>> I just don't think this old monitor is going to work correctly no matter
>> what we throw at it. 
> The last thing left to try is to capture the EDID table with nvidia-settings, 
> configure it to stop trying to load it from the monitor and instead feed the 
> captured file to it.  If that doesn't work either, then there is no solution 
> I 
> can think of ... 
>
>
>> I will saw this, we threw the kitchen sink at it.  I think this is one
>> of the longest threads I've seen in a long while.  o_O 
>>
>> Dale
>>
>> :-) 
>>
>> P. S.  Monitor updated.  Now it says tomorrow.  It's in the right place
>> to do so.  It's at the Memphis hub.  Usually, it comes from there to the
>> local distribution point and on the truck.  They sometimes deliver by
>> noon.  Could be a little late given it is Monday. 
> Hopefully this won't be the start of a new loong thread on yet another 
> monitor!  LOL!


I hope it works like it should.  If it does, I may do some work on that
old monitor.  Check the caps in the power supply and such as that.  I
rebuilt it a few years ago but maybe I missed something.  I may have
fixed it enough to come on, display part anyway, but not enough for
everything, the ID part, to work correctly. 

Right now, it still shows the new monitor at the hub around Memphis.  It
is Monday and they do get their stuff local a little late. UPS gets
theirs before sunup. Th

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

[Michael]

On Sunday, 30 June 2024 23:56:40 BST Dale wrote:
> Michael wrote:
> > This is good! :D
> > Edit the section below by adding the PreferredMode line:
> > 
> > Section "Monitor"
> > 
> > Identifier "Monitor0"
> > VendorName "Unknown"
> > ModelName  "LG Electronics W2253"
> > HorizSync   30.0 - 83.0
> > VertRefresh 56.0 - 61.0
> > Option "PreferredMode"   "1920x1080_60.00"
> > Option "DPMS"
> > 
> > EndSection
> > 
> > Save it, then check if you get a consistent result when you restart the
> > DM, or reboot.
> > 
> > If it is still playing up you need to show the Xorg.0.log while the
> > monitor is working with the nvidia driver, to see which Modeline it uses
> > and add this in the "Monitor" section too, above the "PreferredMode"
> > entry.
> > 
> > If none of this works reliably, then you have to capture the EDID table
> > while the monitor is working, save it in a file and set nvidia-settings
> > to use it hereafter.  However, if you will NOT be using this monitor for
> > much longer this would be an exercise only to make you feel good for
> > beating it into submission!  LOL!
> 
> OK.  First time, it worked.  Second time, it came up but in low res. 
> Plasma was working to, both times.  So, I opened the Nvidia GUI and told
> it to safe a new config with it in hi res mostly just to see what it
> would add if anything.  It did.  The only change I could see was it
> added metamodes options like this:
> 
> Section "Screen"
> 
> # Removed Option "metamodes" "nvidia-auto-select +0+0"
> Identifier "Screen0"
> Device "Device0"
> Monitor"Monitor0"
> DefaultDepth24
> Option "Stereo" "0"
> Option "nvidiaXineramaInfoOrder" "DP-3"
> Option "metamodes" "1920x1080 +0+0"
> #Option "metamodes" "1920x1080 +0+0; 1024x768_60 +0+0"
> Option "SLI" "Off"
> Option "MultiGPU" "Off"
> Option "BaseMosaic" "off"
> SubSection "Display"
> Depth   24
> EndSubSection
> EndSection
> 
> 
> As you can see, I removed the low res part, don't want that anyway, and
> it seems to work more often but still fails a lot.  So, I removed the
> metamodes Nvidia added.  Then it didn't come up at all, sddm or
> anything, when I restarted DM.  I thought it adding your setting to
> another section might help.  Guess not.  With the following removed, it
> seems to do a little better but still can't depend on it to work.
> 
> Section "Screen"
> #Option "nvidiaXineramaInfoOrder" "DP-3"
> #Option "metamodes" "1920x1080 +0+0"
> #Option "metamodes" "1920x1080 +0+0; 1024x768_60 +0+0"

You can add back:

Option "metamodes" "1920x1080_60 +0+0"


> Basically, it is doing like it always has.  Most of the time, it doesn't
> work.  Sometimes it does.  To be honest tho, I still wonder if it even
> reads the file.  When I change something, I'd expect something
> different.  Generally, it doesn't seem to affect anything unless I
> reboot completely.  Sometimes I'm not sure it does then either.  So, I
> think this old monitor just has a issue.  Maybe I need to rebuild some
> more of the power supply or something in case it is providing bad power
> to the parts that talks to the puter.  Either way, if the new one works,
> I just don't think this old monitor is going to work correctly no matter
> what we throw at it. 

The last thing left to try is to capture the EDID table with nvidia-settings, 
configure it to stop trying to load it from the monitor and instead feed the 
captured file to it.  If that doesn't work either, then there is no solution I 
can think of ... 


> I will saw this, we threw the kitchen sink at it.  I think this is one
> of the longest threads I've seen in a long while.  o_O 
> 
> Dale
> 
> :-) 
> 
> P. S.  Monitor updated.  Now it says tomorrow.  It's in the right place
> to do so.  It's at the Memphis hub.  Usually, it comes from there to the
> local distribution point and on the truck.  They sometimes deliver by
> noon.  Could be a little late given it is Monday. 

Hopefully this won't be the start of a new loong thread on yet another 
monitor!  LOL!


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

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

[Dale]

Michael wrote:
> This is good! :D
> Edit the section below by adding the PreferredMode line:
>
> Section "Monitor"
> Identifier "Monitor0"
> VendorName "Unknown"
> ModelName  "LG Electronics W2253"
> HorizSync   30.0 - 83.0
> VertRefresh 56.0 - 61.0
> Option "PreferredMode"   "1920x1080_60.00"
> Option "DPMS"
> EndSection
>
> Save it, then check if you get a consistent result when you restart the DM, 
> or 
> reboot.
>
> If it is still playing up you need to show the Xorg.0.log while the monitor 
> is 
> working with the nvidia driver, to see which Modeline it uses and add this in 
> the "Monitor" section too, above the "PreferredMode" entry.
>
> If none of this works reliably, then you have to capture the EDID table while 
> the monitor is working, save it in a file and set nvidia-settings to use it 
> hereafter.  However, if you will NOT be using this monitor for much longer 
> this would be an exercise only to make you feel good for beating it into 
> submission!  LOL!

OK.  First time, it worked.  Second time, it came up but in low res. 
Plasma was working to, both times.  So, I opened the Nvidia GUI and told
it to safe a new config with it in hi res mostly just to see what it
would add if anything.  It did.  The only change I could see was it
added metamodes options like this:

Section "Screen"

# Removed Option "metamodes" "nvidia-auto-select +0+0"
    Identifier "Screen0"
    Device "Device0"
    Monitor    "Monitor0"
    DefaultDepth    24
    Option "Stereo" "0"
    Option "nvidiaXineramaInfoOrder" "DP-3"
    Option "metamodes" "1920x1080 +0+0"
#    Option "metamodes" "1920x1080 +0+0; 1024x768_60 +0+0"
    Option "SLI" "Off"
    Option "MultiGPU" "Off"
    Option "BaseMosaic" "off"
    SubSection "Display"
    Depth   24
    EndSubSection
EndSection


As you can see, I removed the low res part, don't want that anyway, and
it seems to work more often but still fails a lot.  So, I removed the
metamodes Nvidia added.  Then it didn't come up at all, sddm or
anything, when I restarted DM.  I thought it adding your setting to
another section might help.  Guess not.  With the following removed, it
seems to do a little better but still can't depend on it to work.

Section "Screen"
#    Option "nvidiaXineramaInfoOrder" "DP-3"
#    Option "metamodes" "1920x1080 +0+0"
#    Option "metamodes" "1920x1080 +0+0; 1024x768_60 +0+0"


Basically, it is doing like it always has.  Most of the time, it doesn't
work.  Sometimes it does.  To be honest tho, I still wonder if it even
reads the file.  When I change something, I'd expect something
different.  Generally, it doesn't seem to affect anything unless I
reboot completely.  Sometimes I'm not sure it does then either.  So, I
think this old monitor just has a issue.  Maybe I need to rebuild some
more of the power supply or something in case it is providing bad power
to the parts that talks to the puter.  Either way, if the new one works,
I just don't think this old monitor is going to work correctly no matter
what we throw at it. 

I will saw this, we threw the kitchen sink at it.  I think this is one
of the longest threads I've seen in a long while.  o_O 

Dale

:-) 

P. S.  Monitor updated.  Now it says tomorrow.  It's in the right place
to do so.  It's at the Memphis hub.  Usually, it comes from there to the
local distribution point and on the truck.  They sometimes deliver by
noon.  Could be a little late given it is Monday. 

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

[Michael]

On Sunday, 30 June 2024 10:36:16 BST Dale wrote:

> Here's a little update.  First, Kubuntu wiped my Gentoo install from
> being able to boot it.  I had to boot the Gentoo USB image, mount
> everything and reinstall grub/EFI stuff.  I got it back and now I can
> boot either one by selecting it in the BIOS. 
> 
> Second.  I decided to annoy the heck out of that thing.  I logged in
> over ssh and I kept restarting DM.  Took me several dozen tries but
> eventually I got KDE to come up, plasma and all.  I opened the Nvidia
> GUI and got it to save the xorg.conf file.  It's different but it has a
> lot of info now.

This is good!  :D

Edit the section below by adding the PreferredMode line:

Section "Monitor"
Identifier "Monitor0"
VendorName "Unknown"
ModelName  "LG Electronics W2253"
HorizSync   30.0 - 83.0
VertRefresh 56.0 - 61.0
Option "PreferredMode"   "1920x1080_60.00"
Option "DPMS"
EndSection

Save it, then check if you get a consistent result when you restart the DM, or 
reboot.

If it is still playing up you need to show the Xorg.0.log while the monitor is 
working with the nvidia driver, to see which Modeline it uses and add this in 
the "Monitor" section too, above the "PreferredMode" entry.

If none of this works reliably, then you have to capture the EDID table while 
the monitor is working, save it in a file and set nvidia-settings to use it 
hereafter.  However, if you will NOT be using this monitor for much longer 
this would be an exercise only to make you feel good for beating it into 
submission!  LOL!


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

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

[Dale]

Dale wrote:
> Mark Knecht wrote:
>>
>>
>> He certainly does have his hands full!
>>
>> I'm confused. (a standard state of being for me...) I thought Dale
>> reported that
>> he installed Kubuntu on an SSD - or did we just talk about that idea
>> - and he
>> said all the port problems were ironed out with the open source driver.
>>
>> What he didn't report was if he installed the nvidia-drivers in
>> Kubuntu. I 
>> personally wouldn't write off the 'old monitor' until doing at least
>> that.
>>
>> sudo apt update
>> sudo apt upgrade
>>
>> ubuntu-drivers list
>> (make sure the video-card is found)
>>
>> sudo apt install nvidia-drivers-550
>> (assuming he has a Quadro P1000 from memory)
>>
>> reboot
>>
>> Shouldn't take more than 5-10 minutes to try. No real risk as 
>> he's going to blow away the Kubuntu install anyway.
>>
>
>
> I do have Kubuntu installed on a 2.5" SSD.  I wasn't sure how to
> install and switch to the Nvidia drivers.  That was on my todo list as
> soon as I had some time.  Thing is, the new monitor may get here
> first.  I just picked a whole gallon ice cream bucket packed full of
> basil.  It's soaking in the sink now.  Dehydrator comes next.  That
> takes at least a day to complete.  On the positive side, the house
> smells really good for a day or so.  LOL 
>
> I also thought of going to boot runlevel on my main rig while in a
> console, unplug the monitor hooked to my main rig now and plug it into
> the new rig.  Then boot and see what happens.  It might work.  It's a
> newer monitor and it's a Samsung instead of a LG.  If it did work, I
> could switch and switch to new monitor when it gets here.  I plan to
> use the old Dell rig to watch TV with while I switch.  I can use the
> backup drives for that.  Moving all these drives could take a while.  O_O
>
> At least now I have the commands needed to try it tho.  That helps.  :-D 
>
> Michael, I did try the settings you posted.  I thought I tried them
> and posted a reply.  I may have missed one tho.  This is a long
> thread.  This monitor has been a serious PITA.  :-@ 
>
> Back to the basil.  Glad my meds are working pretty good.  -_O
>
> Dale
>
> :-) :-) 


Here's a little update.  First, Kubuntu wiped my Gentoo install from
being able to boot it.  I had to boot the Gentoo USB image, mount
everything and reinstall grub/EFI stuff.  I got it back and now I can
boot either one by selecting it in the BIOS. 

Second.  I decided to annoy the heck out of that thing.  I logged in
over ssh and I kept restarting DM.  Took me several dozen tries but
eventually I got KDE to come up, plasma and all.  I opened the Nvidia
GUI and got it to save the xorg.conf file.  It's different but it has a
lot of info now.  Thing is, when I logged out and back in, same thing as
before.  Sometimes it doesn't work at all, sometimes it is the wrong
resolution or plasma doesn't start up or some other problem.  Since
email wraps things, I'm attaching the xorg.conf file it generated. 
Kinda nifty.  Some are like the info Micheal posted. 

I think at this point, I'm cutting the thing off until the new monitor
comes in.  I'm dreaming of hammers, shooting it and other things that
ain't good.  :/ 

Monitor is already about 100 miles from me at a FedEx hub.  I won't be
surprised if it comes in Monday.  It could be Tuesday tho.  They could
know it will take longer for some reason or other.  It's getting close
tho.  Yes, it is 4:30AM here.  Not a good night, yet.

Dale

:-)  :-) 
root@Gentoo-1 ~ # cat /etc/X11/xorg.conf
# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings:  version 550.90.07

# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 550.90.07

Section "ServerLayout"
Identifier "Layout0"
Screen  0  "Screen0" 0 0
InputDevice"Keyboard0" "CoreKeyboard"
InputDevice"Mouse0" "CorePointer"
Option "Xinerama" "0"
EndSection

Section "Files"
EndSection

Section "InputDevice"

# generated from data in "/etc/conf.d/gpm"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol"
Option "Device" "/dev/input/mice"
Option "Emulate3Buttons" "no"
Option "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"

# generated from default
Identifier "Keyboard0"
Driver "kbd"
EndSection

Section "Monitor"
Identifier "Monitor0"
VendorName "Unknown"
ModelName  "LG Electronics W2253"
HorizSync   30.0 - 83.0
VertRefresh 56.0 - 61.0
Option "DPMS"
EndSection

Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName  "Quadro P1000"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor"Monitor0"
DefaultDepth24
Option "Stereo" "0"
Option "nvidiaXineramaInfoOrder" "DP-3"
Option

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

[Dale]

Dale wrote:
> Mark Knecht wrote:
>>
>>
>> He certainly does have his hands full!
>>
>> I'm confused. (a standard state of being for me...) I thought Dale
>> reported that
>> he installed Kubuntu on an SSD - or did we just talk about that idea
>> - and he
>> said all the port problems were ironed out with the open source driver.
>>
>> What he didn't report was if he installed the nvidia-drivers in
>> Kubuntu. I 
>> personally wouldn't write off the 'old monitor' until doing at least
>> that.
>>
>> sudo apt update
>> sudo apt upgrade
>>
>> ubuntu-drivers list
>> (make sure the video-card is found)
>>
>> sudo apt install nvidia-drivers-550
>> (assuming he has a Quadro P1000 from memory)
>>
>> reboot
>>
>> Shouldn't take more than 5-10 minutes to try. No real risk as 
>> he's going to blow away the Kubuntu install anyway.
>>
>
>
> I do have Kubuntu installed on a 2.5" SSD.  I wasn't sure how to
> install and switch to the Nvidia drivers.  That was on my todo list as
> soon as I had some time.  Thing is, the new monitor may get here
> first.  I just picked a whole gallon ice cream bucket packed full of
> basil.  It's soaking in the sink now.  Dehydrator comes next.  That
> takes at least a day to complete.  On the positive side, the house
> smells really good for a day or so.  LOL 
>
> I also thought of going to boot runlevel on my main rig while in a
> console, unplug the monitor hooked to my main rig now and plug it into
> the new rig.  Then boot and see what happens.  It might work.  It's a
> newer monitor and it's a Samsung instead of a LG.  If it did work, I
> could switch and switch to new monitor when it gets here.  I plan to
> use the old Dell rig to watch TV with while I switch.  I can use the
> backup drives for that.  Moving all these drives could take a while.  O_O
>
> At least now I have the commands needed to try it tho.  That helps.  :-D 
>
> Michael, I did try the settings you posted.  I thought I tried them
> and posted a reply.  I may have missed one tho.  This is a long
> thread.  This monitor has been a serious PITA.  :-@ 
>
> Back to the basil.  Glad my meds are working pretty good.  -_O
>
> Dale
>
> :-) :-) 


Here's a little update.  First, Kubuntu wiped my Gentoo install from
being able to boot it.  I had to boot the Gentoo USB image, mount
everything and reinstall grub/EFI stuff.  I got it back and now I can
boot either one by selecting it in the BIOS. 

Second.  I decided to annoy the heck out of that thing.  I logged in
over ssh and I kept restarting DM.  Took me several dozen tries but
eventually I got KDE to come up, plasma and all.  I opened the Nvidia
GUI and got it to save the xorg.conf file.  It's different but it has a
lot of info now.  Thing is, when I logged out and back in, same thing as
before.  Sometimes it doesn't work at all, sometimes it is the wrong
resolution or plasma doesn't start up or some other problem.  Since
email wraps things, I'm attaching the xorg.conf file it generated. 
Kinda nifty.  Some are like the info Micheal posted. 

I think at this point, I'm cutting the thing off until the new monitor
comes in.  I'm dreaming of hammers, shooting it and other things that
ain't good.  :/ 

Monitor is already about 100 miles from me at a FedEx hub.  I won't be
surprised if it comes in Monday.  It could be Tuesday tho.  They could
know it will take longer for some reason or other.  It's getting close
tho. 

Dale

:-)  :-) 
root@Gentoo-1 ~ # cat /etc/X11/xorg.conf
# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings:  version 550.90.07

# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 550.90.07

Section "ServerLayout"
Identifier "Layout0"
Screen  0  "Screen0" 0 0
InputDevice"Keyboard0" "CoreKeyboard"
InputDevice"Mouse0" "CorePointer"
Option "Xinerama" "0"
EndSection

Section "Files"
EndSection

Section "InputDevice"

# generated from data in "/etc/conf.d/gpm"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol"
Option "Device" "/dev/input/mice"
Option "Emulate3Buttons" "no"
Option "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"

# generated from default
Identifier "Keyboard0"
Driver "kbd"
EndSection

Section "Monitor"
Identifier "Monitor0"
VendorName "Unknown"
ModelName  "LG Electronics W2253"
HorizSync   30.0 - 83.0
VertRefresh 56.0 - 61.0
Option "DPMS"
EndSection

Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName  "Quadro P1000"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor"Monitor0"
DefaultDepth24
Option "Stereo" "0"
Option "nvidiaXineramaInfoOrder" "DP-3"
Option "metamodes" "nvidia-auto-select +0+0"
Optio

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 Sat, Jun 29, 2024 at 3:15 PM Michael  > wrote:
> >
> > On Saturday, 29 June 2024 21:30:59 BST Dale wrote:
> > > I booted the rig up and decided to try something.  Once it was
> booted, I
> > > logged in from my main rig via ssh.  I then typed in the command to
> > > start DM.  It started and looked OK.  Then I just up arrow and changed
> > > it to restart the DM.  I restarted DM back to back several times, more
> > > than a dozen.  Sometimes it wouldn't work, sometimes it would be low
> > > resolution and sometimes it would come up and look like it should, hi
> > > res and all.  I also tried logging in when it was working and I could
> > > login.  The biggest thing I noticed, it never came up fully.  Most of
> > > the time it came up in hi res but no plasma.  A few times it was a low
> > > res screen and no plasma.  Looked like maybe 720P or less.
> > >
> > > The thing is, it didn't fully come up even once.  It was always
> lacking
> > > plasma at least.  Some of the time, it was low res.  Several
> times, the
> > > monitor would go black and cut off completely.  It would go to sleep.
> > > If the new monitor works, I'm thinking Micheal is right.  The monitor
> > > works with slower systems and the nouveau drivers on boot media.  With
> > > Nvidia on the install, hit or miss, mostly miss.  I think it has only
> > > worked fully twice.
> >
> > I think after all these attempts you have proven this monitor with
> this nvidia
> > card just won't work on its own, unless and until you try changing the
> > "Monitor" settings as I suggested in my previous message, or
> extract, store
> > and feed the monitor's EDID file to your card.
> >
> > However, you have your hands full and may want to leave this for now
> and wait
> > for the next larger and more modern monitor to show up.  Hopefully
> that will
> > work better!  :-)
>
> He certainly does have his hands full!
>
> I'm confused. (a standard state of being for me...) I thought Dale
> reported that
> he installed Kubuntu on an SSD - or did we just talk about that idea -
> and he
> said all the port problems were ironed out with the open source driver.
>
> What he didn't report was if he installed the nvidia-drivers in
> Kubuntu. I 
> personally wouldn't write off the 'old monitor' until doing at least that.
>
> sudo apt update
> sudo apt upgrade
>
> ubuntu-drivers list
> (make sure the video-card is found)
>
> sudo apt install nvidia-drivers-550
> (assuming he has a Quadro P1000 from memory)
>
> reboot
>
> Shouldn't take more than 5-10 minutes to try. No real risk as 
> he's going to blow away the Kubuntu install anyway.
>


I do have Kubuntu installed on a 2.5" SSD.  I wasn't sure how to install
and switch to the Nvidia drivers.  That was on my todo list as soon as I
had some time.  Thing is, the new monitor may get here first.  I just
picked a whole gallon ice cream bucket packed full of basil.  It's
soaking in the sink now.  Dehydrator comes next.  That takes at least a
day to complete.  On the positive side, the house smells really good for
a day or so.  LOL 

I also thought of going to boot runlevel on my main rig while in a
console, unplug the monitor hooked to my main rig now and plug it into
the new rig.  Then boot and see what happens.  It might work.  It's a
newer monitor and it's a Samsung instead of a LG.  If it did work, I
could switch and switch to new monitor when it gets here.  I plan to use
the old Dell rig to watch TV with while I switch.  I can use the backup
drives for that.  Moving all these drives could take a while.  O_O

At least now I have the commands needed to try it tho.  That helps.  :-D 

Michael, I did try the settings you posted.  I thought I tried them and
posted a reply.  I may have missed one tho.  This is a long thread. 
This monitor has been a serious PITA.  :-@ 

Back to the basil.  Glad my meds are working pretty good.  -_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 Sat, Jun 29, 2024 at 3:15 PM Michael  wrote:
>
> On Saturday, 29 June 2024 21:30:59 BST Dale wrote:
> > I booted the rig up and decided to try something.  Once it was booted, I
> > logged in from my main rig via ssh.  I then typed in the command to
> > start DM.  It started and looked OK.  Then I just up arrow and changed
> > it to restart the DM.  I restarted DM back to back several times, more
> > than a dozen.  Sometimes it wouldn't work, sometimes it would be low
> > resolution and sometimes it would come up and look like it should, hi
> > res and all.  I also tried logging in when it was working and I could
> > login.  The biggest thing I noticed, it never came up fully.  Most of
> > the time it came up in hi res but no plasma.  A few times it was a low
> > res screen and no plasma.  Looked like maybe 720P or less.
> >
> > The thing is, it didn't fully come up even once.  It was always lacking
> > plasma at least.  Some of the time, it was low res.  Several times, the
> > monitor would go black and cut off completely.  It would go to sleep.
> > If the new monitor works, I'm thinking Micheal is right.  The monitor
> > works with slower systems and the nouveau drivers on boot media.  With
> > Nvidia on the install, hit or miss, mostly miss.  I think it has only
> > worked fully twice.
>
> I think after all these attempts you have proven this monitor with this
nvidia
> card just won't work on its own, unless and until you try changing the
> "Monitor" settings as I suggested in my previous message, or extract,
store
> and feed the monitor's EDID file to your card.
>
> However, you have your hands full and may want to leave this for now and
wait
> for the next larger and more modern monitor to show up.  Hopefully that
will
> work better!  :-)

He certainly does have his hands full!

I'm confused. (a standard state of being for me...) I thought Dale reported
that
he installed Kubuntu on an SSD - or did we just talk about that idea - and
he
said all the port problems were ironed out with the open source driver.

What he didn't report was if he installed the nvidia-drivers in Kubuntu. I
personally wouldn't write off the 'old monitor' until doing at least that.

sudo apt update
sudo apt upgrade

ubuntu-drivers list
(make sure the video-card is found)

sudo apt install nvidia-drivers-550
(assuming he has a Quadro P1000 from memory)

reboot

Shouldn't take more than 5-10 minutes to try. No real risk as
he's going to blow away the Kubuntu install anyway.

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

[Dale]

Jack wrote:
> Have you tried downloading the EDID from the monitor so it can be
> loaded as firmware from disk, so the response speed of the monitor
> isn't a factor?  I had to do that once for a similar reason, but it
> was so many years ago I don't actually remember the details - in fact
> it might have been a big glass CRT  monitor where I had to get the
> edid from off the interwebs somewhere.
>

I haven't but maybe I should.  Thing is, if the new monitor that is on
the way works, I won't likely ever have this monitor on the new rig
again.  It is the smallest and oldest monitor I have.  I usually use it
during installs or on rigs I rarely use anyway.  This is mostly on the
NAS box rigs that I use to do backups with.  I only boot them once a
week and they only run for a couple hours at most.  I pitched the old
CRT monitors long ago.  Those thing produced a LOT of heat and pulled a
huge amount of power compared to the new flat screen ones. 

I just realized something.  The CPU cooler and m.2 cooler is made by the
same company.  No wonder they look so much alike.  ROFL  Oh, I did add
some thermal pad to the controller end.  It was making some contact
before but it looks like it was only touching about half of the
controller chip based on the indentation it left behind in the pad.  A
.5mm thick piece made it fairly flat between the controller and memory
chip.  It would likely work fine even under heavy use but now I know it
is going to cool very well.  I can be a little OCD on some things.  :/ 

Oh, I'm in the heat picking basil.  Dang that stuff smells good.  Almost
got a ice cream bucket full.  :-D  I'm still on the first planter.  I
got two more to go.  o_O

Dale

:-)  :-) 

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

[Michael]

On Saturday, 29 June 2024 21:30:59 BST Dale wrote:
> I booted the rig up and decided to try something.  Once it was booted, I
> logged in from my main rig via ssh.  I then typed in the command to
> start DM.  It started and looked OK.  Then I just up arrow and changed
> it to restart the DM.  I restarted DM back to back several times, more
> than a dozen.  Sometimes it wouldn't work, sometimes it would be low
> resolution and sometimes it would come up and look like it should, hi
> res and all.  I also tried logging in when it was working and I could
> login.  The biggest thing I noticed, it never came up fully.  Most of
> the time it came up in hi res but no plasma.  A few times it was a low
> res screen and no plasma.  Looked like maybe 720P or less. 
> 
> The thing is, it didn't fully come up even once.  It was always lacking
> plasma at least.  Some of the time, it was low res.  Several times, the
> monitor would go black and cut off completely.  It would go to sleep. 
> If the new monitor works, I'm thinking Micheal is right.  The monitor
> works with slower systems and the nouveau drivers on boot media.  With
> Nvidia on the install, hit or miss, mostly miss.  I think it has only
> worked fully twice. 

I think after all these attempts you have proven this monitor with this nvidia 
card just won't work on its own, unless and until you try changing the 
"Monitor" settings as I suggested in my previous message, or extract, store 
and feed the monitor's EDID file to your card.

However, you have your hands full and may want to leave this for now and wait 
for the next larger and more modern monitor to show up.  Hopefully that will 
work better!  :-)


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

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

[Jack]

Have you tried downloading the EDID from the monitor so it can be loaded 
as firmware from disk, so the response speed of the monitor isn't a 
factor?  I had to do that once for a similar reason, but it was so many 
years ago I don't actually remember the details - in fact it might have 
been a big glass CRT  monitor where I had to get the edid from off the 
interwebs somewhere.


On 6/29/24 4:30 PM, Dale wrote:

I booted the rig up and decided to try something.  Once it was booted, I
logged in from my main rig via ssh.  I then typed in the command to
start DM.  It started and looked OK.  Then I just up arrow and changed
it to restart the DM.  I restarted DM back to back several times, more
than a dozen.  Sometimes it wouldn't work, sometimes it would be low
resolution and sometimes it would come up and look like it should, hi
res and all.  I also tried logging in when it was working and I could
login.  The biggest thing I noticed, it never came up fully.  Most of
the time it came up in hi res but no plasma.  A few times it was a low
res screen and no plasma.  Looked like maybe 720P or less.

The thing is, it didn't fully come up even once.  It was always lacking
plasma at least.  Some of the time, it was low res.  Several times, the
monitor would go black and cut off completely.  It would go to sleep.
If the new monitor works, I'm thinking Micheal is right.  The monitor
works with slower systems and the nouveau drivers on boot media.  With
Nvidia on the install, hit or miss, mostly miss.  I think it has only
worked fully twice.

The last update showed the monitor a couple states away.  FedEx is
pretty speedy.  I think if things move well, it could be here Monday.
It still shows Tuesday tho.  Given I been dealing with this for a week
or so now, another few days isn't a big deal.  Plus, I'll have a really
nice large monitor for these old eyes.  o_o

I took meds last night.  I didn't wake up in time to pick my basil
again.  I got three planters of it that need picking.  It's hot and
humid outside.  Try again in the morning.  That basil sure is good.
Even opening the jar smells awesome.  Nothing like the store bought stuff.

I finally uploaded some pics.  Some are while the rig is running.  You
can see the LEDs on the memory stick lit up.  Some are components.
Also, there is a couple of the little m.2 stick cooler.  I think that
little thing is so cute.  Kinda looks like the CPU cooler, just
smaller.  m.2 sticks runs at just above 100F even when pretty busy.
Very effective.  :-D  This is a link to the gallery or whatever.

https://postimg.cc/gallery/w6HQp83

Just imagine that in a Fractal Design Define XL case now.  Dang that
case is big.  It's a hair larger than my Cooler Master HAF-932 which is
a awesome case.  Oh, I also finally fixed the power on light on the
front.  I hooked the wires up backwards.  LEDs never work well when
connected up wrong.  LOL

Dale

:-)  :-)

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

[Dale]

I booted the rig up and decided to try something.  Once it was booted, I
logged in from my main rig via ssh.  I then typed in the command to
start DM.  It started and looked OK.  Then I just up arrow and changed
it to restart the DM.  I restarted DM back to back several times, more
than a dozen.  Sometimes it wouldn't work, sometimes it would be low
resolution and sometimes it would come up and look like it should, hi
res and all.  I also tried logging in when it was working and I could
login.  The biggest thing I noticed, it never came up fully.  Most of
the time it came up in hi res but no plasma.  A few times it was a low
res screen and no plasma.  Looked like maybe 720P or less. 

The thing is, it didn't fully come up even once.  It was always lacking
plasma at least.  Some of the time, it was low res.  Several times, the
monitor would go black and cut off completely.  It would go to sleep. 
If the new monitor works, I'm thinking Micheal is right.  The monitor
works with slower systems and the nouveau drivers on boot media.  With
Nvidia on the install, hit or miss, mostly miss.  I think it has only
worked fully twice. 

The last update showed the monitor a couple states away.  FedEx is
pretty speedy.  I think if things move well, it could be here Monday. 
It still shows Tuesday tho.  Given I been dealing with this for a week
or so now, another few days isn't a big deal.  Plus, I'll have a really
nice large monitor for these old eyes.  o_o

I took meds last night.  I didn't wake up in time to pick my basil
again.  I got three planters of it that need picking.  It's hot and
humid outside.  Try again in the morning.  That basil sure is good. 
Even opening the jar smells awesome.  Nothing like the store bought stuff. 

I finally uploaded some pics.  Some are while the rig is running.  You
can see the LEDs on the memory stick lit up.  Some are components. 
Also, there is a couple of the little m.2 stick cooler.  I think that
little thing is so cute.  Kinda looks like the CPU cooler, just
smaller.  m.2 sticks runs at just above 100F even when pretty busy. 
Very effective.  :-D  This is a link to the gallery or whatever. 

https://postimg.cc/gallery/w6HQp83

Just imagine that in a Fractal Design Define XL case now.  Dang that
case is big.  It's a hair larger than my Cooler Master HAF-932 which is
a awesome case.  Oh, I also finally fixed the power on light on the
front.  I hooked the wires up backwards.  LEDs never work well when
connected up wrong.  LOL 

Dale

:-)  :-) 

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:
>
> 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 there 
> to configure your kernel, including disabling the nouveau driver.
>
> https://wiki.gentoo.org/wiki/NVIDIA/nvidia-drivers
>


I went through that guide.  I did find some drivers that needed to be
enabled according to the guide.  I enabled them, recompiled and
rebooted.  Nothing changed. 


> If you intend to have both nouveau and nvidia drivers and switch between 
> them, 
> then you can build nouveau as a module and implement the more convoluted 
> switching methods suggested in the next guide, but I suggest you leave this 
> for later and not confuse the two drivers:
>
> https://wiki.gentoo.org/wiki/Nouveau_%26_nvidia-drivers_switching

I wasn't intending to use both, just see if the nouveau drivers would
work and perform well.  With some tweaking maybe.  They seem to work
fine on the boot media.  If they did that on the install and with all my
monitors connected, I'd be fine with it.  I want the monitors to work. 
Nvidia would be nice given it is what I'm used to but right now, Nvidia
is on my bad list.  :-D  Keep in mind, I may end up with three monitors,
maybe four, connected.  Whatever driver I use needs to be up to the
task.  I'd think Nvidia would be, if it ever works that is.  LOL 


>
> Having checked your kernel against the nvidia-driver guide, installed your 
> updated kernel & initramfs images you should reboot.  Use 'lspci -k' and scan 
> dmesg to make sure nvidia is loaded and there were no hiccups.
>
> You've tried not having an xorg.conf and didn't work, or at least it did not 
> work reliably.  Mind you, you also tried with a xorg.conf and this didn't 
> make 
> things better.  LOL!  However, I think this was because the "Monitor" section 
> was mostly empty:
>
> Section "Monitor"
> Identifier "Monitor0"
> VendorName "Unknown"
> ModelName  "Unknown"
> Option "DPMS"
> EndSection
>
> Restart, if you need to, the display-manager until you eventually arrive at a 
> fully loaded and functioning desktop.  nvidia-smi should reveal if the driver 
> is loaded and working fully.  You can run nvidia-settings, (emerge x11-
> drivers/nvidia-drivers with USE="tools") to tweak resolution and frequency 
> for 
> your monitor, which will then be stored in your config file:
>
> https://download.nvidia.com/XFree86/Linux-x86_64/1.0-6106/nvidia-settings-user-guide.txt

I have tools enabled.  Did that long ago.  Those tools while rarely used
can come in handy. 

>
> O, while all is working as desired 'xrandr -q' will provide you with some 
> useful information for your xorg.conf:
>
> Identifier - e.g. "DisplayPort-0", or "LG Electronics W2253"
>
> Modeline - e.g. Modeline 1920x1080_60.0  138.50  1920 1968 2000 2080  1080 
> 1083 1088  +hsync +vsync
>
> and you can set a preferred option in your xorg.conf; e.g.
>
> HorizSync   15.0 - 67.0
> VertRefresh 59.0 - 60.0
> Modeline"1920x1080_60.0  138.50  1920 1968 2000 2080  1080 1083 1088 
>  +hsync +vsync"
> Option "PreferredMode" "1920x1080"_60.0"
>
> or some such.


This is the output of xrandr and nvidia-settings.


root@Gentoo-1 ~ # nvidia-settings -q all

ERROR: The control display is undefined; please run `nvidia-settings
--help` for usage information.

root@Gentoo-1 ~ # xrandr -q
Can't open display
root@Gentoo-1 ~ #


At one point, the nvidia command spit out a LOT of info.  I scrolled
through it and saw nothing that looked like a error.  Thing is, I can't
get it back now.  The xrandr command also spit out a little info.  For
some reason, after a reboot and the screen being like it was, it shows
that above now.  I have DM running, logged into KDE but no plasma. 
Resolution looks correct.  I think if plasma was working, it would be
normal.  A 'ps aux | grep plasma' shows it is running.  There is nothing
on the screen tho.  Not even one dot.  I left a Konsole window open the
last time it worked.  That's how I know it is up.  Otherwise, I'd have a
black screen and nothing else. 


>
> If the above won't do it, you can capture the monitor's EDID while it is 
> working - you can use nvidia-settings again:
>
> https://nvidia.custhelp.com/app/answers/detail/a_id/3571/~/managing-a-display-edid-on-linux
>
> There's a more manual way to do this too:
>
> find /sys |grep -i edid
>
> then copy the corresponding file to /lib/firmware/LG/W2253_edid.bin
>
> and add it to your kernel before you recompile it:
>

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] 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

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] 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 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

:-)  :-) 

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

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 2:13 PM Dale  > wrote:
> 
> > I've tried to use nvidia-settings but the man page is like Greek. 
> The one thing I did figure out, -q all.  On my main rig, it spits out
> TONS of info.  On the new rig, it just says something like no display
> found or something.  It's like two lines, maybe one.
> >
> > Had several interruptions so managed to try Kubuntu "Try" option. 
> It comes up just fine, correct resolution, plasma is working and all. 
> I'm attaching the Xorg log from Kubuntu.
> >
> > Maybe the Kubuntu log will shed some light.
> >
> > Dale
> >
> > :-)  :-)
>
> OK, so if Kubuntu comes up and runs stable for an hour or two then I
> don't think it's your new rig or monitor.
>
> I have a suspicion that Kubuntu booted and loaded the Open Source
> driver and not the nvidia driver, but that's just a guess. However, if
> that's the case then you can almost certainly use whatever Kubuntu has
> used as far as drivers and an xorg.conf file and see if that helps
> with your Gentoo issues. Once you get Gentoo working with the Open
> Source driver then you could investigate using nvidia's.
>
> If you have time to let the machine soak awhile then I'd consider a
> reboot into Kubuntu and then take a look at what drivers are loaded
> using lsmod. There will likely be a huge list. I have a 2 year old
> machine that's not unlike your new machine (yours is slightly more
> powerful I think) but the list of drivers loaded is just huge. However
> it works, and once you get it going with lots of drivers you can then
> rebuild things with them in the kernel if you want to.
>
> Anyway, look at lsmod and report back. Here's mine running Kubuntu,
> and I have no xorg.conf but it runs fine with 3 monitors.
>
> mark@science2:~$ lsmod | grep nvidia
> nvidia_uvm           1789952  0
> nvidia_drm             90112  16
> nvidia_modeset       1314816  39 nvidia_drm
> nvidia              56827904  1890 nvidia_uvm,nvidia_modeset
> video                  73728  2 asus_wmi,nvidia_modeset
> mark@science2:~$
>
> Good luck,
> Mark


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. 

Dale

:-)  :-) 

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 22:06:36 BST Dale wrote:
>> Mark Knecht wrote:
>>> On Thu, Jun 27, 2024 at 12:03 AM Dale >>
>>> > wrote:
 Update.  I played around a bit.  I figured I didn't have a lot to lose
 here.  It either works, or it doesn't.  After playing around a bit, I
 got it to work.  I have not restarted it to see if it will work again,
 yet.  I wanted to grab some log info first, while it is working.  So,
 this part is about when KDE comes up completely but could include some
 attempts that failed.  Comes up completely means, in the correct
 resolution, background image and the panel thing on the bottom, which
 means plasma is running as it should.  I'm doing these inside the email
 instead of as attachments.  Sorry for the length.  I just want to share
 this while I have it available.

 This first one, I had a few failures before it succeeded.  I couldn't
 figure out when the working bit started so it is the complete log.
>>> Hi Dale,
>>>I have returned home and can once again bottom post.
>>>
>>>There's no way I'm going to read and understand this
>>> whole thread but I did have one question and one comment:
>>>
>>> 1) Did you ever actually try the Kubunu option that didn't
>>> require an install? I saw you mentions Knoppix and maybe
>>> one other option. Just curious as to what the results were.
>>>
>>> 2) I see you discussing xorg.conf file which I don't use
>>> here but did you generate this file - if you are really using
>>> it - using the nvidia-settings app, or by hand? 
>>>
>>>If your system will stay up I believe nvidia-settings is
>>> recommended by NVidia, or was anyway. It does a good
>>> job of showing the layout and handling options that NVidia
>>> says make their cards work better.
>>>
>>> Good luck,
>>> Mark
>> I booted the Gentoo live image and Knoppix.  Knoppix is old.  I don't
>> think it is being maintained anymore but even on this new hardware, even
>> it worked.  I've booted other things to and all work fine except the
>> Gentoo install, the one thing I need to work.  I checked, I did download
>> Kubuntu but I don't remember trying it.  With my memory tho, I may have
>> and just don't remember it.  :/  I'll add it to my Ventoy stick and try
>> it shortly.  It's hot, humid and my energy level isn't much.  The family
>> visit to the hospital drained me good.  And she is still sick.  I took
>> her some tomatoes this morning and she likes the peaches I got for her
>> too.  Not much she can eat. 
>>
>> I've tried with no xorg.conf at first.  Then I tried with one that tells
>> it to use the nvidia driver, even tho lsmod shows it loaded and lspci -k
>> shows it being used.  Then I used nvidia-xconfig to create a conf file. 
>> Then I tried some options that Michael suggested.  On occasion, it
>> works.  Most of the time, it doesn't.  To be honest, I'm not sure if
>> anything we do is affecting it.  I think sometimes things just drop into
>> place and it works.  Most of the time, things don't drop into place and
>> it fails or only partially works. 
>>
>> Given I've used different boot media, a different video card and
>> different config options, I'm thinking it is the monitor and it just
>> clashes with this one install but works with others, which may figure
>> out to ignore what the monitor fails to do.  I find it odd but it is
>> logical. 
>>
>> I've tried to use nvidia-settings but the man page is like Greek.  The
>> one thing I did figure out, -q all.  On my main rig, it spits out TONS
>> of info.  On the new rig, it just says something like no display found
>> or something.  It's like two lines, maybe one. 
>>
>> Had several interruptions so managed to try Kubuntu "Try" option.  It
>> comes up just fine, correct resolution, plasma is working and all.  I'm
>> attaching the Xorg log from Kubuntu. 
>>
>> Maybe the Kubuntu log will shed some light. 
>>
>> Dale
>>
>> :-)  :-) 
> [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. 

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

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 2:13 PM Dale  wrote:

> I've tried to use nvidia-settings but the man page is like Greek.  The
one thing I did figure out, -q all.  On my main rig, it spits out TONS of
info.  On the new rig, it just says something like no display found or
something.  It's like two lines, maybe one.
>
> Had several interruptions so managed to try Kubuntu "Try" option.  It
comes up just fine, correct resolution, plasma is working and all.  I'm
attaching the Xorg log from Kubuntu.
>
> Maybe the Kubuntu log will shed some light.
>
> Dale
>
> :-)  :-)

OK, so if Kubuntu comes up and runs stable for an hour or two then I don't
think it's your new rig or monitor.

I have a suspicion that Kubuntu booted and loaded the Open Source driver
and not the nvidia driver, but that's just a guess. However, if that's the
case then you can almost certainly use whatever Kubuntu has used as far as
drivers and an xorg.conf file and see if that helps with your Gentoo
issues. Once you get Gentoo working with the Open Source driver then you
could investigate using nvidia's.

If you have time to let the machine soak awhile then I'd consider a reboot
into Kubuntu and then take a look at what drivers are loaded using lsmod.
There will likely be a huge list. I have a 2 year old machine that's not
unlike your new machine (yours is slightly more powerful I think) but the
list of drivers loaded is just huge. However it works, and once you get it
going with lots of drivers you can then rebuild things with them in the
kernel if you want to.

Anyway, look at lsmod and report back. Here's mine running Kubuntu, and I
have no xorg.conf but it runs fine with 3 monitors.

mark@science2:~$ lsmod | grep nvidia
nvidia_uvm   1789952  0
nvidia_drm 90112  16
nvidia_modeset   1314816  39 nvidia_drm
nvidia  56827904  1890 nvidia_uvm,nvidia_modeset
video  73728  2 asus_wmi,nvidia_modeset
mark@science2:~$

Good luck,
Mark

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 22:06:36 BST Dale wrote:
> Mark Knecht wrote:
> > On Thu, Jun 27, 2024 at 12:03 AM Dale  > 
> > > wrote:
> > > Update.  I played around a bit.  I figured I didn't have a lot to lose
> > > here.  It either works, or it doesn't.  After playing around a bit, I
> > > got it to work.  I have not restarted it to see if it will work again,
> > > yet.  I wanted to grab some log info first, while it is working.  So,
> > > this part is about when KDE comes up completely but could include some
> > > attempts that failed.  Comes up completely means, in the correct
> > > resolution, background image and the panel thing on the bottom, which
> > > means plasma is running as it should.  I'm doing these inside the email
> > > instead of as attachments.  Sorry for the length.  I just want to share
> > > this while I have it available.
> > > 
> > > This first one, I had a few failures before it succeeded.  I couldn't
> > > figure out when the working bit started so it is the complete log.
> > 
> > Hi Dale,
> >I have returned home and can once again bottom post.
> > 
> >There's no way I'm going to read and understand this
> > whole thread but I did have one question and one comment:
> > 
> > 1) Did you ever actually try the Kubunu option that didn't
> > require an install? I saw you mentions Knoppix and maybe
> > one other option. Just curious as to what the results were.
> > 
> > 2) I see you discussing xorg.conf file which I don't use
> > here but did you generate this file - if you are really using
> > it - using the nvidia-settings app, or by hand? 
> > 
> >If your system will stay up I believe nvidia-settings is
> > recommended by NVidia, or was anyway. It does a good
> > job of showing the layout and handling options that NVidia
> > says make their cards work better.
> > 
> > Good luck,
> > Mark
> 
> I booted the Gentoo live image and Knoppix.  Knoppix is old.  I don't
> think it is being maintained anymore but even on this new hardware, even
> it worked.  I've booted other things to and all work fine except the
> Gentoo install, the one thing I need to work.  I checked, I did download
> Kubuntu but I don't remember trying it.  With my memory tho, I may have
> and just don't remember it.  :/  I'll add it to my Ventoy stick and try
> it shortly.  It's hot, humid and my energy level isn't much.  The family
> visit to the hospital drained me good.  And she is still sick.  I took
> her some tomatoes this morning and she likes the peaches I got for her
> too.  Not much she can eat. 
> 
> I've tried with no xorg.conf at first.  Then I tried with one that tells
> it to use the nvidia driver, even tho lsmod shows it loaded and lspci -k
> shows it being used.  Then I used nvidia-xconfig to create a conf file. 
> Then I tried some options that Michael suggested.  On occasion, it
> works.  Most of the time, it doesn't.  To be honest, I'm not sure if
> anything we do is affecting it.  I think sometimes things just drop into
> place and it works.  Most of the time, things don't drop into place and
> it fails or only partially works. 
> 
> Given I've used different boot media, a different video card and
> different config options, I'm thinking it is the monitor and it just
> clashes with this one install but works with others, which may figure
> out to ignore what the monitor fails to do.  I find it odd but it is
> logical. 
> 
> I've tried to use nvidia-settings but the man page is like Greek.  The
> one thing I did figure out, -q all.  On my main rig, it spits out TONS
> of info.  On the new rig, it just says something like no display found
> or something.  It's like two lines, maybe one. 
> 
> Had several interruptions so managed to try Kubuntu "Try" option.  It
> comes up just fine, correct resolution, plasma is working and all.  I'm
> attaching the Xorg log from Kubuntu. 
> 
> Maybe the Kubuntu log will shed some light. 
> 
> Dale
> 
> :-)  :-) 

[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?  


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

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 12:03 AM Dale  > wrote:
> >
> > Update.  I played around a bit.  I figured I didn't have a lot to lose
> > here.  It either works, or it doesn't.  After playing around a bit, I
> > got it to work.  I have not restarted it to see if it will work again,
> > yet.  I wanted to grab some log info first, while it is working.  So,
> > this part is about when KDE comes up completely but could include some
> > attempts that failed.  Comes up completely means, in the correct
> > resolution, background image and the panel thing on the bottom, which
> > means plasma is running as it should.  I'm doing these inside the email
> > instead of as attachments.  Sorry for the length.  I just want to share
> > this while I have it available.
> >
> > This first one, I had a few failures before it succeeded.  I couldn't
> > figure out when the working bit started so it is the complete log.
> >
> >
>
> Hi Dale,
>    I have returned home and can once again bottom post.
>
>    There's no way I'm going to read and understand this
> whole thread but I did have one question and one comment:
>
> 1) Did you ever actually try the Kubunu option that didn't
> require an install? I saw you mentions Knoppix and maybe
> one other option. Just curious as to what the results were.
>
> 2) I see you discussing xorg.conf file which I don't use
> here but did you generate this file - if you are really using
> it - using the nvidia-settings app, or by hand? 
>
>    If your system will stay up I believe nvidia-settings is
> recommended by NVidia, or was anyway. It does a good
> job of showing the layout and handling options that NVidia
> says make their cards work better.
>
> Good luck,
> Mark

I booted the Gentoo live image and Knoppix.  Knoppix is old.  I don't
think it is being maintained anymore but even on this new hardware, even
it worked.  I've booted other things to and all work fine except the
Gentoo install, the one thing I need to work.  I checked, I did download
Kubuntu but I don't remember trying it.  With my memory tho, I may have
and just don't remember it.  :/  I'll add it to my Ventoy stick and try
it shortly.  It's hot, humid and my energy level isn't much.  The family
visit to the hospital drained me good.  And she is still sick.  I took
her some tomatoes this morning and she likes the peaches I got for her
too.  Not much she can eat. 

I've tried with no xorg.conf at first.  Then I tried with one that tells
it to use the nvidia driver, even tho lsmod shows it loaded and lspci -k
shows it being used.  Then I used nvidia-xconfig to create a conf file. 
Then I tried some options that Michael suggested.  On occasion, it
works.  Most of the time, it doesn't.  To be honest, I'm not sure if
anything we do is affecting it.  I think sometimes things just drop into
place and it works.  Most of the time, things don't drop into place and
it fails or only partially works. 

Given I've used different boot media, a different video card and
different config options, I'm thinking it is the monitor and it just
clashes with this one install but works with others, which may figure
out to ignore what the monitor fails to do.  I find it odd but it is
logical. 

I've tried to use nvidia-settings but the man page is like Greek.  The
one thing I did figure out, -q all.  On my main rig, it spits out TONS
of info.  On the new rig, it just says something like no display found
or something.  It's like two lines, maybe one. 

Had several interruptions so managed to try Kubuntu "Try" option.  It
comes up just fine, correct resolution, plasma is working and all.  I'm
attaching the Xorg log from Kubuntu. 

Maybe the Kubuntu log will shed some light. 

Dale

:-)  :-) 
[27.870] (--) Log file renamed from "/var/log/Xorg.pid-2309.log" to "/var/log/Xorg.0.log"
[27.874] 
X.Org X Server 1.21.1.11
X Protocol Version 11, Revision 0
[27.874] Current Operating System: Linux kubuntu 6.8.0-31-generic #31-Ubuntu SMP PREEMPT_DYNAMIC Sat Apr 20 00:40:06 UTC 2024 x86_64
[27.874] Kernel command line: BOOT_IMAGE=/casper/vmlinuz rdinit=/vtoy/vtoy --- quiet splash
[27.874] xorg-server 2:21.1.12-1ubuntu1 (For technical support please see http://www.ubuntu.com/support) 
[27.874] Current version of pixman: 0.42.2
[27.874] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[27.874] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[27.874] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Jun 27 15:42:53 2024
[27.875] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[27.875] (==) No Layout section.  Using the first Screen section.
[27.875] (==) No screen section available. Using defaults.
[27.875] (**) |-->Screen "Default Screen Section" (0)
[27.875] (**) |  

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 12:03 AM Dale  wrote:
>
> Update.  I played around a bit.  I figured I didn't have a lot to lose
> here.  It either works, or it doesn't.  After playing around a bit, I
> got it to work.  I have not restarted it to see if it will work again,
> yet.  I wanted to grab some log info first, while it is working.  So,
> this part is about when KDE comes up completely but could include some
> attempts that failed.  Comes up completely means, in the correct
> resolution, background image and the panel thing on the bottom, which
> means plasma is running as it should.  I'm doing these inside the email
> instead of as attachments.  Sorry for the length.  I just want to share
> this while I have it available.
>
> This first one, I had a few failures before it succeeded.  I couldn't
> figure out when the working bit started so it is the complete log.
>
>

Hi Dale,
   I have returned home and can once again bottom post.

   There's no way I'm going to read and understand this
whole thread but I did have one question and one comment:

1) Did you ever actually try the Kubunu option that didn't
require an install? I saw you mentions Knoppix and maybe
one other option. Just curious as to what the results were.

2) I see you discussing xorg.conf file which I don't use
here but did you generate this file - if you are really using
it - using the nvidia-settings app, or by hand?

   If your system will stay up I believe nvidia-settings is
recommended by NVidia, or was anyway. It does a good
job of showing the layout and handling options that NVidia
says make their cards work better.

Good luck,
Mark

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 07:54:43 BST Dale wrote:
> Update.  I played around a bit.  I figured I didn't have a lot to lose
> here.  It either works, or it doesn't.  After playing around a bit, I
> got it to work.  I have not restarted it to see if it will work again,
> yet.  I wanted to grab some log info first, while it is working.  So,
> this part is about when KDE comes up completely but could include some
> attempts that failed.  Comes up completely means, in the correct
> resolution, background image and the panel thing on the bottom, which
> means plasma is running as it should.  I'm doing these inside the email
> instead of as attachments.  Sorry for the length.  I just want to share
> this while I have it available.

Your Display Manager (SDDM) works fine.  There is no problem with the the DM.

Your system log does not reveal anything untoward.  The driver components are 
loading fine.  No problem with this either.

Your Xorg.0.log now shows a different port (DP-5) and the monitor bobs up & 
down.  My money is on a buggy EDID.


> [  1236.810] (--) NVIDIA(GPU-0):
> [  1237.031] (--) NVIDIA(GPU-0): LG Electronics W2253 (DFP-5): connected
> [  1237.031] (--) NVIDIA(GPU-0): LG Electronics W2253 (DFP-5): Internal TMDS
> [  1237.031] (--) NVIDIA(GPU-0): LG Electronics W2253 (DFP-5): 300.0 MHz
> maximum pixel clock
[Snip ...]

Are you still plugged into the same physical port on the video card?

If yes, then its designation DFP-? is allocated dynamically.

The monitor is shown to be disconnected a couple of times and eventually 
reconnected.  Again on port DP-5.  Normally this should be on port DP-0 if you 
have plugged it into the first port.


> This is xorg.conf. 

At which point did you originally generate this file?  While the monitor was 
on and running, or after it went sideways?


> Gentoo-1 ~ # cat /etc/X11/xorg.conf
> # nvidia-xconfig: X configuration file generated by nvidia-xconfig
> # nvidia-xconfig:  version 550.90.07
[Snip ...]

> Section "Monitor"
> Identifier "Monitor0"
> VendorName "Unknown"
> ModelName  "Unknown"
> Option "DPMS"
> EndSection

Regenerate the file while the monitor is working and check what/if its details 
come up in the above section.

> #Section "Device"
> #Identifier "Device0"
> #Driver "nvidia"
> #VendorName "NVIDIA Corporation"
> #EndSection
> 
> Section "Device"
> 
>Identifier  "Device0"
> #   Identifier  "nvidia"
>Driver  "nvidia"
>BusID   "PCI:9:0:0"
>Option "UseEDID" "false" ## Comment out this entry for now <==
> 
> EndSection
> 
> Section "Screen"
> Identifier "Screen0"
> Device "Device0"
> Monitor"Monitor0"
> DefaultDepth24
> SubSection "Display"
> Depth   24
> EndSubSection
> EndSection
> 
> Gentoo-1 ~ #
> 
> 
> I took the info you sent and sort of combined it with what
> nvidia-xconfig created.  This is when it worked, this time anyway. 
> Other things I tried did nothing.  Now that I have documented all this,
> I'm going to reboot the rig and see if it works again.  I think we
> already have failed logs but will share what happens. 

Comment out the line: Option "UseEDID" "false"

Let's see if the Monitor shows up in the recreated config file, otherwise 
you'll need to fill in its Model name and sync frequencies to take probing and 
guessing out of the equation.

If this still doesn't work, then you should try to feed its EDID file to the 
card.


> Given I get different results even with the same settings, I'm wondering
> about that monitor.  I've changed video cards so that should eliminate
> that.  The only common thing is the monitor.  Thing is, that monitor
> worked for a long time on my main rig, it also has worked fine on the
> NAS box and the old Dell system as well.  That was very recent I might
> add.  This new system is the only one that has issues with that monitor. 

Were the other PCs using the same DP cable, or HDMI/DVI?  What xorg.conf files 
did they have generated?


> The new monitor should give us clues.  If it just works when it gets
> here, then it is the monitor acting weird.  If it does the same thing,
> there is a config error somewhere.  I can't think of anything else. 

I can think of a buggy monitor EDID.  There are a lot of cheap monitors being 
churned out with average display panels, but bottom dollar chip, bezel and 
stand.  Power saving features introduce their own bugs.  You could check the 
monitor's own menu to disable eco modes and what not, if you keep your monitor 
running 24-7.


> Open to ideas still.  I'd like to get this working.  If for no other
> reason, the new monitor could have the same issue and require some
> special settings somewhere.
> 
> Thanks for all the help.  Sorry to have so much info in one email.  :/  
> At least we have details of when it is working now tho.  :-D

The email line wrap makes things difficult to read.  You can redirect the 
Xorg.0.

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

[Dale]

Update.  I played around a bit.  I figured I didn't have a lot to lose
here.  It either works, or it doesn't.  After playing around a bit, I
got it to work.  I have not restarted it to see if it will work again,
yet.  I wanted to grab some log info first, while it is working.  So,
this part is about when KDE comes up completely but could include some
attempts that failed.  Comes up completely means, in the correct
resolution, background image and the panel thing on the bottom, which
means plasma is running as it should.  I'm doing these inside the email
instead of as attachments.  Sorry for the length.  I just want to share
this while I have it available.

This first one, I had a few failures before it succeeded.  I couldn't
figure out when the working bit started so it is the complete log.



Gentoo-1 ~ # cat /var/log/Xorg.0.log
[  1236.678] (--) Log file renamed from "/var/log/Xorg.pid-3720.log" to
"/var/log/Xorg.0.log"
[  1236.678]
X.Org X Server 1.21.1.13
X Protocol Version 11, Revision 0
[  1236.678] Current Operating System: Linux Gentoo-1 6.9.4-gentoo #11
SMP PREEMPT_DYNAMIC Sat Jun 22 18:45:21 CDT 2024 x86_64
[  1236.678] Kernel command line: BOOT_IMAGE=/kernel-6.9.4-6
root=UUID=26e58ee4-9c8f-4efd-bbb3-215df71cf85e ro
[  1236.678] 
[  1236.678] Current version of pixman: 0.43.4
[  1236.678]    Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.
[  1236.678] Markers: (--) probed, (**) from config file, (==) default
setting,
    (++) from command line, (!!) notice, (II) informational,
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  1236.678] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Jun 27
00:50:03 2024
[  1236.678] (==) Using config file: "/etc/X11/xorg.conf"
[  1236.678] (==) Using config directory: "/etc/X11/xorg.conf.d"
[  1236.678] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[  1236.678] (==) ServerLayout "Layout0"
[  1236.678] (**) |-->Screen "Screen0" (0)
[  1236.678] (**) |   |-->Monitor "Monitor0"
[  1236.678] (**) |   |-->Device "Device0"
[  1236.678] (**) |   |-->GPUDevice "nvidia"
[  1236.678] (**) |   |-->GPUDevice "Device0"
[  1236.678] (**) |-->Input Device "Keyboard0"
[  1236.678] (**) |-->Input Device "Mouse0"
[  1236.678] (**) Allowing byte-swapped clients
[  1236.678] (==) Automatically adding devices
[  1236.678] (==) Automatically enabling devices
[  1236.678] (==) Automatically adding GPU devices
[  1236.678] (==) Automatically binding GPU devices
[  1236.678] (==) Max clients allowed: 256, resource mask: 0x1f
[  1236.678] (WW) The directory "/usr/share/fonts/OTF" does not exist.
[  1236.678]    Entry deleted from font path.
[  1236.678] (WW) `fonts.dir' not found (or not valid) in
"/usr/share/fonts/75dpi".
[  1236.678]    Entry deleted from font path.
[  1236.678]    (Run 'mkfontdir' on "/usr/share/fonts/75dpi").
[  1236.678] (==) FontPath set to:
    /usr/share/fonts/misc,
    /usr/share/fonts/TTF,
    /usr/share/fonts/Type1,
    /usr/share/fonts/100dpi
[  1236.678] (==) ModulePath set to "/usr/lib64/xorg/modules"
[  1236.678] (WW) Hotplugging is on, devices using drivers 'kbd',
'mouse' or 'vmmouse' will be disabled.
[  1236.678] (WW) Disabling Keyboard0
[  1236.678] (WW) Disabling Mouse0
[  1236.678] (II) Module ABI versions:
[  1236.678]    X.Org ANSI C Emulation: 0.4
[  1236.678]    X.Org Video Driver: 25.2
[  1236.678]    X.Org XInput driver : 24.4
[  1236.678]    X.Org Server Extension : 10.0
[  1236.678] (++) using VT number 8

[  1236.678] (II) systemd-logind: logind integration requires -keeptty
and -keeptty was not provided, disabling logind integration
[  1236.679] (II) xfree86: Adding drm device (/dev/dri/card0)
[  1236.679] (II) Platform probe for
/sys/devices/pci:00/:00:03.1/:09:00.0/drm/card0
[  1236.799] (--) PCI:*(9@0:0:0) 10de:1cb1:10de:11bc rev 161, Mem @
0xfb00/16777216, 0xd000/268435456, 0xe000/33554432, I/O @
0xe000/128, BIOS @ 0x/524288
[  1236.799] (II) LoadModule: "glx"
[  1236.799] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so
[  1236.800] (II) Module glx: vendor="X.Org Foundation"
[  1236.800]    compiled for 1.21.1.13, module version = 1.0.0
[  1236.800]    ABI class: X.Org Server Extension, version 10.0
[  1236.800] (II) LoadModule: "nvidia"
[  1236.800] (II) Loading /usr/lib64/xorg/modules/drivers/nvidia_drv.so
[  1236.800] (II) Module nvidia: vendor="NVIDIA Corporation"
[  1236.800]    compiled for 1.6.99.901, module version = 1.0.0
[  1236.800]    Module class: X.Org Video Driver
[  1236.800] (II) NVIDIA dlloader X Driver  550.90.07  Fri May 31
09:34:34 UTC 2024
[  1236.800] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
[  1236.803] (II) Loading sub module "fb"
[  1236.803] (II) LoadModule: "fb"
[  1236.803] (II) Module "fb" already built-in
[  1236.803] (II) Loading sub module "wfb"
[  1236.803] (II) LoadModule: "wfb"
[  1236.803] (II) Loading /usr/lib64/xorg/m

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

[Dale]

Update.  I ordered a monitor.  It's bigger than the one I have now.  I'd
still like to get this one working if you have ideas.  May help someone
else, we may learn something, you most likely will remember it.  LOL  My
plan, get new monitor working with new rig.  When I switch current rig
to new rig, monitor moves over with it too.  This way, the working
monitors stay with the rig they work with.  I need a larger monitor and
a extra monitor anyway.  May give me that second monitor I mentioned
earlier too.  Monitor is a Samsung LS32B304NWN.  I'm pretty sure it is
better than my current monitor in most respects.  I don't game or
anything anyway.  On other reply, if you have ideas, I'll try them. 

Oh, sorry for late reply.  My sis-n-law was supposed to have surgery. 
She's been sick a while and was to dehydrated to have it since they been
dragging their feet.  Spent over half the day to accomplish nothing. 
Wore me out. 

Ebay claims it should be here by next Tuesday.  Could be earlier but it
does have a ways to go. 

Dale

:-)  :-) 

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

[Dale]

Well, I spoke to soon.  I shutdown for a while.  When I rebooted, to get
the logs you wanted, it started cutting off again like it did before. 
It seems it worked that one time but it just wanted to tease me.  :/


Michael wrote:
> On Wednesday, 26 June 2024 01:28:47 BST Dale wrote:
>> Michael wrote:
>>> The above message indicates the same problem you had experienced before
>>> you
>>> reinstalled.  The monitor is not sending its EDID table, or the card can't
>>> read it.
>>>
>>> Your Xorg sets a default dummy resolution of 640 x 480, because it can't
>>> find anything connected to the card.
>>>
>>> Things I would try, until someone who can grok nvidia contributes better
>>> ideas:
>>>
>>> Eliminate the hardware being the cause of the problem, e.g.: try a
>>> different cable, different monitor, then try the same card (with same
>>> drivers and same kernel settings) on your other PC.  If this proves
>>> there's nothing wrong with the cable, card, or kernel settings:
>>>
>>> 1. Try different ports and restart display-manager each time.
>>>
>>> 2. Add these two lines at the bottom of /usr/share/sddm/scripts/Xsetup:
>>>
>>> xrandr --setprovideroutputsource modesetting NVIDIA-0
>>> xrandr --auto
>>>
>>> Again restart display-manager.
>>>
>>> 3. Add a file /etc/X11/xorg.conf.d/20nvidia.conf
>>>
>>> Section "Device"
>>>
>>>Identifier  "nvidia"
>>>Driver  "nvidia"
>>>BusID   "PCI:9:0:0"
>>>Option "UseEDID" "false" ## Try this too ##
>>>
>>> EndSection
>>>
>>> Again restart display-manager.
>>>
>>> Every time you try a setting and it doesn't produce the goods, revert it
>>> before you try the next thing.  Make notes and keep an eye on your logs in
>>> case you spot a difference.
>>>
>>> If none of these tweaks work, then you can try capturing the EDID table
>>> and creating a file for the card to load.
> [snip ...]

I tried all those in different ways.  Basically, same thing.  The last
one did flash me just long enough to see the sddm login screen was low
resolution. 


>
>> I was
>> even thinking of moving my main rig monitor to the new rig and see what
>> it did.  I'd already tried a different card so didn't see any need in
>> repeating that.  Then I had a thought.  Why is it saying port DP-3?  Why
>> is it not port DP-0?
> Your PC indicated DFP-3 was what it had booted at - from your Xorg.0.log:
>
> [44.311] (--) NVIDIA(0): Valid display device(s) on GPU-0 at PCI:9:0:0
> [44.311] (--) NVIDIA(0): DFP-0
> [44.311] (--) NVIDIA(0): DFP-1
> [44.311] (--) NVIDIA(0): DFP-2
> [44.311] (--) NVIDIA(0): DFP-3 (boot)
> [44.311] (--) NVIDIA(0): DFP-4
> [44.311] (--) NVIDIA(0): DFP-5
> [44.311] (--) NVIDIA(0): DFP-6
> [44.311] (--) NVIDIA(0): DFP-7
>
> which is the display device connector type nvidia identifies the monitor 
> being 
> connected to.  However, then it prints this discouraging message:
>
> [44.312] (--) NVIDIA(GPU-0): 
> [44.332] (--) NVIDIA(GPU-0): DFP-3: disconnected  <== This ===
> [44.332] (--) NVIDIA(GPU-0): DFP-3: Internal TMDS
> [44.332] (--) NVIDIA(GPU-0): DFP-3: 165.0 MHz maximum pixel clock
> [44.332] (--) NVIDIA(GPU-0): 
>

I noticed that too.  I was curious why it was saying disconnected when I
didn't. 


>> I thought the first port was the one on the
>> bottom.  Turns out, the top port is the first one.  So, I moved the
>> cable to the first port, DP-0.
> I thought you had already tried this prior to reinstalling, when I had 
> suggested to try different ports.
>

I did try another port, just not all of them.  I figured one port may be
bad.  Surely not more than one tho.  Plus, another card did the same thing.

>> I booted the rig up, started DM, got the
>> login screen as usual and guess what was next, a complete desktop.  I
>> changed it to not power off or switch to a screensaver so that it would
>> stay on and I could keep a eye on it. I heated up supper, ate, typing
>> this reply and it is still running, in 1080P no less. 
> YES!  :-D
>

NO!!   O_O

>> Now tell me this, why would it not work on DP-3 or DP-2 when I tried
>> those earlier on?  Does one always have to have a monitor connected to
>> DP-0 first then others as monitors are added? 
> It may have something to do with auto-detecting PNP display devices, like 
> DisplayPort monitor devices.  There is a HPD pin (Hot Plug Detect) on the DP, 
> which lets the card know if a monitor turns off.  This seems to cause the 
> card's driver to detect the display as "disconnected", which then disables 
> the 
> port.
>
> The question is why would the monitor turn off.  Well, it might be taking too 
> long for the card to walk from DP-1 to DP-3, by which time the monitor has 
> gone to sleep to save energy.  If the monitor is on DP-1, then it doesn't get 
> a chance to do this.
>
> Alternatively, the Quadro P1000 video card being a 'pro' graphics card may 
> have been designed with the assumption a monitor (the primary monitor) is 
> *al

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

[Michael]

On Tuesday, 25 June 2024 19:54:33 BST Dale wrote:
> Michael wrote:

> > You need to have USE="elogind -systemd" in your make.conf, then add the
> > elogind service to the *boot* runlevel as shown here:
> > 
> > https://wiki.gentoo.org/wiki/Elogind
> 
> I read down through that.  I did find that acl had made it into the USE
> flag line.  I removed it.

You shouldn't have.


> It's not on my main rig so no idea where that
> came from.

It is enabled by the profile defaults:

~ $ euse -I acl
global use flags (searching: acl)

[+ CD   ] /var/db/repos/gentoo/profiles/use.desc:acl - Add support for Access 
Control Lists
[snip ...]


> > Can you please save and attach as plain text files your:
> > 
> > 1. dmesg
> > 2. Xorg.0.log
> > 3. ~/.local/share/sddm/xorg-session.log
> > 4. /var/log/sddm.log
> > 
> > after you end up in a black screen, in case they reveal something.
> 
> Should be attached.  I blanked the files and then rebooted and started
> display-manager, (DM).  You should have only the most recent info.  I'm
> also putting a chunk of messages below.  It might help.  It isn't much. 
> Same as before it seems.  I still say this is something simple but hard
> to find.  :/ 
> 
> Dale
> 
> :-)  :-) 
> 
> Messages:
[snip ...] 

> Jun 25 13:31:18 Gentoo-1 kernel: nvidia-modeset: WARNING: GPU:0: Unable
> to read EDID for display device DP-3

The above message indicates the same problem you had experienced before you 
reinstalled.  The monitor is not sending its EDID table, or the card can't 
read it.

Your Xorg sets a default dummy resolution of 640 x 480, because it can't find 
anything connected to the card.

Things I would try, until someone who can grok nvidia contributes better 
ideas:

Eliminate the hardware being the cause of the problem, e.g.: try a different 
cable, different monitor, then try the same card (with same drivers and same 
kernel settings) on your other PC.  If this proves there's nothing wrong with 
the cable, card, or kernel settings:

1. Try different ports and restart display-manager each time.

2. Add these two lines at the bottom of /usr/share/sddm/scripts/Xsetup:

xrandr --setprovideroutputsource modesetting NVIDIA-0
xrandr --auto

Again restart display-manager.

3. Add a file /etc/X11/xorg.conf.d/20nvidia.conf

Section "Device"
   Identifier  "nvidia"
   Driver  "nvidia"
   BusID   "PCI:9:0:0"
   Option "UseEDID" "false" ## Try this too ##
EndSection

Again restart display-manager.

Every time you try a setting and it doesn't produce the goods, revert it 
before you try the next thing.  Make notes and keep an eye on your logs in 
case you spot a difference.

If none of these tweaks work, then you can try capturing the EDID table and 
creating a file for the card to load.

HTH.

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

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

[Dale]

Michael wrote:
> On Tuesday, 25 June 2024 15:27:00 BST Dale wrote:
>> Picking here to get a fresh sub thread going.  Attempt two. 
>>
>> I got all the packages installed.  Made sure the Nvidia video drivers
>> were loaded.  I remembered to make sure elogind was running.  It wasn't,
>> so I started it.  Why doesn't display-manager pull that in???
> You need to have USE="elogind -systemd" in your make.conf, then add the 
> elogind service to the *boot* runlevel as shown here:
>
> https://wiki.gentoo.org/wiki/Elogind
>

I read down through that.  I did find that acl had made it into the USE
flag line.  I removed it.  It's not on my main rig so no idea where that
came from.  I added -systemd but I think it was already set somewhere
else.  The elogind flag was already set.  I ran emerge -auDN world just
to be sure.  It did recompile packages for the acl change but not
anything else.  I also checked the drivers needed in the kernel.  Looks
like they all there. 


>> Does this yield any clues? 
> Not yet.
>
> Can you please save and attach as plain text files your:
>
> 1. dmesg
> 2. Xorg.0.log
> 3. ~/.local/share/sddm/xorg-session.log
> 4. /var/log/sddm.log
>
> after you end up in a black screen, in case they reveal something.


Should be attached.  I blanked the files and then rebooted and started
display-manager, (DM).  You should have only the most recent info.  I'm
also putting a chunk of messages below.  It might help.  It isn't much. 
Same as before it seems.  I still say this is something simple but hard
to find.  :/ 

Dale

:-)  :-) 


Messages:

Jun 25 13:31:08 Gentoo-1 login[2726]: pam_unix(login:session): session
opened for user root(uid=0) by root(uid=0)
Jun 25 13:31:08 Gentoo-1 kernel: elogind-daemon[1945]: New session 2 of
user root.
Jun 25 13:31:08 Gentoo-1 login[2759]: ROOT LOGIN  on '/dev/tty1'
Jun 25 13:31:18 Gentoo-1 kernel: nvidia-modeset: WARNING: GPU:0: Unable
to read EDID for display device DP-3
Jun 25 13:31:18 Gentoo-1 sddm-helper[2834]:
pam_unix(sddm-greeter:session): session opened for user sddm(uid=219) by
root(uid=0)
Jun 25 13:31:18 Gentoo-1 kernel: elogind-daemon[1945]: Existing logind
session ID 2 used by new audit session, ignoring.
Jun 25 13:31:18 Gentoo-1 kernel: elogind-daemon[1945]: New session c1 of
user sddm.

[0.00] Linux version 6.9.4-gentoo (root@Gentoo-1) (gcc (Gentoo 
13.2.1_p20240210 p14) 13.2.1 20240210, GNU ld (Gentoo 2.42 p3) 2.42.0) #11 SMP 
PREEMPT_DYNAMIC Sat Jun 22 18:45:21 CDT 2024
[0.00] Command line: BOOT_IMAGE=/kernel-6.9.4-6 
root=UUID=26e58ee4-9c8f-4efd-bbb3-215df71cf85e ro
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009] usable
[0.00] BIOS-e820: [mem 0x000a-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x09d1efff] usable
[0.00] BIOS-e820: [mem 0x09d1f000-0x09ff] reserved
[0.00] BIOS-e820: [mem 0x0a00-0x0a1f] usable
[0.00] BIOS-e820: [mem 0x0a20-0x0a20dfff] ACPI NVS
[0.00] BIOS-e820: [mem 0x0a20e000-0x0aff] usable
[0.00] BIOS-e820: [mem 0x0b00-0x0b01] reserved
[0.00] BIOS-e820: [mem 0x0b02-0xca603fff] usable
[0.00] BIOS-e820: [mem 0xca604000-0xca967fff] reserved
[0.00] BIOS-e820: [mem 0xca968000-0xcaac2fff] ACPI data
[0.00] BIOS-e820: [mem 0xcaac3000-0xcae97fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcae98000-0xcbbfefff] reserved
[0.00] BIOS-e820: [mem 0xcbbff000-0xccff] usable
[0.00] BIOS-e820: [mem 0xcd00-0xcfff] reserved
[0.00] BIOS-e820: [mem 0xf000-0xf7ff] reserved
[0.00] BIOS-e820: [mem 0xfd20-0xfd2f] reserved
[0.00] BIOS-e820: [mem 0xfd60-0xfd7f] reserved
[0.00] BIOS-e820: [mem 0xfea0-0xfea0] reserved
[0.00] BIOS-e820: [mem 0xfeb8-0xfec01fff] reserved
[0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
[0.00] BIOS-e820: [mem 0xfec3-0xfec30fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved
[0.00] BIOS-e820: [mem 0xfed4-0xfed44fff] reserved
[0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved
[0.00] BIOS-e820: [mem 0xfedc2000-0xfedc] reserved
[0.00] BIOS-e820: [mem 0xfedd4000-0xfedd5fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00102f37] usable
[0.00] BIOS-e820: [mem 0x00102f38-0x00102fff] reserved
[0.

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

[Michael]

On Tuesday, 25 June 2024 15:27:00 BST Dale wrote:
> Picking here to get a fresh sub thread going.  Attempt two. 
> 
> I got all the packages installed.  Made sure the Nvidia video drivers
> were loaded.  I remembered to make sure elogind was running.  It wasn't,
> so I started it.  Why doesn't display-manager pull that in???

You need to have USE="elogind -systemd" in your make.conf, then add the 
elogind service to the *boot* runlevel as shown here:

https://wiki.gentoo.org/wiki/Elogind


> Anyway, I
> started display-manager and got the sddm screen.  I selected Plasma x11
> instead of Plasma wayland.  I then logged in.  It took a little bit but
> finally the screen came up.  All I get is the 'Welcome to KDE plasma"
> window.  Everything else is black.  I like the screen that says "simple
> by default".  It's simple alright.  A black screen is pretty simple. 

LOL!


> The mouse pointer moves so it sees the mouse.  Right click should bring
> up a menu.  Nothing.  The little panel thing that is usually at the
> bottom, nothing.  Once I close the welcome window, it's black. 
> 
> This is the messages file from the point of me starting display-manager. 
[snip ..]

> Does this yield any clues? 

Not yet.

Can you please save and attach as plain text files your:

1. dmesg
2. Xorg.0.log
3. ~/.local/share/sddm/xorg-session.log
4. /var/log/sddm.log

after you end up in a black screen, in case they reveal something.


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

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

[Dale]

Picking here to get a fresh sub thread going.  Attempt two. 

I got all the packages installed.  Made sure the Nvidia video drivers
were loaded.  I remembered to make sure elogind was running.  It wasn't,
so I started it.  Why doesn't display-manager pull that in???  Anyway, I
started display-manager and got the sddm screen.  I selected Plasma x11
instead of Plasma wayland.  I then logged in.  It took a little bit but
finally the screen came up.  All I get is the 'Welcome to KDE plasma"
window.  Everything else is black.  I like the screen that says "simple
by default".  It's simple alright.  A black screen is pretty simple. 

The mouse pointer moves so it sees the mouse.  Right click should bring
up a menu.  Nothing.  The little panel thing that is usually at the
bottom, nothing.  Once I close the welcome window, it's black. 

This is the messages file from the point of me starting display-manager. 



Jun 25 09:08:32 Gentoo-1 elogind-daemon[3079]: New session 5 of user root.
Jun 25 09:08:32 Gentoo-1 login[3115]: ROOT LOGIN  on '/dev/tty1'
Jun 25 09:09:03 Gentoo-1 sddm-helper[3204]:
pam_unix(sddm-greeter:session): session opened for user sddm(uid=219) by
root(uid=0)
Jun 25 09:09:03 Gentoo-1 elogind-daemon[3079]: Existing logind session
ID 5 used by new audit session, ignoring.
Jun 25 09:09:03 Gentoo-1 elogind-daemon[3079]: New session c1 of user sddm.
Jun 25 09:09:40 Gentoo-1 sddm-helper[3223]: gkr-pam: unable to locate
daemon control file
Jun 25 09:09:40 Gentoo-1 sddm-helper[3223]: gkr-pam: stashed password to
try later in open session
Jun 25 09:09:40 Gentoo-1 sddm-helper[3223]: pam_kwallet5(sddm:auth):
pam_kwallet5: pam_sm_authenticate
Jun 25 09:09:40 Gentoo-1 sddm-helper[3223]: pam_kwallet5(sddm:setcred):
pam_kwallet5: pam_sm_setcred
Jun 25 09:09:40 Gentoo-1 sddm-helper[3223]: pam_unix(sddm:session):
session opened for user dale(uid=1000) by dale(uid=0)
Jun 25 09:09:40 Gentoo-1 elogind-daemon[3079]: New session 6 of user dale.
Jun 25 09:09:40 Gentoo-1 sddm-helper[3223]: gkr-pam:
gnome-keyring-daemon started properly and unlocked keyring
Jun 25 09:09:40 Gentoo-1 sddm-helper[3223]: pam_kwallet5(sddm:session):
pam_kwallet5: pam_sm_open_session
Jun 25 09:09:40 Gentoo-1 sddm-helper[3204]:
pam_unix(sddm-greeter:session): session closed for user sddm
Jun 25 09:09:40 Gentoo-1 elogind-daemon[3079]: Removed session c1.
Jun 25 09:09:40 Gentoo-1 sddm-helper[3235]: pam_kwallet5: final socket
path: /run/user/1000/kwallet5.socket
Jun 25 09:09:40 Gentoo-1 dbus-daemon[3249]: [session uid=1000 pid=3247
pidfd=4] Activating service name='org.a11y.Bus' requested by ':1.1'
(uid=1000 pid=3241 comm="/usr/bin/nvidia-settings --load-config-only"
label="kernel")
Jun 25 09:09:40 Gentoo-1 dbus-daemon[3249]: [session uid=1000 pid=3247
pidfd=4] Successfully activated service 'org.a11y.Bus'
Jun 25 09:09:40 Gentoo-1 kernel: nvidia_uvm: module uses symbols
nvUvmInterfaceDisableAccessCntr from proprietary module nvidia,
inheriting taint.
Jun 25 09:09:40 Gentoo-1 kernel: nvidia-uvm: Loaded the UVM driver,
major device number 240.
Jun 25 09:09:41 Gentoo-1 dbus-daemon[3273]: [session uid=1000 pid=3271
pidfd=4] Activating service name='org.freedesktop.portal.Desktop'
requested by ':1.3' (uid=1000 pid=3297
comm="/usr/lib64/libexec/kf5/klauncher --fd=9" label="kernel")
Jun 25 09:09:41 Gentoo-1 dbus-daemon[3273]: [session uid=1000 pid=3271
pidfd=4] Activating service name='org.freedesktop.portal.Documents'
requested by ':1.4' (uid=1000 pid=3300
comm="/usr/libexec/xdg-desktop-portal" label="kernel")
Jun 25 09:09:41 Gentoo-1 dbus-daemon[3273]: [session uid=1000 pid=3271
pidfd=4] Activating service
name='org.freedesktop.impl.portal.PermissionStore' requested by ':1.5'
(uid=1000 pid=3307 comm="/usr/libexec/xdg-document-portal" label="kernel")
Jun 25 09:09:41 Gentoo-1 dbus-daemon[3273]: [session uid=1000 pid=3271
pidfd=4] Successfully activated service
'org.freedesktop.impl.portal.PermissionStore'
Jun 25 09:09:41 Gentoo-1 dbus-daemon[3273]: [session uid=1000 pid=3271
pidfd=4] Successfully activated service 'org.freedesktop.portal.Documents'
Jun 25 09:09:41 Gentoo-1 dbus-daemon[3273]: [session uid=1000 pid=3271
pidfd=4] Activating service
name='org.freedesktop.impl.portal.desktop.kde' requested by ':1.4'
(uid=1000 pid=3300 comm="/usr/libexec/xdg-desktop-portal" label="kernel")
Jun 25 09:09:41 Gentoo-1 dbus-daemon[3273]: [session uid=1000 pid=3271
pidfd=4] Successfully activated service
'org.freedesktop.impl.portal.desktop.kde'
Jun 25 09:09:41 Gentoo-1 dbus-daemon[3273]: [session uid=1000 pid=3271
pidfd=4] Successfully activated service 'org.freedesktop.portal.Desktop'
Jun 25 09:09:41 Gentoo-1 dbus-daemon[3051]: [system] Activating service
name='net.hadess.PowerProfiles' requested by ':1.11' (uid=1000 pid=3300
comm="/usr/libexec/xdg-desktop-portal" label="kernel") (using servicehelper)
Jun 25 09:09:41 Gentoo-1 dbus-daemon[3051]: [system] Activated service
'net.hadess.PowerProfiles' failed: Launch helper exited with unknown
return code 1
Jun 25 09:09:

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

[Dale]

Michael wrote:
> On Tuesday, 25 June 2024 00:47:07 BST Dale wrote:
>> Michael wrote:
>>> The first option in the man page explains what you did:
>>>
>>> https://linux.die.net/man/8/dracut
>>>
>>> -f, --force
>>> overwrite existing initramfs file.
>>>
>>> Did you have an initramfs already in there?
>> I had the kernel and the config file on /boot.
> Did these files arrived in /boot/ by installing them yourself manually, or by 
> having them installed automatically by calling 'make install', which utilised 
> 'sys-kernel/installkernel' to do it with?
>
> If the latter, did 'sys-kernel/installkernel' have the right USE flags set 
> for 
> your system?
>

I always do my kernel install manually.  While dracut puts the image in
/boot, I have to rename it so grub will match the names up correctly. 
Way back tho, I had one init image for each kernel version.  Grub would
match ever how many kernels I had of that version to the same init image
and boot.  Then either I did something different or it stopped working. 
Now each kernel has to have its own init image.  Could be me. 

>> I did not have anything
>> else there except grub and the CPU microcode file.  I didn't save the
>> init thingy when I was copying files over from previous install.  I just
>> saved the config and kernel.
> I suspect you may have overlaid manual and automated kernel installation 
> procedures, resulting in one trying to over-write the other.  Then you run 
> dracut and it complained, until you used --force to overwrite whatever files 
> had already been installed in /boot.
>

I manually config and build the kernel and then manually copy the kernel
to /boot. 


>>> No don't start over!  Have you read through this:
>>>
>>> https://wiki.gentoo.org/wiki/Dracut
> [snip ...]
>
>> Yep.  I saw that too.  Thing is, it confuses me.  On the main install
>> page, it shows /efi mounted on the / partition.  In other words, the
>> same place /boot, /usr and /var are mounted too.  In the page you link
>> to it seems to show the efi partition mounted inside /boot.  Like this: 
>> /boot/efi.  The main page I think says this is no longer recommended. 
>> Which am I to follow?  If it being inside /boot is discouraged, someone
>> needs to update the page. 
> Err ... you lost me there.  Where in the 
> 'https://wiki.gentoo.org/wiki/Dracut' 
> wiki page does it state what you mention above?!  o_O
>
> The ESP partition's mountpoint is /efi.  Some time ago the ESP mountpoint 
> used 
> to be /boot/efi, but this is no longer recommended.
>
> The boot partition's mountpoint for your installation is /boot.
>
> The directories for /usr, /var, et al. will be found in the / partition.  If 
> you have chosen for your /var directory to be stored on a different 
> partition, 
> then its mountpoint would be /var.
>

I may have confused the pages but in one place it showed it inside
/boot.  In another place it said /efi was on / itself.  I did it the
last way as I did the first time.  I think I read on this list somewhere
about the change.  Could have been on -dev mailing list too. 

>> I'm continuing on with the install but still puzzled about the dracut
>> error.  Is this what /efi should look like? 
>>
>>
>> (chroot) livecd / # tree /efi/
>> /efi/
>> └── EFI
>> └── gentoo
>> └── grubx64.efi
>>
>> 3 directories, 1 file
>> (chroot) livecd / #
> Yes, this looks good.  The MoBo's UEFI firmware will load grubx64.efi, which 
> in turn will fetch your kernel & initrd images from /boot.
>

It did.  I got to the point where I needed to boot and it worked.  Yay!!

>> I never looked in the directory on the last install.  Nothing reported a
>> error so I just went with it.  ;-)
> I'm guessing, in your last install you had not mixed up manual and automated 
> kernel installation steps, but in this one you did.  ;-)
>
> You probably want to spend some quality time reading this at your leisure:
>
> https://wiki.gentoo.org/wiki/Installkernel

I've read up a little on that but I've done it manually so long, I just
keep doing it that way.  Someone posted I can set it up to do just like
I'm doing it but still, I just stick with the old way. 


>
> Regarding the microcode file '/boot/amd-uc.img', this is created by the 'sys-
> kernel/linux-firmware' package if it has USE="initramfs" set.  GRUB will find 
> pick up this image file and include it along with any other initramfs images 
> when you run grub-mkconfig, or when grub-mkconfig is run by 'make install'.  
> Then GRUB will load it at boot time.  However, you can built both the AMD CPU 
> microcode and any other firmware needed by your machine in the kernel.  Just 
> add them in your kernel:
>
> # Firmware loader
> CONFIG_EXTRA_FIRMWARE="."
>
> before you build it.
>
> Regarding Nvidia's module, I don't think you need an initramfs for this.  
> When 
> the kernel loads it will fetch the Nvidia module from /lib/modules/, provided 
> it can mount the root partition.


I did check, grub did include it when I ran the grub-mkc

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

[Michael]

On Tuesday, 25 June 2024 00:47:07 BST Dale wrote:
> Michael wrote:

> > The first option in the man page explains what you did:
> > 
> > https://linux.die.net/man/8/dracut
> > 
> > -f, --force
> > overwrite existing initramfs file.
> > 
> > Did you have an initramfs already in there?
> 
> I had the kernel and the config file on /boot.

Did these files arrived in /boot/ by installing them yourself manually, or by 
having them installed automatically by calling 'make install', which utilised 
'sys-kernel/installkernel' to do it with?

If the latter, did 'sys-kernel/installkernel' have the right USE flags set for 
your system?


> I did not have anything
> else there except grub and the CPU microcode file.  I didn't save the
> init thingy when I was copying files over from previous install.  I just
> saved the config and kernel.

I suspect you may have overlaid manual and automated kernel installation 
procedures, resulting in one trying to over-write the other.  Then you run 
dracut and it complained, until you used --force to overwrite whatever files 
had already been installed in /boot.


> > No don't start over!  Have you read through this:
> > 
> > https://wiki.gentoo.org/wiki/Dracut
[snip ...]

> Yep.  I saw that too.  Thing is, it confuses me.  On the main install
> page, it shows /efi mounted on the / partition.  In other words, the
> same place /boot, /usr and /var are mounted too.  In the page you link
> to it seems to show the efi partition mounted inside /boot.  Like this: 
> /boot/efi.  The main page I think says this is no longer recommended. 
> Which am I to follow?  If it being inside /boot is discouraged, someone
> needs to update the page. 

Err ... you lost me there.  Where in the 'https://wiki.gentoo.org/wiki/Dracut' 
wiki page does it state what you mention above?!  o_O

The ESP partition's mountpoint is /efi.  Some time ago the ESP mountpoint used 
to be /boot/efi, but this is no longer recommended.

The boot partition's mountpoint for your installation is /boot.

The directories for /usr, /var, et al. will be found in the / partition.  If 
you have chosen for your /var directory to be stored on a different partition, 
then its mountpoint would be /var.


> I'm continuing on with the install but still puzzled about the dracut
> error.  Is this what /efi should look like? 
> 
> 
> (chroot) livecd / # tree /efi/
> /efi/
> └── EFI
> └── gentoo
> └── grubx64.efi
> 
> 3 directories, 1 file
> (chroot) livecd / #

Yes, this looks good.  The MoBo's UEFI firmware will load grubx64.efi, which 
in turn will fetch your kernel & initrd images from /boot.


> I never looked in the directory on the last install.  Nothing reported a
> error so I just went with it.  ;-)

I'm guessing, in your last install you had not mixed up manual and automated 
kernel installation steps, but in this one you did.  ;-)

You probably want to spend some quality time reading this at your leisure:

https://wiki.gentoo.org/wiki/Installkernel

Regarding the microcode file '/boot/amd-uc.img', this is created by the 'sys-
kernel/linux-firmware' package if it has USE="initramfs" set.  GRUB will find 
pick up this image file and include it along with any other initramfs images 
when you run grub-mkconfig, or when grub-mkconfig is run by 'make install'.  
Then GRUB will load it at boot time.  However, you can built both the AMD CPU 
microcode and any other firmware needed by your machine in the kernel.  Just 
add them in your kernel:

# Firmware loader
CONFIG_EXTRA_FIRMWARE="."

before you build it.

Regarding Nvidia's module, I don't think you need an initramfs for this.  When 
the kernel loads it will fetch the Nvidia module from /lib/modules/, provided 
it can mount the root partition.

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

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

[Dale]

Michael wrote:
> On Monday, 24 June 2024 22:03:14 BST Dale wrote:
>> Michael wrote:
>>> On Monday, 24 June 2024 20:47:15 BST Dale wrote:
 Have you seen this before?
>>> No, because I've never used dracut.
>> I just had a thought.  I have /usr on the root partition now.  Do I even
>> need a init thingy? 
> Only you can answer this.
>
> You don't need it if your kernel image has all the drivers it requires built-
> in to mount / and start initializing your hardware.
>
> Binary distros tend to built a lot of kernel drivers as modules and these 
> will 
> not be accessible until / has been mounted.  Therefore initrd/initramfs will 
> include necessary modules, as well as firmware, CPU microcode, etc. to be 
> able 
> to run in memory enough of a temporary initial / fs, until the real / becomes 
> accessible.
>
> This is explained briefly here:
>
> https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/
> Kernel#Building_an_initramfs
>

I build all drivers in the kernel except the nvidia drivers.  I do have
a CPU micrcode thing for this CPU tho in /boot.  It's in the list of
things grub picks up.  I assume since Grub finds it, it is part of the
boot process. 


 (chroot) livecd /usr/src/linux # dracut --kver=$(cat
 include/config/kernel.release)
 dracut[I]: Executing: /usr/bin/dracut --kver=6.9.4-gentoo
 dracut[F]: Can't write to
 /efi/dba652170b7a716f303c3c5966799436/6.9.4-gentoo: Directory
 /efi/dba652170b7a716f303c3c5966799436/6.9.4-gentoo does not exist or is
 not accessible.
 (chroot) livecd /usr/src/linux #


 The directory inside /efi does not exist.
>>> The long string is either a PARTUUID, or a fs UUID.
>>>
>>> Run blikid to find out what it is.
>> /dev/nvme0n1p1: UUID="6488-1019" BLOCK_SIZE="512" TYPE="vfat"
>> PARTLABEL="efi-part" PARTUUID="50add3c0-4ab3-4453-85e5-93af643a586e"
>>
>> I don't see anything, UUID or anything else that starts with dba6 for
>> any partition.  I don't know why dracut is looking for that. 
> Hmm ... I wonder if it is implementing a systemd-boot UUID for each OS 
> kernel.  
> :-/
>

I'm on openrc here.  I checked the stage tarball, it's openrc.  I used
grep on /etc and no systemd USE flags enabled there either.  Is confusing. 


>>> Do you have a directory called EFI in your /efi partition?
>>>
>>> Have you mounted your /mnt/gentoo/boot partition when you called dracut?
>> Yep.  There is.  Should that be there?  This is what is there. 
>>
>> (chroot) livecd / # ls -al /efi/
>> total 12
>> drwxr-xr-x  3 root root 4096 Dec 31  1969 .
>> drwxr-xr-x 17 root root 4096 Jun 23 12:06 ..
>> drwxr-xr-x  3 root root 4096 Jun 24 14:29 EFI
>> -rwxr-xr-x  1 root root0 Jun 24 14:01 test
>> (chroot) livecd / # ls -al /efi/EFI/gentoo/grubx64.efi
>> -rwxr-xr-x 1 root root 143360 Jun 24 14:33 /efi/EFI/gentoo/grubx64.efi
> That's all as it should be.
>
>
>> I mounted /boot when I mounted the others.  I already have a kernel and
>> such in /boot.  When I did a search, I found where someone posted they
>> used force with dracut to get it to install a init thingy.  I used it
>> and it did build and put one in /boot.  Thing is, I've never had to use
>> force before and figure something is wrong somewhere.
> The first option in the man page explains what you did:
>
> https://linux.die.net/man/8/dracut
>
> -f, --force
> overwrite existing initramfs file.
>
> Did you have an initramfs already in there?

I had the kernel and the config file on /boot.  I did not have anything
else there except grub and the CPU microcode file.  I didn't save the
init thingy when I was copying files over from previous install.  I just
saved the config and kernel.


>
>> This is /boot. 
>>
>>
>> (chroot) livecd / # ls -al /boot/
>> total 22512
>> drwxr-xr-x  4 root root 4096 Jun 24 14:29 .
>> drwxr-xr-x 17 root root 4096 Jun 23 12:06 ..
>> -rw-r--r--  1 root root77312 Jun 24 11:40 amd-uc.img
>> -rw-r--r--  1 root root   158391 Jun 24 12:02 config-6.9.4-6
>> drwxr-xr-x  6 root root 4096 Jun 24 14:29 grub
>> -rw---  1 root root  7740012 Jun 24 14:06 initramfs-6.9.4-6.img
>> -rw-r--r--  1 root root 15000576 Jun 24 12:02 kernel-6.9.4-6
>> drwx--  2 root root16384 Jun 24 04:03 lost+found
> This looks good.
>
>
>> That give you any clues?  Or am I starting over again.  ROFL 
>>
>> Dale
>>
>> :-)  :-) 
> No don't start over!  Have you read through this:
>
> https://wiki.gentoo.org/wiki/Dracut
>
>
> I don't use an initramfs, dracut, or systemd, wherever I can avoid them and I 
> do avoid them on my Gentoo.  Someone more clued up in these and their 
> peculiarities should chime in here.


Yep.  I saw that too.  Thing is, it confuses me.  On the main install
page, it shows /efi mounted on the / partition.  In other words, the
same place /boot, /usr and /var are mounted too.  In the page you link
to it seems to show the efi partition mounted inside /boot.  Like this: 
/boot/efi.  The main page I think says this is no longer recommended. 
Which am I to 

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

[Michael]

On Monday, 24 June 2024 22:03:14 BST Dale wrote:
> Michael wrote:
> > On Monday, 24 June 2024 20:47:15 BST Dale wrote:
> >> Have you seen this before?
> > 
> > No, because I've never used dracut.
> 
> I just had a thought.  I have /usr on the root partition now.  Do I even
> need a init thingy? 

Only you can answer this.

You don't need it if your kernel image has all the drivers it requires built-
in to mount / and start initializing your hardware.

Binary distros tend to built a lot of kernel drivers as modules and these will 
not be accessible until / has been mounted.  Therefore initrd/initramfs will 
include necessary modules, as well as firmware, CPU microcode, etc. to be able 
to run in memory enough of a temporary initial / fs, until the real / becomes 
accessible.

This is explained briefly here:

https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/
Kernel#Building_an_initramfs


> >> (chroot) livecd /usr/src/linux # dracut --kver=$(cat
> >> include/config/kernel.release)
> >> dracut[I]: Executing: /usr/bin/dracut --kver=6.9.4-gentoo
> >> dracut[F]: Can't write to
> >> /efi/dba652170b7a716f303c3c5966799436/6.9.4-gentoo: Directory
> >> /efi/dba652170b7a716f303c3c5966799436/6.9.4-gentoo does not exist or is
> >> not accessible.
> >> (chroot) livecd /usr/src/linux #
> >> 
> >> 
> >> The directory inside /efi does not exist.
> > 
> > The long string is either a PARTUUID, or a fs UUID.
> > 
> > Run blikid to find out what it is.
> 
> /dev/nvme0n1p1: UUID="6488-1019" BLOCK_SIZE="512" TYPE="vfat"
> PARTLABEL="efi-part" PARTUUID="50add3c0-4ab3-4453-85e5-93af643a586e"
> 
> I don't see anything, UUID or anything else that starts with dba6 for
> any partition.  I don't know why dracut is looking for that. 

Hmm ... I wonder if it is implementing a systemd-boot UUID for each OS kernel.  
:-/


> > Do you have a directory called EFI in your /efi partition?
> > 
> > Have you mounted your /mnt/gentoo/boot partition when you called dracut?
> 
> Yep.  There is.  Should that be there?  This is what is there. 
> 
> (chroot) livecd / # ls -al /efi/
> total 12
> drwxr-xr-x  3 root root 4096 Dec 31  1969 .
> drwxr-xr-x 17 root root 4096 Jun 23 12:06 ..
> drwxr-xr-x  3 root root 4096 Jun 24 14:29 EFI
> -rwxr-xr-x  1 root root0 Jun 24 14:01 test
> (chroot) livecd / # ls -al /efi/EFI/gentoo/grubx64.efi
> -rwxr-xr-x 1 root root 143360 Jun 24 14:33 /efi/EFI/gentoo/grubx64.efi

That's all as it should be.


> I mounted /boot when I mounted the others.  I already have a kernel and
> such in /boot.  When I did a search, I found where someone posted they
> used force with dracut to get it to install a init thingy.  I used it
> and it did build and put one in /boot.  Thing is, I've never had to use
> force before and figure something is wrong somewhere.

The first option in the man page explains what you did:

https://linux.die.net/man/8/dracut

-f, --force
overwrite existing initramfs file.

Did you have an initramfs already in there?

> This is /boot. 
> 
> 
> (chroot) livecd / # ls -al /boot/
> total 22512
> drwxr-xr-x  4 root root 4096 Jun 24 14:29 .
> drwxr-xr-x 17 root root 4096 Jun 23 12:06 ..
> -rw-r--r--  1 root root77312 Jun 24 11:40 amd-uc.img
> -rw-r--r--  1 root root   158391 Jun 24 12:02 config-6.9.4-6
> drwxr-xr-x  6 root root 4096 Jun 24 14:29 grub
> -rw---  1 root root  7740012 Jun 24 14:06 initramfs-6.9.4-6.img
> -rw-r--r--  1 root root 15000576 Jun 24 12:02 kernel-6.9.4-6
> drwx--  2 root root16384 Jun 24 04:03 lost+found

This looks good.


> That give you any clues?  Or am I starting over again.  ROFL 
> 
> Dale
> 
> :-)  :-) 

No don't start over!  Have you read through this:

https://wiki.gentoo.org/wiki/Dracut


I don't use an initramfs, dracut, or systemd, wherever I can avoid them and I 
do avoid them on my Gentoo.  Someone more clued up in these and their 
peculiarities should chime in here.

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

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

[Dale]

Michael wrote:
> On Monday, 24 June 2024 20:47:15 BST Dale wrote:
>
>> Have you seen this before?
> No, because I've never used dracut.

I just had a thought.  I have /usr on the root partition now.  Do I even
need a init thingy? 


>
>
>> (chroot) livecd /usr/src/linux # dracut --kver=$(cat
>> include/config/kernel.release)
>> dracut[I]: Executing: /usr/bin/dracut --kver=6.9.4-gentoo
>> dracut[F]: Can't write to
>> /efi/dba652170b7a716f303c3c5966799436/6.9.4-gentoo: Directory
>> /efi/dba652170b7a716f303c3c5966799436/6.9.4-gentoo does not exist or is
>> not accessible.
>> (chroot) livecd /usr/src/linux #
>>
>>
>> The directory inside /efi does not exist.  
> The long string is either a PARTUUID, or a fs UUID.
>
> Run blikid to find out what it is.

/dev/nvme0n1p1: UUID="6488-1019" BLOCK_SIZE="512" TYPE="vfat"
PARTLABEL="efi-part" PARTUUID="50add3c0-4ab3-4453-85e5-93af643a586e"

I don't see anything, UUID or anything else that starts with dba6 for
any partition.  I don't know why dracut is looking for that. 


>  <<< SNIP >>>
>> Thoughts?  I miss something??
>>
>> Dale
>>
>> :-)  :-) 
> Do you have a directory called EFI in your /efi partition?
>
> Have you mounted your /mnt/gentoo/boot partition when you called dracut?


Yep.  There is.  Should that be there?  This is what is there. 

(chroot) livecd / # ls -al /efi/
total 12
drwxr-xr-x  3 root root 4096 Dec 31  1969 .
drwxr-xr-x 17 root root 4096 Jun 23 12:06 ..
drwxr-xr-x  3 root root 4096 Jun 24 14:29 EFI
-rwxr-xr-x  1 root root    0 Jun 24 14:01 test
(chroot) livecd / # ls -al /efi/EFI/gentoo/grubx64.efi
-rwxr-xr-x 1 root root 143360 Jun 24 14:33 /efi/EFI/gentoo/grubx64.efi
(chroot) livecd / # 

I mounted /boot when I mounted the others.  I already have a kernel and
such in /boot.  When I did a search, I found where someone posted they
used force with dracut to get it to install a init thingy.  I used it
and it did build and put one in /boot.  Thing is, I've never had to use
force before and figure something is wrong somewhere.  This is /boot. 


(chroot) livecd / # ls -al /boot/
total 22512
drwxr-xr-x  4 root root 4096 Jun 24 14:29 .
drwxr-xr-x 17 root root 4096 Jun 23 12:06 ..
-rw-r--r--  1 root root    77312 Jun 24 11:40 amd-uc.img
-rw-r--r--  1 root root   158391 Jun 24 12:02 config-6.9.4-6
drwxr-xr-x  6 root root 4096 Jun 24 14:29 grub
-rw---  1 root root  7740012 Jun 24 14:06 initramfs-6.9.4-6.img
-rw-r--r--  1 root root 15000576 Jun 24 12:02 kernel-6.9.4-6
drwx--  2 root root    16384 Jun 24 04:03 lost+found
(chroot) livecd / #


That give you any clues?  Or am I starting over again.  ROFL 

Dale

:-)  :-) 

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

[Michael]

On Monday, 24 June 2024 20:47:15 BST Dale wrote:

> Have you seen this before?

No, because I've never used dracut.


> (chroot) livecd /usr/src/linux # dracut --kver=$(cat
> include/config/kernel.release)
> dracut[I]: Executing: /usr/bin/dracut --kver=6.9.4-gentoo
> dracut[F]: Can't write to
> /efi/dba652170b7a716f303c3c5966799436/6.9.4-gentoo: Directory
> /efi/dba652170b7a716f303c3c5966799436/6.9.4-gentoo does not exist or is
> not accessible.
> (chroot) livecd /usr/src/linux #
> 
> 
> The directory inside /efi does not exist.  

The long string is either a PARTUUID, or a fs UUID.

Run blikid to find out what it is.


> This is from the boot media,
> not the chroot environment. 
> 
> 
> livecd ~ # mount | grep efi
> /dev/nvme0n1p1 on /mnt/gentoo/efi type vfat
> (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mi
> xed,errors=remount-ro) livecd ~ #

That's find as is.


> I removed the efi parts for the live media that is booted.  The efi
> partition is mounted rw and is vfat.  Right?  

Right.


> I used touch to create a
> test file and it created the file in /efi from within the chroot
> environment just fine.  It seems dracut has a issue tho.  I went back
> through the docs and don't see anything I missed but I don't see what it
> is that creates what dracut is looking for either.  This is the correct
> file structure??
> 
> 
> (chroot) livecd / # ls -al /
> total 447012
> drwxr-xr-x  17 root root  4096 Jun 23 12:06 .
> drwxr-xr-x  17 root root  4096 Jun 23 12:06 ..
> lrwxrwxrwx   1 root root 7 Jun 23 12:06 bin -> usr/bin
> drwxr-xr-x   4 root root  4096 Jun 24 14:29 boot
> drwxr-xr-x  19 root root  4760 Jun 24 11:58 dev
> drwxr-xr-x   3 root root  4096 Dec 31  1969 efi
> drwxr-xr-x  49 root root  4096 Jun 24 14:32 etc
> drwxr-xr-x   2 root root  4096 Jun 23 12:06 home
> lrwxrwxrwx   1 root root 7 Jun 23 12:06 lib -> usr/lib
> lrwxrwxrwx   1 root root 9 Jun 23 12:06 lib64 -> usr/lib64
> drwxr-xr-x   2 root root  4096 Jun 23 12:06 media
> drwxr-xr-x   2 root root  4096 Jun 23 12:06 mnt
> drwxr-xr-x   5 root root  4096 Jun 24 05:19 opt
> dr-xr-xr-x 461 root root 0 Jun 24 04:39 proc
> drwx--   2 root root  4096 Jun 23 12:06 root
> drwxr-xr-x   3 root root60 Jun 24 04:40 run
> lrwxrwxrwx   1 root root 7 Jun 23 12:06 sbin -> usr/bin
> -rw-r--r--   1 root root 457688576 Jun 23 12:44
> stage3-amd64-desktop-openrc-20240623T164908Z.tar.xz
> dr-xr-xr-x  13 root root 0 Jun 24 04:44 sys
> drwxrwxrwt   3 root root60 Jun 24 14:32 tmp
> drwxr-xr-x  11 root root  4096 Jun 23 12:09 usr
> drwxr-xr-x  10 root root  4096 Jun 24 10:19 var

That's all fine as is.


> Thoughts?  I miss something??
> 
> Dale
> 
> :-)  :-) 

Do you have a directory called EFI in your /efi partition?

Have you mounted your /mnt/gentoo/boot partition when you called dracut?

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

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

[Dale]

Michael wrote:
> On Monday, 24 June 2024 17:54:44 BST Dale wrote:
>
>> I also ran into that locale thing again.  Using your export command,
>> fixed it, again.  I find it odd that the commands to reset the
>> environment does not reset that somehow.  Anyway, it works.  I have that
>> LC_ALL set on my main rig.  It's been that way for years.  Should I
>> change it or leave it since it works??
> It is recommended to leave the LC_ALL unset, because it overrides all other 
> settings.  Check the 'Warning' under the section "Environment variables for 
> locales" on this Guide:
>
> https://wiki.gentoo.org/wiki/Localization/Guide
>
> If you have it in your /etc/env.d/02locale, or your bashrc, or any other 
> startup script, unset it.  When you call:
>
> ~ $ locale
>
> at the end it should have an empty LC_ALL:
>
> LC_ALL=
>

I'll put that on my todo list.  Try to do that when I know I'll need to
reboot or something. 


>> My CPU seems to be running about 20F cooler now.
> Cool!  Ha!  Quite literally.  ;-)


Have you seen this before?


(chroot) livecd /usr/src/linux # dracut --kver=$(cat
include/config/kernel.release)
dracut[I]: Executing: /usr/bin/dracut --kver=6.9.4-gentoo
dracut[F]: Can't write to
/efi/dba652170b7a716f303c3c5966799436/6.9.4-gentoo: Directory
/efi/dba652170b7a716f303c3c5966799436/6.9.4-gentoo does not exist or is
not accessible.
(chroot) livecd /usr/src/linux #


The directory inside /efi does not exist.  This is from the boot media,
not the chroot environment. 


livecd ~ # mount | grep efi
/dev/nvme0n1p1 on /mnt/gentoo/efi type vfat
(rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
livecd ~ #

I removed the efi parts for the live media that is booted.  The efi
partition is mounted rw and is vfat.  Right?  I used touch to create a
test file and it created the file in /efi from within the chroot
environment just fine.  It seems dracut has a issue tho.  I went back
through the docs and don't see anything I missed but I don't see what it
is that creates what dracut is looking for either.  This is the correct
file structure??


(chroot) livecd / # ls -al /
total 447012
drwxr-xr-x  17 root root  4096 Jun 23 12:06 .
drwxr-xr-x  17 root root  4096 Jun 23 12:06 ..
lrwxrwxrwx   1 root root 7 Jun 23 12:06 bin -> usr/bin
drwxr-xr-x   4 root root  4096 Jun 24 14:29 boot
drwxr-xr-x  19 root root  4760 Jun 24 11:58 dev
drwxr-xr-x   3 root root  4096 Dec 31  1969 efi
drwxr-xr-x  49 root root  4096 Jun 24 14:32 etc
drwxr-xr-x   2 root root  4096 Jun 23 12:06 home
lrwxrwxrwx   1 root root 7 Jun 23 12:06 lib -> usr/lib
lrwxrwxrwx   1 root root 9 Jun 23 12:06 lib64 -> usr/lib64
drwxr-xr-x   2 root root  4096 Jun 23 12:06 media
drwxr-xr-x   2 root root  4096 Jun 23 12:06 mnt
drwxr-xr-x   5 root root  4096 Jun 24 05:19 opt
dr-xr-xr-x 461 root root 0 Jun 24 04:39 proc
drwx--   2 root root  4096 Jun 23 12:06 root
drwxr-xr-x   3 root root    60 Jun 24 04:40 run
lrwxrwxrwx   1 root root 7 Jun 23 12:06 sbin -> usr/bin
-rw-r--r--   1 root root 457688576 Jun 23 12:44
stage3-amd64-desktop-openrc-20240623T164908Z.tar.xz
dr-xr-xr-x  13 root root 0 Jun 24 04:44 sys
drwxrwxrwt   3 root root    60 Jun 24 14:32 tmp
drwxr-xr-x  11 root root  4096 Jun 23 12:09 usr
drwxr-xr-x  10 root root  4096 Jun 24 10:19 var
(chroot) livecd / #



Thoughts?  I miss something??

Dale

:-)  :-) 

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

[Michael]

On Monday, 24 June 2024 17:54:44 BST Dale wrote:
> Michael wrote:

> > For an ESP on a disk partition, it would be FAT32 (while FAT12 or FAT16
> > can be used for removable media).  VFAT is an extension to FAT allowing
> > long filenames.  In any case it's just a symlink:
> > 
> > ~ $ ls -la /usr/bin/mkfs.vfat
> > lrwxrwxrwx 1 root root 8 Mar 24 08:52 /usr/bin/mkfs.vfat -> mkfs.fat
> 
> I followed the guide.  I copied the mkfs command and the option then
> replaced with my partition info.  The command in the docs was a sda
> drive not nvme.  This part of the docs worked fine last time.  I just
> repeated the same.

Good.  You'll have the correct filesystem format for your EFI system 
partition.  :-)


[snip ...]
> I also ran into that locale thing again.  Using your export command,
> fixed it, again.  I find it odd that the commands to reset the
> environment does not reset that somehow.  Anyway, it works.  I have that
> LC_ALL set on my main rig.  It's been that way for years.  Should I
> change it or leave it since it works??

It is recommended to leave the LC_ALL unset, because it overrides all other 
settings.  Check the 'Warning' under the section "Environment variables for 
locales" on this Guide:

https://wiki.gentoo.org/wiki/Localization/Guide

If you have it in your /etc/env.d/02locale, or your bashrc, or any other 
startup script, unset it.  When you call:

~ $ locale

at the end it should have an empty LC_ALL:

LC_ALL=


> My CPU seems to be running about 20F cooler now.

Cool!  Ha!  Quite literally.  ;-)


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

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

[Dale]

Michael wrote:
> On Monday, 24 June 2024 14:25:47 BST Dale wrote:
>> Michael wrote:
>>> You should at least try to launch a X11 session using a console and see
>>> what is printed out on the CLI after you exit (or if it crashes).
>>>
>>> ~ $ exec dbus-launch --exit-with-session startplasma-x11
>> I tried every combination I could think of.  It seems the more I tried,
>> the worse the failure got. 
>>
>> Anyway, I've started a fresh install.  I fixed my partition boo boo.  I
>> didn't need much of anything except to just get a fresh start so I used
>> the zap feature of gdisk.  After that, I used cgdisk to set up
>> everything else, making sure the efi partition was ef00 and had the old
>> fat type partition on it.  Or was it vfat?  Whatever the docs said.  I
>> copy and paste some of it except for the partition info. 
> For an ESP on a disk partition, it would be FAT32 (while FAT12 or FAT16 can 
> be 
> used for removable media).  VFAT is an extension to FAT allowing long 
> filenames.  In any case it's just a symlink:
>
> ~ $ ls -la /usr/bin/mkfs.vfat
> lrwxrwxrwx 1 root root 8 Mar 24 08:52 /usr/bin/mkfs.vfat -> mkfs.fat
>

I followed the guide.  I copied the mkfs command and the option then
replaced with my partition info.  The command in the docs was a sda
drive not nvme.  This part of the docs worked fine last time.  I just
repeated the same.


>> I did notice one thing, I copied some USE flags over from my current
>> rig.  I found some that might not should have been copied over before. 
>> I wonder if that could have caused a problem or two.  I realized I chose
>> the merged /usr stage3 but had split-usr USE flag in make.conf.  That
>> was one I remembered.  There was a couple others as well. 
> Some of the USE flags will be dictated by the make.profile you used.  If you 
> selected the merged /usr profile 23.0 and the corresponding non-legacy stage 
> 3 
> archive for desktop plasma 23.0, you shouldn't have USE="split-usr".


When I copied over my USE line from make.conf, it is quite lengthy.  I
bet I missed that split-usr and could have missed a couple others.  I'm
not sure what problems that could cause tho.  I did look through it
pretty good this time.  What made me notice the difference, when I got
the link for the stage3 file, the one for split-usr is in a different
section, most likely because it is going away.  I didn't even see it for
the first install.  It's kinda to the right away from the others.  That
is one thing I noticed that was wrong, so far.  I may run into something
else before it is over.  I said before that it is likely me that missed
something.  A package, USE flag or something.  At this point, USE flag
applies. 

I also ran into that locale thing again.  Using your export command,
fixed it, again.  I find it odd that the commands to reset the
environment does not reset that somehow.  Anyway, it works.  I have that
LC_ALL set on my main rig.  It's been that way for years.  Should I
change it or leave it since it works??

My CPU seems to be running about 20F cooler now.  I may try stress again
later to make sure it is maxed out long enough to show up accurately. 

Dale

:-)  :-) 

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

[Michael]

On Monday, 24 June 2024 15:29:21 BST Dale wrote:
> Dale wrote:

> If a person is trying to copy another install and runs into a failure in
> a package to compile, skip ahead and deal with the locale section first
> then come back.  This failure is between syncing the tree and during the
> Optional: Updating the @world set section.  I moved the USE line over
> from my old system with some changes so I expected quite a few updates. 
> I ran into libdrm failing, no matter what USE flags I try.  It failed
> with this: 
> 
> 
> ninja: build stopped: subcommand failed.
>  * ERROR: x11-libs/libdrm-2.4.120::gentoo failed (compile phase):
>  *   ninja -v -j16 -l10 failed
[snip ...]

>  * Working directory:
> '/var/tmp/portage/x11-libs/libdrm-2.4.120/work/libdrm-2.4.120-abi_x86_64.amd
> 64' * S: '/var/tmp/portage/x11-libs/libdrm-2.4.120/work/libdrm-2.4.120'
> /var/tmp/portage/x11-libs/libdrm-2.4.120/temp/environment: line 87:
> warning: setlocale: LC_MESSAGES: cannot change locale (en_US.UTF8): No such
> file or directory
> /var/tmp/portage/x11-libs/libdrm-2.4.120/temp/environment: line 90:
> warning: setlocale: LC_NUMERIC: cannot change locale (en_US.UTF8): No
> such file or directory
> /var/tmp/portage/x11-libs/libdrm-2.4.120/temp/environment: line 93:
> warning: setlocale: LC_TIME: cannot change locale (en_US.UTF8): No such
> file or directory
>  *
>  * The following package has failed to build, install, or execute postinst:
>  *
>  *  (x11-libs/libdrm-2.4.120:0/0::gentoo, ebuild scheduled for merge),
> Log file:
>  *   '/var/log/portage/x11-libs:libdrm-2.4.120:20240624-140627.log'
> 
> 
> The key part is that part about 8 lines or so up.  If the locale is not
> set, it will fail.  Once it is set, it compiles just fine. 

You mentioned this in your previous install and I suggested you checked your 
locale.  You had specified (well, you had copied over from you old system) a 
non-empty LC_ALL in that case.


> I don't know if the docs should be changed or not.  It could be that in
> most cases, doing it early could cause other problems.

The handbook is written for all sort of different profiles, inc. users of the 
musl libc - see note under the section "Configure locales".

However, I think setting an appropriate locale earlier should not be a problem 
and as you have identified it would actually avoid any failures when updating 
a relatively full @world set like yours. You can raise a bug in BGO to this 
effect.  Select /product/ "Documentation" and then /component/ "Handbook".


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

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

[Michael]

On Monday, 24 June 2024 14:25:47 BST Dale wrote:
> Michael wrote:

> > You should at least try to launch a X11 session using a console and see
> > what is printed out on the CLI after you exit (or if it crashes).
> > 
> > ~ $ exec dbus-launch --exit-with-session startplasma-x11
> 
> I tried every combination I could think of.  It seems the more I tried,
> the worse the failure got. 
> 
> Anyway, I've started a fresh install.  I fixed my partition boo boo.  I
> didn't need much of anything except to just get a fresh start so I used
> the zap feature of gdisk.  After that, I used cgdisk to set up
> everything else, making sure the efi partition was ef00 and had the old
> fat type partition on it.  Or was it vfat?  Whatever the docs said.  I
> copy and paste some of it except for the partition info. 

For an ESP on a disk partition, it would be FAT32 (while FAT12 or FAT16 can be 
used for removable media).  VFAT is an extension to FAT allowing long 
filenames.  In any case it's just a symlink:

~ $ ls -la /usr/bin/mkfs.vfat
lrwxrwxrwx 1 root root 8 Mar 24 08:52 /usr/bin/mkfs.vfat -> mkfs.fat


> I did notice one thing, I copied some USE flags over from my current
> rig.  I found some that might not should have been copied over before. 
> I wonder if that could have caused a problem or two.  I realized I chose
> the merged /usr stage3 but had split-usr USE flag in make.conf.  That
> was one I remembered.  There was a couple others as well. 

Some of the USE flags will be dictated by the make.profile you used.  If you 
selected the merged /usr profile 23.0 and the corresponding non-legacy stage 3 
archive for desktop plasma 23.0, you shouldn't have USE="split-usr".


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

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

[Peter Humphrey]

On Monday, 24 June 2024 15:29:21 BST Dale wrote:

> If a person is trying to copy another install and runs into a failure in
> a package to compile, skip ahead and deal with the locale section first
> then come back.

Yes, I've been doing that for some time now, having tripped over something as 
you describe.

-- 
Regards,
Peter.

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

[Dale]

Dale wrote:
> Michael wrote:
>> On Monday, 24 June 2024 06:19:10 BST Dale wrote:
>>> William Kenworthy wrote:
 ...

> Now to ponder what comes next. 
>
> Dale
>
> :-)  :-) 
 Hi Dale, did I see in one of your early emails you created an
 xorg.conf for nvidia?  Have you followed the gentoo Xorg guide where
 it says to try first without that file?  I doubt the knoppix etc use a
 conf file and so must depend on the auto detection.

 Based on my own experience I can say using an xorg.conf (though it was
 a radeon card) is an easy way to shoot yourself in the foot!

 BillK
>>> At first I did not have a xorg.conf file.  When it didn't work right, I
>>> tried creating one to see if it would work.  It didn't work with or
>>> without one. 
>> Yes, but at first you were trying to launch a Wayland session.
>>
>> Did you also try to launch an X11 session without an xorg.conf file?  Any 
>> changes you need to include non-default settings should be added under /etc/
>> X11/xorg.conf.d/.
>>
>> https://wiki.gentoo.org/wiki/Xorg/Guide#Configuration
>>
>> You should at least try to launch a X11 session using a console and see what 
>> is printed out on the CLI after you exit (or if it crashes).
>>
>> ~ $ exec dbus-launch --exit-with-session startplasma-x11
>
> I tried every combination I could think of.  It seems the more I tried,
> the worse the failure got. 
>
> Anyway, I've started a fresh install.  I fixed my partition boo boo.  I
> didn't need much of anything except to just get a fresh start so I used
> the zap feature of gdisk.  After that, I used cgdisk to set up
> everything else, making sure the efi partition was ef00 and had the old
> fat type partition on it.  Or was it vfat?  Whatever the docs said.  I
> copy and paste some of it except for the partition info. 
>
> I did notice one thing, I copied some USE flags over from my current
> rig.  I found some that might not should have been copied over before. 
> I wonder if that could have caused a problem or two.  I realized I chose
> the merged /usr stage3 but had split-usr USE flag in make.conf.  That
> was one I remembered.  There was a couple others as well. 
>
> Right now, I'm warming up that thermal paste some more.  ROFL 
>
> Dale
>
> :-)  :-) 
>


If a person is trying to copy another install and runs into a failure in
a package to compile, skip ahead and deal with the locale section first
then come back.  This failure is between syncing the tree and during the
Optional: Updating the @world set section.  I moved the USE line over
from my old system with some changes so I expected quite a few updates. 
I ran into libdrm failing, no matter what USE flags I try.  It failed
with this: 


ninja: build stopped: subcommand failed.
 * ERROR: x11-libs/libdrm-2.4.120::gentoo failed (compile phase):
 *   ninja -v -j16 -l10 failed
 *
 * Call stack:
 * ebuild.sh, line  136:  Called src_compile
 *   environment, line 3348:  Called meson-multilib_src_compile
 *   environment, line 2023:  Called multilib-minimal_src_compile
 *   environment, line 2217:  Called multilib_foreach_abi
'multilib-minimal_abi_src_compile'
 *   environment, line 2484:  Called multibuild_foreach_variant
'_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_compile'
 *   environment, line 2177:  Called _multibuild_run
'_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_compile'
 *   environment, line 2175:  Called _multilib_multibuild_wrapper
'multilib-minimal_abi_src_compile'
 *   environment, line  634:  Called multilib-minimal_abi_src_compile
 *   environment, line 2211:  Called multilib_src_compile
 *   environment, line 2704:  Called meson_src_compile
 *   environment, line 2090:  Called eninja
 *   environment, line 1470:  Called die
 * The specific snippet of code:
 *   "$@" || die -n "${*} failed"
 *
 * If you need support, post the output of `emerge --info
'=x11-libs/libdrm-2.4.120::gentoo'`,
 * the complete build log and the output of `emerge -pqv
'=x11-libs/libdrm-2.4.120::gentoo'`.
 * The complete build log is located at
'/var/log/portage/x11-libs:libdrm-2.4.120:20240624-140627.log'.
 * For convenience, a symlink to the build log is located at
'/var/tmp/portage/x11-libs/libdrm-2.4.120/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/x11-libs/libdrm-2.4.120/temp/environment'.
 * Working directory:
'/var/tmp/portage/x11-libs/libdrm-2.4.120/work/libdrm-2.4.120-abi_x86_64.amd64'
 * S: '/var/tmp/portage/x11-libs/libdrm-2.4.120/work/libdrm-2.4.120'
/var/tmp/portage/x11-libs/libdrm-2.4.120/temp/environment: line 87:
warning: setlocale: LC_MESSAGES: cannot change locale (en_US.UTF8): No
such file or directory
/var/tmp/portage/x11-libs/libdrm-2.4.120/temp/environment: line 90:
warning: setlocale: LC_NUMERIC: cannot change locale (en_US.UTF8): No
such file or directory
/var/tmp/portage/x11-libs/libdrm-2.4.120/temp/environment: line 93:
warning: setlocale: LC_TIME: cannot change locale (en

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

[Dale]

Michael wrote:
> On Monday, 24 June 2024 06:19:10 BST Dale wrote:
>> William Kenworthy wrote:
>>> ...
>>>
 Now to ponder what comes next. 

 Dale

 :-)  :-) 
>>> Hi Dale, did I see in one of your early emails you created an
>>> xorg.conf for nvidia?  Have you followed the gentoo Xorg guide where
>>> it says to try first without that file?  I doubt the knoppix etc use a
>>> conf file and so must depend on the auto detection.
>>>
>>> Based on my own experience I can say using an xorg.conf (though it was
>>> a radeon card) is an easy way to shoot yourself in the foot!
>>>
>>> BillK
>> At first I did not have a xorg.conf file.  When it didn't work right, I
>> tried creating one to see if it would work.  It didn't work with or
>> without one. 
> Yes, but at first you were trying to launch a Wayland session.
>
> Did you also try to launch an X11 session without an xorg.conf file?  Any 
> changes you need to include non-default settings should be added under /etc/
> X11/xorg.conf.d/.
>
> https://wiki.gentoo.org/wiki/Xorg/Guide#Configuration
>
> You should at least try to launch a X11 session using a console and see what 
> is printed out on the CLI after you exit (or if it crashes).
>
> ~ $ exec dbus-launch --exit-with-session startplasma-x11


I tried every combination I could think of.  It seems the more I tried,
the worse the failure got. 

Anyway, I've started a fresh install.  I fixed my partition boo boo.  I
didn't need much of anything except to just get a fresh start so I used
the zap feature of gdisk.  After that, I used cgdisk to set up
everything else, making sure the efi partition was ef00 and had the old
fat type partition on it.  Or was it vfat?  Whatever the docs said.  I
copy and paste some of it except for the partition info. 

I did notice one thing, I copied some USE flags over from my current
rig.  I found some that might not should have been copied over before. 
I wonder if that could have caused a problem or two.  I realized I chose
the merged /usr stage3 but had split-usr USE flag in make.conf.  That
was one I remembered.  There was a couple others as well. 

Right now, I'm warming up that thermal paste some more.  ROFL 

Dale

:-)  :-) 

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

[Michael]

On Monday, 24 June 2024 06:19:10 BST Dale wrote:
> William Kenworthy wrote:
> > ...
> > 
> >> Now to ponder what comes next. 
> >> 
> >> Dale
> >> 
> >> :-)  :-) 
> > 
> > Hi Dale, did I see in one of your early emails you created an
> > xorg.conf for nvidia?  Have you followed the gentoo Xorg guide where
> > it says to try first without that file?  I doubt the knoppix etc use a
> > conf file and so must depend on the auto detection.
> > 
> > Based on my own experience I can say using an xorg.conf (though it was
> > a radeon card) is an easy way to shoot yourself in the foot!
> > 
> > BillK
> 
> At first I did not have a xorg.conf file.  When it didn't work right, I
> tried creating one to see if it would work.  It didn't work with or
> without one. 

Yes, but at first you were trying to launch a Wayland session.

Did you also try to launch an X11 session without an xorg.conf file?  Any 
changes you need to include non-default settings should be added under /etc/
X11/xorg.conf.d/.

https://wiki.gentoo.org/wiki/Xorg/Guide#Configuration

You should at least try to launch a X11 session using a console and see what 
is printed out on the CLI after you exit (or if it crashes).

~ $ exec dbus-launch --exit-with-session startplasma-x11


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

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

[Michael]

On Monday, 24 June 2024 02:55:33 BST Dale wrote:
> Michael wrote:
> > On Sunday, 23 June 2024 23:37:15 BST Dale wrote:
> >> Michael wrote:
> >>> On Sunday, 23 June 2024 13:19:18 BST Dale wrote:

> >> I kinda like /boot on its own partition.  If /boot gets corrupted
> >> somehow, I can get the kernel and config again from /usr/src/linux.
> >> Building the init thingy again is trivial.  So is reinstalling grub.  If
> >> I were to lose root somehow, I'd have to reinstall but I got the kernel
> >> and its config file.  It ain't much but it's something.  As it is, /boot
> >> is on the same partition as root.  If root goes bad, all is lost, except
> >> for any backup copies I might have.  If I redo the install, I'd have a
> >> EFI partition and a separate /boot partition as well.  The EFI would be
> >> like 8MBs or so and the /boot partition would be ext2 and 8GBs or so.
> >> Plenty of room for expansion.
> > 
> > I see.  I don't think you need to redo the install.  All you need to do
> > is:
> > 
> > 1. Back up the ESP contents, just in case.
> > 2. Shrink the ESP partition, down to a reasonable size.  500M or 1G would
> > be more than enough.
> > 3. Create a new partition, say ~7G in the space your just freed up, of
> > type
> > 8300.
> > 4. Check if the content of the ESP fs is intact (it should be, but we're
> > talking about FAT here) and if not reformat as FAT32 and copy over the
> > files from the ESP backup.
> > 5. Format the new /boot partition and copy over the files from your
> > current / boot tdirectory to the new /boot partition you created.
> > 6. Adjust your fstab and reboot.
> > 
> > NOTE: The GPT partition numbering order will be messed up, but this does
> > not alter their functionality.  If it annoys you, then use gdisk to
> > re-order them.
> Oh, I'd mess that up quick.  o_O 

Unlikely.  :-)

Press s to ... sort.

Check 'man gdisk' for the 3 menus of gdisk and their commands.  Anyway, the 
numbering of partitions as stored in the GPT tables is of less importance if 
you use UUIDs in your fstab.


> >> I'm going to compare some data between the Gentoo live DVD and my
> >> install.  If I don't see something obvious, I'm going to fix my
> >> partition boo boo with a fresh start.  While at it.  What is the best
> >> way to wipe the partition data from a m.2 stick?  They not spinning rust
> >> so don't want to try to dd or use shred on the whole thing.  Doesn't
> >> gdisk have a wipe partition option?  Curious what you think is the best
> >> way to do that.  Don't want to shorten the life of my m.2 stick.
> > 
> > In this case do not reinstall.  Most of it, if not all, would be
> > unnecessarily deleting and rewriting the same data.
> > 
> > gdisk can destroy all the GPT data structures on a disk.  Press x, then z.
> > However, I suggest you don't this.  Use Gparted to shrink your ESP and add
> > a new partition for /boot as I explained above.  The focus on sorting out
> > your graphic card.
[snip ...]

> Now to ponder what comes next. 
> 
> Dale
> 
> :-)  :-) 

Well, before you consider what comes next, you should consider what comes 
first.  If you must reinstall, then you may want to erase securely all data on 
the NVMe disk instead of just deleting the GPT tables.  You can use nvme-cli 
for secure deletion of your data; e.g. for /dev/nvme0n1:

nvme format /dev/nvme0 --namespace-id=1 --ses=1 --pi=1

Wait until it completes and do not interrupt it.

(man nvme-format for more information).


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

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

[Wols Lists]

On 24/06/2024 02:55, Dale wrote:

Now to ponder what comes next.


Stibbons?

Cheers,
Wol

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

[Dale]

William Kenworthy wrote:
> ...
>> Now to ponder what comes next. 
>>
>> Dale
>>
>> :-)  :-) 
>>
> Hi Dale, did I see in one of your early emails you created an
> xorg.conf for nvidia?  Have you followed the gentoo Xorg guide where
> it says to try first without that file?  I doubt the knoppix etc use a
> conf file and so must depend on the auto detection.
>
> Based on my own experience I can say using an xorg.conf (though it was
> a radeon card) is an easy way to shoot yourself in the foot!
>
> BillK
>
>


At first I did not have a xorg.conf file.  When it didn't work right, I
tried creating one to see if it would work.  It didn't work with or
without one. 

I suspect once I get everything done correctly, it won't need one.
Neither the Gentoo live DVD or the Knoppix system has one. 

Dale

:-)  :-) 

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

[William Kenworthy]

...

Now to ponder what comes next.

Dale

:-)  :-)

Hi Dale, did I see in one of your early emails you created an xorg.conf 
for nvidia?  Have you followed the gentoo Xorg guide where it says to 
try first without that file?  I doubt the knoppix etc use a conf file 
and so must depend on the auto detection.


Based on my own experience I can say using an xorg.conf (though it was a 
radeon card) is an easy way to shoot yourself in the foot!


BillK

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

[Dale]

Michael wrote:
> On Sunday, 23 June 2024 23:37:15 BST Dale wrote:
>> Michael wrote:
>>> On Sunday, 23 June 2024 13:19:18 BST Dale wrote:
 That's my thinking.  The only benefit to reinstalling is correcting the
 partition boo boo.
>>> What in particular are you referring to?  I thought you created an ESP, /
>>> and /home partitions, if I recall.
>> I was thinking the EFI partition, ef02, and /boot were the same
>> partition.  I only created one that was huge.  I made the ef02 partition
>> 8GBs I think when 8MBs would have been more than enough from what I've
>> read.
> OK, the "EFI System Partition" is type ef00.  You need this partition type to 
> be able to boot a UEFI MoBo using its (BIOS) firmware.  This is where GRUB, 
> or 
> any other boot manager will install its UEFI executable image.
>
> ef02 is the partition code type for the "BIOS Boot Partition".  You do NOT 
> need one of these, since you are not trying to boot a GPT disk on a legacy 
> BIOS MoBo.
>
> Your new /boot partition can be a normal linux partition, type 8300 and you 
> can format this as ext2/3/4, or whatever GRUB can read.
>

I thought it was ef02.  I think it is in the install guide anyway.  Good
to know it is ef00 for the efi partition tho.  Less chance of me messing
that up.  LOL


>> I kinda like /boot on its own partition.  If /boot gets corrupted
>> somehow, I can get the kernel and config again from /usr/src/linux. 
>> Building the init thingy again is trivial.  So is reinstalling grub.  If
>> I were to lose root somehow, I'd have to reinstall but I got the kernel
>> and its config file.  It ain't much but it's something.  As it is, /boot
>> is on the same partition as root.  If root goes bad, all is lost, except
>> for any backup copies I might have.  If I redo the install, I'd have a
>> EFI partition and a separate /boot partition as well.  The EFI would be
>> like 8MBs or so and the /boot partition would be ext2 and 8GBs or so. 
>> Plenty of room for expansion.
> I see.  I don't think you need to redo the install.  All you need to do is:
>
> 1. Back up the ESP contents, just in case.
> 2. Shrink the ESP partition, down to a reasonable size.  500M or 1G would be 
> more than enough.
> 3. Create a new partition, say ~7G in the space your just freed up, of type 
> 8300.
> 4. Check if the content of the ESP fs is intact (it should be, but we're 
> talking about FAT here) and if not reformat as FAT32 and copy over the files 
> from the ESP backup.
> 5. Format the new /boot partition and copy over the files from your current /
> boot tdirectory to the new /boot partition you created.
> 6. Adjust your fstab and reboot.
>
> NOTE: The GPT partition numbering order will be messed up, but this does not 
> alter their functionality.  If it annoys you, then use gdisk to re-order them.

Oh, I'd mess that up quick.  o_O 


>
>> I saved messages, sddm log and the Xorg log.  Honestly tho, they will be
>> different because the live DVD uses the kernel drivers, nouveau, where I
>> use Nvidia.  Still, I got them anyway. 
>>
>> Several years ago, I took the CPU cooler off my main rig.  I dunked the
>> fin part into some heavy duty cleaner that cleans off dirt and dust. 
>> They wasn't to bad really since I blow them clean with compressed air
>> from my compressor pretty regular.  Still, it looked new when I was
>> done.  I used alcohol and a toothbrush to clean the old paste off of the
>> base.  The original paste was what came with the CPU I think.  I'm
>> pretty sure I put Arctic Silver on the second time.  I can't remember
>> the exact amount but it did cool better after a few updates and some
>> compiling.  I don't know if it was the fin cleaning or the thermal paste
>> or both tho.  I think Arctic Silver is still considered a good brand and
>> very good product.  I'm pretty sure it never dries out.  Even some
>> cheaper generic brands are quite good. 
> Ha!  I thought my low temperatures were too good to be true!  The Mobo had 
> lost its settings (it reminds me I need to replace the CMOS battery) and 
> consequently the CPU was underclocked.  I reconfigured everything and on a 
> second run the temperature was cooler, but only by 2-3°C cooler.  Still, 
> grateful for small mercies.  :-)
>

Well, it being done likely makes you feel better anyway.  You know it is
fresh and should be good for a while. 


>> I'm going to compare some data between the Gentoo live DVD and my
>> install.  If I don't see something obvious, I'm going to fix my
>> partition boo boo with a fresh start.  While at it.  What is the best
>> way to wipe the partition data from a m.2 stick?  They not spinning rust
>> so don't want to try to dd or use shred on the whole thing.  Doesn't
>> gdisk have a wipe partition option?  Curious what you think is the best
>> way to do that.  Don't want to shorten the life of my m.2 stick. 
> In this case do not reinstall.  Most of it, if not all, would be 
> unnecessarily 
> deleting and rewriting the same data.
>
> gdisk can 

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

[Michael]

On Sunday, 23 June 2024 23:37:15 BST Dale wrote:
> Michael wrote:
> > On Sunday, 23 June 2024 13:19:18 BST Dale wrote:
> >> That's my thinking.  The only benefit to reinstalling is correcting the
> >> partition boo boo.
> > 
> > What in particular are you referring to?  I thought you created an ESP, /
> > and /home partitions, if I recall.
> 
> I was thinking the EFI partition, ef02, and /boot were the same
> partition.  I only created one that was huge.  I made the ef02 partition
> 8GBs I think when 8MBs would have been more than enough from what I've
> read.

OK, the "EFI System Partition" is type ef00.  You need this partition type to 
be able to boot a UEFI MoBo using its (BIOS) firmware.  This is where GRUB, or 
any other boot manager will install its UEFI executable image.

ef02 is the partition code type for the "BIOS Boot Partition".  You do NOT 
need one of these, since you are not trying to boot a GPT disk on a legacy 
BIOS MoBo.

Your new /boot partition can be a normal linux partition, type 8300 and you 
can format this as ext2/3/4, or whatever GRUB can read.


> I kinda like /boot on its own partition.  If /boot gets corrupted
> somehow, I can get the kernel and config again from /usr/src/linux. 
> Building the init thingy again is trivial.  So is reinstalling grub.  If
> I were to lose root somehow, I'd have to reinstall but I got the kernel
> and its config file.  It ain't much but it's something.  As it is, /boot
> is on the same partition as root.  If root goes bad, all is lost, except
> for any backup copies I might have.  If I redo the install, I'd have a
> EFI partition and a separate /boot partition as well.  The EFI would be
> like 8MBs or so and the /boot partition would be ext2 and 8GBs or so. 
> Plenty of room for expansion.

I see.  I don't think you need to redo the install.  All you need to do is:

1. Back up the ESP contents, just in case.
2. Shrink the ESP partition, down to a reasonable size.  500M or 1G would be 
more than enough.
3. Create a new partition, say ~7G in the space your just freed up, of type 
8300.
4. Check if the content of the ESP fs is intact (it should be, but we're 
talking about FAT here) and if not reformat as FAT32 and copy over the files 
from the ESP backup.
5. Format the new /boot partition and copy over the files from your current /
boot tdirectory to the new /boot partition you created.
6. Adjust your fstab and reboot.

NOTE: The GPT partition numbering order will be messed up, but this does not 
alter their functionality.  If it annoys you, then use gdisk to re-order them.


> I saved messages, sddm log and the Xorg log.  Honestly tho, they will be
> different because the live DVD uses the kernel drivers, nouveau, where I
> use Nvidia.  Still, I got them anyway. 
> 
> Several years ago, I took the CPU cooler off my main rig.  I dunked the
> fin part into some heavy duty cleaner that cleans off dirt and dust. 
> They wasn't to bad really since I blow them clean with compressed air
> from my compressor pretty regular.  Still, it looked new when I was
> done.  I used alcohol and a toothbrush to clean the old paste off of the
> base.  The original paste was what came with the CPU I think.  I'm
> pretty sure I put Arctic Silver on the second time.  I can't remember
> the exact amount but it did cool better after a few updates and some
> compiling.  I don't know if it was the fin cleaning or the thermal paste
> or both tho.  I think Arctic Silver is still considered a good brand and
> very good product.  I'm pretty sure it never dries out.  Even some
> cheaper generic brands are quite good. 

Ha!  I thought my low temperatures were too good to be true!  The Mobo had 
lost its settings (it reminds me I need to replace the CMOS battery) and 
consequently the CPU was underclocked.  I reconfigured everything and on a 
second run the temperature was cooler, but only by 2-3°C cooler.  Still, 
grateful for small mercies.  :-)


> I'm going to compare some data between the Gentoo live DVD and my
> install.  If I don't see something obvious, I'm going to fix my
> partition boo boo with a fresh start.  While at it.  What is the best
> way to wipe the partition data from a m.2 stick?  They not spinning rust
> so don't want to try to dd or use shred on the whole thing.  Doesn't
> gdisk have a wipe partition option?  Curious what you think is the best
> way to do that.  Don't want to shorten the life of my m.2 stick. 

In this case do not reinstall.  Most of it, if not all, would be unnecessarily 
deleting and rewriting the same data.

gdisk can destroy all the GPT data structures on a disk.  Press x, then z.  
However, I suggest you don't this.  Use Gparted to shrink your ESP and add a 
new partition for /boot as I explained above.  The focus on sorting out your 
graphic card.


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

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

[Dale]

Michael wrote:
> On Sunday, 23 June 2024 13:19:18 BST Dale wrote:
>>
>> That's my thinking.  The only benefit to reinstalling is correcting the
>> partition boo boo.
> What in particular are you referring to?  I thought you created an ESP, / and 
> /home partitions, if I recall.
>

I was thinking the EFI partition, ef02, and /boot were the same
partition.  I only created one that was huge.  I made the ef02 partition
8GBs I think when 8MBs would have been more than enough from what I've
read.  I kinda like /boot on its own partition.  If /boot gets corrupted
somehow, I can get the kernel and config again from /usr/src/linux. 
Building the init thingy again is trivial.  So is reinstalling grub.  If
I were to lose root somehow, I'd have to reinstall but I got the kernel
and its config file.  It ain't much but it's something.  As it is, /boot
is on the same partition as root.  If root goes bad, all is lost, except
for any backup copies I might have.  If I redo the install, I'd have a
EFI partition and a separate /boot partition as well.  The EFI would be
like 8MBs or so and the /boot partition would be ext2 and 8GBs or so. 
Plenty of room for expansion.


>> I also might learn something, maybe.  Of course,
>> there is that blind squirrel tho.  I think I'll get the config file info
>> from the Gentoo media tho. 
>>
>> Since my last message, it's been sitting on a Knoppix screen.  It's
>> still sitting there just like I left it for my second nap.  So, hardware
>> is certainly in the clear.  A config issue is the problem, which means I
>> was right, I missed something.  Somewhere. 
>>
>> Now to go find it.  ;?
> See what config files (if any) may have been created for Xorg, what drivers 
> are loaded for your graphics, what kernel modules are in play.
>
> lspci -knn
>
> for other drivers too.
>
> Also save dmesg to compare with your kernel's output.
>
> PS. It's getting warmer and noticed on an older PC the temperatures were 
> creeping up a bit and the fans were getting louder.  Last time I applied 
> thermal paste on its CPU was in 2017.  So, I took it apart, cleaned it and re-
> applied fresh, very expensive, thermal paste.  Well, I fell off my seat after 
> I restarted it and run cpuburn on it for 10 minutes on all cores.  A 19% 
> reduction in CPU temperature!!  0_0


I saved messages, sddm log and the Xorg log.  Honestly tho, they will be
different because the live DVD uses the kernel drivers, nouveau, where I
use Nvidia.  Still, I got them anyway. 

Several years ago, I took the CPU cooler off my main rig.  I dunked the
fin part into some heavy duty cleaner that cleans off dirt and dust. 
They wasn't to bad really since I blow them clean with compressed air
from my compressor pretty regular.  Still, it looked new when I was
done.  I used alcohol and a toothbrush to clean the old paste off of the
base.  The original paste was what came with the CPU I think.  I'm
pretty sure I put Arctic Silver on the second time.  I can't remember
the exact amount but it did cool better after a few updates and some
compiling.  I don't know if it was the fin cleaning or the thermal paste
or both tho.  I think Arctic Silver is still considered a good brand and
very good product.  I'm pretty sure it never dries out.  Even some
cheaper generic brands are quite good. 

I'm going to compare some data between the Gentoo live DVD and my
install.  If I don't see something obvious, I'm going to fix my
partition boo boo with a fresh start.  While at it.  What is the best
way to wipe the partition data from a m.2 stick?  They not spinning rust
so don't want to try to dd or use shred on the whole thing.  Doesn't
gdisk have a wipe partition option?  Curious what you think is the best
way to do that.  Don't want to shorten the life of my m.2 stick. 

Dale

:-)  :-) 

P. S.  Ended up with a LOT of dried basil.  Now I'm drying hot banana
and jalapeno peppers.  Suspect my eyes will water when I warm up
supper.  '_' 

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

[Michael]

On Sunday, 23 June 2024 13:19:18 BST Dale wrote:
> Michael wrote:
> > On Sunday, 23 June 2024 08:53:01 BST Dale wrote:
> >> Top posting for consistency.
> >> 
> >> I booted the Gentoo GUI media.  I opened a window just in case it
> >> rebooted or something while I took a little nap.  The resolution is
> >> 1080P which is what I expected the monitor to run at.  When I got back
> >> up a few minutes ago, the same window was there.  It ran for hours
> >> without the monitor powering off.  I think this eliminates hardware.
> > 
> > Yes!  :-)
> 
> I was worried that $100 video card I bought, most I ever spent on a
> video card, was for nothing.  I'd hate for it to be defective somehow. 
> 
> >> I also found something new.  I can go in the BIOS menu and boot a USB
> >> stick directly from that by just clicking on it.  O_O  WOW!!!  I said
> >> the new BIOS had improved by a lot.  Can that thing wash dishes too???
> >> LOL
> > 
> > It is the same as the legacy BIOS in this respect, only the GUI is
> > different. With the old BIOS you would press F2 or Delete at POST and
> > then go into the boot menu to select 'Removable Media' or some such.
> 
> Well, on this one, I thought I was going to select it for a temporary
> boot after exiting the BIOS, one time thing, but when I clicked it, the
> menu screen for Knoppix popped up.  I didn't exit the BIOS or anything. 
> Just click and off it went to boot what I clicked.  o_O 
> 
> >> Still open to ideas if anyone has any.  If not, I may safe key files and
> >> start over, and fix my partition layout too.
> > 
> > Diff the settings used by the LiveUSB and the settings you have configured
> > on your installation.  Starting over with your installation, only to
> > follow the same path and without *knowing* what you need to change, will
> > not necessarily resolve your issue.
> 
> That's my thinking.  The only benefit to reinstalling is correcting the
> partition boo boo.

What in particular are you referring to?  I thought you created an ESP, / and 
/home partitions, if I recall.


> I also might learn something, maybe.  Of course,
> there is that blind squirrel tho.  I think I'll get the config file info
> from the Gentoo media tho. 
> 
> Since my last message, it's been sitting on a Knoppix screen.  It's
> still sitting there just like I left it for my second nap.  So, hardware
> is certainly in the clear.  A config issue is the problem, which means I
> was right, I missed something.  Somewhere. 
> 
> Now to go find it.  ;?

See what config files (if any) may have been created for Xorg, what drivers 
are loaded for your graphics, what kernel modules are in play.

lspci -knn

for other drivers too.

Also save dmesg to compare with your kernel's output.

PS. It's getting warmer and noticed on an older PC the temperatures were 
creeping up a bit and the fans were getting louder.  Last time I applied 
thermal paste on its CPU was in 2017.  So, I took it apart, cleaned it and re-
applied fresh, very expensive, thermal paste.  Well, I fell off my seat after 
I restarted it and run cpuburn on it for 10 minutes on all cores.  A 19% 
reduction in CPU temperature!!  0_0

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

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

[Dale]

Michael wrote:
> On Sunday, 23 June 2024 08:53:01 BST Dale wrote:
>> Top posting for consistency.
>>
>> I booted the Gentoo GUI media.  I opened a window just in case it
>> rebooted or something while I took a little nap.  The resolution is
>> 1080P which is what I expected the monitor to run at.  When I got back
>> up a few minutes ago, the same window was there.  It ran for hours
>> without the monitor powering off.  I think this eliminates hardware. 
> Yes!  :-)

I was worried that $100 video card I bought, most I ever spent on a
video card, was for nothing.  I'd hate for it to be defective somehow. 

>
>> I also found something new.  I can go in the BIOS menu and boot a USB
>> stick directly from that by just clicking on it.  O_O  WOW!!!  I said
>> the new BIOS had improved by a lot.  Can that thing wash dishes too??? 
>> LOL 
> It is the same as the legacy BIOS in this respect, only the GUI is different. 
>  
> With the old BIOS you would press F2 or Delete at POST and then go into the 
> boot menu to select 'Removable Media' or some such.

Well, on this one, I thought I was going to select it for a temporary
boot after exiting the BIOS, one time thing, but when I clicked it, the
menu screen for Knoppix popped up.  I didn't exit the BIOS or anything. 
Just click and off it went to boot what I clicked.  o_O 


>> Still open to ideas if anyone has any.  If not, I may safe key files and
>> start over, and fix my partition layout too. 
> Diff the settings used by the LiveUSB and the settings you have configured on 
> your installation.  Starting over with your installation, only to follow the 
> same path and without *knowing* what you need to change, will not necessarily 
> resolve your issue.

That's my thinking.  The only benefit to reinstalling is correcting the
partition boo boo.  I also might learn something, maybe.  Of course,
there is that blind squirrel tho.  I think I'll get the config file info
from the Gentoo media tho. 

Since my last message, it's been sitting on a Knoppix screen.  It's
still sitting there just like I left it for my second nap.  So, hardware
is certainly in the clear.  A config issue is the problem, which means I
was right, I missed something.  Somewhere. 

Now to go find it.  ;?

Dale

:-)  :-) 

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

[Michael]

On Sunday, 23 June 2024 08:53:01 BST Dale wrote:
> Top posting for consistency.
> 
> I booted the Gentoo GUI media.  I opened a window just in case it
> rebooted or something while I took a little nap.  The resolution is
> 1080P which is what I expected the monitor to run at.  When I got back
> up a few minutes ago, the same window was there.  It ran for hours
> without the monitor powering off.  I think this eliminates hardware. 

Yes!  :-)

> I also found something new.  I can go in the BIOS menu and boot a USB
> stick directly from that by just clicking on it.  O_O  WOW!!!  I said
> the new BIOS had improved by a lot.  Can that thing wash dishes too??? 
> LOL 

It is the same as the legacy BIOS in this respect, only the GUI is different.  
With the old BIOS you would press F2 or Delete at POST and then go into the 
boot menu to select 'Removable Media' or some such.

> Still open to ideas if anyone has any.  If not, I may safe key files and
> start over, and fix my partition layout too. 

Diff the settings used by the LiveUSB and the settings you have configured on 
your installation.  Starting over with your installation, only to follow the 
same path and without *knowing* what you need to change, will not necessarily 
resolve your issue.

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

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

[Michael]

On Sunday, 23 June 2024 02:21:11 BST Dale wrote:
> Michael wrote:
> > On Saturday, 22 June 2024 19:13:42 BST Dale wrote:
> >> Dale wrote:
> >>> Michael wrote:
> >> root@Gentoo-1 ~ # xrandr --verbose
> >> Can't open display
> >> root@Gentoo-1 ~ #
> >> 
> >> 
> >> That's after I started display-manager but this time, it did nothing.
> >> The screen stayed on a console.  I did move the cable to another port
> >> before booting up.
> > 
> > The xerver is not running.
> 
> How do I start it?  I did a /etc/init.d/  and I see
> display-manager and xdm.  I been using display-manager.  I have sddm set
> for display-manager.  Like this.
> 
> 
> root@Gentoo-1 ~ # cat /etc/conf.d/xdm

What you show below is the content of /etc/conf.d/display-manager, NOT of xdm.

> # We always try and start X on a static VT. The various DMs normally default
> # to using VT7. If you wish to use the xdm init script, then you should
> ensure
> # that the VT checked is the same VT your DM wants to use. We do this
> check to
> # ensure that you haven't accidentally configured something to run on the VT
> # in your /etc/inittab file so that you don't get a dead keyboard.
> CHECKVT=7
> 
> # What display manager do you use ?  [ xdm | gdm | sddm | gpe | lightdm
> 
> | entrance ]
> 
> # NOTE: If this is set in /etc/rc.conf, that setting will override this one.
> DISPLAYMANAGER="sddm"

Make sure you do not start both xdm and sddm as an rc service concurrently.  
Just display-manager will do.


> >> This is the other info except nothing xorg there, just wayland.  See
> >> below for more on that.
> >> 
> >> 
> >> root@Gentoo-1 ~ # cat /home/dale/.local/share/sddm/wayland-session.log
> > 
> > I thought you said you were having a problem starting a X session, not
> > starting a Wayland session.  What desktop session are you selecting in
> > your
> > SDDM?
> > 
> > [snip ...]
> 
> That made me think.  After a few attempts, I got the sddm login screen
> to come up.  I checked and it was logging me into a KDE wayland session,
> as a default.

Wayland has been having problems with sddm for some time now - on some 
systems.  I have had to stay with sddm-0.18.1-r8 on this box to be able to 
start Wayland, or I end up with a black screen and a blinking cursor on the 
top left corner:

https://bugs.gentoo.org/913862
https://bugs.gentoo.org/915483


> I changed it to x11.  

Good, let's have some consistency!  :-)


> The first time, it logged in but
> nothing plasma showed up.  No panel at the bottom and a black screen for
> the background.  The only thing there was gkrellm.  I leave it there so
> I can tell if it is working, to some degree at least.  Otherwise, it is
> just a black screen. 

OK, partial progress at least.

What happens if you drop into a console and restart display-manager?  Will it 
load a full and functioning X11 plasma session?


> > kde-plasma/plasma-meta-6.1.0 is still in testing - I sync'ed earlier
> > today:
> > 
> > ~ $ eshowkw kde-plasma/plasma-meta
> > 
> > Keywords for kde-plasma/plasma-meta:
> >   |   |   u   |
> >   | 
> >   | a   a p s l r   a |   n   |
> >   | m   r h   p p   i o i s l m m | e u s | r
> >   | d a m p p c a x a o s 3 p 6 i | a s l | e
> >   | 6 r 6 p p 6 r 8 6 n c 9 h 8 p | p e o | p
> >   | 4 m 4 a c 4 c 6 4 g v 0 a k s | i d t | o
> > 
> > --+---+---+---
> > [I]5.27.11-r1 | + ~ + o o ~ o + o ~ ~ o o o o | 8 o 5 | gentoo
> > --+---+---+---
> > 
> >  6.1.0| ~ o o o o o o o o o o o o o o | 8 o 6 | gentoo
> 
> I see some qt stuff that is version 6.  KDE has gotten pretty
> confusing.  It depends on qt so much that KDE depends heavily on
> versions matching up somehow. 

Best you stick with a stable portage for now, at least until you get your GUI 
working.


> Is there a guide about installing the GUI parts, including KDE?  I found
> a Xorg guide.  I'm good all the way down to startx.  At that point,
> nothing.  I installed xterm just so startx should show some windows on
> the screen.  Nothing.  Monitor goes to sleep. 

I don't have a clear understanding of what you try, what results you obtain 
and what you change in your approach:

- display-manager with sddm, selecting a plasma X11 session?
- display-manager with sddm, selecting a plasma Wayland session?
- startx with xserver?
- startx with wayland?
- startx with something else?


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

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

[Dale]

Top posting for consistency.

I booted the Gentoo GUI media.  I opened a window just in case it
rebooted or something while I took a little nap.  The resolution is
1080P which is what I expected the monitor to run at.  When I got back
up a few minutes ago, the same window was there.  It ran for hours
without the monitor powering off.  I think this eliminates hardware. 

I found a Knoppix USB stick, for some reason Knoppix doesn't show up on
the Ventoy stick even tho it is there, and booted that stick.  I opened
a window the same as I did on the Gentoo media, just in case it reboots
or something.  It's already ran longer than my install did.  No problems
so far.  I'm not expecting any really given it ran fine on the Gentoo
media. 

I also found something new.  I can go in the BIOS menu and boot a USB
stick directly from that by just clicking on it.  O_O  WOW!!!  I said
the new BIOS had improved by a lot.  Can that thing wash dishes too??? 
LOL 

Still open to ideas if anyone has any.  If not, I may safe key files and
start over, and fix my partition layout too. 

This is progress.  Hardware is good.  :-D

Dale

:-)  :-) 


Dale wrote:
> Hi Mark,
>
> I think you have a good point.  I think I missed something.  Gentoo can
> be complicated to get going the first time with all the config options. 
> Once it is going tho, it goes.  I feel I missed either a config option
> in the guide or maybe some package is missing that isn't pulled in as a
> dependency.  I could have a wrong USE flag too. 
>
> Along your lines of thinking, I'll boot the Gentoo GUI image which has a
> GUI.  I tend not to use it but I can let it run and see what resolution
> it runs at.  If it fails to, then it may be hardware.  If it runs fine,
> something on my install in wonky.  I may test with Knoppix as well.  I'm
> pretty sure I have a EFI version lurking about here somewhere. 
>
> Those are good ideas.  No problem with top posting.  I top posted to
> make it easier for you to read my reply.  ;-) 
>
> Dale
>
> :-)  :-)
>
>
>
> Mark Knecht wrote:
>> Dale,
>>    Sorry for top posting but I'm travelling and responding on my phone.
>>
>>    I don't think this is you hardware and probably not KDE. It's
>> possibly some Gentoo-ish issue.
>>
>>    To test and get a KDE config I would boot a Kubuntu flash drive and
>> choose the 'Try it's option which installs nothing. If the GUI stays
>> up then look at drivers and general config. I run Kubuntu on 5
>> machines, all with different hardware, and I've never had a failure
>> that I did cause. I've installed Kubuntu on at least 20 machines over
>> the last 6 or 7 machines and every one has booted first time.
>>
>>    Give it a try. If it does fail then it's possibly something about
>> your hardware but if the machine works as well as you say then I would
>> buy you a cup of coffee if it's not Gentoo-bssed.
>>
>> Good luck,
>> Mark
>

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

[Wols Lists]

On 22/06/2024 21:04, Michael wrote:

This is the other info except nothing xorg there, just wayland.  See
below for more on that.


root@Gentoo-1 ~ # cat/home/dale/.local/share/sddm/wayland-session.log

I thought you said you were having a problem starting a X session, not
starting a Wayland session.  What desktop session are you selecting in your
SDDM?


This may well not be relevant, but I tried to get plasma on wayland 
running. I had it completely fail on me too.


Then I discovered that sddm needs X.

Even if you want to run wayland, you need X if you want sddm.

Cheers,
Wol

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

[Dale]

Hi Mark,

I think you have a good point.  I think I missed something.  Gentoo can
be complicated to get going the first time with all the config options. 
Once it is going tho, it goes.  I feel I missed either a config option
in the guide or maybe some package is missing that isn't pulled in as a
dependency.  I could have a wrong USE flag too. 

Along your lines of thinking, I'll boot the Gentoo GUI image which has a
GUI.  I tend not to use it but I can let it run and see what resolution
it runs at.  If it fails to, then it may be hardware.  If it runs fine,
something on my install in wonky.  I may test with Knoppix as well.  I'm
pretty sure I have a EFI version lurking about here somewhere. 

Those are good ideas.  No problem with top posting.  I top posted to
make it easier for you to read my reply.  ;-) 

Dale

:-)  :-)



Mark Knecht wrote:
> Dale,
>    Sorry for top posting but I'm travelling and responding on my phone.
>
>    I don't think this is you hardware and probably not KDE. It's
> possibly some Gentoo-ish issue.
>
>    To test and get a KDE config I would boot a Kubuntu flash drive and
> choose the 'Try it's option which installs nothing. If the GUI stays
> up then look at drivers and general config. I run Kubuntu on 5
> machines, all with different hardware, and I've never had a failure
> that I did cause. I've installed Kubuntu on at least 20 machines over
> the last 6 or 7 machines and every one has booted first time.
>
>    Give it a try. If it does fail then it's possibly something about
> your hardware but if the machine works as well as you say then I would
> buy you a cup of coffee if it's not Gentoo-bssed.
>
> Good luck,
> Mark

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

[Dale]

Michael wrote:
> On Saturday, 22 June 2024 19:13:42 BST Dale wrote:
>> Dale wrote:
>>> Michael wrote:
>
>> root@Gentoo-1 ~ # xrandr --verbose
>> Can't open display
>> root@Gentoo-1 ~ #
>>
>>
>> That's after I started display-manager but this time, it did nothing. 
>> The screen stayed on a console.  I did move the cable to another port
>> before booting up. 
> The xerver is not running.
>

How do I start it?  I did a /etc/init.d/  and I see
display-manager and xdm.  I been using display-manager.  I have sddm set
for display-manager.  Like this.


root@Gentoo-1 ~ # cat /etc/conf.d/xdm
# We always try and start X on a static VT. The various DMs normally default
# to using VT7. If you wish to use the xdm init script, then you should
ensure
# that the VT checked is the same VT your DM wants to use. We do this
check to
# ensure that you haven't accidentally configured something to run on the VT
# in your /etc/inittab file so that you don't get a dead keyboard.
CHECKVT=7

# What display manager do you use ?  [ xdm | gdm | sddm | gpe | lightdm
| entrance ]
# NOTE: If this is set in /etc/rc.conf, that setting will override this one.
DISPLAYMANAGER="sddm"

root@Gentoo-1 ~ #


>> This is the other info except nothing xorg there, just wayland.  See
>> below for more on that. 
>>
>>
>> root@Gentoo-1 ~ # cat /home/dale/.local/share/sddm/wayland-session.log
> I thought you said you were having a problem starting a X session, not 
> starting a Wayland session.  What desktop session are you selecting in your 
> SDDM?
>
> [snip ...]

That made me think.  After a few attempts, I got the sddm login screen
to come up.  I checked and it was logging me into a KDE wayland session,
as a default.  I changed it to x11.  The first time, it logged in but
nothing plasma showed up.  No panel at the bottom and a black screen for
the background.  The only thing there was gkrellm.  I leave it there so
I can tell if it is working, to some degree at least.  Otherwise, it is
just a black screen. 


>> dbus-daemon[2766]: [session uid=1000 pid=2766 pidfd=5] Successfully
>> activated service 'org.freedesktop.portal.Documents'
>> fuse: device not found, try 'modprobe fuse' first
>> error: fuse init failed: Can't mount path /run/user/1000/doc
> It can't find the path /run/user/1000/ for your user to be able to set up 
> desktop environment variables, user authentication and other desktop related 
> files.  Is your fs mounted fully?
>
> [snip ...]

As far as I know.  Here's some info.


root@Gentoo-1 ~ # mount
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs
(rw,nosuid,noexec,size=10240k,nr_inodes=8218422,mode=755)
devpts on /dev/pts type devpts
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noexec)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,mode=755)
/dev/nvme0n1p2 on / type ext4 (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs
(rw,nosuid,nodev,noexec,relatime)
none on /sys/fs/cgroup type cgroup2
(rw,nosuid,nodev,noexec,relatime,nsdelegate)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc
(rw,nosuid,nodev,noexec,relatime)
/dev/nvme0n1p3 on /var type ext4 (rw,relatime)
tmpfs on /var/tmp/portage type tmpfs (rw,noatime,size=41943040k)
tmpfs on /run/user/0 type tmpfs
(rw,nosuid,nodev,relatime,size=6576248k,nr_inodes=1644062,mode=700)
root@Gentoo-1 ~ #


>> No backend specified, automatically choosing drm
>> kwin_wayland_drm: No suitable DRM devices have been found
> [snip ...]
>
> It should have found and listed your video card here  and its drivers. 
>
> Can it not detect your card at all?  :-/
>

I have no idea.  The lspci command shows it. 

0a:00.0 VGA compatible controller: NVIDIA Corporation GP107GL [Quadro
P1000] (rev a1)


>> The Wayland connection broke. Did the Wayland compositor die?
>> The Wayland connection broke. Did the Wayland compositor die?
>> The Wayland connection broke. Did the Wayland compositor die?
>> qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
>> dbus-daemon[2766]: [session uid=1000 pid=2766 pidfd=5] Activated service
>> 'org.freedesktop.impl.portal.desktop.kde' failed: Process
>> org.freedesktop.impl.portal.desktop.kde exited with status 1
>>
>> (/usr/libexec/xdg-desktop-portal:2787): xdg-desktop-portal-WARNING **:
>> 03:20:14.512: Failed to create settings proxy: Error calling
>> StartServiceByName for org.freedesktop.impl.portal.desktop.kde: Process
>> org.freedesktop.impl.portal.desktop.kde exited with status 1
>>
>> (/usr/libexec/xdg-desktop-portal:2787): xdg-desktop-portal-WARNING **:
>> 03:20:14.512: No skeleton to export
>> kdeinit5: Communication error with launcher. Exiting!
>> dbus-daemon[2766]: [session u

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

[Mark Knecht]

Dale,
   Sorry for top posting but I'm travelling and responding on my phone.

   I don't think this is you hardware and probably not KDE. It's possibly
some Gentoo-ish issue.

   To test and get a KDE config I would boot a Kubuntu flash drive and
choose the 'Try it's option which installs nothing. If the GUI stays up
then look at drivers and general config. I run Kubuntu on 5 machines, all
with different hardware, and I've never had a failure that I did cause.
I've installed Kubuntu on at least 20 machines over the last 6 or 7
machines and every one has booted first time.

   Give it a try. If it does fail then it's possibly something about your
hardware but if the machine works as well as you say then I would buy you a
cup of coffee if it's not Gentoo-bssed.

Good luck,
Mark

On Fri, Jun 21, 2024, 12:03 PM Dale  wrote:

> Howdy,
>
> On my new rig, I've got everything installed.  I mostly been on a
> console which has worked without issue.  Now I've started using the GUI,
> KDE, and I'm having issues.  I wanted to run a command to generate a
> xorg.conf file and it generate all the needed info regarding hardware
> and such since the GUI wasn't working right without a config file.  The
> only one I found is the nvidia one.  It is minimal at best.  Anyway,
> when I try to start display-manager, with or without a config file, I
> get the sddm login.  I login and if I just let it sit there, after a
> minute or so, the monitor goes black.  It is still powered up but
> nothing on the screen at all.  I've moved the mouse and pressed buttons
> on the keyboard to make sure it isn't powering off but nothing.  Also,
> the resolution is pretty low too.  It should run in 1080P easily.  The
> card supports 4K I think.  The monitor tho has ran 1080P on my main rig
> before, for years I might add.
>
> I used tail -f to watch a few error logs.  I watched sddm, messages and
> Xorg.0.log.  The only thing that got added when the monitor went black
> was this:
>
>
>
> Jun 21 13:27:41 Gentoo-1 kernel: nvidia-modeset: WARNING: GPU:0: Unable
> to read EDID for display device DP-3
> Jun 21 13:29:01 Gentoo-1 kernel: nvidia-modeset: WARNING: GPU:0: Unable
> to read EDID for display device LG Electronics W2253 (DP-3)
> Jun 21 13:29:02 Gentoo-1 kernel: nvidia-modeset: WARNING: GPU:0: Unable
> to read EDID for display device DP-3
> Jun 21 13:29:03 Gentoo-1 kernel: nvidia-modeset: WARNING: GPU:0: Unable
> to read EDID for display device LG Electronics W2253 (DP-3)
>
>
> If I let it sit for a good while, it comes back on, sort of.  The plasma
> panel thing on the bottom, where the app menu, clock and all is, doesn't
> come back tho.  Also, the background is just black, no picture like
> usual.  The only thing that shows up is gkrellm.  I'm pretty sure plasma
> died.  I thought maybe it was heat, the fan isn't running on the video
> card or something.  Nvidia shows the card between 25 and 30C.  The fan
> nvidia says is at 34%.  If that is correct, then the fan is running and
> heat is not a issue.  Out comes the flashlight and a mirror.  Yep, fan
> spinning.  According to IR temp thingy, nothing even gets into the 90F
> area.  I think if it was heat, I'd see something getting hot with the IR
> temp thing.
>
> There is two versions of Nvidia driver for this card in the tree.  I've
> tried both, no change at all.  Screen goes black and after a while comes
> back but most of the desktop has crashed.
>
> By the way, I ran the tail command over ssh.  Sometimes when the monitor
> goes black, it doesn't come back.  I can use ssh to reboot and repeat tho.
>
> Did I miss something during the install?  Does the error above cause
> this problem?  If so, how do I fix it?  If you need info, just let me
> know the command to run.  I monitored all I could think of.  The one
> above is all I saw that showed a problem exists.  Given this rig is
> still in testing, I can reboot or anything else as needed.
>
> Thanks.
>
> Dale
>
> :-)  :-)
>
>

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

[Michael]

On Saturday, 22 June 2024 19:13:42 BST Dale wrote:
> Dale wrote:
> > Michael wrote:


> root@Gentoo-1 ~ # xrandr --verbose
> Can't open display
> root@Gentoo-1 ~ #
> 
> 
> That's after I started display-manager but this time, it did nothing. 
> The screen stayed on a console.  I did move the cable to another port
> before booting up. 

The xerver is not running.


> This is the other info except nothing xorg there, just wayland.  See
> below for more on that. 
> 
> 
> root@Gentoo-1 ~ # cat /home/dale/.local/share/sddm/wayland-session.log

I thought you said you were having a problem starting a X session, not 
starting a Wayland session.  What desktop session are you selecting in your 
SDDM?

[snip ...]
> dbus-daemon[2766]: [session uid=1000 pid=2766 pidfd=5] Successfully
> activated service 'org.freedesktop.portal.Documents'
> fuse: device not found, try 'modprobe fuse' first
> error: fuse init failed: Can't mount path /run/user/1000/doc

It can't find the path /run/user/1000/ for your user to be able to set up 
desktop environment variables, user authentication and other desktop related 
files.  Is your fs mounted fully?

[snip ...]
> No backend specified, automatically choosing drm
> kwin_wayland_drm: No suitable DRM devices have been found
[snip ...]

It should have found and listed your video card here  and its drivers. 

Can it not detect your card at all?  :-/


> The Wayland connection broke. Did the Wayland compositor die?
> The Wayland connection broke. Did the Wayland compositor die?
> The Wayland connection broke. Did the Wayland compositor die?
> qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
> dbus-daemon[2766]: [session uid=1000 pid=2766 pidfd=5] Activated service
> 'org.freedesktop.impl.portal.desktop.kde' failed: Process
> org.freedesktop.impl.portal.desktop.kde exited with status 1
> 
> (/usr/libexec/xdg-desktop-portal:2787): xdg-desktop-portal-WARNING **:
> 03:20:14.512: Failed to create settings proxy: Error calling
> StartServiceByName for org.freedesktop.impl.portal.desktop.kde: Process
> org.freedesktop.impl.portal.desktop.kde exited with status 1
> 
> (/usr/libexec/xdg-desktop-portal:2787): xdg-desktop-portal-WARNING **:
> 03:20:14.512: No skeleton to export
> kdeinit5: Communication error with launcher. Exiting!
> dbus-daemon[2766]: [session uid=1000 pid=2766 pidfd=5] Activating
> service name='org.freedesktop.impl.portal.desktop.kde' requested by
> ':1.5' (uid=1000 pid=2787 comm="/usr/libexec/xdg-desktop-portal"
> label="kernel")
> Error: could not determine $DISPLAY.
> Error: Can not contact kdeinit5!
> org.kde.startup: "kdeinit5_shutdown" () exited with code 255
> startplasma-wayland: Shutting down...
> startplasmacompositor: Shutting down...
> startplasmacompositor: Done.
> root@Gentoo-1 ~ #
> 
> 
> Since it complains about DRM.  Here's this.
> 
> 
> root@Gentoo-1 ~ # lsmod
> Module  Size  Used by
> nvidia_drm102400  0
> nvidia_modeset   1544192  1 nvidia_drm
> nvidia  59744256  1 nvidia_modeset
> root@Gentoo-1 ~ #

I have no experience with Nvidia to know what modules are needed.


> What's that about fuse???

It seems it can't find the fs containing the /run directory and it tries to 
launch fuse to probe & mount block devices.


> To add to this, this is a new video card.  It's a P1000, Nvidia of
> course.  Could it be a bad card that works to a point but then dies?  I
> got a older PCIe V2 card I'm going to try.  That was the card that was
> in during the early stages.  The P1000 was the one that got hung up by
> the post office and arrived days late.  I'm going to test the other
> slower card shortly, got to remember to downgrade nvidia-drivers to
> tho.  ;-)

You may want to walk through the Gentoo wiki for Nvidia to make sure you have 
all necessary drivers installed.  Then you may be more productive if you try 
to solve either Xorg, or Wayland desktop session problems separately.

If the problem is with your hardware, neither desktop session type will work.

 
> On the above wayland info, I recall some having issues with wayland. I
> tried to disable wayland by putting -wayland in make.conf and
> rebuilding.  Since it wanted to rebuild a lot, I removed everything GUI
> related from the world file and then ran --depclean to clean house. 
> Then I emerge everything I removed from the world file again, while I
> napped.  The output above could be old but may still provide a clue.  If
> I could figure out how to go back to KDE V5 instead of the new V6, I
> would, to eliminate a wayland issue if nothing else.  I removed
> everything from /etc/portage/package.keyword file but I think KDE V6 is
> stable now.  The odd part, right now, even sddm isn't coming up. 

kde-plasma/plasma-meta-6.1.0 is still in testing - I sync'ed earlier today:

~ $ eshowkw kde-plasma/plasma-meta
Keywords for kde-plasma/plasma-meta:
  |   |   u   |  
  | a   a p s l r   a

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

[Dale]

Howdy again.

Put in other card.  It's a NVS 510.  Anyway, output of some common log
files. 


root@Gentoo-1 ~ # tail -f /var/log/messages
Jun 22 13:47:29 Gentoo-1 kernel: elogind-daemon[1756]: New session 5 of
user root.
Jun 22 13:47:58 Gentoo-1 sddm-helper[2518]:
pam_unix(sddm-greeter:session): session opened for user sddm(uid=219) by
root(uid=0)
Jun 22 13:47:58 Gentoo-1 kernel: elogind-daemon[1756]: Existing logind
session ID 2 used by new audit session, ignoring.
Jun 22 13:47:58 Gentoo-1 kernel: elogind-daemon[1756]: New session c1 of
user sddm.


root@Gentoo-1 ~ # tail -f /var/log/sddm.log
[13:47:54.140] (II) DAEMON: Initializing...
[13:47:54.142] (II) DAEMON: Starting...
[13:47:54.142] (II) DAEMON: Logind interface found
[13:47:54.143] (II) DAEMON: Adding new display...
[13:47:54.144] (II) DAEMON: Loaded empty theme configuration
[13:47:54.144] (II) DAEMON: Xauthority path: "/run/sddm/xauth_jyVtSb"
[13:47:54.144] (II) DAEMON: Using VT 7
[13:47:54.144] (II) DAEMON: Display server starting...
[13:47:54.144] (II) DAEMON: Writing cookie to "/run/sddm/xauth_jyVtSb"
[13:47:54.144] (II) DAEMON: Running: /usr/bin/X -nolisten tcp
-background none -seat seat0 vt7 -auth /run/sddm/xauth_jyVtSb -noreset
-displayfd 16
[13:47:58.178] (II) DAEMON: Setting default cursor
[13:47:58.182] (II) DAEMON: Running display setup script 
"/usr/share/sddm/scripts/Xsetup"
[13:47:58.184] (II) DAEMON: Display server started.
[13:47:58.184] (II) DAEMON: Socket server starting...
[13:47:58.184] (II) DAEMON: Socket server started.
[13:47:58.184] (II) DAEMON: Loaded empty theme configuration
[13:47:58.184] (II) DAEMON: Greeter starting...
[13:47:58.190] (II) HELPER: [PAM] Starting...
[13:47:58.190] (II) HELPER: [PAM] Authenticating...
[13:47:58.190] (II) HELPER: [PAM] returning.
[13:47:58.202] (II) HELPER: Writing cookie to "/tmp/xauth_Tuevmm"
[13:47:58.202] (II) HELPER: Starting X11 session: ""
"/usr/bin/sddm-greeter --socket /tmp/sddm-:0-OtsNHf"
[13:47:58.203] (II) DAEMON: Greeter session started successfully
[13:47:58.247] (II) DAEMON: Message received from greeter: Connect



root@Gentoo-1 ~ # tail -f /var/log/Xorg.0.log
[    67.090] (II) event1  - Power Button: device removed
[    67.109] (II) event0  - Power Button: device removed
[    67.120] (II) event3  - DELL Dell USB Entry Keyboard: device removed
[    67.136] (II) event2  - Logitech USB Optical Mouse: device removed
[    67.163] (II) UnloadModule: "libinput"
[    67.163] (II) UnloadModule: "libinput"
[    67.164] (II) UnloadModule: "libinput"
[    67.164] (II) UnloadModule: "libinput"
[    67.444] (II) NVIDIA(GPU-0): Deleting GPU-0
[    67.450] (II) Server terminated successfully (0). Closing log file.


Basically, it behaves in the same way as the other card.  Does make the
monitor a suspect doesn't it? 

Thoughts?? 

Dale

:-)  :-) 

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

[Dale]

Dale wrote:
> Michael wrote:
>> On Friday, 21 June 2024 20:02:22 BST Dale wrote:
>>> Howdy,
>>>
>>> On my new rig, I've got everything installed.  I mostly been on a
>>> console which has worked without issue.  Now I've started using the GUI,
>>> KDE, and I'm having issues.  I wanted to run a command to generate a
>>> xorg.conf file and it generate all the needed info regarding hardware
>>> and such since the GUI wasn't working right without a config file.  The
>>> only one I found is the nvidia one.  It is minimal at best.  Anyway,
>>> when I try to start display-manager, with or without a config file, I
>>> get the sddm login.  I login and if I just let it sit there, after a
>>> minute or so, the monitor goes black.  It is still powered up but
>>> nothing on the screen at all.  I've moved the mouse and pressed buttons
>>> on the keyboard to make sure it isn't powering off but nothing.  Also,
>>> the resolution is pretty low too.  It should run in 1080P easily.  The
>>> card supports 4K I think.  The monitor tho has ran 1080P on my main rig
>>> before, for years I might add. 
>>>
>>> I used tail -f to watch a few error logs.  I watched sddm, messages and
>>> Xorg.0.log.  The only thing that got added when the monitor went black
>>> was this:
>>>
>>>
>>>
>>> Jun 21 13:27:41 Gentoo-1 kernel: nvidia-modeset: WARNING: GPU:0: Unable
>>> to read EDID for display device DP-3
>>> Jun 21 13:29:01 Gentoo-1 kernel: nvidia-modeset: WARNING: GPU:0: Unable
>>> to read EDID for display device LG Electronics W2253 (DP-3)
>>> Jun 21 13:29:02 Gentoo-1 kernel: nvidia-modeset: WARNING: GPU:0: Unable
>>> to read EDID for display device DP-3
>>> Jun 21 13:29:03 Gentoo-1 kernel: nvidia-modeset: WARNING: GPU:0: Unable
>>> to read EDID for display device LG Electronics W2253 (DP-3)
>> There are reports in the interwebs about LG monitors having buggy EDID 
>> tables:
>>
>> https://gist.github.com/kj800x/be3001c07c49fdb36970633b0bc6defb
> Reading that link, mine doesn't behave that way.  I see the services
> starting up during boot up just fine, small print but it's there, if I
> squint a bit.  Also, the sddm login screen shows up just fine.  I might
> add, this same monitor works just fine on the NAS box rig and the older
> Dell rig I have lurking about.  It also worked fine on my main rig years
> ago before I bought a larger monitor.  It is also the monitor I used on
> the TrueNAS system when I used it.  It also works fine with Knoppix and
> the official Gentoo GUI DVD image.  Basically, this monitor has never
> gave me any problems with any Linux based install until this new
> install.  That's what confuses me. 
>
>
>> What is connected at DP-1 and is the problem resolved if you change the port 
>> you connect your monitor on the card?
>>
>> Do you get an EDID table shown in your Xorg.0.log, or with xrandr --verbose?
>>
>> Does your ~/.local/share/sddm/xorg-session.log reveal anything more?
>>
>
> I'll check those next time I'm able to spend some time with it.  Right
> now, I'm picking basil to dehydrate and chop for later use.  Basil
> smells so good too.  Nice dark leaves.  I have five trays of it from one
> planter.  Now to pick planter two, if my back will allow it.  My back is
> angry despite meds.  :-@

OK.  It got to hot and my back is beyond angry now.  This is one of them.


root@Gentoo-1 ~ # xrandr --verbose
Can't open display
root@Gentoo-1 ~ #


That's after I started display-manager but this time, it did nothing. 
The screen stayed on a console.  I did move the cable to another port
before booting up. 

This is the other info except nothing xorg there, just wayland.  See
below for more on that. 


root@Gentoo-1 ~ # cat /home/dale/.local/share/sddm/wayland-session.log
org.kde.startup: not a reply org.freedesktop.locale1
QDBusMessage(type=Error, service="org.freedesktop.DBus", error
name="org.freedesktop.DBus.Error.ServiceUnknown", error message="The
name org.freedesktop.locale1 was not provided by any .service files",
signature="s", contents=("The name org.freedesktop.locale1 was not
provided by any .service files") )
dbus-daemon[2766]: [session uid=1000 pid=2766 pidfd=5] Activating
service name='org.kde.KSplash' requested by ':1.0' (uid=1000 pid=2767
comm="/usr/bin/startplasma-wayland" label="kernel")
dbus-daemon[2766]: [session uid=1000 pid=2766 pidfd=5] Activating
service name='org.freedesktop.portal.Desktop' requested by ':1.4'
(uid=1000 pid=2780 comm="/usr/bin/ksplashqml" label="kernel")
dbus-daemon[2766]: [session uid=1000 pid=2766 pidfd=5] Activating
service name='org.freedesktop.portal.Documents' requested by ':1.5'
(uid=1000 pid=2787 comm="/usr/libexec/xdg-desktop-portal" label="kernel")
dbus-daemon[2766]: [session uid=1000 pid=2766 pidfd=5] Activating
service name='org.freedesktop.impl.portal.PermissionStore' requested by
':1.6' (uid=1000 pid=2793 comm="/usr/libexec/xdg-document-portal"
label="kernel")
kdeinit5: preparing to launch '/usr/lib64/libexec/kf5/klauncher'
kdeinit5: Launched KLauncher, pid = 2799, 

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

[Dale]

Michael wrote:
> On Friday, 21 June 2024 20:02:22 BST Dale wrote:
>> Howdy,
>>
>> On my new rig, I've got everything installed.  I mostly been on a
>> console which has worked without issue.  Now I've started using the GUI,
>> KDE, and I'm having issues.  I wanted to run a command to generate a
>> xorg.conf file and it generate all the needed info regarding hardware
>> and such since the GUI wasn't working right without a config file.  The
>> only one I found is the nvidia one.  It is minimal at best.  Anyway,
>> when I try to start display-manager, with or without a config file, I
>> get the sddm login.  I login and if I just let it sit there, after a
>> minute or so, the monitor goes black.  It is still powered up but
>> nothing on the screen at all.  I've moved the mouse and pressed buttons
>> on the keyboard to make sure it isn't powering off but nothing.  Also,
>> the resolution is pretty low too.  It should run in 1080P easily.  The
>> card supports 4K I think.  The monitor tho has ran 1080P on my main rig
>> before, for years I might add. 
>>
>> I used tail -f to watch a few error logs.  I watched sddm, messages and
>> Xorg.0.log.  The only thing that got added when the monitor went black
>> was this:
>>
>>
>>
>> Jun 21 13:27:41 Gentoo-1 kernel: nvidia-modeset: WARNING: GPU:0: Unable
>> to read EDID for display device DP-3
>> Jun 21 13:29:01 Gentoo-1 kernel: nvidia-modeset: WARNING: GPU:0: Unable
>> to read EDID for display device LG Electronics W2253 (DP-3)
>> Jun 21 13:29:02 Gentoo-1 kernel: nvidia-modeset: WARNING: GPU:0: Unable
>> to read EDID for display device DP-3
>> Jun 21 13:29:03 Gentoo-1 kernel: nvidia-modeset: WARNING: GPU:0: Unable
>> to read EDID for display device LG Electronics W2253 (DP-3)
> There are reports in the interwebs about LG monitors having buggy EDID tables:
>
> https://gist.github.com/kj800x/be3001c07c49fdb36970633b0bc6defb

Reading that link, mine doesn't behave that way.  I see the services
starting up during boot up just fine, small print but it's there, if I
squint a bit.  Also, the sddm login screen shows up just fine.  I might
add, this same monitor works just fine on the NAS box rig and the older
Dell rig I have lurking about.  It also worked fine on my main rig years
ago before I bought a larger monitor.  It is also the monitor I used on
the TrueNAS system when I used it.  It also works fine with Knoppix and
the official Gentoo GUI DVD image.  Basically, this monitor has never
gave me any problems with any Linux based install until this new
install.  That's what confuses me. 


>
> What is connected at DP-1 and is the problem resolved if you change the port 
> you connect your monitor on the card?
>
> Do you get an EDID table shown in your Xorg.0.log, or with xrandr --verbose?
>
> Does your ~/.local/share/sddm/xorg-session.log reveal anything more?
>


I'll check those next time I'm able to spend some time with it.  Right
now, I'm picking basil to dehydrate and chop for later use.  Basil
smells so good too.  Nice dark leaves.  I have five trays of it from one
planter.  Now to pick planter two, if my back will allow it.  My back is
angry despite meds.  :-@


>> If I let it sit for a good while, it comes back on, sort of.  The plasma
>> panel thing on the bottom, where the app menu, clock and all is, doesn't
>> come back tho.  Also, the background is just black, no picture like
>> usual.  The only thing that shows up is gkrellm.  I'm pretty sure plasma
>> died.  I thought maybe it was heat, the fan isn't running on the video
>> card or something.  Nvidia shows the card between 25 and 30C.  The fan
>> nvidia says is at 34%.  If that is correct, then the fan is running and
>> heat is not a issue.  Out comes the flashlight and a mirror.  Yep, fan
>> spinning.  According to IR temp thingy, nothing even gets into the 90F
>> area.  I think if it was heat, I'd see something getting hot with the IR
>> temp thing. 
>>
>> There is two versions of Nvidia driver for this card in the tree.  I've
>> tried both, no change at all.  Screen goes black and after a while comes
>> back but most of the desktop has crashed. 
>>
>> By the way, I ran the tail command over ssh.  Sometimes when the monitor
>> goes black, it doesn't come back.  I can use ssh to reboot and repeat tho. 
>>
>> Did I miss something during the install?  Does the error above cause
>> this problem?  If so, how do I fix it?  If you need info, just let me
>> know the command to run.  I monitored all I could think of.  The one
>> above is all I saw that showed a problem exists.  Given this rig is
>> still in testing, I can reboot or anything else as needed. 
>>
>> Thanks.
>>
>> Dale
>>
>> :-)  :-) 
> If this is a buggy EDID, or monitor chip, you should be able to extract the 
> EDID table and store it as a firmware blob for the video card to load.


I may try to boot the Gentoo GUI DVD and see what entries it has for X
config files.  Do you know what files I should look for or is it the
same for that as a hard drive ba

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

[Jude DaShiell]

kde hasn't been accessible enough for screen reader users like me to
install it and use it.  That out of the way, could that be kde locking
your screen for you using a 1 minute time limit?  If so, maybe that can be
adjusted.  The gsettings app likely isn't on your machine so it won't help
for me to go through my braille notes and send you the two lines for
disabling screen locking with gsettings.


--
 Jude 
 "There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo.
 Please use in that order."
 Ed Howdershelt 1940.

On Sat, 22 Jun 2024, Michael wrote:

> On Friday, 21 June 2024 20:02:22 BST Dale wrote:
> > Howdy,
> >
> > On my new rig, I've got everything installed.  I mostly been on a
> > console which has worked without issue.  Now I've started using the GUI,
> > KDE, and I'm having issues.  I wanted to run a command to generate a
> > xorg.conf file and it generate all the needed info regarding hardware
> > and such since the GUI wasn't working right without a config file.  The
> > only one I found is the nvidia one.  It is minimal at best.  Anyway,
> > when I try to start display-manager, with or without a config file, I
> > get the sddm login.  I login and if I just let it sit there, after a
> > minute or so, the monitor goes black.  It is still powered up but
> > nothing on the screen at all.  I've moved the mouse and pressed buttons
> > on the keyboard to make sure it isn't powering off but nothing.  Also,
> > the resolution is pretty low too.  It should run in 1080P easily.  The
> > card supports 4K I think.  The monitor tho has ran 1080P on my main rig
> > before, for years I might add.
> >
> > I used tail -f to watch a few error logs.  I watched sddm, messages and
> > Xorg.0.log.  The only thing that got added when the monitor went black
> > was this:
> >
> >
> >
> > Jun 21 13:27:41 Gentoo-1 kernel: nvidia-modeset: WARNING: GPU:0: Unable
> > to read EDID for display device DP-3
> > Jun 21 13:29:01 Gentoo-1 kernel: nvidia-modeset: WARNING: GPU:0: Unable
> > to read EDID for display device LG Electronics W2253 (DP-3)
> > Jun 21 13:29:02 Gentoo-1 kernel: nvidia-modeset: WARNING: GPU:0: Unable
> > to read EDID for display device DP-3
> > Jun 21 13:29:03 Gentoo-1 kernel: nvidia-modeset: WARNING: GPU:0: Unable
> > to read EDID for display device LG Electronics W2253 (DP-3)
>
> There are reports in the interwebs about LG monitors having buggy EDID tables:
>
> https://gist.github.com/kj800x/be3001c07c49fdb36970633b0bc6defb
>
> What is connected at DP-1 and is the problem resolved if you change the port
> you connect your monitor on the card?
>
> Do you get an EDID table shown in your Xorg.0.log, or with xrandr --verbose?
>
> Does your ~/.local/share/sddm/xorg-session.log reveal anything more?
>
>
> > If I let it sit for a good while, it comes back on, sort of.  The plasma
> > panel thing on the bottom, where the app menu, clock and all is, doesn't
> > come back tho.  Also, the background is just black, no picture like
> > usual.  The only thing that shows up is gkrellm.  I'm pretty sure plasma
> > died.  I thought maybe it was heat, the fan isn't running on the video
> > card or something.  Nvidia shows the card between 25 and 30C.  The fan
> > nvidia says is at 34%.  If that is correct, then the fan is running and
> > heat is not a issue.  Out comes the flashlight and a mirror.  Yep, fan
> > spinning.  According to IR temp thingy, nothing even gets into the 90F
> > area.  I think if it was heat, I'd see something getting hot with the IR
> > temp thing.
> >
> > There is two versions of Nvidia driver for this card in the tree.  I've
> > tried both, no change at all.  Screen goes black and after a while comes
> > back but most of the desktop has crashed.
> >
> > By the way, I ran the tail command over ssh.  Sometimes when the monitor
> > goes black, it doesn't come back.  I can use ssh to reboot and repeat tho.
> >
> > Did I miss something during the install?  Does the error above cause
> > this problem?  If so, how do I fix it?  If you need info, just let me
> > know the command to run.  I monitored all I could think of.  The one
> > above is all I saw that showed a problem exists.  Given this rig is
> > still in testing, I can reboot or anything else as needed.
> >
> > Thanks.
> >
> > Dale
> >
> > :-)  :-)
>
> If this is a buggy EDID, or monitor chip, you should be able to extract the
> EDID table and store it as a firmware blob for the video card to load.

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

[Michael]

On Friday, 21 June 2024 20:02:22 BST Dale wrote:
> Howdy,
> 
> On my new rig, I've got everything installed.  I mostly been on a
> console which has worked without issue.  Now I've started using the GUI,
> KDE, and I'm having issues.  I wanted to run a command to generate a
> xorg.conf file and it generate all the needed info regarding hardware
> and such since the GUI wasn't working right without a config file.  The
> only one I found is the nvidia one.  It is minimal at best.  Anyway,
> when I try to start display-manager, with or without a config file, I
> get the sddm login.  I login and if I just let it sit there, after a
> minute or so, the monitor goes black.  It is still powered up but
> nothing on the screen at all.  I've moved the mouse and pressed buttons
> on the keyboard to make sure it isn't powering off but nothing.  Also,
> the resolution is pretty low too.  It should run in 1080P easily.  The
> card supports 4K I think.  The monitor tho has ran 1080P on my main rig
> before, for years I might add. 
> 
> I used tail -f to watch a few error logs.  I watched sddm, messages and
> Xorg.0.log.  The only thing that got added when the monitor went black
> was this:
> 
> 
> 
> Jun 21 13:27:41 Gentoo-1 kernel: nvidia-modeset: WARNING: GPU:0: Unable
> to read EDID for display device DP-3
> Jun 21 13:29:01 Gentoo-1 kernel: nvidia-modeset: WARNING: GPU:0: Unable
> to read EDID for display device LG Electronics W2253 (DP-3)
> Jun 21 13:29:02 Gentoo-1 kernel: nvidia-modeset: WARNING: GPU:0: Unable
> to read EDID for display device DP-3
> Jun 21 13:29:03 Gentoo-1 kernel: nvidia-modeset: WARNING: GPU:0: Unable
> to read EDID for display device LG Electronics W2253 (DP-3)

There are reports in the interwebs about LG monitors having buggy EDID tables:

https://gist.github.com/kj800x/be3001c07c49fdb36970633b0bc6defb

What is connected at DP-1 and is the problem resolved if you change the port 
you connect your monitor on the card?

Do you get an EDID table shown in your Xorg.0.log, or with xrandr --verbose?

Does your ~/.local/share/sddm/xorg-session.log reveal anything more?


> If I let it sit for a good while, it comes back on, sort of.  The plasma
> panel thing on the bottom, where the app menu, clock and all is, doesn't
> come back tho.  Also, the background is just black, no picture like
> usual.  The only thing that shows up is gkrellm.  I'm pretty sure plasma
> died.  I thought maybe it was heat, the fan isn't running on the video
> card or something.  Nvidia shows the card between 25 and 30C.  The fan
> nvidia says is at 34%.  If that is correct, then the fan is running and
> heat is not a issue.  Out comes the flashlight and a mirror.  Yep, fan
> spinning.  According to IR temp thingy, nothing even gets into the 90F
> area.  I think if it was heat, I'd see something getting hot with the IR
> temp thing. 
> 
> There is two versions of Nvidia driver for this card in the tree.  I've
> tried both, no change at all.  Screen goes black and after a while comes
> back but most of the desktop has crashed. 
> 
> By the way, I ran the tail command over ssh.  Sometimes when the monitor
> goes black, it doesn't come back.  I can use ssh to reboot and repeat tho. 
> 
> Did I miss something during the install?  Does the error above cause
> this problem?  If so, how do I fix it?  If you need info, just let me
> know the command to run.  I monitored all I could think of.  The one
> above is all I saw that showed a problem exists.  Given this rig is
> still in testing, I can reboot or anything else as needed. 
> 
> Thanks.
> 
> Dale
> 
> :-)  :-) 

If this is a buggy EDID, or monitor chip, you should be able to extract the 
EDID table and store it as a firmware blob for the video card to load.

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