It looks exactly like what you get when you run: sudo dmesg
or some variation on that command
in a terminal or on a TTY.
I can not reproduce this behaviour
not even when I purposely disable my display manager (sddm in KDE)
and have no idea how to debug this
when you are unable to switch to at least a TTY and run commands there to investigate
Using a live medium to boot and then chroot into the system and then examining the logs for any error or failure message there
would be my strategy.
I looked online It is indeed exactly like the output from
dmesg
But nowhere online i see someone getting it on boot
Will chroot into my manjaro installation from a live usb boot
And see what i can do…
will update what i find out when i do so, Thanks alot!
No, it’s the output from journald, which by default goes to tty12 ─ if properly configured, because that didn’t use to be set up by default in Manjaro.
Somehow, pressing that Fn+F3 combination locked the OPs laptop into tty12, which means it must have messed with his boot-up files, and particularly, with the systemd configuration.
I suspected as much - but I could not reproduce.
I only have Manjaro in a VM
and if I go to tty12 - there is nothing there
not by default anyway
and when I run journalctl -k
(or any other switch I tried)
the output format is different
not what is shown here.
No i have it installed in a seperate partition from my windows installation.
The previous image was at the same screen as the second image the only difference is i plugged in a flash drive which logged on the screen.
I have to add something i just remembered i did this morning which is deleting pacman cache (i always do that no problem)
But what i did today is i also deleted the contents of ~/.cache
I dont know if this relates to the problem because the OS was working fine for a better of 4 hours before the error appeared.
Before i go on and chroot i Tried to edit the boot options by adding init=/bin/bash and make the system boot into bash and it worked! Anything i can do here to get useful info or probably timeshift or i should go ahead and chroot?
It should have sent you into single user/rescue mode
and asked for the admin password to proceed …
apparently not
an admin password is probably not set anyway - the sudo password will not work as that is the user’s password
so then it’s probably better to chroot and examine the log from there journalctl -r
or something like that, which lets you find the latest error messages most easily
I’m not very familiar with the tool - use man journalctl
or maybe someone else may know a quicker/better way to filter the logs
because
I don’t
ps:
Just to be sure
when booting, at the grub prompt, press “E”
and add a space and then a 1 to the end of the kernel line
just after the “ro”
which is last …