Mate doesn't boot

Hello community

I am using mate 18.04 and when I try to boot it “freezes” with splash. I dont have any idea how to fix it. My notebook is HP Dv7 with 16gb ram core i7. I am enable to run with recovery mode and I have already run grub recreation, fsck but the issue continues.
I run mate using DVD and it works fine, so the problem is not the notebook.
I have a dual boot and with windows it works fine.

I am developing an application since 2015 that is only in this notebook. The backup is not updated :frowning:

Could you please help me?

Thanks a lot

Have you disabled secure boot/ UEFI in Bios?

I dont know to do that, actually as my notebook is old (about 10 years), I think this option doesnt exists.

I saw in BIOS configuration and there arent these options.

With your laptop being 10 years, have you ever updated the bios? Sometimes problems can be solved by updating the bios.

But it was working until 2 days ago. I have loaded from DVD as well. As the notebook has dual boot, I also loaded windows. So I believe the problem is not the notebook. Two days ago, I have a problem with python3 then I removed it and reinstalled. After that, the problem happened. I tested the softwares that I have been used such Oracle, Apache, VirtualBox and everything was working fine. I turned off the machine and when I turned on, the mate not loaded anymore

Linux has never done that great a job of managing dependencies, and this leads to a situation where simple actions can have disastrous consequences.

For example, removing and reinstalling Python, will basically TRASH your whole system, because Python has soooooo many cross-dependencies (other programs that depend on Python) – so when you remove it, Linux will STUPIDLY decide that half your system can’t work anymore and should ALSO be removed – but then when you reinstall Python, it JUST re-installs Python.

Unlike windows, Linux makes ZERO attempt to ‘checkpoint’ a major system change like this, so there is no easy way you can go back and undo the damage.

So I hate to say it, but at this point your system is trashed petty good, and there are only a few ways to proceed, none of which is much fun.

One would be to try to boot from the recovery environment, then remount your / root partition Read/Write and reinstall your full MATE desktop, and GRUB boot loader, and hope that fixes things without screwing up your dual boot .

Second would be to log in using a “Live-Session” as you have been – then make a backup of your full user home folder on external media, and reinstall MATE - being very careful to erase and install over your previous MATE partitions, and NOT your windows partition.

Either way, once you recover a working MATE enviroment, you can restore your HOME folder from your backup, and begin the laborous process of re-installing all your add-on programs from the repositories and re-configuring your MATE development environment.

Years ago I was absolutely dazzled by how nicely the Lucid 10.04 Gnome desktop worked, and the smooth way that weekly ‘updates’ were seamlessly pushed down from the servers - and was foolishly lulled into thinking that really smart people had figured all this out and that Linux had solid package management — and then tripped over EXACTLY the same “Python Trap” you did – and learned my lesson.

There are some things about Linux which are great, and some which are not so good, and some which are just HORRIBLE, and the primitive dependency handling is one of the very, very WORST.

if you look up the Wikipedia article l on “DLL Hell” you will see that this issue also effects Windows, going back many years - but in Windows there are simple work arounds which allow multiple versions of DLLs to happily co-exist on your system, which lets me run decade old programs side by side with today’s releases, without issues.

This bad situation in Linux has lead to a host of new “app packaging” solutions like “snappy”, “flatpak”, “appimage”, and “docker”, which all represent various incompatible ugly hacks to try to get around the primitive dependency management in Linux - by substituting something even MORE primitive - just running each app in it’s own “do your own thing” Linux container or virtual machine.

But none of those ‘solutions’ has been deployed system wide, which means almost a decade after my unfortunate experience, you can STILL utterly destroy your system by doing something as simple as trying to remove and re-install Python.

1 Like


I don’t have a lot of software installed, most important are Oracle and Formspider. My application is based 95% in database. I will try to copy oracle datafiles and try to restore the linux. I think that linux developers should be concern to create any kind of lock to avoid this situation mainly for not expert users.

I will try to use your second suggestion: Live-Session…

Anyway thank you so much for your explanation and help