I restarted since my last session was unstable, every new terminal I launched closed immediately. I can boot up to the Gnome login screen and enter my credentials, but the monitor receives no signal.
The tty combinations (Ctrl + Alt + F3 and rest of the function keys) don’t work and there’s no familiar “cog” icon to change desktop environments.
Is there another way to access and log in via the shell and update the system, to start with?
The easiest to re-gain access to the system, is booting a Live system from USB and chrooting into the system.
Here is a good guide: Setting up chroot from a live image in Fedora. Regenerate grub2 for Fedora. · GitHub
(The purpose of the bash script seems to be different, but you can follow it until line 23).
Yet another guide: OS Chroot 101: covering btrfs subvolumes - Fedora Magazine
The Fedora magazine guide doesn’t address encrypted volumes, the script hasn’t been written for btrfs. I use the btrfs file system and have encrypted my system.
I decrypted my OS volume with cryptsetup and can inspect the familiar files in /mnt/ but don’t immediately know how to continue to mounting in chroot.
If you look at the gist I linked, in line 6 there is an unlock command. I personally have only used cryptsetup luksopen ... in the past (don’t know that other command).
So either you use the cryptsetup command, or from Live disk you can even use Gnome Disks to unlock your luks container.
After that everything is the same… (just your partition descriptor accordingly).
I was able to chroot into my Fedora installation, updated with dnf and attempted re-generating grub for my UEFI system.
Now I’m sadly stuck at the grub> prompt, also after choosing my OS drive from the BIOS boot menu (F11). I’m not seeing the bootloader menu (where kernels and the recovery mode can be selected).
The grub.cfg appear to not have been recreated – I restarted from the live USB, started chroot and the following files do not exist:
/boot/efi/EFI/fedora/grub.cfg
/boot/grub2/grub.cfg
I may reinstall, I’ve considered doing so in any case due to having initially moved my Fedora installation (the same SSD) over from a low-end Intel system (to AMD).
Do the files actually not exist? Or are the /boot and /boot/efi partitions not mounted so the files cannot be seen?
You did say that you did a chroot from the live usb and there are some steps involved to have the environment proper, including mounting everything below the mount point used for the root file system.
The partitions should be mounted as I followed the Fedora Magazine instructions. In the terminal I’m logged in as [root@localhost-live /]#, after running sudo chroot /mnt and the preceding steps mentioned in the article:
ls /boot/efi/EFI/fedora/
outputs:
BOOTIA32.CSV BOOTX64.CSV gcdia32.efi gcdx64.efi grubia32.efi grubx64.efi mmia32.efi mmx64.efi shim.efi shimia32.efi shimx64.efi
ls /boot/grub2/
outputs:
fonts grubenv themes
How to manually generate the grub.cfg files on a UEFI system, if this would allow my installation to boot? As noted above, I’ve tried starting the system:
I was able to chroot into my Fedora installation, updated with dnf and attempted re-generating grub for my UEFI system.
Now I’m sadly stuck at the grub> prompt, also after choosing my OS drive from the BIOS boot menu (F11). I’m not seeing the bootloader menu (where kernels and the recovery mode can be selected).
Ok, that output shows the partitions /boot and /boot/efi appear to be mounted.
What mode was used for boot during the install? On a system that boots EFI you should have seen
# ls /boot/grub2
fonts grub.cfg grubenv i386-pc themes x86_64-efi
4 of those 6 are directories.
You also should have seen a grub.cfg file under /boot/efi/EFI/fedora/
My response would be to (in the chroot environment) run sudo dnf reinstall grub2* then attempt to boot again.
If you did not initially boot to uefi mode for the install then you will need to start over and reinstall the system in uefi mode (boot the install media in uefi mode for a uefi install).
I’m afraid that this wasn’t a conscious decision, I can’t recall and have likely used the default setting. I can only tell that running [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS (in thechroot session) returns UEFI.
My response would be to (in the chroot environment) run
sudo dnf reinstall grub2*then attempt to boot again.
I’ve already ran # dnf reinstall shim-* grub2-efi-* grub2-common which may have the same effect. Successfully reinstalled several packages back then, but now I get errors:
Installed package grub2-common-1:2.06-70.fc37.noarch (from updates) not available.
Installed package grub2-efi-ia32-1:2.06-70.fc37.x86_64 (from updates) not available.
Installed package grub2-efi-ia32-cdboot-1:2.06-70.fc37.x86_64 (from updates) not available.
Installed package grub2-efi-x64-1:2.06-70.fc37.x86_64 (from updates) not available.
Installed package grub2-efi-x64-cdboot-1:2.06-70.fc37.x86_64 (from updates) not available.
Installed package grub2-pc-1:2.06-70.fc37.x86_64 (from updates) not available.
Installed package grub2-pc-modules-1:2.06-70.fc37.noarch (from updates) not available.
Installed package grub2-tools-1:2.06-70.fc37.x86_64 (from updates) not available.
Installed package grub2-tools-efi-1:2.06-70.fc37.x86_64 (from updates) not available.
Installed package grub2-tools-extra-1:2.06-70.fc37.x86_64 (from updates) not available.
Installed package grub2-tools-minimal-1:2.06-70.fc37.x86_64 (from updates) not available.
I’ve prepared to reinstall Fedora over the weekend, no need to devote any significant amount of your time anymore. I’ll keep the original system SSD around for a while (to export the names of installed DNF packages and Docker images, for instance – the data which can’t necessarily be simply copied over).
This erroneous line in .bashrc caused the booting issue (I’ve reinstalled on another drive, the same symptoms after restoring specific files and directories to /home/user/):
alias edit-aliases='nano ~/.bash_aliases' && source ~/.bashrc
corrected:
alias edit-aliases='nano ~/.bash_aliases && source ~/.bashrc'
Marking as a solution, even though the other answers were more informative in general.
I have to learn analyzing system logs, the problem could likely have been easily resolved soon after the first failed boot…