When asking questions in the forum, it would be most helpful to all members if you provide some basic information.
When you provide info from the terminal, usually from your logs, you have to format it so the content is easy to read.
First copy and paste your text/terminal/code into the post
Then select the text/code and click the post edit toolbar button </> .
Another handy way is to use 3 backticks ` at the start and 3 more at the end of the text like this:
Paste text or code here
Please open a terminal and type the commands as below. (Do Not type the $)
First no matter what the problem, provide the hardware and software with inxi -Fxxxza --no-host
inxi -Fxxxza --no-host
System: Kernel: 5.3.18-1-MANJARO x86_64 bits: 64 compiler: gcc v: 9.2.0 parameters: BOOT_IMAGE=/boot/vmlinuz-5.3-x86_64 root=UUID=84ef5c14-5b87-41fa-b405-b9b5988c56dd rw quiet udev.log_priority=3 Desktop: Gnome 3.34.3 wm: gnome-shell dm: GDM 3.34.1 Distro: Manjaro Linux Machine: Type: Vmware System: VMware product: VMware7,1 v: N/A serial: <root required> Chassis: No Enclosure type: 1 serial: <root required> Mobo: Intel model: 440BX Desktop Reference Platform serial: <root required> UEFI: VMware v: VMW71.00V.14410784.B64.1908150010 date: 08/15/2019 CPU: Topology: 2x Single Core model: Intel Core i7-7700K bits: 64 type: SMP arch: Kaby Lake family: 6 model-id: 9E (158) stepping: 9 microcode: CA L2 cache: 16.0 MiB flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 bogomips: 16803 Speed: 4199 MHz min/max: N/A Core speeds (MHz): 1: 4199 2: 4199 Vulnerabilities: Type: itlb_multihit status: KVM: Vulnerable Type: l1tf mitigation: PTE Inversion Type: mds mitigation: Clear CPU buffers; SMT Host state unknown Type: meltdown mitigation: PTI Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl and seccomp Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling Type: tsx_async_abort status: Not affected Graphics: Device-1: VMware SVGA II Adapter driver: vmwgfx v: 18.104.22.168 bus ID: 00:0f.0 chip ID: 15ad:0405 Display: x11 server: X.org 1.20.7 driver: vmwgfx compositor: gnome-shell resolution: <xdpyinfo missing> OpenGL: renderer: llvmpipe (LLVM 9.0.1 256 bits) v: 3.3 Mesa 19.3.4 compat-v: 3.1 direct render: Yes Audio: Device-1: Ensoniq ES1371/ES1373 / Creative Labs CT2518 driver: snd_ens1371 v: kernel bus ID: 02:02.0 chip ID: 1274:1371 Sound Server: ALSA v: k5.3.18-1-MANJARO Network: Device-1: Intel 82371AB/EB/MB PIIX4 ACPI vendor: VMware Virtual Machine type: network bridge driver: N/A port: 2150 bus ID: 00:07.3 chip ID: 8086:7113 Device-2: Intel 82545EM Gigabit Ethernet vendor: VMware PRO/1000 MT Single Port driver: e1000 v: 7.3.21-k8-NAPI port: 1040 bus ID: 02:01.0 chip ID: 8086:100f IF: ens33 state: up speed: 1000 Mbps duplex: full mac: 00:0c:29:40:f5:37 Drives: Local Storage: total: 25.00 GiB used: 283.45 GiB (1133.8%) ID-1: /dev/sda vendor: VMware model: Virtual S size: 25.00 GiB block size: physical: 512 B logical: 512 B serial: N/A rev: 1.0 scheme: GPT Partition: ID-1: / raw size: 24.70 GiB size: 24.19 GiB (97.92%) used: 8.51 GiB (35.2%) fs: ext4 dev: /dev/sda2 Sensors: Message: No sensors data was found. Is sensors configured? Info: Processes: 195 Uptime: 4m Memory: 2.90 GiB used: 1.30 GiB (44.9%) Init: systemd v: 242 Compilers: gcc: 9.2.0 Shell: bash v: 5.0.11 running in: gnome-terminal inxi: 3.0.37
Two basic commands used to find errors
This command is used to get hardware boot stopping errors and some other things.
This command is used for all kinds of errors and for trouble shooting.
Non-booting sort of errors , this means the user never gets to a login prompt or a prompt of any kind.
** If this is not your situation then skip this and start with Trouble Shooting below. **
If you end up in a non boot situation you still need to get to a command prompt and do some trouble shooting.
Here are three things to try.
First try to get to another TTY (command terminal) with the key combination. CTLALT+F2. You can try any of several combinations from F1 to F6. If you get a login prompt then good for you and you can start to troubleshoot your situation, login with your user name and password.
You can also use the Grub prompt to try to get to a TTY, see my General Notes at the bottom.
If the above does not work then >> Using the chroot method.
For this method, You can use chroot from a live Manjaro usb stick.
Boot Manjaro with live usb and then open a terminal and type
You have just logged into your Manjaro install and can now change or repair anything within your Manjaro system.
With all of these methods of logging in you are now in control of your Manjaro install.
You can now copy or look at logs as they exist on your normal Manjaro system and do other rescue type things.
Trouble Shooting and finding Errors comands
dmesg will show any hardware problems and should be run first, look for the words Error, Failed or sometimes even different color lines. Look the whole thing over to get a sense of how it works, basically all your hardware gets checked by the linux kernel from most primitive like your CPU (important) to other things like your sound card etc...
dmesg more convenient use
$ dmesg | less
and then the arrow keys to move up and down (if you are chroot in GUI you do not need this).
To get hardware info use some of these examples:
$ dmesg | grep sd
get info on sata drives
$ dmesg | grep usb
get info on usb devices
$ dmesg | grep eth
I think you get the idea.
This one is not tested >>>
$ dmesg | grep -E '\b(wl|e(th|n([osp]?[0-9]|x)))\w+'
$ journalctl will show all kinds of stuff as documented here Link
The most useful in a no boot situation is the previous boot or current boot so use the command as below.
$ journalctl -p3 -b -1
the numbers in the command are important as you have read on the linked wiki .
p3 picks up all non-critical errors from the boot probably not what we want in a non-boot, so use
p2 and then
p1 and finally
p0 is used to pick up emergency errors like a kernel dump.
-b -1 conveys the boot log that is being searched, in this case the boot previous to our current boot.
So to get critical boot errors from current boot use
$ journalctl -p2 -b -0
It may also be important to look at the xserver logs in a non-booting situation (not on Wayland). Use the
cat command to have a look, just enter the commands as below. Obviously Do not include > the current session etc... in the command line.
$ cat /var/log/Xorg.0.log > the current session
$ cat /var/log/Xorg.0.log.old > or the previous successful session
$ cat /var/log/Xorg.1.log > after the last suspend
No GUI errors , this means the boot completes but you are left with a non-starting desktop environment sometimes with just a mouse cursor. In these situations you are already booted but the GUI is not working and you can almost always use CTLALT+F2 to get to a prompt.
You can use almost the same commands as above to track down the problems.
With journalctl just look for errors with
$ journalctl -p3
What to do with the error you find?
Now that you have this information post the critical things using the code tags in the forum software depicted with the </> symbol in the post editor toolbar.
Booting to command prompt from Grub
At Manjaro Grub menu use the keyboard to hit E to edit the kernel boot line.
In the grub editor look for the line beginning with
linux, it should look like this.
linux /boot/vmlinuz-4.11-x86_64 root=UUID=0a01099a-1e33-489a-a2de-10104e8492f5 rw quiet
Go to the end of the line and backspace (delete) the word quiet and add
systemd.unit=multi-user.target like below.
linux /boot/vmlinuz-4.11-x86_64 root=UUID=0a01099a-1e33-489a-a2de-10104e8492f5 rw systemd.unit=multi-user.target
Or you can also just add "3" in place of the "systemd.unit=multi-user.target"
Now boot the system with F10 key
You should be offered to login. Login with your user account.
At this point you should have a working system with an Internet connection.
Find Sleep errors in journalctl
journalctl -b0 | grep Suspend
journalctl -b0 | grep Resume
Follow journalctl live
The above command is really pretty useful so lets use it. For example, open a terminal and type the command and then plug in a usb device or close and then open the lid on your laptop, put your computer to sleep etc... You should see what the linux kernel and the desktop thinks about your actions and what may be wrong or happening right.
If you get recurring errors follow these steps to get a clean log with the problems.
Clean the log and paste errors
Please make sure your system is up to date with the command,
sudo pacman -Syyu
Then clean your journalctl with
sudo journalctl --vacuum-time=1d
and then after that the command
sudo journalctl --vacuum-size=250M
Now log out and log back in. Do not skip this step.
Then wait for the problem and look at the errors with,
You may find you can google the errors and get an idea of what is going on or report the errors as described above.
Please PM anika200 before making edits to this post beyond more than a couple words or corrections , Thank you.
If you do not get a reply in 365 days then go for it.