[22.10] Failed to start Light Display Manager (and MORE fun stories from a 20.04 migration over to 22.10

Every now and then I find enough strenght and courage to attempt a stupid upgrade stunt on a production machine and it always end up in catastrophe. I then hate myself and rage at my poor judgement but then realize that when I share my problems with this community that I ALWAYS manage to find solutions. And you've guessed it: today is one of those days. So no pressure :smiley:

So I recently upgraded to 22.10 on my production machine and I started configuring it back. I even managed to get a few reboots done without any problems. But it's now been a couple of days since I had touched it but finally found some time today. So I rebooted it again wishing this would close the playbook activities once and for all. And I was wrong.

So here I am, with a bunch of problems I have no idea how to tackle, hoping to get some precious help.

Problem #1 - TTY7 refuses to start (Failed to start Light Display Manager)

After googling it out, I mostly found support article such as lightdm - failed to start Light Display Manager - Ask Ubuntu but when I invoked sudo dpkg -l | grep lightdm it showed ii lightdm so lightdm is installed. But even if it wouldn't be I would still have another issue...

Problem #2 - No IP address because NIC is configured via a static IP in TTY7
This one should fix itself by bringing TTY7 back up but as of right now I am unable to do any remove diagnostic because it uses a static IP address that I configured under MATE's Edit connection

Therefore I also need to ask is if this feature or is this a bug? That is, when one manually configures network IPs in GUI is networking really supposed NOT to work when GUI doesn't work and we can only work via terminal? Or does it seems worthy of opening a bug?

Problem #3 - Is it really a big problem #3 or are they really smaller and distinct problemS ?
Looking back at the previous screenshot we can read Dev loop11: unable to read RDB block 8. Based on my experience, Dev loop is harddrive related. But is it really though?

sudo dmesg as a couple more things to say:

At the 38th second we do see more Dev loop11 related content. For me this proves that there would also be a potential problem there. So "problem #3" would be "Dev Loop 11 errors".

But then at 64 seconds there is a UBSAN error which seems to be sound-related. So that would be problem #4: "UBSAN problem".

So, what's your view on all of the above? Is it just one big lightdm problem that will see everything else fixed when working again OR is it really 3 separated problems(and 1 bug) like I think it is?


Hi, @DLS (Daniel LaSalle) :slight_smile:

That doesn't look good :worried: Let me try to help with your problem #1: "[FAILED] Failed to start Light Display Manager". Read the following reply of mine in a different topic, that I also posted here in the "Ubuntu MATE Community", on 22nd September 2022, to a problem that @Pratyay was having and see if my answer there and/or @Pratyay follow-up reply helps you:


Hola señor Marques!

Thanks a lot for your (super) fast reply. I have indeed follow the instructions to get a recovery shell running and I have had a similar (Or worst) experience than @Pratyay

Positive: I was able to issue sudo dpkg-reconfigure lightdm and has @Pratyay did, I rebooted. But then the same problem happened (Failed to start Light Display Manager).

Negative: During recovery boot there are remount options. But when I select network I get a Failed to get unit file state for resolvconf-pull-resolved.path: no such file or directorywhich naturally brought me at resolv.conf - Unable to start resolvconf-pull-resolved - Ask Ubuntu

When I issued the commands in the solution here's what happened:

So I am still in the same state of shock as when I first posted this :slight_smile:
All joking aside, gracias for your always informative replies <3


Hi again, @DLS .

You wrote:

:slight_smile: That's Spanish and I'm Portuguese. You probably intended to write "Olá, Senhor Marques!" :wink:

You also wrote:

Hmmm... Try to issue the following command and see what is the output:

sudo systemctl status systemd-resolved

If that service is stopped, try to start or restart it:

sudo systemctl restart systemd-resolved

You may also try to renew the DHCP lease in your computer:

sudo dhclient -v

Also see if "/etc/resolv.conf" is a symbolic link to "/run/systemd/resolve/stub-resolv.conf" as it should be and if the content is what you expect it to be. In my case the uncommented lines of that file are the following:

options edns0 trust-ad
search .

Finally, you wrote:

You're most welcome :slight_smile: Just replace the Spanish "gracias" by the Portuguese "obrigado", please :wink:

1 Like

Obrigado Senhor Marques!

That's running and enabled.

SIII! That patches the network portion.

Yes it is a symlink pointing to the stub-resolv.conf and our content matches 100%.

I have also issued sudo apt purge lightdm -y && sudo apt install lightdm -y and after reboot TTY7 is back up!

On the minus sides:

  1. I seem to have lost my NIC configuration as it boots in down mode yet dhclient -v always fixes it. Bug?
  2. Dev loop11 error still present;
  3. UBSAN error still present.

So this confirms all of those events are not the same cause. I guess I'll hope a bug for UBSAN.

Any ideas for networking? Should I reinstall it? Or open a totally different thread perhaps?


Hi again, @DLS :slight_smile:

I'm glad that you've made some progress with my tips! Still regarding networking, for diagnostic purposes, you may try to reboot your computer again and, after the reboot but before issuing the "dhclient -v" command, see the status of the "networking" and the "NetworkManager" services with the following commands:

systemctl status networking

systemctl status NetworkManager

You may also get a much more complete log of those services by running the related "journalctl" commands for those services and see if something that looks relevant comes up in those logs:

journalctl -u networking

journalctl -u NetworkManager

1 Like

Regarding this other problem of yours:

In my experience, in recent Ubuntu (MATE) installs, these /dev/loop[number] block devices are used by "snaps". Issue the following commands to see the list of those loop block devices that are used in your installation:

lsblk | grep -i 'loop'

losetup -a

Here are 3 related "Ask Ubuntu" questions and answers:


Finally, @DLS, for your last issue / error:

I've searched for the specific error message in your screenshot:

UBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40
index 65 is out of range for type 'snd_emu10k1_voice [64]'

... and I've found the following message, submitted on 7th September 2022, by someone called Tasos Sahanidis, to the ALSA ("Advanced Linux Sound Architecture") development mailing list ("alsa-devel") that identifies a bug initially discovered in PipeWire (audio) and includes a patch that fixes the bug for that specific error message:

https://lore.kernel.org/all/[email protected]/

By the way, I've also found that UBSAN is the "Undefined Behavior Sanitizer" for the Linux kernel: