LMDE BREAKAGES - tracking TESTING

[viking777]

Obviously nothing wrong with your PATH then - what about ruscook's suggestion?

Incidentally, I didn't get this problem at all.

[zerozero]

i was for awhile fighting with that error this morning as well;

- sudo was updated these days, and the sudoers file is all messed up;
- the fix is here http://forums.linuxmint.com/viewtopic.p ... 80#p466552

[xircon]

Got it, it appears to be a problem with the new sudo - works if I su to root. I kept my old sudoers file, anyone got the maintainers version so I can compare?

:Edit: Cheers zerozero.

[zerozero]

sudoers.dpkg-dist

Code: Select all

#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults	env_reset
Defaults	secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root	ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo	ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d

[viking777]

Well here is mine:

#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d

Strange thing is though, although I have updated sudo today I was not offered the usual choice to keep/replace sudoers(you ALWAYS replace btw if you want things to work - just back the original up first). Not only that but the last modification time to the sudoers file is from two weeks ago?

[GeneC]

i was for awhile fighting with that error this morning as well;

- sudo was updated these days, and the sudoers file is all messed up;
- the fix is here http://forums.linuxmint.com/viewtopic.p ... 80#p466552

zerozero (or anyone)
Can you explain how I edit the sudoers file?

When I open it as administrator with Gedit (my ususal way of editing), I see the first line in sudoers

#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d

I am not sure how to use visudo, nor do I have a /etc/sudoers.d
Could I have the syntax of the command to edit it.

Thanks.

-------------------------------------

EDIT

Actually, DO I have to edit it. Everything seems to be working OK?

[zerozero]

i always use gedit if i have to mess with those things a bit of attention and recheck what you are doing and you should be fine.

anyway, just because you are asking, visudo:
the quote is from here http://maeks84.wordpress.com/2008/05/29 ... se-visudo/

sudo visudo

You have two “modes”
• Command mode – Press ‘ESC’ to access.
• Insert mode – Press ‘I’ to access.
You’re always in one or the other.

• To move the insertion point around, press ‘ESC’ and use the arrow keys.
• Once you’re where you want to be, press ‘I’ and start entering text.
• To delete a character, you need to be in command mode, select the character and press the delete key. (Note: not the Backspace key) You can do this in insert mode, but it does some funky things with the text.
• To save your changes, in command mode, type :w and press enter.
• To quit, in command mode, type :q and press enter.
• To quit without saving any changes, in command mode, type :q! and press enter.

Be careful, if you mess it up, you will no longer be able to sudo. Then you need to sudo to fix it. Bit of a problem there. To fix it, you need to login as root, run visudo, and fix the file.

give it a go

[viking777]

Actually, DO I have to edit it. Everything seems to be working OK?

NO! If it ain't broke - don't fix it

For future reference though you just type

Code: Select all

sudo visudo 

In a terminal.

But for an even better tip, you can edit in any root text editor you like provided that when you have finished you open a terminal and type

Code: Select all

visudo -c

To error check it.

Of course if it finds any errors you will have to fix them, it doesn't do it for you. The most common error is not leaving a new line at the end of the file.

[GeneC]

Thanks zerozero

I think I will just leave it as is for now.
"sudo" seems to be working fine, if I see a problem in the future I will try the change, and post.

Be Well.

Viking

Thanks for that.
I am going to leave it alone, but "add" the commands you gave me to my "clicompanion".
I am getting to old and senile to actually "REMEMBER" commands.....

[viking777]

I am getting to old and senile to actually "REMEMBER" commands.....

You think I remember them

My 'clicompaion' consists of about 40 sheets of A4 stapled together and stuffed under my monitor

[GeneC]

[Gerd50]

Hey, good there are LMDE scientists in board

My /etc/sudoers was looking like this:

Code: Select all

# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#

Defaults	env_reset

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root	ALL=(ALL) ALL

but /etc/sudoers.dpkg-dist was ok.

I tried to edit sudoers with 'sudo visudo /etc/sudoers' but the cli sayd sth like - no Path for /usr/local/sbin, /usr/sbin /sbin found.
Then i tried it with gksu gedit and added the line

Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

and that worked. I could upgrade and distupgrade without problems afterwards.

The visudo command seems not to be necessary in order to edit sudoers in this case.

[xircon]

Its Catch 22, if you have broken sudo (as I did) sudo visudo will also be broken

[Gerd50]

sudo visudo now opens /etc/sudoers with nano what means nothing is broken anymore i hope

[xircon]

Anyone notice their machine running a bit hotter? Mine is running 5-6 degs hotter. Fan is running a lot more than before.

[viking777]

Its Catch 22, if you have broken sudo (as I did) sudo visudo will also be broken

Not sure if that is true or not xircon, I didn't break mine so I can't confirm it one way or another. But one thing I would like to repeat to everyone not you in particular is this (and I know I sound like a broken record here) when you are offered the choice between accepting a packages maintainers version of a file and your own version of a file you always,always, always (it doesn't matter how many times I repeat that word I know it won't sink in) accept the package maintainers version. If you are as cautious as I am then at the time you are offered that choice you just open a file manager or a terminal, whatever you prefer, and you make a backup of the file in question - in this case - /etc/sudoers. Stopping to do this will in no way affect the upgrade that is in progress. Once you have done this you come back to the upgrade and you choose to accept the package maintainers version of the file. Now in most cases accepting this option will automatically create a backup of the old file anyway, but by following my advice, you will be covered for the very rare occasions when an automatic backup is not created. Why do you do this? Well you shouldn't even need to ask because today's update has demonstrated more clearly than any number of words that I can type why you should do this.

Ok so you reboot and the upgrade works, or if you have chosen to keep your own version it fails, so what next? Well the first thing to do is to compare the new file and your backup file side by side and see what the differences are (the program 'meld' is quite good for this, it is in the repos). Chances are that whatever changes you have made to the original 'sudoers' can be safely incorporated into the new version and it will still work.

In fact, imho, the option to keep your own file version should be permanently removed from apt and replaced with something like:

"You or a program on you system has modified the file /etc/sudoers. This file is going to be overwritten would you like to make a backup copy of the original file Y/N"

Such a message would prevent people from deliberately screwing their own system whilst still alerting them to the fact that a file that they might have modified has been replaced.

Sermon over - sorry.

[xircon]

Preaching to the converted (now:)) Thing is I had read that post.......................... and still screwed it up. As soon as I had posted I remembered. Will take the maintainers config files from now on and back up like a good little boy

[xircon]

Definitely running hotter, tried "GRUB_CMDLINE_LINUX_DEFAULT="quiet nomodeset radeon.modeset=0 acpi_osi=Linux pcie_aspm=force"
" as suggested in various places (bold section). Only repasted in July, so its not that. Running at 1.2ghz powersave mode as well. Any ideas?

:Edit: Fan is constantly on:

Code: Select all

~$ sudo sensors
acpitz-virtual-0
Adapter: Virtual device
temp1:        +52.5°C  (crit = +102.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +53.0°C  (high = +95.0°C, crit = +105.0°C)
Core 2:       +53.0°C  (high = +95.0°C, crit = +105.0°C)

[zerozero]

from the top of my head, your dist-upgrade brought you to 3.0.0-3 kernel, maybe this v. is not playing very nice with your hardware or your setting, dunno

[viking777]

I have to say that I seriously doubt I would notice if anything was 5deg hotter, but having performed the same upgrade today (including 3.0.0.3 kernel) I can't notice any difference, and certainly my fan is not running (at all). My cpu temp is 49c which is not unusual for a laptop.

Edit. Run

Code: Select all

top

and see if that shows anything eating up cpu cycles.