Gparted won't accept root password??? [SOLVED!]

[Just17]

That seems correct to me.     

Here these commands launch gparted without issue:     
gksu -l /usr/sbin/gparted     
gksu -u root /usr/sbin/gparted     

As root (su):     
usr/sbin/gparted
-bash: usr/sbin/gparted: No such file or directory      

missing  /    ??

[djohnston]

As root (su):    
usr/sbin/gparted
-bash: usr/sbin/gparted: No such file or directory    

Should be:

/usr/sbin/gparted

EDIT: Just18 beat me to it.

[Neal ManBear]

ROFL!!!!! I made a typo!     

As root (su):     
/usr/sbin/gparted     
launches gparted without issues.     

[AS]

Looking back at pags's post on consolehelper, I see

"consolehelper requires that a PAM configuration for every managed program exist.  So to make /sbin/foo or /usr/sbin/foo managed, you need to create a link from /usr/bin/foo to /usr/bin/consolehelper  and create the file /etc/pam.d/foo, normally using the pam_con‐sole( PAM module."

Well, just checked /etc/pam.d directory, and there is a gparted file. The contents are:

USER=root
PROGRAM=/usr/sbin/gparted
SESSION=true

the content of the file certainly is not correct for a file to be in /etc/pam.d. From man pam.d:

       The syntax of the /etc/pam.conf configuration file is as follows. The file is made up of a list of rules, each rule is
       typically placed on a single line, but may be extended with an escaped end of line: `\<LF>´. Comments are preceded with `#´
       marks and extend to the next end of line.

       The format of each rule is a space separated collection of tokens, the first three being case-insensitive:

That said, if a pam.d module is not defined, a default module /etc/pam.d/other is used, which will deny any access:

#%PAM-1.0
auth     required       pam_deny.so
account  required       pam_deny.so
password required       pam_deny.so
session  required       pam_deny.so

AS

[Bald Brick]

Looking back at pags's post on consolehelper, I see

"consolehelper requires that a PAM configuration for every managed program exist.  So to make /sbin/foo or /usr/sbin/foo managed, you need to create a link from /usr/bin/foo to /usr/bin/consolehelper  and create the file /etc/pam.d/foo, normally using the pam_con‐sole( PAM module."

Well, just checked /etc/pam.d directory, and there is a gparted file. The contents are:

USER=root
PROGRAM=/usr/sbin/gparted
SESSION=true

the content of the file certainly is not correct for a file to be in /etc/pam.d.

It seems that the files /etc/pam.d/gparted and /etc/security/console.apps/gparted have simply switched places in newer installs of gparted. Switch them back and all is well.

The contents of gparted in /etc/security/console.apps (which should be in /etc/pam.d) is

Code: [Select]

#%PAM-1.0
auth sufficient pam_rootok.so
auth sufficient pam_timestamp.so
auth include system-auth
session required pam_permit.so
session optional pam_xauth.so
session optional pam_timestamp.so
account required pam_permit.so

The gparted that djohnston quoted belongs in /etc/security/console.apps.

[AS]

It seems that the files /etc/pam.d/gparted and /etc/security/console.apps/gparted have simply switched places in newer installs of gparted. Switch them back and all is well.

Confirmed, working fine after swapping the two files! 

[Old-Polack]

Looking back at pags's post on consolehelper, I see

"consolehelper requires that a PAM configuration for every managed program exist.  So to make /sbin/foo or /usr/sbin/foo managed, you need to create a link from /usr/bin/foo to /usr/bin/consolehelper  and create the file /etc/pam.d/foo, normally using the pam_con‐sole( PAM module."

Well, just checked /etc/pam.d directory, and there is a gparted file. The contents are:

USER=root
PROGRAM=/usr/sbin/gparted
SESSION=true

the content of the file certainly is not correct for a file to be in /etc/pam.d.

It seems that the files /etc/pam.d/gparted and /etc/security/console.apps/gparted have simply switched places in newer installs of gparted. Switch them back and all is well.

The contents of gparted in /etc/security/console.apps (which should be in /etc/pam.d) is

Code: [Select]

#%PAM-1.0
auth sufficient pam_rootok.so
auth sufficient pam_timestamp.so
auth include system-auth
session required pam_permit.so
session optional pam_xauth.so
session optional pam_timestamp.so
account required pam_permit.so

The gparted that djohnston quoted belongs in /etc/security/console.apps.

Second confirmation ... works perfect after the switch.

[Just17]

It seems that the files /etc/pam.d/gparted and /etc/security/console.apps/gparted have simply switched places in newer installs of gparted. Switch them back and all is well.

Well spotted BB 

[djohnston]

Badda bing, badda boom.

Good call, Bald Brick.
That did the trick.
Swapped the files from a shell
And now all is well.

Now the original poster can change the title of the first post.

[wharfhouse]

Badda bing, badda boom.

Good call, Bald Brick.
That did the trick.
Swapped the files from a shell
And now all is well.

Now the original poster can change the title of the first post.

Before I do, can someone summarize in simple terms (I'm still a novice remember! ) what exactly was the problem, why there was a problem, and what I need to do on my system to achieve the apparent success that you experienced guys have got in the hope of increasing my knowledge of how Linux works? 

I'm fascinated by all the technical stuff above... totally over my head! 

[pags]

Badda bing, badda boom.

Good call, Bald Brick.
That did the trick.
Swapped the files from a shell
And now all is well.

Now the original poster can change the title of the first post.

Before I do, can someone summarize in simple terms (I'm still a novice remember! ) what exactly was the problem, why there was a problem, and what I need to do on my system to achieve the apparent success that you experienced guys have got in the hope of increasing my knowledge of how Linux works? 

I'm fascinated by all the technical stuff above... totally over my head! 

The file in /etc/pam.d/

Code: [Select]

[jpaglia@paglia-e6500 ~]$ ls /etc/pam.d/gparted -l
-rw-r--r-- 1 root root 225 Feb 17  2011 /etc/pam.d/gparted

should have been in /etc/security/console.apps/

Code: [Select]

[jpaglia@paglia-e6500 ~]$ ls /etc/security/console.apps/gparted
/etc/security/console.apps/gparted
[jpaglia@paglia-e6500 ~]$

and vice-versa.

Swapping these two files (as root) corrects the issue

Code: [Select]

mv /etc/pam.d/gparted ~
mv /etc/security/console.apps/gparted /etc/pam.d/
mv ~/gparted /etc/security/console.apps/


[djohnston]

It seems that the files /etc/pam.d/gparted and /etc/security/console.apps/gparted have simply switched places in newer installs of gparted. Switch them back and all is well.

Bald Brick,

I posted your solution at the linuxgator forum here. Hopefully, they'll get it straightened out.

[Neal ManBear]

I'm working on an update that should fix this. So far, the testing is showing up as positive. If no further issues are found, there will be an update coming to your system soon.      

[wedgetail]

Just out of curiosity is this GParted talk here the same as GParted live bootCD 

[Neal ManBear]

Just out of curiosity is this GParted talk here the same as GParted live bootCD 

     
No. We are not gparted live. We are PCLinuxOS, and we are discussing the gparted package in our repository.