do have any symlink network mounts? If so, that may be the cause
I didn’t set any. So, if they are not pre-set by default, no.
no, you would have to create them.
did you have this issue on a previous Boot Environment (BE)?
I don’t think so. I rarely use lumina but I never had to ditch a BE before because of that problem before 17.12 came along.
FYI/btw I tried solving that problem by (via appcafe) unlocking trueos-desktop, uninstalling lumina re-installing it (and all other packages that were automatically uninstalled as well) and re-lock trueos-desktop, hoping any corrupted file would be replaced. But that didn’t change anything.
So far I haven’t found the file(s) / reason why this happens. Also, I have never managed to log into Lumina on a respective BE ever again once that problem occured.
In fact, at the moment, all BEs seem to be corrupted that way, which make me think that maybe it really is some file/setting within the home/user folder causing this problem. But, as stated, it can’t be a file/setting (at least not only) one in the folders /home/[user]/.lumina, /home/[user]/.config/lumina-desktop or /home/[user]/.config/lthemeengine or the file /home/[user]/.config/lumina-mimeapps.list.
I renamed all those without avail. The start info looks different (expectedly) but still hangs at “finalizing”.
look at how much drive space is available?
There is another recent thread having issues, and it turned out is was a lack of space
Well, I guess >50GB of free space should be enough.
And that’s after I added 5 BEs for testing.
But I’m still not sure what to think. I upgraded one of the BEs to UNSTABLE and was able to login into lumina at first boot. Have to try again. Especially after having used xfce since then.
I’ll report back.
how much disk space available?
zpool list -v
thses 2 command see how much space is left
In case my post wasn’t clear: I have about 52GB free space left. I’ll try your commands next time I’m on TrueOS. My number comes from thunar. Should be ok, too.
just because “you think” it might be enough, does not mean it is
BE Active Mountpoint Space Created
initial - - 4.3G 2017-10-22 12:20
12.0-CURRENT-up-20171209_172152 - - 6.0G 2017-12-09 17:21
12.0-CURRENT-up-20180201_142817 - - 93.8M 2018-02-01 14:23
12.0-CURRENT-up-20180202_151937 NR / 20.3G 2018-02-02 15:19
I’m not sure what you mean.
My TrueOS system is on a 100GB partition, more than 50% of which are free - with 7 BEs, the largest one has about 12GB, another one maybe 10GB, the others between a few hundred MB and 5GB (all values out of my head because I’m currently running W7). So disk space-wise all pans out, as far as I can see.
That “think” was a rethorical/ironic one. Never in my zfs life had a BE with 20GB or more. Though I had some problems with disk space back when my partition for pcbsd/trueos was just 20GB and there was a update due… Had to uninstall quite a lot to get enough free disk space to be able to update - until I discovered pkg-static.
Just saying that disk space is not an issue. And why would it matter for just logging into Lumina, anyway? All those BEs I have now I only have because I want to figure out the problem and potentially have a sane, unspoiled BE. Usually I only have 1 or 2 BEs.
But I’ll come back to you with the output the commands your provided give me.
just letting you see my last BE was 93M and this one is 20.3G
last last year, I had one 49G, 2 failed upgrade had ate space
Ok, now I can reveal my free disk space via different tools/command:
Thunar: Free disk space: 40,2GB
df -h: available disk space 37GB
zpool list -v: free disk space: 40,5GB
BE disk spaces: 13GB, 11,5GB, 11,3GB, 2,7GB, 46MB, 42MB, 28MB
I’d still say, free disk space is not the cause for lumina to hold at finalizing.
I’ll do some more login tests now.
Repeated tests show that the only BE I can login into lumina on is UNSTABLE. And on that one it takes 1 min. for “finalizing” to, well, finally finalize and get to the desktop.
Before 17.12 came along (June/july? 2017 Stable + August 2017 Update) that never was an issue.
On none of the 17.12 STABLE BEs I have the “finalizing” process finishes (within 5 min. at least). Unfortunately my working August 2017 BE got pruned by an update process because back then my BE limit was too low and I couldn’t tell the process if and which one BE to prune or rather to cancel the update process…
Please do an
ls -l ~/Desktop on your system and see if you have any symlinks to the “/net/…” directory tree. Simply checking the existance of those files will try to load the network mounts and is the primary reason I have seen for the Lumina login to “pause” on the finalizing step.
Will do and report back.
Thanks for the hint.
Well, no “/net/…” symlinks. There were some “.desktop” symlinks I now deleted. Some even dating back to pcbsd, they always escaped me because no more icon, just plain white - similar to the txt files on my desktop.
Even cleared the Desktop completely incl. the icons xfce fixed on there.
But still no luck when trying to log into Lumina on a 17.12 Stable BE (incl. Jan 2018 Updates).
I can confirm the very slow logins with PCDM, and relogins are even slower.
Therefore: A suggestion:
If someone would tell us, what to check and observe, some users could remotely ssh-login to TrueOS, and observe PCDM’s behaviour while (re-)logging in.
Then we would have some data.
Do you have any iSCSI or FC volumes connected e.g. for VMs?
I’ve also encountered very long lumina startup times when automount was enabled and constantly froze my VMs because it periodically tried to access the volumes and therefore was blocking I/O. Since I’ve nuked automount on all my systems that access network storage/volumes on a regular basis, lumina startup times also went back to normal on these systems.
We also had sporadical problems on clients with USB drives connected at boot, also likely caused by automount. Still didn’t find the time to dive into this to fully resolve the issue, but I was thinking about setting additional requirements for the automountd service to start it after lumina - don’t know yet how this interferes with autofs mounted home directories…
Thanks @sko for the hint.
Culprit found. It’s automount for me, too.
Disabled -> no problem logging in.
Enabled -> logging in halting at “finalizing” “forever”. At least too long for me to wait out.
But: This is only a problem with Lumina. No problem with xfce in this regard. And, as far as I can tell and remember, this didn’t happen with the pre-17.12 STABLE update and it doesn’t happen with the UNSTABLE “release”, at least not the one from about 2 weeks ago.
“Only” the dev “know” what happened to “automount” in 17.12 that wasn’t there before and was fixed in UNSTABLE.
RC3 - update (taken from telegram) - discussion thread