Getting hold of help
Every pro geek was once a newbie, so don’t be afraid to be baffled.
Things do go wrong, and in general the Linux community is friendly and willing to help. But there’s a lot you can do to help them help you. First, remember this is free software. You didn’t pay for roundthe-clock support, so be grateful if someone tries to help you. Rants of the variety “Linux isn’t ready for primetime” are generally not welcome or useful.
That may be your opinion or experience, but hundreds of thousands of happy desktop Linux users probably say otherwise. Penning those rants and then deleting them is a good way to calm down (and not feel so foolish the next morning). Part of the joy of Linux is solving problems, although in the beginning it’s hard to know where to start. For Elementary OS, its support site ( https://elementary.io/
support) is a good start.
Conveniently brushing aside installation problems, your first challenge might be to get wireless working (you may be one of the lucky ones with a chipset that works off the bat, in which case spare a thought for the less fortunate). Most of the time wireless woes stem from the fact that the code which runs on the wireless radio chips is proprietary and can’t be redistributed. This doesn’t mean it’s in any way illegal for you obtain it yourself.
Solve your wireless woes
The first step is to find out which chipset we’re dealing with. The make and model number aren’t necessarily the best guides here, since manufacturers have a habit of changing hardware between revisions. The Terminal lspci command tells us all about any PCI devices connected to our system
(there’s lsusb for USB devices). That command generates lots of output, so we’ll filter it using grep , so we only hear about network devices. Open the Terminal and run: lspci -nnk | grep -iA2 net The -nn part tells lspci to give vendor and device codes, which look like 1814:3090 and uniquely identify PCI hardware. The k tells it to give information about any kernel drivers that can handle the device. We “pipe” (with the | symbol) the output to grep , to restrict it to entries only containing the text
net . Use man grep to find out more about grep 's many switches. You’ll probably see information for both your wired and wireless interfaces, but it should be reasonably clear which is which. In our case, the relevant output was 02:00.0 Network controller [0280]: Ralink corp. RT3090 Wireless 802.11n 1T/1R PCIe [1814:3090]
Subsystem: Lite-On Communications Inc RT3090 Wireless 802.11n 1T/1R PCIe [11ad:6622]
Kernel driver in use: rt2800pci
This card works out of the box, but if it didn’t we’d be diligently searching (on the Ubuntu and the Elementary fora), including in our search terms the driver ( rt2800pci ) and the device codes ( 1814:3090 ). A lack of available firmware won’t stop the driver being loaded, (though it will stop it doing anything useful). If the output for your wireless device doesn’t report a kernel driver in use, it’s possible you have a different problem. Hopefully one that the above investigation helps you to solve, a good place to start is the Wireless hardware section of the Ubuntu Wiki at https://help.ubuntu.com/ community/HardwareSupportComponents WirelessNetworkCardsRealTek.
Find help… fast
Recalcitrant wireless drivers are far from the only thing that impedes people’s first steps with Linux, but whatever your problem there are a few general things you should do before seeking community assistance. Linux may not be as popular as other desktop operating systems, but it’s popular enough that someone else has already run into the same issue.
First, spend some time searching forums and the web for the particular error message or the hardware that may be causing it. Second, don’t blindly go copying and pasting terminal commands from random corners of the Internet. Error messages can be red herrings: the same one may turn out to be catastrophic in one situation but harmless in another. Trying to solve a problem that doesn’t exist instead of the one at hand generally results in two or more problems. So don’t follow someone else’s solution unless you’re sure you’re on the same page and check release versions.
Do read support threads in their entirety. There’s unfortunately evolved a special class of forum poster who will post all kinds of convoluted ‘solutions’ to a problem. Sometimes this is well-meaning, and sometimes the given solutions may even work, but often it’s just someone wanting to show off their “mad” Linux “skillz” and belittle or confuse the original poster. Said skillz turn out not to pay the bills when, for example, the proffered solution breaks down after a system update. Unless you’re trying to do something hideously complicated, or something went hideously wrong, the solution you seek ought to be fairly straightforward. Check the date on any posts you come across. A solution from 2003 is unlikely to still apply today.
Unfortunately, some of the most common beginner problems are the scary ones: the system dumping you at the GRUB rescue shell, or flashing up some text quicker than any human can read and then dumping you at a black screen.
SuperGrub2Disc ( www.supergrubdisk.org) is a rescue disc that might be able to help with bootloader troubles. The dreaded black screen is usually indicative of misbehaving graphics drivers (almost always the Nvidia proprietary drivers, but sometimes old or quirky hardware is to blame). If you’re lucky you should be able to login by switching to a console (as opposed to the graphical display manager) by pressing Ctrl+Alt+F1 . From here you should study the X.org file with less /var/log/Xorg.0.log for any clues (scroll through it with the Up and Down arrows, and press Q to quit).
“Don’t blindly go copying and pasting terminal commands from random parts of the Internet”
More generally, you can look at the whole system journal for the current boot with journalctl -b . If something went wrong and you had to reboot, then you can see messages from the previous boot with journalctl -b -1 . The system log receives all kind of information: some of it makes for interesting reading, but most of it is the computer equivalent of parochial chatter. Journal entries are stratified into eight levels, numbered zero to seven (programmers like to start enumerating things at zero, much to the chagrin of normal people), where zero is the most severe ("emergency") and seven the least ("debug”, programmers like to enumerate things backwards too). Most log entries above level three ("error") won’t relate to things that went wrong.
To see only the more important messages use the -p (priority) switch, for example journalctl -b -p 3 . Information you find there might at least help you or generous forum elves to localise the problem. Don’t be afraid to ask for help, but be considerate when you do. This stickied post on the Ubuntu Forums covers the basics: https://ubuntuforums.org/ showthread.php?t=1422475.