If you run dpkg-reconfigure debconf -p low and select text mode and priority low, followed by dpkg-reconfigure -ap low you will get configuration questions of the type: use: 1. unix authentication 2. consolekit 3. likewise 4. ... The choices should be seperated by a space: 1 2 3 If you select everything and then change your /home folder: sudo chmod -cR 777 /home* ; sudo -cR chown -cR 1000 /home/* you will get faulty ~/.dmrc and ~/.dbus settings.
Many users will do that because they cannot remove installation files from their home folder through nautilus gui (to save space for instance). If you start: $ sudo nautilus you can change the permissions, but only one by one. I suspect that is the problem. Since your different authentication methods conflict, you experience a wide variety of crashes. To get a backtrace you should start valgrind 'previously crashed process' and then gdb 2>&1 | gdb-<previously_crashed_process> and use gdb attach pid (check with pidof or ps -A).
The problem is that most crashes are fatal, requiring reboot and which application will crash is unpredictable. I have not been able to backtrace this properly, I am currently searching the proper debug symbols: 'apt-cache search <packagename> | grep "dbg"'. Could you try this out on VirtualBox or VMWare or a dedicated testing machine, or better yet a server with many partitions? It could work, I promise.
If you run dpkg-reconfigure debconf -p low and select text mode and priority low, followed by dpkg-reconfigure -ap low you will get configuration questions of the type: use: 1. unix authentication 2. consolekit 3. likewise 4. ... The choices should be seperated by a space: 1 2 3 If you select everything and then change your /home folder: sudo chmod -cR 777 /home* ; sudo -cR chown -cR 1000 /home/* you will get faulty ~/.dmrc and ~/.dbus settings.
Many users will do that because they cannot remove installation files from their home folder through nautilus gui (to save space for instance). If you start: $ sudo nautilus you can change the permissions, but only one by one. I suspect that is the problem. Since your different authentication methods conflict, you experience a wide variety of crashes. To get a backtrace you should start valgrind 'previously crashed process' and then gdb 2>&1 | gdb-<previously _crashed_ process> and use gdb attach pid (check with pidof or ps -A).
The problem is that most crashes are fatal, requiring reboot and which application will crash is unpredictable. I have not been able to backtrace this properly, I am currently searching the proper debug symbols: 'apt-cache search <packagename> | grep "dbg"'. Could you try this out on VirtualBox or VMWare or a dedicated testing machine, or better yet a server with many partitions? It could work, I promise.