Twice yesterday I tried to update to 1.4S from 1.0-boa-T-8.7. Each time the update stopped near the beginning, after saying it was going to re-run apt update. After snooping around, I found /opt/tmp/aegir-install.log, and this is what was at the end of it:

Configuration file `/etc/mysql/my.cnf'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : background this process to examine the situation
The default action is to keep your current version.
*** my.cnf (Y/I/N/O/D/Z) [default=N] ? q|qexit

I'm running a Linode 1GB Slice, with Ubuntu 10.04, and I started out all the way back on 0.4-boa-C. Should I have updated to 1.0-boa-T-8.10 first? I think I've skipped versions in the past just fine... Should I run it again in debug mode?

Frankly, I'm looking for help, but I think this is a bug, so I put it in as a bug report.

Thanks,
-Joseph

P.S. I was looking for help over here first: http://groups.drupal.org/node/175804

Comments

omega8cc’s picture

omega8cc commented
Status: Active » Postponed (maintainer needs more info)

Could you post your BOA logs, as listed at: http://drupal.org/node/add/project-issue/barracuda ? Thanks.

omega8cc’s picture

omega8cc commented
Status: Postponed (maintainer needs more info) » Active

Barracuda has a few workarounds to this issue (hanging mysql install while it should just go ahead in the non-interactive mode) but honestly, I have no idea what the Ubuntu folks broken this time so it re-appears anyway - we never had this issue on Debian.

Now, to fix this, please run:

dpkg --configure --force-all -a
aptitude update -y
aptitude safe-upgrade -y
aptitude full-upgrade -y

Then run Barracuda again, just to make sure it keeps its own stuff in sync.

jtbayly’s picture

jtbayly commented

Much obliged. I'll try this out next week.

Do you still want the log files? I didn't think they would be helpful in this particular issue, so I skipped them. But I know I could be wrong.

Thanks,
-Joseph

omega8cc’s picture

omega8cc commented
Status: Active » Postponed (maintainer needs more info)

Yes, the logs are always required as they help to diagnose the problem without too much guessing and asking for those details anyway.

jtbayly’s picture

jtbayly commented
Status: Postponed (maintainer needs more info) » Active

Your instructions fixed the problem. Thank you for your help.

I had to make a decision about whether to keep the old my.cnf, or replace it with the new one being installed by the package. I kept the old one.

Below is a link to the log files you requested, as well as the diff of the two my.cnf files.
https://gist.github.com/1506209

Is there anything else that you would like?

-Joseph

omega8cc’s picture

omega8cc commented
Component: Code » Documentation
Status: Active » Needs work
Issue tags: +BOA-todo

Thanks for the logs. It is hard to reproduce, because we are always testing upgrades between following releases and not too often between random releases, plus, it is often not really possible, because the version of database server at the time of testing is already higher than at the time of some older BOA release etc.

In any case, we should at least add this to troubleshooting docs for BOA, I think.

jtbayly’s picture

jtbayly commented

I might add that I had no idea it was possible to run into issues by not upgrading immediately upon a new release of BOA. Your last comment explains why that's the case, and it makes complete sense to me.

Now that I know it, I'll make sure to update right away. It might be worth putting something about it into the READMEs. Or on the project page?

Thanks again,
-Joseph

omega8cc’s picture

omega8cc commented
Component: Documentation » Code
Status: Needs work » Fixed

It is your decision when you are running upgrade, but since 1.0-boa-T-8.7 Edition, there is running daily upgrade monitor: http://drupalcode.org/project/barracuda.git/blob/HEAD:/CHANGELOG.txt#l284

It sends you one e-mail *daily* to let you know that there is a new release available. It is rather hard to ignore, unless those e-mails are filtered by your spam filters or you forgot to set your e-mail on Barracuda install.

By the way, we just fixed this issue in HEAD by adding to standard apt-get and aptitude commands some options: -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold so it should never happen again, even if you have skipped a few releases.

It has been committed as a part of new feature for major upgrade from Lenny to Squeeze: http://drupalcode.org/project/barracuda.git/commit/02600987aa97c3a2f1bf6... which is important because of Lenny EOL on 6th of February 2012 - http://lists.debian.org/debian-security-announce/2011/msg00238.html

Automatically closed -- issue fixed for 2 weeks with no activity.