Lubuntu Hybrid - LXQT/KDE/UNITY D̶i̶s̶p̶l̶a̶y̶ ̶M̶a̶n̶a̶g̶e̶r̶ Blinking Cursor of Death

[freq32]

It started with the 19.10 eoan upgrade. (not Lubuntu’s fault, my system is jacked up - looking for insight).

Nvidia and Broadcom drivers were nixed, and wouldn’t load. I’ve got that mostly fixed now after downgrading to 19.04… but I can only verify this via log files because since the downgrade, my GUI is MIA.

All in the Xorg.0.log is peachy (including the Nvidia / EFI / Legacy fiasco) … and the last thing to repair is the FRIGGIN DISPLAY MANAGER SESSION.

SDDM, GDM3, LIGHTDM … none will work. I’ve tried just about everything.

There’s a curious situation that occurs on this partition (legacy hybrid) when I boot to recovery, the plymouth screen, (all green OK’s) at the very end bleeds onto the recovery menu GUI in a super glitched out way. and when I try to repair GRUB … it says GRUB not in boot/efi (as if something is wrong in grub but only when entering this Ubuntu).

If I continue into boot as normal, I get the lovely blue “LUBUNTU” splash followed by a strange Terminal Login with the hostname (computer name) prompt, then a black screen that then goes to a blinking little cursor in the top left corner, where the computer sits… FOREVER.

When I look at the logs, it seems everything is happening okie dokey on the syslog behind the blackness, but i look at the sddmlog or lightdm and its ERROR after ERROR dbus terminated or nonexistent. Oddly, I remember that the only one I could get to work is GDM3, but after this 9.10 upgrade (never should have done it) GDM3 throws it’s own error… it won’t respond or init even when using dpkg-reconfigure (not even the GUI select menu pops up in the terminal).

I’ll get the screen shot and error when I get home and post it in a couple of hours.

(lastly I’ve semi-ruled out hardware - ran disk check, smart data, ram tests, nothing stands out) and the fact that 2 other linux install run from GRUB fine - including a second stock openbox Lubuntu)

[guiverc]

It may be you’re just missing the 1; but year.month is the format of Ubuntu releases and that decade is important; 9.10 (2009.Oct) has a very different meaning to 19.10 (2019.Oct), likewise 9.04/19.10.

[freq32]

oh that’s just a typo, I used the codenames in apt config (disco, eoan) … to downgrade I changed the sources and pinned those in apt config.

[freq32]

I should mention I might have chosen the Lubuntu dev channel, that’s ok or a big no-no?

[freq32]

My thoughts, there’s a missing / broken package dealing with d-bus, grub is super-fried and I’m fighting a dead horse until i fix that, or the KDE / Unity is not playing nice with LXqt, or lastly if it’s still the graphics driver (prob not but that glitch on at the end of the plymouth is odd).

Please tell me if any of these make more sense and what to look into, for anyone who is an expert in the display manager, xsession server, boot up of distros. thank you!

[guiverc]

@freq32

since the downgrade

@freq32

downgrading to 9.04

I don’t really understand what you’ve done, did you remove (eoan) packages manually, then install (disco) packages yourself? as the apt packaging tools are only designed to ‘upgrade’ to later packages.

If I want to ‘downgrade’ I just re-install (Manual partitioning & selecting no-format of partitions) so it’s possible this is what you mean, but it’s not clear to me (this way doesn’t have problems usually as it wipes system directories, installs, then re-adds back your added packages if available in your ‘new’ release, without touching any user directory unless you had format selected)

I’m sorry, but I don’t understand what your release is. If you use ubuntu-support-status to get a summary of your support status (unsupported packages), does it reflect a 19.04 system (support till Jan 2020)? or contains 19.10 packages too (support till July 2020)? or a mixture? I’m confused sorry.

[freq32]

you can achieve a downgrade by manually editing sources list to the previous version, and then pin to the release in apt.conf

https://wiki.debian.org/AptConfiguration

(it’s not recommended and you may have to go in and fix some things after, but it works)

this is what I should have done before I crazily upgraded forgetting how fragile my stack was.

[freq32]

your suggestion to use ubuntu-support-status revealed something, particularly the headers being no longer downloadable.

Anything else?

OUTPUT OF ubuntu-support-status : https://pastebin.com/UxL6PqGa

what header version is best with Lubuntu 19.04?

[guiverc]

The yellow tagged detail (no longer downloadable)

1. linux-headers-5.3.0-19-generic linux-image-5.3.0-19-generic

2. linux-modules-5.3.0-19-generic linux-modules-extra-5.3.0-19-generic

are for a 19.10 (eoan) kernel left behind. In your position I’d probably pick some of those unsupported to see where they came from, checking for 19.10/eoan packages that weren’t ‘downgraded’; the reason I suggested it (ie. what I’d do)

[freq32]

here’s the apport.log errors, happening under the black screen (every .2 seconds this error fires)

APPORT.LOG : https://pastebin.com/Qe53YCbD

I’m backing up the data at this point. the other OS’s are reporting a hardware error at boot up now.

[freq32]

and everywhere I look, this seems to be a mystery with just some loose clues as to what causes it…

EXCEPT THIS : https://serverfault.com/questions/892465/starting-systemd-services-sharing-a-session-d-bus-on-headless-system

[freq32]

I have a backup of the system from July I’m going to restore with rsync.

I just got a little glimpse into what is occurring. My BIOS has Legacy/EFI , and therefore 2 Grubs… somehow this partition is partially installed with the EFI, and also the legacy, but the legacy is booting from within the EFI grub. (Grub within a GRUB). Weird.

And the headers were indeed screwy as a result (thus the locked/undownloadable).

At any rate, none of that is right and I’m going to clean house.

[freq32]

windows is the bane of my existence. it turns out that there were remnants of a windows partition in the grub files and the efi boot partition (among many bad settings that goofed as a result of). once the UUID and boot record was cleared of Windows, I could see the light.

F*** windows. Never again. I’m back up.