Light DM issues

jedi

Another reboot, no problems...
The error from terminal on trying to start spacefm;
Attempt to unlock mutex that was not locked
Maybe SID is just in a bad mood and breaking some of his toys.  Perhaps he'll calm down in a couple of days...
Forum Netiquette

"No matter how smart you are you can never convince someone stupid that they are stupid."  Anonymous

statmonkey

Thanks for weighing in Jedi.  Can I ask if when you did your lightdm upgrade did you keep your old config files or did you install the maintainer's version?

There must be something different between our builds. 

Really hoping this is just Sid playing naughty.  I really have a ton of stuff to do today.  Not sure I could accept loss of spacefm and this keyboard lag, doubling of keypress, lack of ability to use terminal in x is really painful.

VastOne

I am in a bad way, I seem to have lost all access to my home directory which is it on its own partition, no matter what partition I try to log into I have no access to home.  The login attempt just flashes back to the login name again. I have tried to change ownership of my own home directory to no avail, because this isn't exactly what it looks like when you don't have permissions to your home directory.

I'm now in the process of installing on a different partition all over again.  If I was on a Windows machine seeing these same things I would swear  I was dealing with a virus. Will keep you updated on what's going on.
VSIDO      VSIDO Change Blog    

    I dev VSIDO

VastOne

I should add that none of this was going on until I started mucking around with this LightDM and systemd issue that's been plaguing us
VSIDO      VSIDO Change Blog    

    I dev VSIDO

VastOne

Further info on just what I did... I downloaded the deb for the old version of LightDM 1.10.1-3 and installed it on the broken partition ... it was as statmonkey said, puking on several systemd messages that lightdm was no good and then getting to a login prompt at tty1

I dpkg -i the old lightdm version and was happy when I rebooted and found the issue resolved.. or so it seemed... I had a login screen but it did not show my login name which is (was?) the default in the VSIDO version of the lightdm conf file setup... blah blah blah and yada yada yada... get on with it!

Tried to login there with my creds and it just flashes right back to the login screen... ok, I can deal with that.. Reboot back to the partition of the old build (which shares the same /home vastone home directory) and am getting the exact same results... it will not login, it just spits me back out to the login screen and any login I use with that /home directory does the same thing

I am now on a new build partition that I disabled using that specific /home partition and instead using it's own partition as the new /home.  It boots and logs in fine... but as soon as I change fstab to reflect the old /home/vastone partition it does the same exact thing on the login again.  I have checked all uuid's and nothing has changed in fstab

I am testing now copying the old home to the new home on that I am on now and doing a chown on it.. will update again when I reboot
VSIDO      VSIDO Change Blog    

    I dev VSIDO

statmonkey

#20
Fixed lightdm sort of from this tip:

Quote


Joined: 2010-08-26
Posts: 736

Status: Offline
   
It seems you've picked the 'wrong' choice when lightdm asked via debconf about how it should deal with "/etc/lightdm/lightdm.conf" during the dist-upgrade. The 'correct' answer would have been 'Y'es, to allow replacing the current version of /etc/lightdm/lightdm.conf with the new template from the maintainer.

By uninstalling lightdm and purging it.  I then reinstalled and rebooted.  Lightdm now works but not the way I had it configured.  I will have to research what it is now doing.  This is a pretty crappily documented app so ...... may take me a while.

Spacefm is sadly not working as reported by Jedi.  I will move to that next.  I am convinced that in order to work with systemd these and a lot of other apps are going to continue to be repackaged to make use of it Or they will be just broken and left to die.  See the paragraph in my rant about this.  I am guessing those of us who have customized things like lightdm are going to suffer some breakage because of it.  I have a long list of crap on my machine that is not working correctly as well and will report back on what I find that works.  Looks like a long day.

Sorry to hear your issues VO.  Mine are weirder still since I have characters diasappearing, keyboard skip and partitions that won't mount as well.  If you have downgraded lightdm then upgrading and making the proper Y selection to choose the maintainers version should fix it.  Then you will probably have to customize it all over again from the /etc/lightdm/lightdm.conf file to get back to what you actually want.

Guess I will just keep adding to this.  Apparently something has decided that my drives are uefi and the system keeps trying to load them that way.  This is causing the drives not to be found and not sure if this is from systemd, grub or where yet, it might be related to the spaceFM issues.  Additionally I am running into keyboard issues, mpd problems and numerous other issues.  It looks like a reinstall is in my future.  But my frustration is mounting.

jedi

Yes, I chose the maintainers version.  With lightDM and Grub, I usually do.  (choose the maintainers version)  I like to see if something is going to break!  I am also deeply disappointed with the issue of spacefm.  I switched last night back to pcmanfm, but it ain't then same!
I have no other issues, and, as amof have gone through all of my installed apps to make sure of this.  So far for me, only spacefm is being naughty.
By using the Liquorix Kernel, have I avoided the issues you all are having?

For orbea's benefit, when doing a dist-upgrade, live-config-sysvinit has been being held back for quite a while now.  (several weeks at least?)

@statmonkey, doing a dist-upgrade right now shows an update to "keyboard-configuration".  Not sure if that'll help with your issues...
Forum Netiquette

"No matter how smart you are you can never convince someone stupid that they are stupid."  Anonymous

jedi

I am going to reboot again and verify I'm not having troubles...
Forum Netiquette

"No matter how smart you are you can never convince someone stupid that they are stupid."  Anonymous

jedi

Having rebooted, and then also powered off, I can safely say that on my system I'm not seeing the issues you all are.  Spacefm continues to not work, and also the Disk-Manager tool.  As I can edit the fstab directly, the Disk-Manager utility is not worrisome to me.  Spacefm however, I am most upset about as I use it a lot and truly like it's interface and function.

Sorry for the in and out, I've been sick for the past 2 weeks with a lung infection.  I am sleeping a lot but will check back in every few hours...
Forum Netiquette

"No matter how smart you are you can never convince someone stupid that they are stupid."  Anonymous

statmonkey

Jedi, sorry you are not feeling well but what a trooper still trying to help :)  I will do an up again and see if the keyboard things go away.  I would guess most of this will settle in the next day or two.  I really do a lot of custom stuff to my system so it will be a painful return to normalcy for me.  Oh well. Get better soon and thanks for the info.

VastOne

Had to go on a long bike ride in the poring rain to ease my brain

There are several issues and I want to address them and try to use this thread (or another one) as a catch all for them

This bug seems to validated everything about the "Attempt to unlock mutex that was not locked' that is  killing both spacefm and disk-manager.
It may be possible to regress to the previous pygtk version and resolve it... I am not sure. I do believe that disk-manager is still maintained and it should be fixed.  I do not think IG will fix it for spaceFM but he may surprise us.  Right now I am using Thunar instead and like Jedi said, it just ain't the same...

With the rain pounding my head and wind freezing my gonads, I was able to think a bit...

My issue with a separate /home partition is most troubling.  All I did on that partition was do a dpkg -i install of the old version of lightdm.  Why would that freeze out that partition to all  VSIDO installs that share it? The drive is being mounted via fstab and I can access it from tty1 as me and delete/add files to it so it is not a permission issue.  I copied over that entire partition to a new install as /home/vastone (on a shared partition with /) and cannot boot to it there either. So it appears to be a config setting specific to that /home in .config somewhere

So to be clear I am on a new install of VSIDO, with home on the same partition as / and updated to today ... I chose the package maintainer version (the first time I have done that since creating VSIDO) and I have a vanilla login screen but can access it. Both spacefm and disk-manager are broken

Nice going jedi being sick and coming here to infect us all... I blame you!

Not sure what else I can add... once I access the log files for lightdm on that failed VSIDO build I will post the results but neither lightdm or systemd are giving me much info that I can relate to
VSIDO      VSIDO Change Blog    

    I dev VSIDO

orbea

I just want to add that I'm getting "Attempt to unlock mutex that was not locked" for disk-manager too, but spacefm still seems to be working as expected...

VastOne

^ That is interesting... and definitely adds to this mystery

One thing I have noticed too in all these changes is that even though I do not have any power management enabled I come back to my computer and it is at a dark screen that leads to a login screen  .. my up time shows everything as normal, but every single app I had open prior to this is closed and gone
VSIDO      VSIDO Change Blog    

    I dev VSIDO

statmonkey

Confirming this.  A bit confused about why spaceFM is still working for some.  Curious

VastOne

One thing I am seeing regarding my separate /home partition is that it appears that that directory is not mounting in the login process and a 'new' home directory is being copied over from /etc/skel to the local directory

Of course /etc/fstab still has home labeled and mounted from the original separate /home partition and that is where the confusion begins
VSIDO      VSIDO Change Blog    

    I dev VSIDO