Moving to Ubuntu 18 without first upgrading MIAB

I’m migrating to a new Ubuntu 18 box, but I’m unable to upgrade MIAB first. The documentation states:

Upgrade your existing Mail-in-a-Box to version v0.30 first. This is mandatory and relates to limitations in the PHP versions supported by ownCloud/Nextcloud database migrations.

Given that the box I’m moving from has severe technical problems which render the upgrade of MIAB impossible, I’m attempting to migrate first and do the upgrade once I’m there. What problems am I likely to run into, and how might I address these?

Thanks in advance
Dominic

Having got part way through the process, the setup aborted. I’m wondering if it’s an option to install an earlier version of MIAB on Ubuntu 18, run my restores and proceed with upgrading MIAB. Push comes to shove I could run up a clean Ubuntu 14 to use as an intermediate step. Seeking inspiration

You may want to try a tool such as imapsync or doveadmin backup. I don’t think you can run earlier versions of MiaB on 18.04.

i don’t know from what version you are coming and your setup, but what if you move /home/user-data to an external NFS drive and remount that partition on /home/user-data (after moving the old one).

If that’s working, you can upgrade the server to a recent 14.04 version.

On this site, there is a description, how to upgrade to 18.04 and the latest version.

Hello there was a major post on this board about how to handle this …

The thread needs to be read carefully … as the first part is not necessarily relevant. I have linked directly to the relevant portion. I have to ask which version of MiaB are you currently on … and what is the specific ‘severe technical problems’? If you are at v0.30 then you likely are golden. If not, then more work may be entailed. I also speculate that rsync could be your friend.

Thanks to all for responding. It’s a great help, and I’m looking at all your suggestions. The specific “severe technical problems” are that it’s run out of inodes, so a very empty disk looks full, and anything involving creating files is a problem.
I’ve been attempting to build a working system on Ubuntu 14 with a view to restoring my data there before upgrading. Ran into trouble with apt-get and php7.0 - so some of your other suggestions will definitely be useful. Actually wondering if I can just rsync my entire volume to get round the inode problem. To be continued…

This is highly experimental … the people on the Ubuntu IRC channel thought that I was insane for wanting to try, but they did not seem to comprehend that I intended to only upgrade packages and then destroy the system … so anyways … there is a repository for Ubuntu 14.04 archived. That repository may allow you to upgrade the necessary packages to then upgrade MiaB to v 0.30.

I haven’t found the PPA yet, but the entire release Ubuntu 14.04.6 is available here for a complete reinstall.

http://releases.ubuntu.com/14.04/ubuntu-14.04.6-server-amd64.iso

Ok, so information on adding the old PPA can be found here:

I don’t see why not … it may be the path of least resistance. Spin up a vps with Ubuntu 18.04, install the most recent MiaB and then rsync /home/user-data/ to the new vps. Question, do you use Nextcloud or not? NC is the biggest obstacle to upgrading.

and in the otherwise, you can just startup a 14.04 distribution, rsync the data, install the latest Miab (0.30); install a 18.04, do the upgrade.

Thanks - I’d already found the iso, but the old repositories link is useful

I now understand why php7.0 is a problem. Adding a reference to Ondřej Surý’s PPA doesn’t help because the versions that match Ubuntu 14 are not “Published”

https://launchpad.net/~ondrej/+archive/ubuntu/php/+packages?field.name_filter=php7.0&field.status_filter=published&field.series_filter=

It looks like they are visible if you filter on “Superseded” instead, although I’m not sure how this helps just yet.

Doesn’t look like they are there on the PPA, but in my broken MIAB server, the php packages are there in /var/cache/apt/archives. Maybe it’s possible to fool apt-get or maybe dpkg into installing it from the .deb files.

OK - so I got boxed in on pretty much everything I tried regarding setting up a fresh ubuntu14, so I went back to my original problem, which was that I’d run out of inodes, which was making all upgrades fail with out of disk. After some googling, this answer https://stackoverflow.com/a/653174/9967 showed me how to find out where the inodes were used. The culprit was /usr/src which had a lot of linux kernel headers. I mounted a second volume, moved the contents of /usr/src to a directory there and made a symbolic link from /usr/src to the directory.
With my inodes back within reason, I ran ‘mailinabox’ and it upgraded a bunch of stuff, and eventually failed on installing certbot.

Nextcloud is already latest version
Installing Z-Push (Exchange/ActiveSync server)…
Installing Mail-in-a-Box system management daemon…
Uninstalling acme-0.25.1:
Successfully uninstalled acme-0.25.1
You are using pip version 10.0.1, however version 19.1.1 is available.
You should consider upgrading via the ‘pip install --upgrade pip’ command.

FAILED: apt-get -y -o Dpkg::Options::=–force-confdef -o Dpkg::Options::=–force-confnew install duplicity python-pip python-virtualenv certbot

Reading package lists…
Building dependency tree…
Reading state information…
E: Unable to locate package certbot

Now that the box is no longer in a critical condition, right now I’m going to bed. I’ll investigate the certbot thing pretty soon though, and obviously I’ll be trying to go through the upgrade to Ubuntu 18 fairly soon, as it should be possible via the documented route.

Thanks to all who offered help. It’s not just about technical suggestions, and there were some excellent ones, but also about the moral support. That always helps, but especially when you’re worried you’ll lose your mail server and feeling guilty for not having maintained it well enough. Thanks.

It sounds like you need to run apt-get autoremove. I don’t know if it will properly run with the old kernal files moved …

Thanks. I’d tried that without success. Fortunately moving the files onto a different volume solves the inode issue.