Light DM issues

[jedi]

on the spacefm issue, upon a reboot, when i try to open it, it will flash on the screen for a second then disappear.  That it is working for orbea is very confusing to me.

@orbea, are you on the latest version of the VSIDO ISO's?  Are you using Debian's Kernel?  As I mentioned in an earlier post, I'm using the Liquorix Kernel myself.  Also, what version of spacefm are you using?  Thanks...

[orbea]

I installed recently with the Aug 21 iso, I haven't changed the kernel or spacefm from the defaults, the only thing I can think that I'm doing differently is running spacefm in daemon mode, maybe I just need to reboot to break it...

[statmonkey]

Have you looked at your /etc/lightdm/lightdm.conf to see what is really being called?  I doubt anything.  I would also look at what systemd is calling on boot. 

I monkeyed with this til very late last night and had some similar issues with drives/boot.  Unfortunately by the time I got it figured out I was so tired and so confused that I can't really remember what I found out or how I did it.  I do know that I think it is unacceptable to make structural changes to things like login/dev calls etc. and not offer any documentation or warnings other than the "maintainer" version question.  I rarely or never accept maintainer versions and this is the first time I ever remember that a program just inexplicably changed what it called, how it called it and where it called it from without warning.  Lightdm was calling the greeter and lightdm.conf from the /usr folder structure which in turn could be used to call things from your structure as you saw fit.  I can't seem to plug anything into the /etc/lightdm/lightdm.conf to get the same results nor is the file documented as to what changed or why nor is there any info online about it from what I can find.  Frustrating to put it mildly.  I know this is the way it is, go with the flow, take your medicine like a man and all that rot.

[PackRat]

@vastone - regarding your /home partition not mounting at boot, any other time I've seen that issue, it has always been related to a problem with gvfs and/or udev (the two work together don't they?).

Edit - another update of lightdm today (21 Sept). I have yet to experience any issues with lightdm. However, inxi is no longer working - appears some directories and some binaries have been replaced:



@vastone - curious that /dev/disk/by-label is a missing directory. All my partitions are mounting though.

Edit #2

Mirage is also giving the error -

Code: [Select]

Attempt to unlock mutex that was not locked
ristretto works though.

[orbea]

maybe I just need to reboot to break it...

Yep... 

[statmonkey]

I think PackRat as per usual is right on with this.  I am facing a re-install at the least but am not comfortable with where things are, it makes little sense to me to reinstall and duplicate the issues I have (plus more) with a new system.  I am in hopes I can struggle along until things settle down.  Among my issues the biggest is that my 4 disk external drive is crashing my system on any attempt to use it.  Hard resets are courting disaster and I am looking at two or three a day.  Adding to that my system is doggy on both boot up and operation along with many of my environment settings/customizations being broken.  Reading this I was reminded of something I saw over in the Aptosid forums some time ago, to wit:

In most cases the migration from sysvinit-core to systemd-sysv is supposed to be smooth and transparent, basically with the only visible effect being there less verbose startup messages (by default). Systemd is stricter when it comes to invalid fstab entries (like long forgotten swap partitions, but also other (syntax) errors are punished by systemd; sysvinit often managing to boot regardless of those is the real error here). Likewise systemd doesn't like dependency loops in system dæmons, this affects a handful of (broken) services (e.g. setserial), which declare conflicting service dependencies and might affect booting.

I could be suffering from all or none of these.  Unfortunately a less verbose messaging system means exactly that, it's less verbose which in turn means you are often depending on in app documentation, etc. to decipher where the problems are.  I feel a little like I brought a knife to a gun fight.

Anyway, the whole udev/gvfs handling has changed and the stricter fstab handling as well means that I am at a bit of a loss. I really need to understand exactly how the system is initializing drives at this point. 

[orbea] sorry you have joined us in losing spaceFM (which for me at least meant handling external drives with ease).  I am seeing a lot of things that are broken but can't look into them at present my priority has to be getting my external drive/sandbox/testing/backup environment back. 

My apologies if this seems like random blathering.  I have gone from light-hearted teasing on this to actually becoming concerned.  I am not seeing a lot on the web on this so I am guessing this must be about my customizations and personal needs, so I guess there is that

[VastOne]

This is all over the place (Attempt to unlock mutex that was not locked) all these links just in the last month

http://forums.linuxmint.com/viewtopic.php?f=47&t=178152

https://code.google.com/p/gtkdialog/issues/detail?id=77

https://bugzilla.redhat.com/show_bug.cgi?id=1138146

http://ubuntuforums.org/showthread.php?t=2244969

http://murga-linux.com/puppy/viewtopic.php?t=95556&sid=e3a5e91a505b42d2feef7c31005f67a7

I feel for you statmonkey and know you are in a bad way... We have lived on this edge for quite some time with little or no issues and now they arrive in bunches

I still cannot access my old home partition on a boot with it as defined as my home in fstab

The only time I have ever seen this was when I did not have the correct access rights to the data.  The fix was always chown -R vastone:vastone /home/vastone as root .... the behavior is exactly the same as this issue, the fix does not work

[VastOne]

For anyone using pcmanfm or thunar and get a not authorized to perform operation when trying to mount a device

edit / create

Code: [Select]

/etc/polkit-1/localauthority/50-local.d/50-filesystem-mount-system-internal.pkla
with this

Code: [Select]

[Mount a system-internal device]
Identity=*
Action=org.freedesktop.udisks2.*
ResultActive=yes
It will resolve all mounting problems as long as udisks2 and gvfs are installed (both are by default in VSIDO)

Not as secure or as elegant as spaceFM but a fix for now

[VastOne]

The tiniest and simplest things can bring down a giant...

The reason I was not able to boot into my /home/vastone directory had NOTHING to do with the directory .. it was the new lightdm login session that does not use a default config anymore... I did not have fluxbox selected in the settings on the top right menu items and it was trying to launch a default session that was not there

I do not know what to be pissed more about, the fact I missed something so FECKING basic or that lightdm is too FECKING stupid to understand fluxbox is the DM

Damn it all

[statmonkey]

Really glad you got it sorted and many thanks for the policy kit hint.  The situation on the apps that don't work now is a different story and the idea that such a radical change in how an app functions comes through with no documentation/warning is still a biggie for me.  This is not what I have come to expect from Debian as I ranted earlier.

[ozitraveller]

I stupidly accepted the maintainers config to be installed too. And then had to use startx to start the de.

I added back all the settings I used in lightdm.conf and rebooted to discover I couldn't login. I used systemrescuecd to edit lightdm.conf and comments out the lines I had just changed, and rebooted. Login now worked!

My original : lightdm.conf

Code: [Select]

[SeatDefaults]
#xserver-command=X
#xserver-layout=
#xserver-config=
xserver-allow-tcp=false <--- now commented out
#xdmcp-manager=
#xdmcp-port=177
#xdmcp-key=
greeter-session=lightdm-greeter <--- now commented out
greeter-hide-users=false  <--- this still works, displays users dropdown
#greeter-allow-guest=true
#greeter-show-manual-login=false
user-session=xfce  <--- now commented  out
#allow-guest=true
#guest-session=UNIMPLEMENTED
session-wrapper=/etc/X11/Xsession  <--- now commented out
#display-setup-script=
#greeter-setup-script=
session-setup-script=/usr/share/star/star-user-setup  <--- now commented out
#session-cleanup-script=
#autologin-guest=false
#autologin-user=
#autologin-user-timeout=0
#autologin-session=UNIMPLEMENTED
#exit-on-failure=false

Anything that is associated with session causes a lock out.

Only uncommented setting line

Code: [Select]

greeter-hide-users=false

I don't have any problems mounting or unmounting.

https://tracker.debian.org/pkg/lightdm

[statmonkey]

So my testing of this has shown me that any customization that I was doing in the lightdm.conf causes it to fail.  I was using lightdm to call and configure my arandr, etc. and attempts to do this in the new setup fail.  I haven't tested calling it as a separate script yet but do know that if I wait until the system settles after login and then run my old default.sh (the script I was calling within lightdm before) it does actually successfully set up my environment.  I am sure that there is some work around just wish there would have been some warning/documentation that would have provided some guidance here.  I am finding several things that are still borked but not ready to comment until I uncover more of the root of the issues.

[jedi]

I have found I can logout, but am unable to 'reboot' or 'shutdown'.  This is ridiculous!  VastOne, glad you got your /home back...

If I try to 'reboot' or 'shutdown', I am sent to a blank screen where it just hangs.  I let it set that way for quite a few minutes to no avail.  I end up having to do a hard reset to do either.  This can only lead to disaster at some point...

Same results from the menu or tty.

Also what happened to "uptime"?  "The following applications are missing from your system: uptime" this comes from running "inxi --recommends".  It says to add it to my system I need to install the proper distribution package for my system: Debian: procps
procps is already the newest version

And yet, Conky displays the uptime just fine...

Like I said, ridiculous...

[VastOne]

^ That seems to be related to you or just your system?

I cannot reproduce any of these behaviors

[jedi]

Yes, like statmonkey, over the years I've "customized" too many things to remember.  The beauty of VSIDO, there is NO NEED to remember!  I reinstall, copy /home back and voilà!  So, yes, it is just my system...