Before anyone complains, I cannot submit this to gitlab because it requires credit card and phone number when I tried to sign up, which is unacceptable. Those saying it didn’t for them probably don’t have anti-tracking / fingerprinting on their browser. Either way, there is no way it is acceptable to give them that information and it is pretty insulting that they should demand it.
Before I start I will say that the gpu is an old kepler nvidia gpu, and from searching there appear to be issues with drivers or xcfe causing this issue but as I am not sure the full details.
I was using system rescue to test a new hard drive (using the setup disk encryption, shred the drive to 0s and then cmp the drive with an endless string of 0s) and after some time on the second day, while in the CMP operation, the desktop environment disappeared. I think this may be a bug with nvidia drivers / xcfe from searching about it.
Before anyone makes the wrong assumption, I was 100% shredding the correct drive that I was testing and not the usb thumbdrive that I was booting systemrescue from. The system was fine until some period after I had started the cmp command and left it running, though the system was probably running for 2 days overall.
The whole desktop disappeared leaving only the terminal and the mouse cursor. Then, when it had finished, I was trying to select the output with the mouse to copy and paste it (I was not aware of how bad the problem was at this point) and the terminal and mouse cursor disappeared too after I had made the selection.
The mouse cursor was still visible.I tried pressing ctrl+alt+F2 and back to ctrl+alt+F1 but that only flashed the first screen up for such a short time that I couldn’t read it. Now the whole screen is blank and I don’t know what I can possibly do to get anything viewable again.
The cursor went away after that and I cannot get anything to display at all.
The computer is still on if you would like me to try and do anything that would help you.
I guess the best thing you can do is to try to reproduce the issue. You can also try to connect to the system running SystemRescue over SSH even when the screen is unusable. For this to work you need to have set a root password or configured an SSH key, and disabled the firewall or allowed the connection in iptables. You can create a custom SystemRescue with a yaml configuration file to make these change and other personal settings (such as your keyboard layout) persistent. All it takes is that you edit the yaml file on the memory stick after you install the system to the memory stick.
When the problem happens again, the best thing to do is check what the system logs say, using journalctl + dmesg and check for any text file in /var/log to see if there is any infrormation. Hopefully these logs will say what goes wrong.
Some memory sticks can be unreliable and a lot of things can happen if thy have corruption or stop responding or whatever. I recommend you always start SystemRescue with both the “copytoram” and “checksum” options so the system runs entirely from the RAM and to verify the system integrity at boot time. This way you dont rely on the memory stick device beyond boot time, and we eliminate this type of problem
Thanks for the reply, when I have time and can somehow get ssh working I will try to reproduce the issue. From searching about it at the time it seemed like it could be something to do with graphics drivers and xfce but I am not sure. To be honest I don’t really know anything about setting up ssh, but I agree that’s the only way I will get information since any logs will be lost when the system is powered down.
Since then, I have been booting with the simple graphics drivers -nomodeset option and it hasn’t happened since I did that.
I will have a look at your documentation regarding yaml configuration later. It seems that even if I get confused with it, you can press e or tab to edit the necessary options at boot time anyway, so learning how to ssh in from another pc is the main problem.
I have edited grubsrcd.cfg to add the copytoram and checksum options into one menu entry. Although I am not sure if you are instead meant to edit the custom.cfg file in the boot/grub/ folder. I imagine it doesn’t matter.
For now I will run with -nomodeset. It does limit the resolutions somewhat but it didn’t happen with that. After I am done testing hard drives I will try and boot into the normal mode and see if I can reproduce it if I can get ssh setup.