Bodhi 6.0 Release Candidate :D

The Settings Panel has some unexpected new behaviors:

#1 Synaptic appeared on System tab. Don't think that should be there at all. Also its the only thing on this tab so making settings panel extra wide.
#2 Advanced Network Settings appeared under preferences. Sometimes items in settings panel preferences are also in the applications menu, but only from the preferences category. This one is not the case. It uses the same icon as the entry applications menu, which normally happens for items in settings panel preferences, but this one is coming from the applications menu system category.
#3 Language Support appeared under preferences. It doesn't seem to do anything at all which clicked or double clicked.

And a whole new "language" category appeared. I imagine that was expected but makes settings panel even wider! It has a few entries which seem to work, unlike that language support under preferences.

<offtopic> kiezel , I updated ephoto in bl6 repo with your nl.po file. Much thanks </offtopic>

In most cases, you need to specify the Display and .Xauthority file to launch an app using pkexec (at the bare minimum), for example:


However, thunar installs a policy kit file that makes this unneeded for it hence pkexec thunar works. This file is located at /usr/share/polkit-1/actions/org.xfce.thunar.policy. And in all honesty this is the prefered way to launch an app with pkexec, create a policy for it.

With BL6 I am including a shell script gksudo which is not the gksudo of old but merely runs pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY $@

I have been using this myself for some time because lets face it pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY is too much to type. And that admin:// stuff doesn't always work as expected, aside from the double password thing. I was defining it an alias but I decided to put in it BL6 as a command in /usr/bin. I will be the first to admit that this is clearly an abuse of pkexec and not really the 'proper' way to do things. So it is up to you if you wish to use it (gksudo) and also be aware it may fail, or possibly even worse, if the command you are running needs more than the two aforementioned environmental variables defined. The proper way to do it is to create a polkit policy file for the app(s) you wish to launch using pkexec. My gksudo hack is only there for users who are advanced enough to use it without borking their machines, in this way it much akin to sudo -i some_random_app. Use at your own risk!



Not much I can do about expected behavior. This functionality is provided by gnome's gvfs admin backend and I am not going to try to patch GVfs to avoid it. I am not even going to look at the code to see why it is doing it. Relatively sure I would not even be able to understand that code without a lot of research. I am also reasonably sure the devs who developed that admin backend had their reasons and are fully aware of the double password issue. It is my understanding that part of the rational for this code was to overcome a limitation of wayland which allegedly does not allow GUI apps to run as root period. In this regard using admin:// does not always give you the full power of actually running an app as root on XOrg. Xorg has no problem with letting you shoot yourself in the foot and hence is regarded as less secure than wayland. 

... Now this is just speculation based on the above observations, it may be that the double password prompt in a file manager that supports gvfs using admin:// occurs because the first password is to 'mount' the file system with elevated permissions and the second password is to launch the app itself. I may be wrong on this wild guess so take it with a grain of salt. I know very little of the inner workings of gvfs, next to nothing about the inner workings of wayland and only enough about Xorg to do what I gotta do with moksha and what I used to do in the past with dwm. Not to even mention all this policy kit stuff, I have grown accustomed to it but have no deep understanding of it either.

I seldom use admin:// so make of that what you will.

This abuse of pkexec doesn't seem any more risky than sudo -i some_app which a few team members were using prior to me explaining how to launch an app with pkexec without going thru the hassle of creating a policy file for it. However aside from mentioning it here I am not planning on drawing attention to the existence of the gksudo script on BL6. Users without a lot of linux experience will not even know it exists unless they just stumble across this fact by trying to run an old script or for some reason are nosing around in /usr/bin.

For the record tho the original gksu and gksudo still compiles and works. I am not going to package it tho as most if not all Linux distros have moved away from it, for a reason. The biggest two reasons are suspected security flaws and the fact it is unmaintained code now. It also bypasses the new policy kit stuff. It should be noted Jeffs old esudo program also bypassed the policy kit stuff and really was just a GUI wrapper around the sudo -i command. With BL6 I have moved away from esudo and we are using policy kit and gnomes authentication service. Enlightenment now has a policy kit module, but I don't know much about using it or how mature the project is. It is fairly recent addition to the e code base. It may or may not ever be backported to Moksha.

Off topic: I've published a web page for explaining the differences between su, sudo, admin:// and pkexec:
easylinuxtipsproject.blogspot.com/p/about-root.html

We will be moving our website and our repos to a new server. I don't anticipate any problems and the new servers should be live on May 1st. However, this entains I hold off on the OFFICIAL release of BL6.0 until sometime after May 1st. As until then both the website and the repo are frozen. I can not update any deb files nor announce anything on Bodhi's blog until the new server is live and working.

This is a very good explanation, thanks for sharing

Are you saying it is the installer hanging after you manually selected the partitions for the installation?

We would need to know more details? What is your current partition set up and what were you changing it to? What file system did you select? Is this a Bios install or UEFI?

I often find it easier to set up my partitions with gparted (which is installed) if I already have a complicated setup and am repartitioning and so on. I do that before I run the installer. Actually, you can do that before you even boot the ISO.

If you wish to try to debug the issue the installer can be run in debug mode


ubiquity -d
It stores the logs in /var/log. I think you need to be root to access the installers logs. Also check the system log. I think the installers partition tool is called partman (it is actually a debian tool). So look for that in the logs.