I am currently working on the prior problem on a tower that I backed up with RescueZilla. However, the other machine I backed up after that tower, before I found problems, was my laptop. It is HP, dual boot Zorin17 and Windows10. I backed up the whole machine with Rescuezilla and also did verification, on an external usb drive.
Now I cannot boot up Zorin on the laptop. I have tried the usual remedy with recovery boot option, fsck, grub repair, to no avail. The Zorin install starts with the "Z", then goes to the "ZORIN" the quickly disappears into the never-ending grey screen.
This is a blow for self confidence, as I had planned to bring local community friends and colleagues from Win10 across.
I had full screen visual of the RescueZilla program on the laptop, so was able to shutdown on completion of the image backup properly. I do not know if it is a coincidence that it has happened after both machines had the RescueZilla system image backups or not? The Windows10 boots up normally. I did some work on it yesterday which I will attach (mobile camera image).
When you're at GRUB, hit "e" to change your boot options. In the screen that follows, look for the words "quiet" and "splash" and delete them, then hit F10 to boot. This switches from the clean, empty black screen and Zorin logo to a verbose report of exactly what the computer's doing while it boots. Seeing where it hangs may help diagnose the problem.
Oh, and don't worry about breaking anything in there--changes made this way only affect that boot; they're not permanent.
Windows Boot Manager isn't going to help; you actually need GRUB. Were you using Windows Boot Manager before creating the backup? If Windows decided your bootloader was no good and "fixed" it, that would explain a lot.
it actually does look like grub, white text on black, if I don't do F9 then windows will start up automatically. I do notice that the partition for Zorin system is 95% full.
Windows Boot Manager also looks like that. It's a display mode that's been supported by computers for ages, so it's good for compatibility. GRUB actually says at the top of the screen, GNU GRUB x.xx where x.xx is the version number. The fact that you go straight to Windows is why I'm concerned Windows screwed things up while trying to 'fix' your bootloader for you. You've already tried the non-destructive options I can think of. (grub repair, etc.)
I am going to investigate the grok readout on the problem. I also have the option of wiping out Windows10, which I want to do in October when support ends. A total re-install from my RescueZilla backup image may fix things?
gdm3 failure to start. Drivers question? Checked using journalctl -xe in root.
Mmmm.... Went through with grok advice and also within the recovery program running I cleaned up space, which was I think the problem, grok prompt. Also while in there it decided to do a software update, and when I had to reboot, the main system loaded AOK.
GDM3 is Gnome Desktop Manager, the part you log into in a graphical login, so that not starting would definitely kill things.
Running out of space is a surprisingly consistent problem that prevents booting. You may want to search the forum for information on deleting logs with journalctl, as log accumulation is a major culprit, though the following command should cut them down:
That command should cut you down to 200M of logs, max. Useful when unable to boot, or just periodically as cleanup. I just ran it myself on a machine that's a relatively new installation (only a month or two) and it deleted almost a gig of logs, which... just too much.
I BELIEVE I'm correct in saying that editing /etc/systemd/journald.conf to uncomment SystemMaxUse and RuntimeMaxUse and setting them to 200M should never use more than 200 MB on logs in an absolute worst case scenario, but I'd feel better if someone with more expertise confirmed that. Also, changing the setting requires a reboot, or reloading the config. Reloading the config can be done with systemctl reload systemd-journald
