Installation hangs at "apt-get upgrade -y: Succeeded."

[omega8cc]

Installation hangs at "apt-get upgrade -y: Succeeded."

[omega8cc]

Thanks for sharing this. I have never seen that problem, but your recipe can help others.

[netivajak]

Identical problem, different packages.

To reproduce:

Install Ubuntu 64bit Minimal
apt-get update ; apt-get upgrade
Edit BARRACUDE.sh.txt as required and run.

As packages linux-generic linux-image-generic are held back the same installation hang occurs.

Possibility exists that any held back package could cause install to hang.

Hope this helps.

edit as per next coment:

Missing info from my comment: vps250 with Tagadab (UK based VPS Provider) on Xen

[omega8cc]

We never tested it on any install with landscape (or local), only on a few minimal Ubuntu/Debian installs provided by vps hosts. Anyway, we want to make it also local-install-friendly and also compatible with any popular vps/cloud hosting, so thank you for this info.

BTW: if possible, please always quote where you tested the install - local VM or any known vps/cloud host.

Thanks.

[aireworth]

Is the "apt-get update; apt-get upgrade" before running the script not the cause of this problem? I was having what looked like this (I never fully investigated it but it occurred at this stage and pressing enter let the script continue)
Repeated this afternoon, with just a bare install of Lucid, no apt-get update/upgrade and
a) the first part of the script ran a lot faster.
b) the hang after the second "succeeded" went away.

(Using Lucid as a vmware machine on local windows xp.)

Colin

[omega8cc]

It was already answered here on Github and on g.d.o a few times. You should run Barracuda on the vanilla system without any prior updates or modifications. If that doesn't work, please report it as a bug and include info about the system, especially when it happens with vanilla vps/cloud node at some known host.

[netivajak]

Would it be worthwhile having a check in the script to see if any packages are held back? Then the script could exit advising either 1) Revert/reimage to vanilla system or 2) manually resolve pkg issues before running script?

[omega8cc]

The installer is designed to work without any such additional changes. If it doesn't work out of the box, then something is wrong (as today unexpected change in Debian, where Redis were removed from experimental to testing (not used) and it cause unexpected failures. We prefer to fix all experienced issues in the script and not just advise users to find and resolve issues. This is why we encourage you to submit issues in the queue.

[netivajak]

Understood. I'm not suggesting that you leave users high and dry fixing their own issues, but by trapping a very specific and possibly common mistake and advising a solution - to revert to a vanilla vps as per the instructions - right at the point where the problem is occuring would be potentially helpful.

It's probably habit for a lot of people to have a new vps install and immediately run the updates for the distro, and normally not a bad one!

My thinking was that since this is not an issue in the script but a misunderstanding or failure to follow instructions it would save unnecessary issues in the queue by advising the user what they had done wrong and enabling them to get their system up without further assistance. I'm not suggesting that you undermine the excellent work in automating the installation by leaving them to their own devices, just to trap a specific "case" if you like.

Sorry for length of reply!

[omega8cc]

Nothing bad will happen when you will start with updating your system before running Barracuda. In fact, it can even make the Barracuda experience better, since if there will be any problems at this point, you will know it is related to your host OS image and/or other external issues with just introduced changes to your OS distribution etc.

But it moves the Barracuda starting point and then results with hard to troubleshoot situations, when two users at the same VPS host reports different problems with the same version of installer etc. This is why we recommend to use Barracuda on vanilla system - it allows us to better catch and resolve specific issues directly in Barracuda, so it then works better also for others - see the latest fix for missing locales at Linode and RackSpaceCloud.

Another problem is that many issues comes from using different SSH clients. The latest good examples are Coda on a Mac causing far too many weird errors, and unknown SSH client on Ubuntu causing problems with (already fixed for others) locales, missing by default at Linode and RackSpaceCloud.

Now any failures on the system update step are better explained with clear how-to on screen: http://github.com/omega8cc/nginx-for-drupal/blob/master/BARRACUDA.sh.txt#L213

[omega8cc]

And another inline help introduced: http://github.com/omega8cc/nginx-for-drupal/blob/master/BARRACUDA.sh.txt#L319

[netivajak]

Brilliant stuff, thanks.