4beta1 (1st build) With gnome live isos only ~/Desktop is present in home directory in either live session or once installed. Checked /etc/skel and it is empty. Reproducible: Steps to Reproduce:
CC: (none) => olavWhiteboard: (none) => 4beta1
Same issue with 4beta1 classic DVD 64 with gnome installation. report.bug.xz in attachment 4474 [details]
/etc/skel only contains tmp directory
CC: (none) => ennael1, mageia, tmb
Summary: Missing directories in home with gnome live isos => Missing directories in home with gnome
(In reply to claire robinson from comment #2) > /etc/skel only contains tmp directory This is all /etc/skel is supposed to contain (when looking without showing dot files) [colin@jimmy linux (colin-v3.12)]$ ls /etc/skel -la total 52 drwxr-xr-x 5 root root 4096 Oct 24 13:13 ./ drwxr-xr-x 170 root root 16384 Nov 4 09:53 ../ -rw-r--r-- 1 root root 387 Oct 21 21:54 .bash_completion -rw-r--r-- 1 root root 24 Oct 21 17:49 .bash_logout -rw-r--r-- 1 root root 191 Oct 21 17:49 .bash_profile -rw-r--r-- 1 root root 124 Oct 21 17:49 .bashrc drwxr-xr-x 2 root root 4096 May 14 2010 .gnome2/ drwxr-xr-x 4 root root 4096 Oct 18 06:56 .mozilla/ -rw-r--r-- 1 root root 3793 Oct 19 15:21 .screenrc drwx------ 2 root root 4096 Oct 18 13:03 tmp/ The various XDG folders (Downloads, Music etc) are supposed to be created by something else... I forget what tho'...
never thought to try that :)
What directories are missing?
Ok, those directories are created by xdg-user-dirs-gtk, which is installed according to the attachment. Don't get it atm.
Please run the following in a terminal: xdg-user-dirs-gtk-update Wondering if it somehow fails to start, or if it isn't executed when logging into the session.
Running xdg-user-dirs-gtk-update has no effect on mga4beta1, with the i586 LiveDVD. xdg-user-dirs-update does create the missing directories, though, so maybe you're calling the wrong command?
CC: (none) => remi
(In reply to Rémi Verschelde from comment #8) > xdg-user-dirs-update does create the missing directories, though, so maybe > you're calling the wrong command? And this one should be run via: /etc/X11/xinit.d/xdg-user-dirs-update So perhaps something isn't processing the /etc/X11/xinit.d files any longer? It should be run by /etc/X11/Xsession, but perhaps gnome/gdm is no longer using it? If so, I suggest adding an xdg autostart .desktop file for this and doing similar things in the xinit.d file that xdg-user-dirs-gtk-update does to avoid starting itself twice under GNOME, KDE and other xdg aware DEs.
Hm, it does not seem to obey stuff in /etc/profile.d anymore either... on a clean mga4-alpha3 install, I ended up with no text / prompts in console and no aliases or anything works... to get a "normal" terminal I "su -" to root and then "su - tmb" back to the user... and then it works... so there is something weird again in gnome land... :/
(In reply to Thomas Backlund from comment #10) > Hm, > > it does not seem to obey stuff in /etc/profile.d anymore either... > > on a clean mga4-alpha3 install, I ended up with no text / prompts in console > and no aliases or anything works... Hmm, isn't it up to bash to read /etc/profile.d stuff rather than the general session? When you're gnome-terminal loads it should load bash and that should ultimately load up the /etc/profile.d stuff... But it does seem somewhat suspicious I have to admit :s
xdg-user-dirs-gtk-update is run via xdg autostart. That it doesn't do anything is the problem. Things like /etc/profile.d is a bash-thing, only if somewhere during the session init bash is used you'll get those environment variables. That is not about GNOME.
This only seems to affect Gnome (so far in my tests anyway)
Actually gdm is sourcing profile stuff: /etc/X11/gdm/Xsession:# This is why we source the profile files below. /etc/X11/gdm/Xsession:# First read /etc/profile and .profile /etc/X11/gdm/Xsession:test -f /etc/profile && . /etc/profile /etc/X11/gdm/Xsession:test -f "$HOME/.profile" && . "$HOME/.profile" and the prompt and aliases all work if I ssh into the box, it's only when I open terminal window from gnome it does not work... anyway, I will do a re-install with beta1 to see if it's reproducable... (iirc someone else reported this too, but I cant be sure for now who it was) and it's somewhat out of scope of this BR ...
From reading the source (badly), it seems xdg-user-dirs-gtk-update only does something once the locale changes or something. I guess you still have to run that other command initially.
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=11607
(In reply to Colin Guthrie from comment #11) > (In reply to Thomas Backlund from comment #10) > > Hm, > > > > it does not seem to obey stuff in /etc/profile.d anymore either... > > > > on a clean mga4-alpha3 install, I ended up with no text / prompts in console > > and no aliases or anything works... > > Hmm, isn't it up to bash to read /etc/profile.d stuff rather than the > general session? > > When you're gnome-terminal loads it should load bash and that should > ultimately load up the /etc/profile.d stuff... > > > But it does seem somewhat suspicious I have to admit :s Actualle the fault comes from gdm. If I use XDM or KDM, the gnome-terminal works as intended... Now to figure out why / what to do... and beta1 Gnome isos are a no-go :/
And indeed its gdm that is broken. I've built a gnome livecd where I used xdm instead of gdm, and then the directories were created as they should
Source RPM: (none) => gdm
and none of the 3 patches we have in gdm alters the behaviour, so i'd say it's an upstream issue
(In reply to Thomas Backlund from comment #18) > and none of the 3 patches we have in gdm alters the behaviour, so i'd say > it's an upstream issue meaning I disabled/enabled one at a time, and tested every one of them
Interesting. I can speak to Ray upstream to see if he has any ideas on this one... Strange that I still cannot reproduce this on my installed system tho'. Seems like it would be the kind of issue that would affect this?
Valid 4RC, currently livedvd gnome 64 5th build
Priority: Normal => release_blockerBlocks: (none) => 11704Whiteboard: 4beta1 => 4RC 4beta1
Fixed in Build 9. It was thought that gnome l10n issues in bug 12328 were related to this but with the dir's now in place the l10n is still an issue. Thomas, you mentioned that the fix was a workaround, i'll leave this open and let you close if you're happy with the fix.
Thomas? What shall we do on that one.?
It's actually still valid with classic dvds
Is this OK now on the Live DVDs? I've had a look and the folders all appear to be there (although created at build time looking at their dates - not at login). Will test an install from classic media at some point very soon.
With an up-to-date Cauldron install, I created a new user, confirmed his homedir was just a copy of /etc/skel, logged in and the folders were created as intended. I'll look at a full fresh install later.
Yeah, for RC live medias I hacked in a call to xdg-user-dirs-update during build to make them visible. This is something to to with gdm, as if you use kdm or other login manager the folders get created on login.
Ok, so I've been reading git commits between gdm 3.6 (in mga3) and gdm 3.10 (current cauldron/ upcoming mga4) and I think I found one reason for profile and language stuff not always working... This is the "breakage": "Remove gdm wrapper script" https://git.gnome.org/browse/gdm/commit/?id=b6c11aa4626f98088fdacf60cd69d6cff22b14bc as before this commit we always sourced /etc/profile and so always get the setup including lang through /etc/profile.d/10lang.sh and so on but after that we dont always apparently trigger any of it. And now I wonder if theese fixes will help (for lang atleast): daemon: get rid of greeter language selection https://git.gnome.org/browse/gdm/commit/?id=0b2d22f63b3e6b3185d4e9a93bb192a21a695f9e session: pass all language vars through to worker https://git.gnome.org/browse/gdm/commit/?id=c672e4e49983d285e829c1ec846d22fbf19bf29a but then we still need to look at the other scripts/configs we use to start Gnome needs to be adapted because of the "remove gdm wrapper script" of course we could restore the "remove gdm wrapper script", but I'd choose that only if we cant fix it properly Thoughts ?
Yup, sounds about right. I'll have a deeper poke at this tonight.
So as far as I can tell, the wrapper script does indeed look rather useless. Ultimate gdm, should launch gdm-session-worker which, in turn, launches /etc/X11/gdm/Xsession. As Thomas already pointed out, this script also sources /etc/profile and eventually exec's gnome-session itself which thus inherits anything set via the /etc/profile sourcing (unless there is some kind of session cleaning going on?) So for the LANG not to be set means that gnome-session was started without first going through /etc/X11/gdm/Xsession. Regarding the suggested commits, I don't *think* they will matter as the first one just removes a feature (and changes library API, so one to be cautious of), and the latter just seems to inherit the env vars for the "worker", but gdm-session-worker starts *before* /etc/X11/gdm/Xsession (which turns into gnome-session). For reference the boot up pstree looks like this when /etc/X11/gdm/Xsession is run: |-gdm-+-gdm-simple-slav-+-X | | |-gdm-session-wor-+-Xsession---pstree | | | |-{gdbus} | | | `-{gmain} | | |-{gdbus} | | |-{gmain} | | `-{pool} | |-{gdbus} | `-{gmain} On the live however, when we are doing the first install bit, we get this: |-gdm-+-gdm-simple-slav-+-Default-+-drakx-matchbox- | | | `-finish-install---{gmain} | | | | | |-X | | |-{gdbus} | | |-{gmain} | | | |-{gdbus} | `-{gmain} The Default here refers to /etc/X11/gdm/Init/Default. Now at this point we have NOT yet run /etc/X11/gdm/Xsession. This is presumably run prior to this point. Note that it is actually here that we also process the /etc/X11/xsetup.d (which is actually what starts drakx-matchbox-window-manager: See Notes below). After this has run, the system should rekick the dm (i.e restart gdm) I've not fully worked out if this is actually done or not, but I suspect strongly that it is not! What this would do is: 1. Keep the environment inherited. 2. GDM_LANG is likely set to en_US.UTF-8 3. When /etc/profile.d/10lang.sh is sourced it uses this and short circuits. A quick test after logging in is to simply: 0. echo $LANG (<-- confirm it's en_US.UTF-8 1. unset GDM_LANG 2. unset LC_SOURCED 3. . /etc/profile.d/10lang.sh 4. echo $LANG (<-- it's now correct) So I suspect, it's the restarting of the DM that's busted. I should be able to test this bit easily enough. Notes: 1. /etc/X11/xsetup.d/30-start-matchbox.xsetup seems to check for /usr/bin/mozilla-firefox. There are comments about starting it with a specific profile for the register page, but this doesn't seem to actually run firefox at all... 2. /etc/X11/xsetup.d/99-dm-reload.xsetup uses a RUNNING_UNDER_GDM env var to restart dm (aka systemctl restart prefdm.service) I'm not sure where this RUNNING_UNDER_GDM env var is set... 3. /etc/X11/xsetup.d/90-speedboot.xsetup This should be nuked!
Indeed, GDM is NOT restarted on the live CD, thus GDM_LANG sticks around and thus we don't get the real locale. Ultimately, this is down to the 99-dm-reload.xsetup not working. I've done some tests and I can tweak things such that it IS restart. I suspect it might be as simple as the lack of /etc/profile sourcing means we don't have /usr/sbin in the path which means we cannot find "service", but I replaced it with direct calls to systemctl and it worked for me (and I got my lang). So I think the LANG related issue is now located. As for the general issue, I'm not sure, but I'd be tempted to call it a freak occurance!
commit c01b45c78de95b0f9dacf6930c58220280ff168b Author: Colin Guthrie <colin@...> Date: Tue Jan 21 22:07:15 2014 +0000 Ensure that GDM is reloaded on live media. With out this the locale settings are not reread and en_US is used for the whole session. I'm not 100% sure why the previous call now fails, but I suspect it could be due to /usr/sbin not being in the path due to /etc/ profile not being sourced early on (i.e. in the gdm binary) and thus this command fails to run. mga#11582 mga#12328 --- Commit Link: http://gitweb.mageia.org/software/build-system/draklive-config/commit/?id=c01b45c78de95b0f9dacf6930c58220280ff168b Bug links: Mageia https://bugs.mageia.org/show_bug.cgi?id=11582 https://bugs.mageia.org/show_bug.cgi?id=12328
OK, so the above should fix the locale thing. Certainly with it applied to the RC Live it allowed me to log in to a French session OK (which previously just gave me English). Other than this, I'd need a way to reproduce the problem of the missing directories. I couldn't reproduce that here. @Claire: How does one reproduce it using the classic ISOs (which you mentioned in comment 24)?
@colin If you do a clean install, does the dirs get created for you ? IIRC it was as simple as even creating a new user and logging in and no special dirs are created then either...
(In reply to Colin Guthrie from comment #30) > > Regarding the suggested commits, I don't *think* they will matter as the > first one just removes a feature (and changes library API, so one to be > cautious of), and the latter just seems to inherit the env vars for the > "worker", but gdm-session-worker starts *before* /etc/X11/gdm/Xsession > (which turns into gnome-session). Yeah, the first one made me somewhat uneasy at this point, but I wonder if the second would still make sense but I think we'll keep it as is for now if it works..
(In reply to Thomas Backlund from comment #35) > Yeah, the first one made me somewhat uneasy at this point, but I wonder if > the second would still make sense but I think we'll keep it as is for now if > it works.. I actually thought about this again as I came home from the office (stayed at work for hacking!). In the first suggestion (https://git.gnome.org/browse/gdm/commit/?id=0b2d22f63b3e6b3185d4e9a93bb192a21a695f9e) because it nukes he use of GDM_LANG, it shouldn't be set when /etc/profile.d/10lang.sh is sourced and the short circuit code there shouldn't be hit. If this works, we could (in theory at least) avoid restarting gdm completely... I'll do a quick test (and nuke te special handling in 10lang.sh) to see if that works...
(In reply to Colin Guthrie from comment #36) > If this works, we could (in theory at least) avoid restarting gdm > completely... I'll do a quick test (and nuke te special handling in > 10lang.sh) to see if that works... OK, so test was: 1. Remove GDM_LANG from 10lang.sh 2. Remove GDM_LANG from gdm/Xsession (partial bit of the previous mentioned upstream commit - not strictly needed) 3. Removed the 99-dm-reload.xsetup Result: GDM *did not* restart, but LANG env var was set correctly and the session was in French. This is IMO a nicer solution, but not sure if the GDM restart does anything else....
If it's still useful, to reproduce just install with Gnome and log in. There were just ~/Desktop and ~/tmp present, and perhaps some hidden bits.
(In reply to claire robinson from comment #38) > If it's still useful, to reproduce just install with Gnome and log in. There > were just ~/Desktop and ~/tmp present, and perhaps some hidden bits. Right, gotcha. My older test VMs didn't seem to have this issue, but a fresh one now does. I'll investigate :)
OK, so this is basically to do with gnome-session packaging. It ships files in /usr/share/xsessions/ which override our ones. Our ones carefully execut /etc/X11/Xsession which processes items in /etc/X11/xinit.d/ among other things. With the file in /usr/share/xsessions/ it overrides this and runs gnome-session directly missing out all our stuff which includes the directory creation. In my quick tests simply nuking these files should be enough. Doing a urpmf to check for similar problems I also see: cinnamon:/usr/share/xsessions/cinnamon.desktop cinnamon:/usr/share/xsessions/cinnamon2d.desktop gnome-classic-session:/usr/share/xsessions/gnome-classic.desktop gnome-session:/usr/share/xsessions/gnome.desktop So I will fix the bottom two but someone should also look at the cinnamon ones and see if they suffer a similar issue.
Please submit gnome-session and gnome-shell-extensions Regarding cinnamon, I suspect that it might need the same fix.
I'll do a quick cinnamon install in vbox now and check
Confirmed by napcok that cinnamon is affected
Wow that was quick :) Hopefully the same fix will help (easy to test if you're installing: just jump to tty2 after package installation and rm the files in /mnt/usr/share/xsessions/ then finish the install as usual, if your first boot is OK and the files created then we can confirm the same fix)
Sorry, but I confirm that too fast. My first Cinnamonn install freezes during last step - Rebooting. Now I installed it again and everything is fine with Cinnamon. All directories in home created.
CC: (none) => napcok
Installed from mga4-final pre-release x86_64 DVD.
Thanks Daniel. That's kinda good news. Now here's my hypothetical one: I wonder if it's GDM that's parsing these files, if so, then we perhaps need to test a cinnamon install but with a gdm greeter for first login! Can you try that with a new user and see if it's affected and if rm'ing the xsessions files solves it without any regressions?
Yep cinnamon seems to be ok.
oh sorry. (makes note to read comments before clicking submit)
Another thing to check: under gdm (and other greeters) are there multiple entries in the session chooser for cinnamon? Prior to my fixes there were four for gnome - two normal and two classic. Afterwards it was just the two of them.
Cinnamon installed with gdm instead of lightdm has two listings for gnome and cinnamon. Actually 2 lots of 2. One is Cinnamon & Cinnamon 2D, the other Cinnamon & Cinnamon (Software Rendering) Only ~/Desktop and ~/tmp are present after logging in to the Cinnamon which accompanies Cinnamon (Software Rendering). When logging in to Cinnamon which accompanies Cinnamon 2D all normal directories are created.
I took a vbox snapshot during install so i'll roll it back and delete those files and try again
An other nice thing... The issue with non-existing text in terminal I reported in comment 10 is now fixed by simply installing the new initscripts/gdm/gmome-session onto the "broken" system :)
At the user creation screen during install, switching to tty2 and looking what is present in /mnt/usr/share/xsessions/ shows.. cinnamon.desktop cinnamon2d.desktop gnome.desktop Checked again right at the very end of installation and still the same, so rm'd them all and rebooted. After reboot available sessions are.. Gnome IceWM Cinnamon Cinnamon2D drak3d After login all dir's are present \o/ so it seems the fix should be applied to cinnamon too.
Fixed in last DVD classical isos
I think cinnamon still needs the fix to be applied though
I mean fixed for GNOME :)
Fix has been applied to cinnamon. Tested here in up-to-date cauldron. It's also fixed in cinnamon
Status: NEW => RESOLVEDResolution: (none) => FIXED