Blank screen at login

[MarieSophie]

But for the sake of non-confusion, by "system" I mean SysVinit versus SystemD.

"I'm logged using a different system" implies computer A is having the problem so you switched to computer B which may not be having the same problem and is likely worthless in terms of investigation.

systemd and sysvinit are known as "init systems". So if you've had to switch to systemd, it's important to specify that you're using a different init system. Even saying "I'm only using systemd now" would have given a clearer picture than "using a different system" did.

Right, TY for the precision, so by saying -"I thought it went without saying that the QSI for a help request should belong to the affected system. " you were indeed expecting me to provide QSI for a system (Init system) which I can't log into ?

[MarieSophie]

I have 26 updates waiting in my queue, I'm hesitating to go ahead :/

Since the SystemD is (seems to be) working, should I go ahead with updates, or will it FU my system the same way as in SysVinit ?

[j2mcgreg]

I have 26 updates waiting in my queue, I'm hesitating to go ahead :/

Since the SystemD is (seems to be) working, should I go ahead with updates, or will it FU my system the same way as in SysVinit ?

I would.

[DukeComposed]

so by saying -"I thought it went without saying that the QSI for a help request should belong to the affected system. " you were indeed expecting me to provide QSI for a system (Init system) which I can't log into ?

In a word, yes: by comparison a QSI from a machine you can log into isn't of much use if it doesn't present with any of the same symptoms. If you can't log into the machine, you can at least provide a QSI on it from a live session or, as you did in this case, by booting with a different init system.

Several people have switched to systemd for troubleshooting in threads over the years, but they at least stated unambiguously that they'd defaulted to using a different init, not a different machine. I'm less pointing out a problem with the methodology than with the nomenclature.

[MarieSophie]

so by saying -"I thought it went without saying that the QSI for a help request should belong to the affected system. " you were indeed expecting me to provide QSI for a system (Init system) which I can't log into ?

In a word, yes: by comparison a QSI from a machine you can log into isn't of much use if it doesn't present with any of the same symptoms. If you can't log into the machine, you can at least provide a QSI on it from a live session or, as you did in this case, by booting with a different init system.

Several people have switched to systemd for troubleshooting in threads over the years, but they at least stated unambiguously that they'd defaulted to using a different init, not a different machine. I'm less pointing out a problem with the methodology than with the nomenclature.

Got it, thank you for the clarification, and sorry for my shortcut, instead of saying I logged in using a different system, I should have said I logged into the same box using a different init system
Noted ! and I will try to remember (probably won't, by try)

[DukeComposed]

Got it, thank you for the clarification, and sorry for my shortcut, instead of saying I logged in using a different system

I've seen people post an irrelevant QSI before because rules are rules and they think that it's some kind of captcha challenge. "I'm having a problem with X, but investigating X is too hard for me, so I'll post my problem with a QSI of Y because this forum is just going to ask for a QSI so maybe this unrelated thing will be good enough, lol" is not an unheard of line of thinking. When troubleshooting a problem, aim for as much clarity as you can. As How to Report Bugs Effectively says, "If the programmer can't tell what you meant, you might as well not have said anything."

[atomick]

How does one "Sign-in - log in via choice X11 or Wayland ?

see only "failsafe wayland" in ~/.config/xfce4/xfconf/xfce4-perchannel-xml/xfce4-session.xml

<property name="FailsafeWayland" type="empty">

is there an easy way to perform this ?

[Stevo]

@MarieSophie wrote:

Yes, my point exactly !
But for the sake of non-confusion, by "system" I mean SysVinit versus SystemD.
The problem happen with SysVinit, which I can't log into, therefore no QSI, and the one I provided is with SystemD.
MSSG

What you could do is log into the SystemD version, create a new user, give it admin access, and then log out. Now log in as the new user, at the grub screen click on Advanced Options and select a Sys V kernel as the boot choice. If this lets you get to the desktop, use Boot Options in MX Tools to make the switch permanent. Finally copy the contents of /home to the new user and then delete the old account. This wouldn't be the first time that a user's profile has gotten corrupted for unknown reasons. It happens, not often, but it does happen.

The GRUB kernel choice comes before any user logins...at least this isn't due to any 6.14 kernel problems. The new kernel is the Bookworm 6.1.0-33 (6.1.133) release.

[Stevo]

How does one "Sign-in - log in via choice X11 or Wayland ?

see only "failsafe wayland" in ~/.config/xfce4/xfconf/xfce4-perchannel-xml/xfce4-session.xml

<property name="FailsafeWayland" type="empty">

is there an easy way to perform this ?

It's somewhere on your KDE user login screen, depending which one you have (so many choices!).

[j2mcgreg]

@MarieSophie wrote:

Yes, my point exactly !
But for the sake of non-confusion, by "system" I mean SysVinit versus SystemD.
The problem happen with SysVinit, which I can't log into, therefore no QSI, and the one I provided is with SystemD.
MSSG

What you could do is log into the SystemD version, create a new user, give it admin access, and then log out. Now log in as the new user, at the grub screen click on Advanced Options and select a Sys V kernel as the boot choice. If this lets you get to the desktop, use Boot Options in MX Tools to make the switch permanent. Finally copy the contents of /home to the new user and then delete the old account. This wouldn't be the first time that a user's profile has gotten corrupted for unknown reasons. It happens, not often, but it does happen.

The GRUB kernel choice comes before any user logins...at least this isn't due to any 6.14 kernel problems. The new kernel is the Bookworm 6.1.0-33 (6.1.133) release.

I was thinking about a bad block on the drive where MX is located but where the next block in the chain wasn't clearly defined when the bad one was replaced automatically from the cache of spares. The new user's login sequence would be written to an unused area of the drive.