I have had a few issues in the past, with Solus booting to a black screen with a blinking cursor. When this happens, it generally indicates that Solus has successfully booted, but for some reason, it was not able to start the GUI. Whenever I have experienced this problem, the root cause has always been an issue with the Nvidia GPU driver. I’ve had issues with both the Nouveau open source driver, as well as the Nvidia proprietary driver. When this occurs, it is generally possible to log into the system, by logging into a terminal via <Ctrl-Alt-F2>. This access allows the user to update GRUB, use eopkg to update the system, view log files and conduct additional diagnostics.
Recently, one of my machines booted to a black screen, with no blinking cursor … aha!, a new issue and an opportunity to learn something new. My first inclination was that the latest W10 October update walked over my ESP partition. Yes, this is a dual boot machine, with Solus installed on a NVME drive, with its own ESP partition, as well as W10 installed on a SSD, with its own ESP partition. The machine boots into Solus by default (on a good day) and I use the boot menu built into my UEFI (F11 at boot time) to boot W10 for old Windows games. BTW – I haven’t purchased a Windows game since Far Cry 3. I figure that if a game developer does not support my preferred OS, then I’m not going to support them. That doesn’t mean that I don’t like to play Crisis, Deus Ex, or Far Cry 2, from time to time, though.
Rather than muck around with diagnosing the boot files (I was pressed for time and I had a project to complete), I simply reinstalled Solus on the NVME drive. All went well, until I ran eopkg and updated the system. After I updated and rebooted, I was back to the black screen, with no cursor!!! Perhaps Microsoft wasn’t screwing with me after all … for a change. I finished my project on another machine and I’ve just revisited this failure to boot, to see what has gone wrong. The very first thing that I tried, was to walk through the Boot Recovery process, located at: https://getsol.us/articles/troubleshoot ... escue/en/
By the way, shouldn’t a snapshot of these handy troubleshooting articles be included on each ISO, for handy reference? Just a thought ...
I booted from the Solus ISO, ran Gparted and determined that I needed to mount both my ESP partition, which is located at /dev/nvme0n1p1 and my root partition, which is located at /dev/nvme0n1p3. Following the Boot Recovery instructions (see the URL above), I then mounted the necessary /proc, /dev and /sys directories, chrooted and then updated the clear boot manager. Afterwards, I exited the chroot and rebooted. As if nothing had ever happened, I was greeted by a Solus graphical login prompt. Whoo Hoo!
So, Gumby, what’s the point of this. First, and this is not a criticism of the devs, the team go out of their way to support users on several different platforms. While it is good that they are so accommodating, as a result a lot of valuable diagnostic information is, unfortunately, never captured here on the forum. Secondly, I wanted to differentiate between the two different diagnostic paths available, based on whether, or not a blinking cursor is available. Also, Solus seems to be gaining in popularity with Windows refugees, who may have limited Linux experience, so I also wanted to reassure these folks that identifying their partitions and using the terminal is no big deal. Granted, at first glance the Boot Rescue procedure may appear somewhat intimidating, but it is really pretty straightforward and the process takes only a few moments. Just take your time and go step by step.
So what have we just accomplished? It is a peculiarity of Linux, that it does not automatically mount hard disks, unless specifically instructed to do so by the /etc/fstab file, which is automatically generated during the Solus installation process. When adding a disk to a working Linux system, it will be necessary to edit this file, if you wish the new drive to be automatically mounted at boot time. Conversely, Windows will automatically mount any disk, which is formatted in a manner that it understands; it will mount a NTFS, or a FAT32 disk, for instance, but it will ignore an ext4 drive. Therefore, after booting a live Linux system from a USB drive, your hard disk is not automatically mounted, which means that it and the files contained therein are not directly accessible by the live system. In order to use the live ISO to modify the system installed on the hard disk, certain partitions on the drive must be mounted, which then allows certain key directories to be mounted. At this point, the live system can directly access and update the key system boot files, which reside on the hard disk. But Gumby, don't you have to be root to tinker with these system boot files? I'm glad that you asked!
OK, but what is this chroot business? Chroot stands for change root. When most live ISOs are booted, the user automatically becomes root, aka the administrator. This allows superuser privileges on the live system (otherwise we could not run gparted, for instance), but it doesn’t do a damn thing for us, for the system which is installed on the hard disk. The chroot command allows us to become root (the admin) for those partitions on the hard drive, which we've just mounted on our live system. Exiting the chroot reverts us back to only being root on the live system.
This was a rather high level overview, but hopefully it takes some of the mystery out of these basic diag and repair procedures. If your problem persists, you’ll need to reach out to the community. The key to getting good quality assistance, is asking good quality questions. Clearly state the problem, the diagnostic process undertaken thus far and the results of those diagnostic efforts.