Bug 31352

Created attachment 13611 [details]
install report

That's usually the sign of a display driver problem. I can't reproduce it in VirtualBox. An extract of the relevant section of the system log (using journalctl) after it failed might provide more information.

If you remove the "#" from the start of the line

#WaylandEnable=false

in /etc/X11/gdm/custom.conf, does that allow GDM to work.

CC: (none) => mageia

(In reply to Martin Whitaker from comment #2)

> 
> If you remove the "#" from the start of the line
> 
> #WaylandEnable=false
> 
> in /etc/X11/gdm/custom.conf, does that allow GDM to work.

yes, but it does always present the login greeter.
when I remove *quiet  splash* from the boot line, the mouse pointer sometimes
disappears 2 or 3 times after *started gdm.service* in text display.

Created attachment 13612 [details]
hopefully relevant part of journal

(In reply to Ben McMonagle from comment #4)
> Created attachment 13612 [details]
> hopefully relevant part of journal


The failure occurs at 10:21:44 with

  org.gnome.Shell.desktop[1687]: malloc(): unaligned tcache chunk detected

I was able to reproduce this on my old laptop, although the stack trace after the failure was different. Whilst trying to eliminate unrelated (and non-fatal) errors, I found that running

  chown -R gdm:gdm /var/lib/gdm

avoids the bug. This is a workaround rather than a true fix, although the ownership of the directories under /var/lib/gdm really ought to be fixed.

An identical 64-bit install on the same laptop did not exhibit this bug.

(In reply to Martin Whitaker from comment #5)


> 
> An identical 64-bit install on the same laptop did not exhibit this bug.

found that as well. 
I had previously installed all individual DE from the x86_64 .iso on this hardware without discovering this issue.
then moved on to i586 as no-one appeared to be testing it.

another good reason for testers to do both the multi DE and single DE installs for both archs on real hardware.

thanks for pinpointing the issue. 
now to get it resolved!

Well, thanks to both of you for the research, and Martin once again pinning it down.
Can we take it that 64-bit systems (which do not show the problem) have the ownership indicated in comment 5 ? My own system does:
 $ sudo ls -l /var/lib/
 drwxrwx--T  5 gdm      gdm      4096 Rha  17 19:21 gdm
(although /var/lib/gdm/ is empty).

End sticky bit: Lowercase t implies x, while uppercase T does not
The Sticky Bit:
If the sticky bit on a directory is set, subdirectories/Files under that directory can only be deleted by either owner of the file, owner of the directory, or the root user. This special permission is useful to prevent users from deleting other user’s file inside a shared folder where everyone has read, write, and execute access.

Maybe that is not relevant, since access is denied outside of owner/group.

Assigning to the Gnome people.

Assignee: bugsquad => gnome

Flagged for errata provisionally in case it escapes into the M9 release. Can be cleared if fixed.

Hardware: All => i586
Keywords: (none) => FOR_ERRATA9

The ownership problem is there on 64-bit systems as well, but on those systems it just results in error messages about not being able to create directories or open files under /var/lib/gdm/.local/share and doesn't cause gnome-shell to die.

I think it's just /var/lib/gdm/.local/share itself that ends up owned by root after gdm is installed. I did the recursive change of ownership from /var/lib/gdm down just to catch anything else.

Checking on a Mageia 8 system, I find

# rpm -qf /var/lib/gdm/.local/share
file /var/lib/gdm/.local/share is not owned by any package

I can modify the gdm package to fix that. That may mask the real bug we've exposed here, but maybe we don't care if it doesn't affect anything else.

Does the updated liblcms2_2-2.14-4.mga9.i586.rpm helps for the fix?
Because of: https://github.com/mm2/Little-CMS/issues/349

CC: (none) => yves.brungard_mageia

installed Gnome only DE from:

Mageia-9-beta1-i586.iso
DATE.txt: Mon Feb 13 12:37:07 PM CET 2023

before updating, issue is not apparent, booting to both wayland and Xors sessions.

after update that includes: 
liblcms2_2-2.14-4.mga9.i586.rpm 

reboot to both wayland and xorg sessions without issue

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