Talk:General troubleshooting
Blacklisting radeon module
- Moved from Talk:Beginners' guide. -- Alad (talk) 14:04, 15 August 2015 (UTC)
Installed Arch on my laptop, during pacstrap the screen went blank, pressing SPACE, CTL+C ... didn't helped only modprobe.blacklist=radeon enabled me to go through the whole installation process. My graphic card is ATI M96 aka Mobility Radeon HD 4650. I believe this info and similar problems should be added to the beginner's guide on a Installation's Issues Troubleshooting section. I believe this is important enough to dual post and separate it from the Removing "Kernel modules" talk. p.s. I may add that this is my first desktop Linux experience--Dhead (talk) 06:20, 4 March 2013 (UTC)
The beginners' guide should not contain hardware-specific info, if the issue is common enough links can be added to Beginners'_guide#Troubleshooting_boot_problems.-- Alad (talk) 14:40, 27 December 2014 (UTC)
Expansion needed
I didn't realize the only page linking here was the Beginners' Guide - thanks for catching my blunder Kynikos. I got rid of that link because I figured this page could only be frustrating for beginners looking for general troubleshooting help. I'm having trouble pinning down the scope - can we have a brainstorm for what kind of content could go in here? | Emiralle 14:03, 11 October 2011 (EDT)
- I have a bunch of random stuff that might fit in here or in General Recommendations or in the respective articles e.g. about xorg-server. Would e.g. [1] (seems what you mean in your first bullet-point) or [2] fit here? -- Karol 14:41, 11 October 2011 (EDT)
- I think that finding troubleshooting tips that are really "general" can be quite difficult, usually the purpose of troubleshooting itself is trying to narrow the field of possible causes of the problem in order to find the specific cause and then solve it. That's why it's much more likely that a troubleshooting procedure can belong much more easily to an article treating a specific piece of software rather than here. -- Kynikos 15:05, 13 October 2011 (EDT)
- I think some of these are close to the mark, but I'm not sure I believe in this article anymore. General troubleshooting is great in a paper encyclopedia where you don't have a powerful search function, but I have a hard time not stepping on other articles' toes here. I say move General Troubleshooting#Finding startup files to FAQ, and move General Troubleshooting#Single user mode either to FAQ or merge with Runlevels. Maybe this page could redirect to FAQ since it's a similar idea and might be helpful. | Emiralle 16:15, 13 October 2011 (EDT)
- I think that finding troubleshooting tips that are really "general" can be quite difficult, usually the purpose of troubleshooting itself is trying to narrow the field of possible causes of the problem in order to find the specific cause and then solve it. That's why it's much more likely that a troubleshooting procedure can belong much more easily to an article treating a specific piece of software rather than here. -- Kynikos 15:05, 13 October 2011 (EDT)
To start things off:
- How about something regarding programs unable to source files or otherwise not working when they don't have the right permissions? It's not particular to a given application, though it's quite related to Users and groups. | Emiralle 14:03, 11 October 2011 (EDT)
- Something general about missing or conflicting kernel modules/drivers/firmware and how to go about diagnosing such issues. | Emiralle 14:03, 11 October 2011 (EDT)
- Um... also this one would probably be more related to Kernel modules. -- Kynikos 15:05, 13 October 2011 (EDT)
- Bring here something from the FAQ? -- Kynikos 15:05, 13 October 2011 (EDT)
- FAQ-ize the two sections of this article, move them to FAQ and delete this article? (You requested brainstorming, after all :P ) -- Kynikos 15:05, 13 October 2011 (EDT)
- Maybe this page could be a FAQ-like list of links to help requests in the forum which have found a solution? -- Kynikos 15:05, 13 October 2011 (EDT)
- Focus on the concept of general Problem Solving Procedures instead of general Troubleshooting? For example list suggestions like "If a GUI application crashes, try to look at its output in tty1 (or the virtual console where you started your wm)". -- Kynikos 15:05, 13 October 2011 (EDT)
- I vote for this idea. We can make this page as "General" as it can. Do not add solution of a particular application. And consider "non-programmer" as the target reader. What request a programming skill or knowledge should go to Step By Step Debugging Guide. We can add info about
- * Search from google
- * Recall what changed
- * Downgrade package
- * Search mailing list
- * Create a new user for a clean environment
- And so on.
- We can add step by step introduction on how to narrow the field of possible causes of the problem . For reference this artical :[3] -- Fengchao 23:52, 1 February 2012 (EST)
- These are certainly good ideas, however I'd like also to point you to ArchWiki:Reports#System_recovery_category where we briefly discussed about merging this article with Step By Step Debugging Guide, as it could be the easiest solution. -- Kynikos 09:05, 4 February 2012 (EST)
- More ideas...
Related article names
Currently there's several "debugging" articles:
- Step_By_Step_Debugging_Guide in Category:Development
- Debug_-_Getting_Traces in Category:Package development
- Boot_debugging in Category:Boot process and Category:System recovery
General troubleshooting is in Category:System administration and Category:System recovery.
Suggestions:
- one category, existing such as Category:System recovery, or create a new one such as Category:Troubleshooting;
- sub-articles such as
Troubleshooting/Traces, Troubleshooting/Step by step, Troubleshooting/Boot,
-- Alad (talk) 09:44, 10 August 2014 (UTC)
- What would be the scope of the main Troubleshooting page? Would General troubleshooting be moved to use that title?
- Step_By_Step_Debugging_Guide and Debug_-_Getting_Traces should be merged into one article, the introductions mention the same purpose. Alternatively, the info for C{,++} programs could be split from info for "others"; this might had been the intention of Debug - Getting Traces.
- -- Lahwaacz (talk) 09:59, 10 August 2014 (UTC)
- No details are implied in the title, so adding "General" to it is redundant IMO. However, only the four first sections (Attention to detail ... Additional support) of General troubleshooting are "general" - see the discussion above for more suggestions on that regard. The others handle specific issues, which I'm unsure belong there.
- Regarding Step_By_Step_Debugging_Guide, as the "others" section is limited in scope, I would agree for merging it with Debug - Getting Traces. -- Alad (talk) 22:03, 12 August 2014 (UTC)
- To me, simple "Troubleshooting" seems too vague, I don't mind including some word in the title specifying that the content is generic. Naming the page "Troubleshooting" might encourage addition of too specific sections similar to General_troubleshooting#Session_permissions. IMO "General troubleshooting" or "Debugging guide" are good titles. -- Lahwaacz (talk) 21:04, 18 August 2014 (UTC)
Introduction
- Moved from Talk:Beginners' guide. -- Alad (talk) 12:41, 25 June 2015 (UTC)
Apart from that there should be a section at the very beginning explaining how to troubleshoot your own problems. Learning dmesg -HLkd and journalctl -b etc were helpful tools for me. I also appreciated learning lsblk, lsmod, ls etc from the various articles, but a quick over view of these helpful commands on this page would help newbies like myself. Victoroux (talk) 14:01, 7 June 2013 (UTC)
- Sorry! Just reading over again, and realizing that I could've saved a tonne of time if I knew the problem of "a bunch of white letters clustered on my screen" was an error I could check. It usually happened when the firmware didn't support something (in my case) but telling the user what he can do when this happens helps ease the wiki hopping. I finally, finally figured out how to debug most of my own problems and I think that is the number one thing this guide should do. No offense, but it would also lessen the load on the "newbie corner" on the forums (not that I know it's loaded or not, but less is better, right?). That way no matter what's written in the guide, if it's incorrect or leads to a bad result, the user can figure out why and what to do.. Victoroux (talk) 14:05, 7 June 2013 (UTC)
- Another useful article that could be mentioned (rebooting from black screens, yay!) Victoroux (talk) 00:27, 8 June 2013 (UTC)
- Regarding your second point, General troubleshooting is in Related articles - it could be expanded there. --Alad (talk) 14:25, 2 July 2014 (UTC)
"Single user mode" section is outdated
The section suggests changing the runlevel.
It could be replaced with a simple reference to man systemd.target
Head on a Stick (talk) 22:43, 16 November 2014 (UTC)
user buses
How is [4] related to session permissions? -- Alad (talk) 12:43, 11 January 2016 (UTC)
Microcode updates
Re: this thread on Reddit and this edit, microcode updates have broken at least one attempt to run Arch. While the recommendation is to make sure they're installed and applied, in this specific instance things exploded, so it might be worthwhile to at least note that microcode updates may break things once in a while. Are you sure this should be left out? (Pinging Lahwaacz) DragoonAethis (talk) 22:38, 29 August 2017 (UTC)
- The reddit thread, which was the source for your edit, does not discuss any details regarding the system which was supposed to be broken by microcode updates, so it's impossible to tell if the concern is valid or not. I see it as just one isolated case out of many. What percentage of these i3-7100U CPUs have this problem? What's Intel's position on this? -- Lahwaacz (talk) 23:30, 29 August 2017 (UTC)
- Alright, I can't find much about this issue anywhere, so this is fine as it is now. -- DragoonAethis (talk) 11:55, 5 September 2017 (UTC)
Cleaning up the page
As you might have noticed, I rewrote some sections already. This will probably be something more major because it needs some clean-up. Current problems:
- General troubleshooting#General procedures looks like it prepares the reader to ask for support. This should not be the case and the reader should try it for themselves first and when all else fails it is time to get some support. It should instead be really general troubleshooting advice.
- The assortment of "general" troubleshooting seems pretty random. General troubleshooting#Message: "file: could not find any magic files!", I have never seen this problem so far and I am over a year now in the Arch IRC channels providing support for others. There are waaaay more common issues. I may move or just remove this section.
- This is a perfect place to ask an important question: What even is the scope of the page? What is "general" and what is not? I would argue that the thing above is not general.
- In my opinion "General" means that it is applicable in many cases.
- Some sections already provide solutions for specific problems. The instructions should be a bit more general to describe how to debug the specific component.
As an example, "Boot problems" can literally be anything. It is alright to list some specific solutions but it should tell the reader, as this is the general troubleshooting page, how to properly troubleshoot this. E.g starting with the firmware/BIOS, does it even reach the bootloader? If it is stuck loading the kernel, it may make sense to remove the quiet
parameter and maybe even add loglevel=7
if there is still not enough output to determine what went wrong.
This is a better way than stating random solutions for the reader to try, in my opinion. Tell me what you think.