Just discovered on my dual boot Manjaro stable system-- 5.9 kernel, 5.20 desktop, bare metal… that on bootup --ctrl+alt+f2 no longer works. Hmmm. In looking at /etc/default/grub, line 18- “Uncomment to use basic console” is GRUB_TERMINAL_INPUT=console. Line 21, “Uncomment to disable graphic terminal” is # GRUB_TERMINAL_OUTPUT=console. Either of these cause the problem or could it be somewhere else. From the logon screen there is no more ctrl+alt+f2 to get to a CLI log on and I consider this dangerous…
Second question- Where does one uncomment in Grub to disable system startup from looking for a hibernation device that is no longer there. One of the installations on this dektop sits and looks for the UUID of a hard drive that doesnt exist any longer.
/etc/fstab does part of it. Delete the disk entry by UUID in fstab. Cant find the place in Systemd to change where it totally disappears.
Masked the unit(swap) in sysctl…solved.
And another question-- when the machine is started, grub allows one to make a selection of which OS to start, yes? So I select one from the list and press the enter key. I am assuming Grub’s job is done as it looks at the hard drive or partition that the selected operating system resides on. At that point to what controls booting? I am assuming that Grub is out of the picture and various files and subroutines on the booted operating system take control to boot, yes¿?
Edit… Looking at the Arch Wiki–it looks like Grub hands things off to systemd to start the os…Didnt do my research on this part my apologies.
If you mean the user log-on, this has nothing to do with GRUB and its mentioned options. I do not know where the change lies that caused your issue, but GRUB basically hands over the boot process to the
initramfs once you press enter on a kernel line.
GRUB itself has no business in hibernation. The only GRUB place you may have defined a hibernation device is in the options for the kernel. Have a look if there is one listed in the cmdline in
initramfs takes over. It contains the binaries, modules/firmware and settings needed to boot. This can be a traditional initramfs, or a systemd based one. It basically prepares everything necessary (device discovery, etc) for the kernel.
Thanks very much for the great explanations and helping me learn… Understand abut inramfs. Didnt know that before… The Grub message I found was quiet hibernation for a disk with its UUID, In /etc/default/grub.That looks to be the root disk. So at boot initramfs takes over from Grub and hands things off to systemd…thanks very much. Arch wiki helped me a lot on this after a second search here with different search terms.
Neither of the installations on the same machine…both Manjaro, one stable and one testing…will go to a terminal at the logon screen with ctrl+alt+f2. Both installations, the logon screen disappears and no tty, no CLI logon…system goes to a black screen and does nothing…wanders off into the weeds.
Many thanks for the great help
So the only remaining problem is after boot, when the GUI logon screen appears–ctrl+alt+f2 does NOT get me to the CLI or TTY…when ctrl+alt+f2 is pressed the GUI logon disappears and a black screen. No tty logon. Nothing.
A blank screen can be a problem with modesetting. Try this: at GRUB boot screen press
e (edit) and add
nomodeset to the line with the kernel options. Then press F10 and it will boot. No worry, such a change only affects one boot (not saved).
If it works, more info here:
Thanks…Added nomodeset to the kernel line, rebooted, got to the GUI login screen and the same result as before. Ctrl+alt+f2, the GUI login disappears, then the monitor displays a no input message and stays black. So it could be that something is crashing the video card outputs. Also per the archwiki page you linked, tried nomodeset plus nouveau.modeset=0 with the same result.
What has changed on the machine --since ctrl+alt+f2 worked…is the upgraded video driver. The machine has 2 hard drives. Running Testing branch on one drive and Stable branch on the other. When I originally attempted installation of the 510 kernel on the Testing drive, the machine would not install any NVidia package for that kernel. Before my install of 510, Testing was on NVidia 450 with the 5.9 kernel. The only way I was able to get an Nvidia driver package to install with the 510 kernel was to upgrade the existing 5.9 Testing kernel to NVidia 455. Apparently there is no 450 driver for 510. I am currently on NVidia 455.45.01. That is the only difference that I am aware of between ctrl+alt+f2 working and not working. It could be something else but this is beginning to look like a problem with NVidia’s 455 driver. Also note that making the temporary changes to the kernel line in Grub has the same effect on both Stable and Testing installations on this machine.
Using ctrl+alt+f2 on a running system has the same effect. Want to go from GUI to TTY to do an update, same effect as from login screen-nothing.
Would be interesting to see if anyone else running the 455 driver experiences this.
Thanks for the suggestions and your continued interest.
Well, in case of nvidia, the suggestion with
nomodeset was not the right track. I can clarify though that this issue has nothing to do with GRUB. You better post a separate/new issue for it, so that your blank screen issue is more apparent and you can attach relevant log files (the error should definetely be in the journal). In fact I see a number of user posts about having troubles with the 455 drivers in the last days. One that looks similar to yours:
If you look at the post, booting with fallback initramfs still works in that case (but it may not be Nvidia related).
Something else you can try is to add
systemd.unit=multi-user.target as a kernel boot option to avoid the boot to graphical at the moment. Then you will have more transparency about the failures. I think that’s all I can contribute for now.
Many thanks for what you have already contributed. Hope the rest f your weekend is excellent and next week is good as well! Thanks.