XFCE - collaboration thread to produce a Porteus module

[Ahau]

yes, these issues are going to drive me to drink

Ok -- so, on the filesystem issue:

I have two flash drives set up; on my backup drive, I installed porteus-xfce on an ext2 partition, and it had the error I described above, where selecting "restart" from the menu sent me through the SLiM login screen; when I created a (standard) save.dat on the ext2 partition, and later reformatted the same device to ext4, this issue went away. Then, to double check, I created a save.dat on my main flash drive (ext4), but I formatted the save.dat to be ext2 instead of xfs. The issue reappeared! So, with both a changes file on the ext4 partition and the save.dat formatted to ext2, I booted up the system and logged out three times, then logged into always fresh mode, ran 'ls -R' in each set, and ran diff on the outputs. There was one file that was present in the ext2 save.dat, but not in the ext4 changes folder....that file? /var/run/slim.pid.

I haven't gotten to the root of this just yet...but I'm getting there

Francois -- please try to create a save.dat on your partition (I know it's already posix compatible, but humor me here), and mount that for your saved changes, and give this thing one more test.

What a pain in the ass!

Posted after 8 minutes 34 seconds:
sorry, the commands are 'reboot' and 'halt', not 'restart' and 'shutdown'. LOL You would enter that in the text box next to "Login".

Will your command to setup dual monitors work if you run it manually instead of as a startup script? If so, try adding it to /etc/rc.d/rc.local.

I'm glad your wifi is working better at home...let's leave the issue for now and readdress it later if others have problems. I think we have our hands full with other issues for the moment

If you can find a way to recreate the "popunders", please let me know how and I'll take a look.

It is bizzare that you're unable to access the multilingual keyboard; if you create a save.dat as suggested above, please try to reconfigure the xkb plugin, and let me know if it falls apart on you again.

You are not mentally ill, but I might get there before we're done

[francois]

I will have to go to bed now. Last day of work before Christmas holiday. I will continue testing then. I will be available a lot more. Just take care of your spirit meanwhile. I might be back in the afternoon or in the evening Eastern time.

Posted after 38 minutes 34 seconds:
I think I found the autostart folder for xfce:
/usr/share/autostart

Posted after 17 hours 17 minutes 40 seconds:
I never use save.dat files as I work from hdd. From rc1 and xfce > system > porteus setting assistant I got into a cli with menus. I went thru it but it did not seem to install the save.dat file. Reusing the porteus setting assistant it welcome me back. However, there was no option in the menu for the save.dat folder.

Looking at the faqs for the save.dat folder, I found some info that might need to be updated:
https://porteus.org/info/docs/37-instal ... #USB-linux

There is no such option as Porteus .dat manager:
open up the menu and navigate to "System -> Porteus .dat manager

I will try to install the save.dat from the v 1.0 installation that I have.

[Ahau]

Ok, so after realizing that this was an issue with how xfce is shutdown, I did some more digging, and found there was a bug reported in xfce4-session 4.8.1, in which rebooting or shutting down the system crashes xorg-server, which returns users to their login manager when attempting to reboot/shutdown from the panel. This was supposedly fixed or at least had a work around as of version 4.8.2 (which is what we are running here), but this appears to be exactly what is happening. This issue is repeatable when using lxdm instead of slim, but not when booting into the lxde environment instead of xfce.

From my /var/log/slim.log:

Code: Select all

Terminal: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
** Message: xfsm-shutdown-helper.c:1470: Using ConsoleKit to Restart
xfsettingsd: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
gdu-notification-daemon: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
wicd-client.py: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
Importing pynotify failed, notifications disabled.
Has notifications support False
Loading...
Connecting to daemon...
Connected.
displaytray True
Done loading.

slim: waiting for X server to shut down

/usr/bin/xauth:  file /var/run/slim.auth does not exist


X.Org X Server 1.9.5
Release Date: 2011-03-17
X Protocol Version 11, Revision 0
Build Operating System: Slackware 13.37 Slackware Linux Project
Current Operating System: Linux porteus 3.1.1-porteus #1 SMP PREEMPT Mon Nov 21 10:47:37 UTC 2011 i686
Kernel command line: root=/dev/ram0 rootfstype=ext4 rw initrd=/32/boot/initrd.xz from_dev=UUID:b459f3f5-b0c4-4462-a638-889d03cd8c19 from_dir=/32/porteus/ vga=791 toroot xfce changes=/dev/sdb2/32/ BOOT_IMAGE=/32/boot/vmlinuz 
Build Date: 18 March 2011  12:08:03AM
 
Current version of pixman: 0.20.2
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Dec 22 13:13:31 2011
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(EE) Failed to load module "nv" (module does not exist, 0)
resize called 1680 1050
slim: unexpected signal 15

The first section appears to be several applications that realize they've been disconnected from the xorg server. The next section is slim respawning (I'm guessing that the xorg server somehow reinitialized init 4 in order to recover from the crash, which ran rc.4, which started slim again). After starting back up, slim gets a signal (15?) to shut down.

What I don't know is:
1) why is this crash still occurring when we are using version 4.8.2?
2) why does this behave differently on an ext2 partiotion (xorg still crashes on ext4, but slim doesn't load back up to the login screen like it does on ext2)
3) why does the system restart on my system after the xorg crash, but it remains running on francois' machine?

I've joined the community forum for xfce and will post on a thread over there to see if I can get any help.

[Hamza]

why does the system restart on my system after the xorg crash, but it remains running on francois' machine?

Mostly sure..this is because the gpu/kernel module is more resistant and don't need to be restarted. I had this issue with another distro on two different computers.

why does this behave differently on an ext2 partiotion (xorg still crashes on ext4, but slim doesn't load back up to the login screen like it does on ext2)

Maybe because when a system is crashing there is alot of read/write attempts and ext2 has something ext4 hasn't.

why is this crash still occurring when we are using version 4.8.2?

Problem similar to my own..with a hardware drivers problem compatibility between two majors version ?

[francois]

1) Made xfce_save.dat for xfce beta and booted the beast. My sda7 is on ext2.
2) Edit the file /etc/slim.conf to direct the lock file to /var/run/slim.pid instead of /var/run/slim.lock
3) rebooted 5 times without any problem. xfce just loads in and out directly without going thru any login manager

4) I have put my dual display script in /etc/rc.d/rc.local

Code: Select all

xrandr --output LVDS1 --mode 1366x768 --output VGA1 --mode 1920x1080 --right-of LVDS1

This will not work. And in addition, after a reboot, this added line will not be no more in the /etc/rc.d/rc.local file.
5) For the keyboard issue: once xkb.desktop script has been executed once then it is possible to add layout thru propertied of the panel keyboard icon.
6) To the question What application are you using to manage your wifi connection?
I use wicd.

What is next?

[Ahau]

francois, that is great news! So, we have a workaround, but are missing a final solution. Hopefully my appeal to the upstream developers will either find a resolution in a future release or they can let me in on what I'm doing wrong One little note -- you are still going through a login manager (SLiM) -- you just never see it because it is set to autologin.

I'm afraid I pushed you in the wrong direction with your xrandr script xrandr must obviously depend on a xorg server running, and when your script is in rc.local, it is executed prior to xorg being loaded. I should have paid more attention to what you were trying to do, and given you the final missing step.

Recreate the xrand script that you previously had working (you mentioned that you had to double click on it), and set it some place safe (I've been keeping things like that in /opt/porteus-scripts/thunar, but some other place would do). Then, open the xfce menu -> Settings -> Session and startup -> application autostart tab -> press the 'Add' button, enter a name and description (arbitrary) and then enter the full path and file name to your script in the 'command' box (e.g. /opt/porteus-scripts/thunar/francois-super-xrandr-script.sh), then click 'OK'. The name will show up in the dialog box with a checkmark next to it. A .desktop item will be automatically generated and placed in /root/.config/autostart, and on your next startup, xfce should run the .desktop script, which will in turn run your super duper script.

What is next? Take a break from my merciless theft of your free time and enjoy the holidays!

[francois]

still going through a login manager (SLiM) -- you just never see it because it is set to autologin.

I did not set it to autologin.

However, looking in panel menu > settings, I do not find the usual login window option where one should select autologin. What would be the name of the option?

You should not be that guilty. In fact, I am happy to do something for the porteus distro which I appreciate so much. In addition, it is a pleasure to interact with you.

À bientôt.

[Ahau]

@hamza -- thank you for your explanations, I think you may be right about the differences being hardware related (I see no other variables that could be the cause).

@francois, you are correct; you did not set the system to autologin... but I did This setting is handled through /etc/slim.conf:

Code: Select all

# default user, leave blank or remove this line
# for avoid pre-loading the username.
default_user        guest

# Focus the password field on start when default_user is set
# Set to "yes" to enable this feature
#focus_password      no

# Automatically login the default user (without entering
# the password. Set to "yes" to enable this feature
auto_login          yes

auto_login is set to yes, and the default_user is set to guest. However, if you use the 'toroot' cheatcode, this line will be modified to read 'default_user root' (in fact, making this slight change is all that the toroot cheatcode does).

If you would like to disable this, then you can modify your slim.conf to read 'auto_login no', and you will be brought to the slim login screen every time you start up the system...but I doubt you have much interest in those unneccessary keystrokes

[francois]

I couldn't have said any better. You read in my mind. Is this a suggestion so that I remove autologin for a test?

I really do not understand the fancy of the normal user and in the Linux world the heresy of working root user.

[Ahau]

No, I'm not suggesting that you do a test

I would understand the concern (over always running as root) better if I had a critical system installed natively, which needed to be reliable and secure. The truth is, if I'm screwing around in porteus and with a slip of the finger I hit 'rm -rf /etc' instead of 'rm -rf /etc/slim.conf.old', salvation is but a button's press away. If I did that with a normal system....

[francois]

And what about data and modules backup?

[Ahau]

I usually run as root, in always fresh mode. So, as long as I don't blow up my flash drive, I'm OK. Yes, I have done that before. Would forcing me to use 'sudo' have stopped me? Probably not, it would have just pissed me off more before I nuked it.

Anyway, back to XFCE -- I'm putting a temporary hold on further development (will still respond to bug reports, questions, etc. here) until after the release of Porteus V1.1 final. I need to focus on our documentation and some other pet projects.

Cheers!

[Ahau]

francois -- some good news for us: I found a patch on the XFCE bugzilla that is intended to resolve the issue with xfce4-session bumping the user back out to the login manager:

https://bugzilla.xfce.org/show_bug.cgi?id=7887

I applied this patch and recompiled xfce4-session this morning, after which xfce stopped bouncing back to slim (even when saving my changes to the ext2 save.dat). If a fix for this bug isn't implemented upstream before my next build of xfce, I'll apply this patch and ask for your help in testing it

[francois]

I will be pleased to be there for testing. Meanwhile, I am playing around other distributions with xfce on it, and even exchange with those comparing these distributions with xfce 4.8 on xfce forums, but also on vector, ubuntu, debian and maybe pclinux xfce versions.

Yet, I think that porteus is a very good basis for xfce. But also, I realise how performant are the kde distributions we have.

Thus, at the risk of repeating myself, I will be pleased to be there for testing your xfce modules.

[crashman]

Hi Ahau

Your XFCE is my standard desktop thank you for great job