On Tue, 17 Mar 2020 at 17:14, home user <mattisonw@xxxxxxxxxxx> wrote:
(On Tue, 17 Mar 2020 at 06:17, George wrote)
> You need to rule out hardware.
Impossible.
Good testing can make a really good case that it's not the hardware (nor
the driver).
Complete testing, 100% ruling out, impossible.
2 or 3 9's should do.
I must live with practical limits same as everyone else.
There are some simple tests that you don't appear to have done.
It can be very helpful to have another system that can connect to the
"patient" system by ssh to examine logs and do proper shutdown/
restart. I've often done this with a borrowed laptop by booting a
live linux distro.
I've installed linux on many dozens of older unloved and unwanted
PC's. This did give me the advantage of an ample supply of spare
system boards, graphics and network cards, and power supplies for
troubleshooting.
Some of these discards had hardware problems like bulging capacitors
or smoked power supplies and were beyond economical repair, most
were being discarded because they couldn't handle newer windows
versions. Some needed a new disk drive, could only use the onboard
graphics or required addition of a network card, and some required
building the kernel with nonstandard options, but I never saw a case
were linux failed to work properly that wasn't caused by a hardware
problem. These days, a bit of time with Google can save hours of
testing.
> To narrow the problem down to your graphics card
> and associated drivers, you need to remove the card
> and use onboard graphics.
If I....
1. shut down,
2. then disconnect the monitors,
3. then remove the graphics card,
4. then re-connect the monitors,
Disconnect external drives and other devices if present -- you
want the simplest possible configuration, then you can things
back until problems start.
Reconnect only one monitor.
5. then power-up,
Boot a Live distro because it should handle the onboard graphics.
If the first attempt fails, check the release notes for suggestions of
kernel options. You will have to edit the boot options:
remove "quiet" and add "noquiet norhgb"
If this works, shut down and put back the graphics card.
The Live distro uses nouveau. It it has problems, try
editing the boot options:
remove "quiet" and add "noquiet norhgb nouveau.modeset=0"
6. then log in and try to duplicate the problem,
is that all? The graphics driver (the one that came from rmpfusion) is
still there, and my impression is that getting those out will be messy,
time-consuming, and risky. Then later I'd have to put them back, also
messy, time-consuming, and risky. If the steps above (If I.... 1
through 6) are sufficient, I'll give it a try.
Live distros are excellent for this sort of testing as they try to include
drivers for a range of configurations.
Here are details of two of the freeze problems that I remember
experiencing with Fedora Live:
A.
1. I launched Firefox.
2. I started entering the URL
"lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx/"
into the address bar. The freeze-up happened before I could finish
entering that URL.
B.
1. I launched Firefox.
2. I entered the URL
"lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx/"
into the address bar.
3. The page was properly displayed.
4. I selected this a thread: this thread ("rescue mode needs rescuing!").
5. The page was properly displayed.
6. I scrolled down. The freeze-up happened.
Now I've had *no* problems when booting from the hard drive, not today,
not recently, not in quite a while.
This does not prove the graphics card and driver are not at fault. But
it's a very good case. I think Samuel was implying the same thing on
Sunday...
> But unless you're seeing a really obvious problem,
> it's unlikely to be failing.
> "Seems fine" is not a diagnostic test.
Well, I don't say that out of the blue; it's not a lazy or gut thing.
> Your symptoms suggest a hardware/ driver problem.
Then shouldn't I experience problems (more and worse) when I boot from
the hard drive?
Newer distros often enable "features" that older kernels and drivers ignored.
Older distros may have workarounds that get lost or broken in recent kernels.
Workarounds added to recent kernels for issues with newer hardware
sometimes cause problems with older hardware.
> If you have Windows 8 or10 installed, it has a
> "fast boot" mode that bypasses the normal boot
> process (using "hibernation"):...
...
> Blame Windows. There have been instances where an OS
> loads firmware that prevents normal reboot until the
> system has been powered off.
I have windows-7.
I looked at that this morning. I did see a fast boot setting in the
Advanced Mode, Boot screen. It was enabled. I switched it to
disabled. It will take many boots before I have high confidence that
that fixed things. One new instance of "one of them moods" immediately
shows the change probably did not fix things. It's impossible to
*prove* the fix worked.
I don't think it is the cause of all the problems, but getting rid of it may
make it easier to sort out other issues.
What else did windows do to my bios? Wait. Do I really want to know?
See links in my previous response.
George N. White III
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
