Quote:
|
" dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem."
|
I'm not so sure if it's a source package that's dealt with here. Or if that's the case, I've been installing _loads_ of source debs that just happen to message that when the installation operation is stopped before it's finished. I know my pc isn't the fastest on earth, but the packages do install pretty swiftly, so I thought they're binaries - source compilation takes so much longer - and still I face that error each time I interrupt apt before it's install process is successfully ended.
Well, what you do after that message:
Code:
sudo dpkg --configure -a
That should fix it, if it does. Then re-run
Code:
sudo apt-get install wine
if it wasn't installed yet.
Note that on Ubuntu the root account is locked for good reasons (if you're against that, it's ok to me - you're free to do what you want, like burn down your house - but it actually is a sensible thing to do if you consider it), and the first user that is created (during the setup) is given full sudo rights. That means that user is the "main" user, who can run anything
with root privileges, using sudo. Yeah, you can even become root trough sudo "abuse", but that's not the point here. Rest of the users created will not have sudo privileges by default, unless you give it to them - and if you do, be careful, or they can become root and kick your butt
Anyway, the first user created during setup has pretty much power, but not without sudo - it's a minimum line of defense, so to say, and not particulary safe unless you think before doing. It's better than logging in as root, but worse than working with thought.
So anything system-wide or admin-like you do, you do trough sudo. That means put "sudo" in front of the command you would otherwise run as root. It asks your user's password unless you just put it in a moment ago (it forgets it in a moment, for security, but I'd rather not have it remember it at all), and then runs the given command with root privileges. Without that the command is run with your user's privileges, which are lower, and can't for example change files owned by someone else; typically system files are owned by either root or some dedicated user/group that is created for the job.
Shortly:
Code:
apt-get install package
should fail, because apt-get needs high privileges to change system files, and that command is executed as regular user, who can't change system files.
Code:
sudo apt-get install package
does not fail, because apt-get is now run with root privileges, and can change system files.
should fail, because the command is executed as a regular user who can't write to /
makes pretty nice damage, because now 'rm' (remove files) is executed as root (because of 'sudo'), and the flags 'r' and 'f' mean 'recursively' and 'force' (or 'without asking questions). Means it tries to remove, without confirmation, each and every file on your filesystems mounted under /, which means all mounted ones
Note that apt is nice when it tells you what to run in order to try and fix the situation. It would be more difficult if it just told you "error" and stopped there.
because it has never happened before.
