New features which should be implemented in Porteus; suggestions are welcome. All questions or problems with testing releases (alpha, beta, or rc) should go in their relevant thread here, rather than the Bug Reports section.

Ahau wrote:@tonio, very interesting, you're entering init 4 after logging out of xfce from init 3 (I think...) Please provide me with the output of 'cat /proc/cmdline' so I can test with the same exact setup (if you are savinfg changes, please let me know the filesystem).

When I activate the rcM module, I get the following output. I could not capture shutdown message, but I will try again
http://pastebin.com/eyk5dqQG

EDIT:
forgot to mention I am not saving changes. I was using this xfce spin to build & test the kertex module I have built for i486.
But from what I gather your suspicion is correct, when shutting down, the instead of going to init 0, the machine turns to init 4 and presents login screen again. Removing the module allows the machine to shutdown. Problem I could not save shutdown messages I tried several approaces, one with script, other with # shutdown -h now | tee shutdown.txt but nothing got saved

@tonio, does the error occur if you put the module in /porteus/modules to activate it at startup? You should not activate the rc.M update in a running system, because rc.M will run during activation, and that is a bad thing-- I should have been more specific when releasing that patch.

@mailmegx, please email me a copy of the module that is causing problems -- ahau@porteus.org -- change the password for 'gx' and tell me what the password is, and I'll sort this out. I'm afraid there are too many moving parts for me to diagnose this remotely

Please take a look at our online documentation, here. Suggestions are welcome!

Ahau wrote:@tonio, does the error occur if you put the module in /porteus/modules to activate it at startup? You should not activate the rc.M update in a running system, because rc.M will run during activation, and that is a bad thing-- I should have been more specific when releasing that patch.

I will try to remaster the iso, with the patches included and see how it responds. I was booting from cd and applying the patches , and in one case running in porteus x86_64 with virtualbox. Hopefully will report back with some information.

guest@porteus:/tmp$ activate wine-1.5.0-i486-1sg.xzm
Updating shared library links: /sbin/ldconfig
Updating XFCE menu: xfce4-panel restart; update-desktop-database
xfce4-panel: Failed to connect to session manager: Failed to connect to the session manager: SESSION_MANAGER environment variable not defined
(xfce4-panel:5188): xfce4-panel-DEBUG: Module "xfce4-mixer-plugin" not found in the factory
xfce4-panel-Message: Plugin "xfce4-mixer-plugin-15" was not found and has been removed from the configuration
^Cxfce4-panel-Message: Plugin systray-6 has been automatically restarted after crash.
The databases in [/usr/local/share/applications, /usr/share/applications] could not be updated.
/opt/porteus-scripts/xactivate: line 61: kill: (5115) - No such process

The process appeared to hang and I used CTRL+C. Have not shut down the sytem, but will do so and see if that works out. I will report back if everything else works as normal.

EDIT:
Shutdown works normally, activation of modules successful, except for message of panel, but other than that the system works well and appears ready to go

@tonio, I have verified the "panel restart" bug you mentioned. This occurred for me a while back and I patched it up for users who login via init 4, but must have missed testing it with startx as guest in 32-bit ( with two user accounts, two architectures, and two methods to login, I now have to test these fixes 8 times over, and occasionally things get missed. Okay, they often get missed ). This is related to how 'su' is used to restart the panel after a module is activated (after using ktsuss to login as root, root then needs to su back to guest to restart the panel).

Please try this modification to /opt/porteus-scripts/activate (you can do this modification after you login to xfce if you prefer -- activate will still work in text-only mode as you know):

Scroll to the bottom of the script and look at the second paragraph from the end, which starts with "# Update XFCE menu". In that paragraph, remove '--login' from this line:

Save the file, and activate a module. If you need to deactivate a module, you should also make this same change to /opt/porteus-scripts/deactivate. If this works for you, I'll request this change upstream in 1.2 RC2 and it should be fixed. I have to test it in 64-bit first, though, and without a modified .bashrc (if my fix doesn't work, you might also need to delete the 'su=su -' alias in .bashrc, that was my only other modification).

@francois,
I see what you mean now -- I noticed that my sessions were being saved when logging out and back in, and had assumed they were working with reboot/halt. That is apparently not the case. I think I've tracked this down to the xfce4-session patch I applied a while back to try and fix your issues with being forced back out to the login manager (it didn't solve your problem, but if I recall correctly, it kept xorg from crashing on my end). I recompiled xfce4-session without the patch, and my session was saved on reboot. I have some more testing to do, but will plan on removing the patch from RC2. I do know the XFCE devs are working on cleaning up xfce4-session for the 4.10 release. There have been lots of issues with it reported on the forum and bug-mail list, so hopefully these things will work themselves out.

Many thanks for your help in testing, guys!

Please take a look at our online documentation, here. Suggestions are welcome!

Ahau wrote:@tonio, I have verified the "panel restart" bug you mentioned. This occurred for me a while back and I patched it up for users who login via init 4, but must have missed testing it with startx as guest in 32-bit ( with two user accounts, two architectures, and two methods to login, I now have to test these fixes 8 times over, and occasionally things get missed. Okay, they often get missed ). This is related to how 'su' is used to restart the panel after a module is activated (after using ktsuss to login as root, root then needs to su back to guest to restart the panel).

Please try this modification to /opt/porteus-scripts/activate (you can do this modification after you login to xfce if you prefer -- activate will still work in text-only mode as you know):

Scroll to the bottom of the script and look at the second paragraph from the end, which starts with "# Update XFCE menu". In that paragraph, remove '--login' from this line:

Save the file, and activate a module. If you need to deactivate a module, you should also make this same change to /opt/porteus-scripts/deactivate. If this works for you, I'll request this change upstream in 1.2 RC2 and it should be fixed. I have to test it in 64-bit first, though, and without a modified .bashrc (if my fix doesn't work, you might also need to delete the 'su=su -' alias in .bashrc, that was my only other modification).

I will try to do this as soon as I can. I notice that this spin along with other v1.2rc1's does not pick up internet connection. It picks up an ipv6 address when the network is mainly ipv4. Trying dhpcd, gives me back null address, and does not work. Using virtualbox within windows 7 does give a working ip address and connection, but will open another thread as this is not unique to XFCE spin

Posted after 21 hour 4 seconds:
@Ahau,

I have made the requested change(s), but the menu entry is not updated , This is still no problem for me as I like to call wine via terminal

The only situation where activate is failing to restart the panel is in 32-bit, if you log in as guest, open a terminal, su to root, then activate a module. This is due to the 'su=su -' alias in .bashrc which is a fix for Trinity; if you happen across this bug, decline the prompt to start a new panel, and manually restart the panel (xfce4-panel -r) as the logged in user; or, change to root using 'su -p' instead of 'su'.

Please take a look at our online documentation, here. Suggestions are welcome!

thanks, francois. It seems that patch I added fixed the issue in some cases, but not all, and not with all options, and broke saved sessions from logout/reboot. I removed the patch and tested, and am reproducing the old bug (X crashes, and when using saved changes on ext2, it kicks me back to login manager). There have been a ton of changes in xfce4-session in preparation for 4.10, but I can't get the latest from git to compile right now...will keep working on it, but it might require upgrading to all of the other (unstable, testing) packages as well. Not sure which is the greater of two evils here...

Posted after 4 days 10 hours 24 minutes 3 seconds:
I have good news and bad. The good news is that the XFCE devs have pushed their first development release for 4.10

The bad news is that it still seems to have the error that pushes us out to the login manager when changes are saved to ext2. I have a bit of cleanup to do and will test this new version without my modifications for 4.8 to see if I can sort this out, and I will report it upstream if it still seems to be an issue with xfce. For those that are curious, I will publish a xfce 4.9 modules in a few days (odd numbered minor version releases are development/testing, evens are stable). I'm so excited to build these packages, I keep getting compile errors because the developer is in an earlier time zone, and the files appear to be from the future

Please take a look at our online documentation, here. Suggestions are welcome!