apt-get hangs when upgrading mysql-server-5.1
When I attempt to do the following:
sudo apt-get update
sudo apt-get upgrade
on my Ubuntu Server 10.04 installation, it hangs at the following line:
Preparing to replace mysql-server-5.1 5.1.41-3ubuntu12.1 (using .../mysql-server-5.1_5.1.41-3ubuntu12.3_i386.deb)
I cannot even CTRL-C out of it! I end up having to kill my session and log in from a different terminal and the upgrade process is still running. I have rebooted it several times and when I go back and try again it tells me:
E: dpkg was interrupted, you must manually run 'sudo --configure -a' to correct the problem.
Once I do that I am back at square one and it freezes up when I try to upgrade mySQL.
Try going a level below apt, after backing up your databases:
sudo dpkg -r mysql-server
sudo apt-get check # verify that apt's metadata is okay
sudo apt-get install mysql-server
added:
Since dpkg -r
is choking try dpkg --purge
and failing that get the package contents with dpkg -L mysql-server-5.1
zap them and then muck about in /var/lib/dpkg
.
I've never seen things get that hairy, sorry.
if at first you don't succeed
I'm sorta thinking aloud here, forgive me. The mysql-server meta-package contains or requires these packages:
libdbd-mysql-perl
libdbi-perl
libhtml-template-perl
libnet-daemon-perl
libplrpc-perl
mysql-client-5.1
mysql-client-core-5.1
mysql-server
mysql-server-5.1
mysql-server-core-5.1
The meta-data for package management is delightfully decoupled, there are central repositories but the packages stand alone. /var/cache/apt/archives
is where *.deb
files that have been installed live.
First, force dpkg to forget about these packages (at the risk of failure to remove some files that we're going to replace anyway).
for i in mysql-server-core-5.1 mysql-server-5.1 ... ; do
sudo dpkg -r --force-remove-reinstreq $i
done
Then get the .deb files needed for a full install:
sudo apt-get install --download-only mysql-server
and then try installing them one by one:
cd /var/cache/apt/archives
sudo dpkg -i mysql-server-core-5.1_5.1.41-3ubuntu12.3_i386.deb
if you have problems there, try:
sudo dpkg -D77777 -i mysql-server-core-5.1... > 2>&1 /tmp/dpkg.log.$$
And try and find the relevant lines out of the zillion in the logfile and post them here. Good luck and godspeed.
Apparently the update is waiting for the server to start and for some reason it does not. To fix the problem there are several possibilities.
The easiest:
-
Open a new terminal, and run:
sudo services mysql start
More complicated but sometimes necessary: (this is handy when you do not have access to another terminal):
-
Press "^z" (Ctrl + Z) which will "STOP" your job. Then run:
sudo services mysql start
-
Once the server is started type the following and hit Enter:
fg
This will place your "STOPPED" job back in the foreground and continue where it left off.
I was having this problem because it was a copy of a VM so I had changed the IP address of the server but didn't change the bind-address in the my.cnf file. Once I changed the bind-address to match, the update didn't hang and completed successfully.
I faced the same problem and I spent more than a day debugging it.
When I removed the database directory, /var/lib/mysql/
, the installation went smoothly.
I was having this exact issue but none of the existing solutions seemed appropriate. Forcing an uninstall is supposed to be unnecessary in any *nix and is definitely not KISS. In my case I found that the cause was simple. MySQL was refusing to start because it was still running! When apt tried to stop MySQL, it was active and never actually stopped.
As always, make sure you have backups!
Stop the service:
sudo service mysql stop
Ensure the service is no longer running:
sudo ps ax | grep mysql
If it is still running, give it some time:
sudo kill <pid>
But eventually, if it is still running, you have to kill it aggressively:
sudo kill -9 <pid>
Once you've confirmed it is no longer running, you can continue with the update.
After the update is completed, especially if you had to kill -9, be sure to run mysqlcheck to ensure that whatever may have caused the service to not stop is not a corrupted or broken table. Also ensure you have regular backups (and make sure those backups actually work!).