SliTaz Forum
You are not logged in.
I've noticed some very interesting, unexpected behavior....
After booting and being logged as user tux, if I exit Xwindows
with Shift-Ctrl-Backspace and then enter either 'startx' or
'tazx', I get again tazx configuration dialog, but this time
around it does not work, it quits with a dialog saying "quit
Quitter" and later the console error message:
/usr/bin/startx: exec: line 11: /home/tux/.xsession: not found
...but there was never a /home/tux/.xsession file... only a
/home/tux/.xinitrc was created. So both 'startx' and 'tazx'
do not work properly to restart xwindows.
I've read the script /usr/bin/tazx and I can see that during
configuration it creates a /home/$USER/.config/openbox directory
with configuration files and then /home/user/.config is chowned
recursively $USER.$USER ...so is this a matter of file permissions?
I'd like to understand how this works and why it is happening so.
My question is, wanting to restart windows from console mode,
what command do I need to enter or what file do I need to
modify in order to make it work as when the system boots up
afresh?
If someone is willing to explain why this is happening this way,
it could be good learning stuff 
Offline
You're just missing the .xsession file.
Try the following commands:
touch .xsession
echo Xorg & > .xsession
echo exec openbox-session > .xsession
startx
It should work now 
Offline
for what it's worth, I've never been able to get X working from the command line. either it works on boot up or you reboot.
Offline
hmm, Trixar, somehow your post squeezed in before mine! I swear, I hit send first!!!
Offline
Unlikely, and I just restarted Xorg twice to prove it works 
Offline
Hm. If only I had a faster laptop! I still stick by my version, I hit send first. You must've sneaked your post in!!!
Offline
Well at first it gives me: Permission denied
because the file is not yet executable.....
chmod u+x .xsession
fixes that but I still get the following errors:
/usr/bin/openbox-session: /home/tux/.config/openbox/autostart.sh: line 8: ivman: not found
........
Openbox-Message: Failed to open the display from the DISPLAY environment variable.
tux@slitaz:~$
(lxpanel:1487): Gtk-WARNING **: cannot open display: :0.0
tux@slitaz:~S ACPI: EC: missing confirmations, switch off interrupt mode.
Are you sure you actually tried what you wrote on your install of Slitaz stable?
Offline
Did I delete my .xsession file? No. Did I restart Xorg several times? Yes. What I gave you was what was written in my .xsession file minus the parts commented out. Anything else I expected you could work out for yourself.
Now comes the question of why ivman fails. It's not commented out in my autostart.sh and works fine with my install of SliTaz. This tells me there is something going wrong somewhere.
Offline
@Trixar_za
I just tried it. Your method works - in case the permissions are all ok.
With the boot command line ,,home=/dev/sdb6" I run into some troubles.
Offline
For completeness, you can find all the Xorg related files @ http://trixarian.net/paste/6
Offline
Guys, are we talking about Slitaz 3.0 stable?
I have the CD made with the iso I downloaded from this site about a week ago...I don't know if you have different versions...
I've tried this on both my desktop computer and my pentium 4 laptop, and I get identical results on both...
It is true that my homemade install was missing the .xsession file...
but I have now tried with the original iso downloaded from this site, and it has of course the original .xsession file, but the result is exactly the same.
The error messages I posted in my previous post are from the original iso I downloaded.....I burnt it to CDROM and absolutely nothing was changed. So there you have it.
Maybe the iso I downloaded from slitaz.org a week ago has been upgraded or something and has this bug, I'm not sure.
EDIT: Actually, I might have made a mistake and the one I have kept might be a slitaz 3.0 downloaded last year and then never actually used.... What I'll do, I'll download it again and burn it to CD and try it out and see if I get the same behavior. I'll let you know.
Offline
SliTaz iso's are very sensitive to changes or corruption because of the compression tech it uses to make the iso size smallter. It's for this very reason that I can never download an SliTaz iso with a download manager that splits the iso into separate chunks while downloading. Iso's downloaded like that never have a matching md5sum nor do they function 100% correctly, which is why I developed the habit of clean downloading the iso.
The best way to check is to use the md5sum command to check the checksum of the iso, then compare it against http://mirror.slitaz.org/iso/3.0/slitaz-3.0.md5 to see if they match. If they do, then you have a prefect iso copy. If they don't, you have a bad iso copy. Note, this checksum is only for the iso. If you burn it, the cd's checksum will be different (or always is in my experience).
Offline
OK, this is what I just did: I burned a new CDROM with the Slitaz 3.0 stable iso that I had downloaded six days ago (February 3, 2012 @ around 12:00 noon U.S. Pacific time), since I am on a slow connection right now.... And it is indeed different from the one from last year....you see, on this one there is no .xsession file in the /home/tux directory, it is missing from the original iso.... (I didn't think I had deleted that file myself....) But the behavior is identical to that of the other iso, the error messages are exactly the same.....the only difference is that this one, just like my homemade install, gives the message:
/usr/bin/startx: exec: line 11: /home/tux/.xsession: not found
What I'll do now, I'll check the checksum of the iso as you suggested, to see if it's the same...
Offline
iso I downloaded last week:
1f3c28d6818bf754c47f7b5fae7a74cf slitaz-3.0.iso
http://mirror.slitaz.org/iso/3.0/slitaz-3.0.md5:
1f3c28d6818bf754c47f7b5fae7a74cf slitaz-3.0.iso
So this means that the iso currently available for download is missing the /home/tux/.xsession file and that it exhibits the behavior I have described.
If you don't believe me, download it yourself and check it out.
Offline
Well, I just tried it. Genko is right, facts are facts. If one follows
touch .xsession
echo Xorg & > .xsession
echo exec openbox-session > .xsession
startx
it works, but one has to set .xsession executable.
Offline
Well, michaelbischof, perhaps it works with the Slitax 3.0 Stable iso you have downloaded a while ago, but it doesn't with the one currently available for download with checksum 1f3c28d6818bf754c47f7b5fae7a74cf slitaz-3.0.iso
This one currently available for download is missing the /home/tux/.xsession file and entering the commands:
touch .xsession
echo Xorg & > .xsession
echo exec openbox-session > .xsession
chmod u+x .xsession
startx
generates the error messages:
/usr/bin/openbox-session: /home/tux/.config/openbox/autostart.sh: line 8: ivman: not found
........
Openbox-Message: Failed to open the display from the DISPLAY environment variable.
tux@slitaz:~$
(lxpanel:1487): Gtk-WARNING **: cannot open display: :0.0
By the way, I'm not personally interested in fixing this bug in the currently available iso.
All I would like to know is what modifications need to be made to the configuration files, after slitaz has booted up and after shutting down xwindows, to make slitaz believe that it is starting anew and therefore open a fresh x session under user tux, as it did just a few minutes earlier.
Can someone explain how this can be done? For me it's more of a learning-about-slitaz thing than it is about fixing this current bug. I think other users of slitaz with an inquiring mind would be much interested in such knowledge too. Slitaz is a great distro and it's great learning about it....
Offline
Wrong, Sir:
the check sum of mine is the same. K3b reads:
1f3c28d6818bf754c47f7b5fae7a74cf
Your case is a bit mysterious for me. Normally I had such troubles on slitaz when I run into troubles with permissions.
An advise: http://doc.slitaz.org/en:guides:faq-login
This worked for me a lot: but I used it only as a kind of inspiration. I created a new user, copied all the .config files and directories from /root to /home/new.user and then changed the ownerships. That worked.
Slitaz still is full of small nasty problems, like this one:
http://forum.slitaz.org/topic/ocale-cannot-set-lc_ctype-to-default-locale
After installation of perl the locales are set somehow wrong, leafpad wants to store anything in ANSI something if I am careless.
Happy hunting!
Offline
Who from the Slitaz team can correct/change the following FAQ?
http://doc.slitaz.org/en:guides:faq-login
,,Explanation
This is caused when files in the user's /home directory are not properly configured. The following files must exist, this can be verified with the ls -la command:
.Xdefaults
.xinitrc
something else?"
Yes, this xsession-file problem is not yet there! When I created it yesterday using the method of Trixar_za it was not set executable!
Offline
Those apps run fine for me with perl install, so it's probably only a issue with some locale setting. Since SliTaz 3 was only starting supporting locales other than us english and french, it's to be expected that some packages don't have the all the locale files to work with all languages.
Secondly, I installed SliTaz, which is probably why it generated the .xsession file. Your assumption that it's a newer iso is wrong too. It hasn't been touched or altered in nearly 2 years.
Thirdly, Linux doesn't get slower with the more stuff you install or uninstall (it doesn't have a registrary to clog up), it doesn't become more fragmented as it goes (journaling takes care of that automagically) and any linux you boot will be as fresh as the day you installed it. So your whole reasoning for putting yourself through so much shlep is based on questionable logic indeed.
I also know for a fact you'll ignore anything I just said and do your own thing. Google why linux is better and spend some time reading the first link that comes up. It's pretty eye opening and will save you hours of learning things the hard why.
Offline
? Hmmh, what person, what comment are you adressing here? A question, before any comment is given.
Offline
First part is about your issue with installing perl. The rest is for genko.
Offline
This perl thing is uncomfortable, but not really serious.
,,Secondly, I installed SliTaz, which is probably why it generated the .xsession file."
No, it is not connected to that. I booted a 3.0-LiveCD in order to check out whether genkos observation is right or not. He was right.
On the other hand: if such a thing happens the most easy thing is to login as root, create a new user, login in as this new user. And then, in case it works, copy all the .config files and directories to the old user and set the permissions right.
This permission issue is most likely the biggest problems for all people who start Linux. Till someone understands why it is meaningful that a user cannot type ,,fdisk -l" it takes some time.
Offline
Guys, I don't understand why my reasoning would be faulty.
To make it very simple to you:
1) I downloaded the current iso for slitaz 3.0 stable.
2) Burned it to CDROM, as is.
3) When booting, and after exiting Xwindows, trying to restart Xwindows I get the errors mentioned above, when following the procedure mentioned above.
I think it is very straightforward and there is no faulty thinking involved here, just facts.
Trixar, as to your statement that I am assuming wrong when I say I have two different iso's.....I am telling you the truth, it's not assumption, but facts. I tried to come up with an iso checksum for the old iso to show you, but I only have the already burnt CD, not the iso. It has a checksum file with checksums of all the stuff on the CD, but not of the iso itself. This is the older iso which came with the .xsession file in /home/tux. If you know of a way to derive the iso's checksum from a burnt CD, please let me know and I will post it. In the meantime I'll post below the checksum file found on this CD, maybe it will be of help in identifying the iso's checksum, so that you will know exactly what I am talking about:
7d2a57627ef70adf1324739387059868 boot/vmlinuz-2.6.30.6-slitaz
df4522b4aade234b74d7827831cdbe58 boot/grub/example-menu.lst
69976741f777a6fb9e282da2b4c6b2c7 boot/rootfs.gz
3c8a0c5111fef9fd9e90ac921e8e327c boot/isolinux/fr.kbd
38405edb84e31dee769230d081ca7732 boot/isolinux/ifmem.c32
c7964057a948365f5cfb49c952c4aeea boot/isolinux/help.txt
0bb9ea953e54dd56025ebf4d293c1492 boot/isolinux/us.cfg
7ec434dafe56fbfbbd9f609a8e51adf1 boot/isolinux/isolinux.bin
c4732bb5511797e44b6198ed04eba45a boot/isolinux/en.kbd
3e850f812b57f524a3cf52b0959fe32b boot/isolinux/en.cfg
6045a9cf649a821bf5289b5e52c20229 boot/isolinux/de.cfg
6c4945fd7122c89bf3a65be1eb0a15b5 boot/isolinux/ru.cfg
a2b7cf1366d6b35066a0424c9558cc06 boot/isolinux/ru.kbd
8e2697879614512c059f4f467ba0caf0 boot/isolinux/poweroff.com
b66c8487e0103be66280d1046612e7e1 boot/isolinux/splash.lss
2499f5ae8924daffbd85505ddbbd2f17 boot/isolinux/hu.kbd
969029d075af9c6fa48601358603fa0b boot/isolinux/ca.kbd
1ebcf7c9072e3cfb832b3a84e62d93f9 boot/isolinux/br.cfg
113bbeb0cd1d2b14db013de5a9b7fb9a boot/isolinux/es.kbd
7bfb2f1ff980de8ba0b66ccb96f4d70e boot/isolinux/display.txt
5c058e6607591a20d6c9d99b51a3b3e4 boot/isolinux/de_CH.cfg
85de1ba17d691f218a81f9ebbab8ecc9 boot/isolinux/enopts.txt
58cacedac9659777534ed5c8dd6f2be6 boot/isolinux/de_CH.kbd
14e3d138bdaa847f9ecb0f276803015b boot/isolinux/options.txt
4c27bfdfa950ea1529a8381ba55a3695 boot/isolinux/isolinux.cfg
58a9b06849620d07c19eeebf28ac59af boot/isolinux/hu.cfg
66e6e3d19136423c0a66b1708269ee43 boot/isolinux/es.cfg
c1b9d6dc81f69b2b905ee2ad4033328e boot/isolinux/de.kbd
2ba424ca6ff85d7185c7eba66ff307b9 boot/isolinux/it.kbd
93d3998853b3563bb09e6ec10f6a7f19 boot/isolinux/fi.kbd
9ac666a92b7e4bdaa13491f4199513b9 boot/isolinux/be.kbd
e7d7816a17e18b75b22a65d049ccec4c boot/isolinux/be.cfg
fdd033d8a3afeaba05f6350739c6086e boot/isolinux/common.cfg
292e5b1b7da75026fb99a260b342a237 boot/isolinux/reboot.c32
db34226bf9ac6f1f64abb333d471d9d8 boot/isolinux/ca.cfg
10f684b00785b093411a4f1a83af2a6c boot/isolinux/jp.kbd
99ee137e600923903792ca8a512e53f5 boot/isolinux/isolinux.msg
723693a6896757559c96a95e50e6a94e boot/isolinux/fi.cfg
a67f97b4b8b23adf21d4aa068976b82c boot/isolinux/fr_CH.cfg
e0583781034a89344786c0afd3a9987b boot/isolinux/it.cfg
4d7599cb46f6dd691bdacd36197a02a3 boot/isolinux/fr_CH.kbd
9c3eb2869d0e16d5044bc166c70b0e66 boot/isolinux/enhelp.txt
d933fd4d8d1aa139e4327e62611a3e4b boot/isolinux/fr.cfg
e2c865db4162bed963bfaa9ef6ac18f0 boot/isolinux/us.kbd
7e7b79486db55c3a41e4d2be5055d681 boot/isolinux/pt.kbd
95d4076bbcb359a06e44b15030da9424 boot/isolinux/br.kbd
7d499ea63a3e6036652f24836d8b2c09 boot/isolinux/jp.cfg
63c564e204b7ea4c96e0d8aeb9a9ff07 boot/isolinux/pt.cfg
7d2a57627ef70adf1324739387059868 boot/bzImage
2ecfce30fc54f0c83c66db4fbe1dd616 boot/gpxe
7b2e71f249953e0d82cb6d08f64cb235 images/header.png
f696018bce9be2bdf9f93f910eeba926 index.html
d1fb41c783bddb6d2107ea9453c387f9 README
4a57d4663e381c47e869e12b236c395e style.css
I'm going to follow michaelbischof's advice and create a new user to see if that works....
Offline
In the meantime, having got to be curious, I used a harddrive installation based on 3.0, the same md5 that you used, genko. There I have the standard user ,,tux". So I created a new user ,,michael" using the controlbox. Then I logged out of ,,tux" and tried to login as ,,michael". It was not possible. There was a directory ,,/home/michael", but in it were only .profile and .ash_history.
Then I copied as root /etc/skel complete to ,,/home/michael" and changed the ownership to michael. Login was not possible.
Then I used the method of Trixar_za to create an .xsession file. It worked, login was not possible. I had to manually make it executable, of courese. Then it worked.
So, plain empiry. I mean I did exactly what I described and the result was like I described it. No blame to anybody, anything, just an experiment. Normally on slitaz I use only ,,tux".
@genko: but you can login as root and have a working Xscreen, do you?
Offline
@michaelbischof
I tried what you suggested, "On the other hand: if such a thing happens the most easy thing is to login as root, create a new user, login in as this new user. And then, in case it works, copy all the .config files and directories to the old user and set the permissions right."
Booted CD which got me into tux's account in Xwindows. CTRL-SHIFT-BACKSPACE to exit Xwindows, then logged into root and created user joe. Logged as user joe, # startx ..... did not work, I get exactly same behavior as before. No permissions were changed.... This is the iso currently available for download. The only commands entered were the ones mentioned in this thread, and I have repeated this procedure more than ten times, so far, with exactly the same result in all instances.
I just don't understand how you can have the same iso as I have and get a completely different behavior from the software when doing exactly the same procedure as I do.
Offline
[ Generated in 0.019 seconds, 7 queries executed - Memory usage: 1.6 MiB (Peak: 1.77 MiB) ]