.Sent: Saturday, January 18, 2020 at 8:55 PM
>From: "Ken Moffat via blfs-support" <[email protected]>
>To: "BLFS Support List" <[email protected]>
>Cc: "Ken Moffat" <[email protected]>
>Subject: Re: [blfs-support] GDM startup problem
>On Sat, Jan 18, 2020 at 08:24:55PM +0100, Cliff McDiarmid via blfs-support
>wrote:
>
>
> >at a guess there is something wrong with that directory
> >(non-existent, or wrong owner or wrong perms). Possibly
> >>http://www.mgreene.org/?p=302[http://www.mgreene.org/?p=302[http://www.mgreene.org/?p=302]]
>
> Thanks Ken. That's what I thought originally. Followed those suggestions as
> part of the 'solving' but it made no difference.
>
> Reinsalled GDM. No difference.
>
> >Pasting from that, since you cannot run X (note that his log was in
> >.local/share not .local)
> >Simple solution, chown -R gdm.gdm /var/lib/gdm
>
> This time did: 'chgrp gdm /var/lib/gdm/.local/share' and 'chown gdm
> /var/lib/gdm/.local/share'
>
> drwxrwx--T 6 gdm gdm 4096 Jan 17 22:50 .
> drwxr-xr-x 31 root root 4096 Jul 10 2019 ..
> drwx------ 6 gdm gdm 4096 Jan 18 15:34 .cache
> drwx------ 7 gdm gdm 4096 Apr 1 2019 .config
> -rw------- 1 root root 16 Apr 1 2019 .esd_auth
> -rw------- 1 root root 34826 Jan 17 00:24 .ICEauthority
> drwxr-xr-x 3 root root 4096 Mar 17 2019 .local
> drwx------ 3 gdm gdm 4096 Apr 1 2019 .nv
>
>I notice that two of those directories are from January and March
>2017. That suggests that the base LFS system is 8.2 or before ?
7.9-systemd-rc2
>I don't use systemd, let alone gdm, so I can't comment on any known
>issues along the way - but I start to wonder if versions have got
>out of kilter. I have no idea what mix of packages / versions you
>are running, perhaps summarising (gcc, binutils, glibc, kernel
>headers, meson, systemd, kernel, glib, gtk3, gnome) might help if
>someone who uses gdm reads this.
Correct - all the packages mentioned. The system has been running for over a
year without issues.
I had begun the build a new lfs from this one using Jhalfs. Relevant?
> I don't get the access errors as before but now get:
>
> (EE) NVIDIA: Failed to initialize the NVIDIA kernel module. Please see the
> [ 2.778] (EE) NVIDIA: system's kernel log for additional error
> messages and
> [ 2.778] (EE) NVIDIA: consult the NVIDIA README for details.
> No apparent reason for this. As mentioned have tried recovering the LFS from
> backup but the errors return.
>
> Cliff
>Not sure if I've parsed that last sentence, so let me try what I
>think you are saying:
>1. On the broken system, you changed ownership of
>/var/lib/gdm/.local/share to gdm:gdm (but not the .local directory
>itself - I have no idea what else, if anything that contains).
Correct. Based on forum advice.
>2. This possibly made progress, i.e. X tried to load the nvidia
>module but failed. I regard that as 'possible' progress because I
>suspect that happens after opening the log.
Yes. The directories were accessible again, but the nvidia module fails to
load.
>3. You restored from backup. I think you are saying that this used
>to work for a while, even without changing perms, but now you are
>back to the failure to open the log ? ~Or are you back to the
>nvidia error
Correct. The backup was from a working system on the 7.1.20. And back to
failure to open log after maybe three reboots.
>For the nvidia kernel module - had you updated the kernel since
>your last usable backup ('usable' in the sense of "I've restored
>this once and gdm worked")
No the kernel module has been in use for the length of the system.
>Sorry, this is all outside my areas of adequacy
No worries
thanks Cliff
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
