Bug 33177 - system "freezes" after login to the display manager
Summary: system "freezes" after login to the display manager
Status: RESOLVED WORKSFORME
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 9
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-05-02 17:28 CEST by w unruh
Modified: 2024-05-09 21:10 CEST (History)
2 users (show)

See Also:
Source RPM: unknown
CVE:
Status comment:


Attachments

Description w unruh 2024-05-02 17:28:38 CEST
Description of problem: Using both sddm and lightdm, the system "freezes" (well the boot to the windows manager stops) after login to the DM (both sddm and lightdm). Ie, in sddm it sits there forever with a mouse pointer with a little rotating circle of dots (the curser moves when I move the cursor location with the trackpad in sddm) or a black screen with a cursor line in lightdm. The desktop never comes up. It does this both for the user, and for a test use created to see if this was generic or specific to something in the user's configuration. (it is not). There is nothing that stands out in any of the logs I have looked at.  If I do alt-ctl bksp-bksp, I return to the DM login screen. I can also go to a cosnole (alt ctl F2 say). Trying startx -- :3.0  also freezes in the same way, and I can get out of the freeze with AC-BsBs.


Version-Release number of selected component (if applicable): Updated Mageia 9 on Dell XPS13 9315 laptop. Since I have no idea what is acting as the blockade, I have no idea where to look.


How reproducible: Always. 
So the "test" user indicates it is not something about the users configuration. 
It is something about the whole system X configuration. 

I finally got around it by using my spare partition and reinstalling Mga9 onto that. In this new version, things work. The old one still does not work.
Comment 1 Ricard Alfe 2024-05-02 20:52:28 CEST
Comprueba si es la version del kernel 6.6.28 el systema que no puedes entrar. Si es así, prueba a desconectar el cabre de red. Luego inicia el sistema y prueba a entrar sin conectar el cabre Luego trabaja sin conectar el cable. Si todo funciona bien conecta el cable y espera a que se congele (ocurre a los pocos minutos). Y comenta
Posible fallo https://bugs.mageia.org/show_bug.cgi?id=33157

CC: (none) => ricardalfe

Comment 2 Ricard Alfe 2024-05-02 21:01:13 CEST
(In reply to Ricard Alfe from comment #1)
> Comprueba si es la version del kernel 6.6.28 el systema que no puedes
> entrar. Si es así, prueba a desconectar el cabre de red. Luego inicia el
> sistema y prueba a entrar sin conectar el cabre Luego trabaja sin conectar
> el cable. Si todo funciona bien conecta el cable y espera a que se congele
> (ocurre a los pocos minutos). Y comenta
> Posible fallo https://bugs.mageia.org/show_bug.cgi?id=33157

Check if the system you cannot enter is kernel version 6.6.28. If so, try disconnecting the mains cable. Then start the system and try to enter without connecting the cable. Then it works without connecting the cable. If everything works well, connect the cable and wait for it to freeze (it happens after a few minutes). and comment
Possible failure https://bugs.mageia.org/show_bug.cgi?id=33157 

Sorry I copied the google translation wrong
Comment 3 w unruh 2024-05-03 21:10:19 CEST
Reinstalling is still working. But since the bug showed up after the system had had a new installation and had been working for almost a month, it is a bit early to say it was solved.The situation is certain different from that of id 33157.
Comment 4 Lewis Smith 2024-05-05 21:36:47 CEST
Bill, please post the output of
 $ inxi -MSG
to summarise the problem system.

That other bug commented about the network cable; Ricard's comment 2 mentions "the mains cable", presuming a laptop.
@Ricard: did you really mean the power cable?

The kernel version might matter: my own kernel-desktop-6.6.28-1.mga9.x86_64 arrived on 23rd April. You suggest that the system in question worked for a time. Can you confirm this?

And, at boot time, choose the previous kernel to see what happens.

CC: (none) => lewyssmith

Comment 5 w unruh 2024-05-06 03:30:21 CEST
Unfortunately I am 3000 miles away from the machine at present and since the machine was needed to do work with, I reinstalled Mageia 9 onto a new partition (I always keep two for reinstallation if needed)

It now works. However, when the old home  files were reinstalled into the user space, The same problem reappeared. so it seems that there is some problem in the user config that tirggered the problem. What it is/was is still mysterious.
But it is working now on the new partition, and It is hard to test the old partition out some more since the machine is needed to do actual work.

But what says that is not the full answer is a) that it did it with both sddm and lightdm, and it also did it when I installed a new test user.

Something has been made very fragile  in X in Mageia 9.
Comment 6 w unruh 2024-05-06 03:31:31 CEST
Note also that I have no problem with network cable (It is a laptop and only uses wireless) or with power cable.
Comment 7 Lewis Smith 2024-05-07 20:58:14 CEST
(In reply to w unruh from comment #5)
> I reinstalled Mageia 9 onto a new partition
> It now works. However, when the old home  files were reinstalled into the
> user space, The same problem reappeared. so it seems that there is some
> problem in the user config that tirggered the problem. What it is/was is
> still mysterious.
This is important. When and if you are able, perhaps try the 'new' HOME (as installed & working) in the 'old' HOME directory. Repeat: if & when.
Comment 8 w unruh 2024-05-07 22:33:48 CEST
It is 120GB.
Originally we had two homes. The one installed with the installation of 
Mageia, /home/d and the other (115G) located in /local/home/d  .
/home/d worked. /local/home/d did not. (changed the home directory in 
/etc/passwd). At that point confusion followed, trying to figure out what 
happened. At one point I made two users with the same uid ( since 
/local/home/d had the same uid as the ser d had in the new instalation. Then 
the fog of much confusion followed. At one point we had a working system with
the bootup directory being /home/d, while $HOME was /usr/d. while pwd gave 
/local/home/d.  (how that
could happen I have no idea.). Anyway, we finally pointed /home/d as a link to
/local/home/d, abd it worked. We have no idea what we did to make it work.(It
is not helped by the fact that the computer was at my son's, and we could onl
communicate by phone, and  had to give him detailed instructions, and was also
temporarily bereft of the family car so could not drive to his place.)

So, at present both the originally installed home directory ( usually at /home/d
and the present Mageia 8 home, on /local/home/d, which is linked by /home/d pointint to /local/home/d work properly.
So I too would like toknow what wolved it. Sorry:
Comment 9 Lewis Smith 2024-05-09 21:10:52 CEST
Thank you for your successful manipulations (although the mention of Mageia 8 is uncomfortable).
I think this has got too convoluted to pursue.
(In reply to Lewis Smith from comment #4)
> The kernel version might matter: my own kernel-desktop-6.6.28-1.mga9.x86_64
> arrived on 23rd April. You suggest that the system in question worked for a
> time. Can you confirm this?
> And, at boot time, choose the previous kernel to see what happens.
It is now too late to try this.

Closing, but you can re-open the bug if & when you can get back to the non-working system, and answer the questions.

Status: NEW => RESOLVED
Resolution: (none) => WORKSFORME


Note You need to log in before you can comment on or make changes to this bug.