On Mon, Jan 20, 2020 at 11:01:45PM +0100, Cliff McDiarmid via blfs-support wrote: > .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: > > > > >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 >
So, I can't count or have forgotten which year we are in. The problem with diagnosing if it is a systemd problem, or indeed a toolchain problem, is that everything has moved on a lot. However, your next response suggests otherwise. > >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. That _is_ somewhat worrying. At one time I wondered if a memory problem (one chip starting to fail) might be involved. I can't see any likely connection, but perhaps memtest86 (current) might dismiss that possibility. It isn't libre, and the free version defaults to only 4 passes (or maybe is limited to only 4), but it seems to work well - and better than the old memtest86+. More likely, if packages have not been updated I think it is possible that someone has strung vulnerabilities together. There have been vulnerabilities all over the place - both the kernel and userspace such as ghostscript and browser engines. > I had begun the build a new lfs from this one using Jhalfs. Relevant? > Not a likely cause of the problem, but I suppose that with a bind mount something in chroot might be doing this. You would need to ask people who use jhalfs from a session running under gdm, but only if you have been doing that between restoring from backup and hitting the problem. > > >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. > The only other things I suggest are that you make a note of what you are doing, and where you browse, to see if there is any likely connection. And: please read the LFS and BLFS errata - particularly the current 9.0 errata (we are getting better at updating that re vulnerabilities) but also previous versions back to 7.9 to see if any of your packages are mentioned. I recommend that you keep the current good backup, but also update vulnerable packages to the extent you are able (dependencies change, and some things give problems with older versions of dependencies or with older compilers). If you do that, check that functionality you use is not impacted (e.g. ghostscript has changed a lot and some things are now prohibited - evince used to be able to open eps files (It needed an external dependency, libspectre) but it doesn't open them now, similarly dvisvgm needed a new version for recent ghostscript), and if ok make a separate backup. Maintaining our own systems is fun, but not in the sense in which most people use 'fun'. Other things which get less mention include perl (loads of serious vulnerabilities in the past few years - fixing them either means upgrading and then rebuilding everything that creates a perl module, or patching the original perl version, I've done that for some versions (based on what I could find at debian or ubuntu) but those are probably newer than what you are running. Details should be in the archives (maybe -support, maybe -dev). Also ffmpeg - they tend to do point updates for older versions, some fix vulnerabillities - and vlc (we've picked up fixed for vlc3, but maybe you are on vlc2 and there might be fixes for that. ĸen -- The politics of wizardry were either very simple, and resolved by someone ceasing to breathe, or as complex as one ball of yarn in a room with three bright-eyed little kittens. - Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
