ddonovan's picture

Self-hosted and tried to do an in-place Jessie upgrade of a TKL WordPress 13.0 appliance, and Apache failed due to having no automated migration from 2.2 -> 2.4 for the things they changed.

I'd really like to get upgraded off TKL13 but this has stood in my way for a couple years now.  I've looked at the Apache docs for the migration, but I don't know what applies to my situation and what doesn't.  I ran the upgrade on a snapshotted instance, which when it failed I reverted the snapshot to get it running again.

Will restoring a TKLBAM backup of my TKL13 appliance into a TKL14 or 15 instance work, or will I just have the same problems with Apache?

Jeremy Davis's picture

Short answer: you'll need to manually make changes to your Apache config.

Long answer is that the Debian upgrade scripts won't touch your config by default. It should give you the option of accepting the new/updated config scripts of anything you've adjusted. But allowing it to do that, it will wipe out your customisations. Even if you allow it to update all the config, there may be new files that have been added that will still require adjustments (as they may clash with updated config). So either way, you will almost certainly need to manually update the Apache config so that it works for you and is compatible with the new Apache 2.4 format. I know it's a pain, but it's a necessary evil.

OTTOMH one major thing that has changed is that all Apache config files now need to have a .conf file extension. So if any of your custom/non-default config files don't yet have that, rename them so they do.

There are also a number of directives that have somewhat changed. When I upgraded the TurnKey library to v14.0, I found the Apache upgrade docs invaluable (and helped me resolve all the issues I hit). This Digital Ocean tutorial is also pretty good too IMO.

Checking the Apache logs (i.e. tail /var/log/apache2/error.log) and/or running a config test (i.e. apachectl configtest) should help you pinpoint exactly where the problems lay.

However, if you can post your problematic Apache config files, I'm more than happy to help you make the required modifications. Beyond the logs, one of the first things to check is the "virtual hosts" you have enabled. Have a look in /etc/apache2/sites-enabled. I.e.:

ls /etc/apache2/sites-enabled

Then cat each of those files and post back here. Feel free to also post the Apache log (or at least the last few lines) and/or the output of apachectl configtest.

ddonovan's picture

The only way in which I interact with Apache is through the Webmin interface, so I'm not aware of having any custom configuration files, nor do I ever modify any of them directly.  I've got everything set up and working the way I want, so if the migration isn't intelligent enough to figure out what needs to be updated and what doesn't, I guess I'd rather just leave it alone than have to break a working system just for the masochistic misery of figuring out how to fix all of it.

Thanks, Apache!

Jeremy Davis's picture

Ah ok. Updating a headless server is definitely much better done via the commandline. Whilst it may seem a bit unintuitive initially, IMO it is much easier than digging around in Webmin. I do use Webmin for a few things, but not much... But obviously I'm a bit biased. I use Linux day in day out and even prefer to update my (Linux) desktop via the commandline! Plus I really enjoy problem solving, so that helps too. :)

So long as your server isn't available via the internet, then not upgrading is certainly an option. Although if it is accessible via the internet (e.g. serving non-static content publicly), then I'd urge you to roll your sleeves up and get into it sooner rather than later. Debian 7/Wheezy is now EOL (as of May 2018). So you will not be getting any further security updates. I'm not aware of any vulnerabilities in the wild, but it's only a matter of time...

FWIW if you work with a snapshot (or similar) of your server, then you can leave the existing server as is until you have all the details worked out. As I said, I'm more than happy to assist with specifics. If you document as you go, then once everything is fully working, you can go again on your main server. You will likely be able to just copy the updated config file across.

Without knowing what you may have changed specifically, I can't be 100% sure, but if it's only Apache config, then it shouldn't take too long. It's probably only a few entries that need adjustment.

Also, if it's only hosting a single WordPress site, and other than WordPress itself, you have made limited changes to the server, then it may be easier to do a semi-automatic TKLBAM data migration. E.g. something like this might work:

  1. Do a backup of your current (v13.0) server:
  2. Launch a new TurnKey v15.0 WordPress server.
  3. Initialise TKLBAM on this new server; replacing HUB_APIKEY with your actual Hub API key (found in your Hub account here):
    tklbam-init HUB_APIKEY
  4. Then create a new directory and rather than doing a full restore, just do a data dump; replacing BACKUP_ID with the actual backup ID number (check the Hub's backups page)
    mkdir /tklbam-dump
    tklbam-restore BACKUP_ID --raw-download=/tklbam-dump
  5. Then just restore the Wordpress directory and the DB:
    tklbam-restore /tklbam-dump --limits="/var/www/wordpress mysql:wordpress" --skip-packages
  6. Then restart Apache and MySQL and you should be good to go:
    service apache2 restart
    service mysql-server restart

Please note that a lot of that was OTTOMH so please let me know if you get any unexpected results.

Anyway, no pressure, but if you do need a hand, please ask and I'll be more than happy to help out.

ddonovan's picture

I'm not the least bit afraid of the command line or of modifying config files, I just don't do it with Apache.   I've done little if any customization of anything, so I'll give the tklbam backup method a whirl (it'll take a while) and see if that goes any better.

Jeremy Davis's picture

Sorry about that, I got the impression that you may have been one to avoid the commandline.

At least in part, that was because I've never found the Webmin Apache config very useful. Way back when I first started playing with TurnKey (~8-9 years ago), Webmin Apache config was actually what first started my transition to a Linux commandline lover! I never could do what I wanted via Webmin, it never worked properly. In comparison, manually editing the Apache config text files seems so much more obvious and intuitive. But perhaps I'm just weird...!? :)

Regardless, good luck with it and feel free to hit me up if you have any specific issues or want some explicit assistance with anything.

ddonovan's picture

First attempt failed with the existing backup, so I deleted that and ran a new one.  Tried restoring from that backup and ran out of disk space on the volume.  So I'm deleting the whole thing and starting over again, will need to enlarge the volume before the next attempt.

ddonovan's picture


This page should be updated since you guys changed the volume name "turnkey" to "turnkeyvm".

ddonovan's picture

Third attempt failed with the following error, same as the first:

Last full backup date: Tue Aug 14 04:23:11 2018
Invalid data - SHA1 hash mismatch for file:
 Calculated hash: a257e115e232bc9780bd25314edfccc4ee337981
 Manifest hash: 4e474e1e6038c3c7f1c516d615c79a729aaa83f4

Think I have a clock problem.  Fixed the time zone and the host clock sync, trying again.

ddonovan's picture

I had to flatten and rebuild the third attempt but I think I've got it sorted out on the fourth attempt.  The directive that was causing Apache to barf was Lockfile in apache2.conf.  I commented it out for now and got it to start.  My databases are actually on an external server so no need to restore that from tklbam, and restored all of /var/www, /etc/ssl and /etc/apache2.  So far, so good.

ddonovan's picture

So I've almost gotten everything running - there was an additional item that needed to be added to apache2.conf to enable .htaccess overrides:

<Directory />
AllowOverride ALL

Once that was done they all came up, even with SSL.  And there was a plugin also causing problems that I no longer use, so simply deleting it resolved the issue.  That's the good news.

The bad news is that it now takes 6... count 'em 6... whole... seconds for each new page to render.

Don't know why the old one is so fast and the new one is so slow, but that's a showstopper as well.

Jeremy Davis's picture

So just to recap, this with a backup of you site, moved to v15.0, right?

Yes 6 seconds is ridiculous and certainly not what I would be expecting! It sounds crazy frustrating! Obviously it's no consolation to you, but all the feedback we've had so far is that the new v15.0 WordPress (and LAMP in general) is performing much better than previous releases. Although in fairness, I'm not sure whether they've mostly been using it for new sites or existing sites.

One thing that does come to mind is that another big change from v14.0 onwards was that php-xcache is no longer used (it was installed and configured by default in v13.x). It has been replaced with Opcacher (built in to PHP). Unless you've adjusted the php.ini in /etc/ though, I would have expected the defaults to be quite sane.

Also if you're using https, one thing that would cause a little bit of a slowdown is the gzip header vulnerabilities. Having said that, security updates should have likely disabled that in your old server too hopefully.

It's been a long time since I've worked with v13.x and in fact v14.0 was the first release that I worked on from a deep development perspective. So I don't have any other specific ideas. But I certainly wouldn't expect it to be so slow.

I've done some googling and haven't hit anything that would even begin to explain your experience. Thinking aloud, I wonder if one of your plugins isn't fully compatible with PHP7? Perhaps it's not fully breaking things, but isn't really operating as it should be?

My guess is that you're not super keen on spending more time on this, but it's probably worth checking resource usage with top (or better still install htop) and check that something isn't chewing up a ton of resources.

Another path that might be worth exploration would be enabling WordPress debugging. It's not an area of expertise for me, so you likely know more here than I do. But FWIW a quick google suggests these setting in your config.php might be useful:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Or set 'WP_DEBUG_DISPLAY to true if you want to see errors displayed on the page (rather than the log). The full WP debugging page looks pretty good.

Unfortunately, other than that, beyond more general troubleshooting stuff, I'm not quite sure where to go?!

Jeremy Davis's picture

As an addendum, perhaps before you get too involved, it's worth disabling all the plugins, making sure WordPress is fully up to date and see how that goes?

At least then you should be a bit clearer whether it's likely something to do with Apache/PHP config and/or WordPress itself, or whether it's one of your plugins.

Just a thought...

ddonovan's picture

After burning a whole day on it I'm ready to throw in the towel.  I'm going to try 14.2 and see if it goes any better, if not then I'll revisit 15.

ddonovan's picture

I'm trying 14.1 next.

ddonovan's picture

... also didn't work.  It just runs slow as molasses as soon as I restore my data to it.  Don't know what I could possibly be doing to cause this.

But knowing what I know now, I'm going to apply what I've learned to another attempt at an in-place upgrade on my existing 13.0 installation.  I can fix Apache's migration issues more readily than its performance issues.  If that doesn't work then maybe just a plain LAMP server will work.

Jeremy Davis's picture

I wonder what it is that is causing the issues?

Good luck on the upgrade. I'm cheering for you! I look forward to hearing how it goes.

As you no doubt already realise, the Apache conf files in v15.0 should work in v14.x. And by extension a v13.x upgraded to a Debian Jessie base (you'll have Apache v2.4.x whichever way you go).

Off the top of my head, the only thing you may want to adjust is either remove the php5-xcache package (or just disable it in php.ini), or disable OPCache in the php.ini (xcache and opcache both provide the same caching mechanism). It may not cause immediate issues, but I recall in v14.0 we had a few appliances which reacted weirdly (until we realised the issue). IIRC the most common symptoms were blank pages under some circumstance (generally a php exception resulting in no html output). Even if everything still appears to be ok - best case scenario it's likely an additional overhead with no value. Although YMMV.

ddonovan's picture

In-place upgrade succeeded.  Trick is to allow Apache to install its own new apache2.conf file, then change this directive as mentioned previously:

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride ALL
        Require all granted

Then my existing .htaccess files work for the WordPress permalink rewrites. 

Apache uses a new Mutex directive to replace LockFile which I couldn't find anywhere on the net.  Disabling it clearly wasn't enough, but I don't know what consequences it had without it.  The new one is:

Mutex file:${APACHE_LOCK_DIR} default


I did the same with PHP, installed the updated php.ini with this changed:

short_open_tag = ON


Still testing everything but it looks like this works.

Jeremy Davis's picture

I'm sure that this will assist others.

TBH though, I'm not at all sure why no one else hit this?! Since we released v14.0, many users have updated and I don't recall anyone bringing that up.

Having said that I do recall that the old SSLMutex was deprecated in Apache v2.4 - as noted as something of a footnote at the bottom of the Apache "Upgrading to 2.4 from 2.2" doc page - Run-Time Configuration Changes (under the sub heading of "Other configuration changes").

As for the new Mutex directive, my memory of this is a little rusty as there haven't been significant changes to Apache in Debian since the upgrade from 2.2.x to 2.4.x (i.e. 7/Wheezy -> 8/Jessie; and our initial development of v14.0 - nearly 3 years ago).

FWIW the Apache docs cover the Mutex directive. As a further FYI, we rely on the Debian defaults and the only mention of it I can find in our customisations, are in the context of SSL and have it commented out in /etc/apache2/mods-available/ssl.conf.

ddonovan's picture

I can't find an entry for xcache anywhere in /etc/php5/apache2/php.ini, and all opcache-related directives are commented out.

Jeremy Davis's picture

As I said my memory of all this stuff is a little rusty as it was quite a while ago since I was actively working on this transition stuff. Sorry if my lack of clarity and/or foggy memories lead you astray.

Anyway, to be a bit more explicit, IIRC as of PHP5.5 (or perhaps it was 5.6? regardless, as of PHP in Debian 8/Jessie) Opcache is integrated into PHP itself. AFAIK Debian compile PHP using the PHP defaults, so enabled for Apache by default; disabled for cli. FYI the PHP Opcache docs cover the options and their defaults. I assume that it covers Opcache for all versions as there does not seem to be version specific variations of that page (or at least not that I could find).

Anyway, to disable it for Apache, you need to uncomment the relevant lines and set it/them to 0. Same (but opposite) for cli. I.e. uncomment the relevant lines and set it/them to 1.

As for xcache. I think it's somewhat similar, although it's not baked into PHP. IIRC if the package is installed, it's enabled by default via directly symlinking the module (via phpenmod), thus enabling it, without modifying php.ini. AFAIK it can still be explicitly disabled within php.ini. Now my memory has been jogged though, it's probably better to disable it via php5dismod (FWIW in Debian 9/Stretch / TurnKey v15.x - it's phpdismod). IIRC the module is (as you'd probably expect) is called xcache, so phpsdismod xcache should do the trick. Alternatively removing the package will also do the trick. I.e.

apt-get remove php5-xcache

Having said all that, as I noted, AFAIK at best it's of no value to have then both enabled, at worst will cause issues.

Hope that helps.

ddonovan's picture

Since performing the upgrade I lost my initial Turnkey-customized blue menu screen at startup.  Is there any way to reinstall it?

ddonovan's picture

Jeremy Davis's picture

First thing I'd double check is that when you did your (dist-)upgrade, that you also updated the TurnKey repos (i.e. the files in /etc/apt/sources.list.d/) to also be jessie (and not just the Debian ones). You probably did, but just in case.

A really quick way to check is like this:

apt-cache policy confconsole

It should return, something like this:

  Installed: 1.0.1+g7e2bdbe
  Candidate: 1.0.1+g7e2bdbe
  Version table:
 *** 1.0.1+g7e2bdbe 999
        999 http://archive.turnkeylinux.org/debian jessie/main amd64 Packages
        100 /var/lib/dpkg/status

If not, then hopefully that's the issue and updating the TurnKey apt source files and installing the latest should (hopefully) fix it.

If it does match that, then I'm not really sure OTTOMH. Obviously your screenshot suggests that the init-script is failing (exit code 1). Although from your output, I'm not completely clear why. I note that it's whinging about $TERM not being set, which may be the issue, but I'm not sure if it is, nor why that would be occurring.

I suggest that you try launching it from the commandline as hopefully that will give us some more explicit output. If nothing else, that might help nudge my memory in the right direction! As you've probably guessed, it should be launchable like this:


Actually, now that I think about it, it may have something to do with the new plugins system that confconsole now supports?! IIRC we added that in v14.2 and I don't think we ever tested it for a Debian (dist-)upgrade scenario (just upgrading from v14.0/14.1 to v14.2). Anyway, if it still whinges about $TERM, perhaps this is worth a try?:

export TERM=linux

Regardless, please post back the stacktrace that manually launching confconsole will likely spit out.

ddonovan's picture

I thought I was being smart and would just R&R confconsole in APT.  Unfortunately after I removed it and tried to reinstall it, APT said it was part of another package (wouldn't tell me which one) and stopped.

Output from apt-cache:

  Installed: (none)
  Candidate: (none)
  Version table:
     0.9.4+39+g4bf3279 0
        100 /var/lib/dpkg/status

Jeremy Davis's picture

The fact that it's mentioning "0.9.4+39+g4bf3279" suggests that it was always still running the Wheezy (v13.x) version of Confconsole. FWIW that was the newest version in the v13.x/Wheezy release. FWIW the first version in the v14.x/Jessie release (i.e. v14.0) was "0.9.4+44+g37f8932" and the most recent (i.e. v14.2 latest update) is "1.0.1+4+g7e2bdbe".

So check that the archive.turnkeylinux.org entries in /etc/apt/sources.list.d are all "jessie" (not "wheezy"). A quick way to check is using grep:

grep -r archive.turnkeylinux.org /etc/apt/sources.list.d

If they are still using wheezy, then swap that out for jessie (as you likely already did for the debian entries when you upgraded). Then try apt-get update && apt-get install confconsole and let me know how you go.

ddonovan's picture

So I did still have references to Wheezy in my security sources, which I hadn't changed for the upgrade.  I changed them to Jessie and still got the same result from APT:

Package confconsole is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'confconsole' has no installation candidate

Jeremy Davis's picture

Please post the output of apt-get update

There must be an error of some sort when it's updating the package lists. Otherwise it doesn't make any sense to me...

ddonovan's picture

root@webserver ~# apt-get update
Hit http://security.debian.org jessie/updates InRelease
Ign http://archive.turnkeylinux.org jessie-security InRelease
Ign http://ftp.us.debian.org jessie InRelease
Hit http://archive.turnkeylinux.org jessie-security Release.gpg
Hit http://ftp.us.debian.org jessie Release.gpg
Hit http://ftp.debian.org jessie-backports InRelease
Hit http://security.debian.org jessie/updates/main Sources
Hit http://ftp.us.debian.org jessie Release
Hit http://archive.turnkeylinux.org jessie-security Release
Hit http://security.debian.org jessie/updates/contrib Sources
Hit http://ftp.us.debian.org jessie/main Sources
Get:1 http://ftp.debian.org jessie-backports/main i386 Packages/DiffIndex [27.8 kB]
Hit http://security.debian.org jessie/updates/non-free Sources
Hit http://ftp.us.debian.org jessie/contrib Sources
Hit http://archive.turnkeylinux.org jessie-security/main i386 Packages
Hit http://ftp.us.debian.org jessie/non-free Sources
Hit http://ftp.us.debian.org jessie/main i386 Packages
Hit http://security.debian.org jessie/updates/non-free i386 Packages
Hit http://ftp.us.debian.org jessie/contrib i386 Packages
Hit http://security.debian.org jessie/updates/contrib Translation-en
Hit http://ftp.us.debian.org jessie/non-free i386 Packages
Get:2 http://ftp.debian.org jessie-backports/main Translation-en/DiffIndex [27.8 kB]
Hit http://security.debian.org jessie/updates/main Translation-en
Hit http://ftp.us.debian.org jessie/contrib Translation-en
Hit http://security.debian.org jessie/updates/non-free Translation-en
Hit http://ftp.us.debian.org jessie/main Translation-en
Hit http://security.debian.org jessie/updates/main i386 Packages
Ign http://archive.turnkeylinux.org jessie-security/main Translation-en
Hit http://ftp.us.debian.org jessie/non-free Translation-en
Hit http://security.debian.org jessie/updates/contrib i386 Packages
Hit http://httpredir.debian.org jessie-updates InRelease
Hit http://httpredir.debian.org jessie-updates/main Sources
Hit http://httpredir.debian.org jessie-updates/contrib Sources
Hit http://httpredir.debian.org jessie-updates/non-free Sources
Get:3 http://httpredir.debian.org jessie-updates/main i386 Packages/DiffIndex [11.8 kB]
Hit http://httpredir.debian.org jessie-updates/contrib i386 Packages
Get:4 http://httpredir.debian.org jessie-updates/non-free i386 Packages/DiffIndex [736 B]
Hit http://httpredir.debian.org jessie-updates/contrib Translation-en
Get:5 http://httpredir.debian.org jessie-updates/main Translation-en/DiffIndex [3688 B]
Get:6 http://httpredir.debian.org jessie-updates/non-free Translation-en/DiffIndex [736 B]
Fetched 72.6 kB in 10s (6743 B/s)
Reading package lists... Done
W: Duplicate sources.list entry http://security.debian.org/ jessie/updates/main i386 Packages (/var/lib/apt/lists/security.debian.org_dists_jessie_updates_main_binary-i386_Packages)
W: Duplicate sources.list entry http://security.debian.org/ jessie/updates/contrib i386 Packages (/var/lib/apt/lists/security.debian.org_dists_jessie_updates_contrib_binary-i386_Packages)
W: You may want to run apt-get update to correct these problems

Jeremy Davis's picture

No obvious errors. As per the warnings at the bottom, it does look like you have duplicate entries for the Debian security repo, but that shouldn't be too big a deal (although probably worth fixing).

But from what I can see of what you've posted, the only TurnKey repo you have configured is the security repo - i.e. "jessie-security". There is no entry for " jessie main".

Somewhere within /etc/apt/sources.list.d/ you'll want an entry like this:

deb http://archive.turnkeylinux.org/debian jessie main

By default we put it in /etc/apt/sources.list.d/sources.list but so long as it's within /etc/apt/sources.list.d/ and the file has a .list

As an aside, it also looks like you're using a local Debian mirror (ftp.us.debian.org ) but still also have entries for the Debian CDN (httpredir.debian.org). I recommend that you pick one and remove (or comment) the other(s).

FWIW here's what I'd probably use:

deb http://archive.turnkeylinux.org/debian jessie main

deb http://deb.debian.org/debian jessie main
deb http://deb.debian.org/debian jessie contrib
#deb http://deb.debian.org/debian jessie non-free
deb http://archive.turnkeylinux.org/debian jessie-security main

deb http://security.debian.org/ jessie/updates main
deb http://security.debian.org/ jessie/updates contrib
#deb http://security.debian.org/ jessie/updates non-free

If you have software from "non-free" you can uncomment those lines (i.e. remove the leading "#"). Also if you have a /etc/apt/sources.list file (possibly where the local Debian mirror is noted? i.e. ftp.us.debian.org ?), I'd probably just disable that. E.g.:

mv /etc/apt/sources.list /etc/apt/sources.list.disabled

Once you've done all that, rerun apt-get update and try installing confconsole again.

ddonovan's picture

Yep, that did it.  The tkl archive was #'d.

Ok one more:

I don't get a grub loader at boot.  Is this fixable?


Jeremy Davis's picture

If you are getting a grub/grub rescue shell, then hopefully you should be able to manually boot. For example, something like what is explained in this blog post I found via google (note that I haven't tested it, but on face value it looks relevant - if you're getting a grub prompt). Although from the look of what you've posted, you may not even be getting that far...

I'm not 100% sure of what your issue may be, but considering you're using LVM, then it may be partitioning that is causing the issue? IIRC LVM on 7/Wheezy required a separate non-LVM boot partition (it couldn't boot straight into LVM). Whereas in Jessie it will happily boot straight into LVM and doesn't require a separate partition. What can sometimes happen is that after an upgrade, the separate /boot partition is loaded later in the boot process, so in your running system it uses that. But when you reboot, it tries to boot straight from the LVM and assumes that the /boot mountpoint in that is your /boot directory - but it's likely empty (everything is in the separate /boot partition). FWIW a somewhat related issue is noted on our tracker.

Another possibility (an "and/or" scenario) is that because you didn't have the TurnKey main repo enabled, it hasn't upgraded our custom "busybox-initramfs" package. That could also explain why there are missing files.

None the less, you should still be able to rescue the system, so long as you can boot from an ISO. Judging from your previous posts it seems you're on a 32 bit system. The OS itself shouldn't matter, but I'm pretty sure you'll need to match the bits (i.e. use a 32 bit live ISO). Personally, I'd be inclined to use a 32 bit Jessie based live ISO to be on the safe side. FWIW, here's a link to the 32 bit v14.1 TurnKey Core ISO that you could boot from in live mode. Whatever you do, DON'T install it! Just boot live into the system. Otherwise you'll totally wipe out your existing OS!! (I'm sure that is obvious to you, but I'd rather state it when not required, than risk a misunderstanding or oversight). If for some reason you want to try something else, that should also work, but I'm not clear on exactly which factors may affect it... In theory, pretty much any Linux live ISO should allow you to do what you need to do.

Once you've booted with a live disk, then you'll need to mount your broken OS. The fact that you're using LVM makes it a little trickier, but assuming that you are using TurnKey ISO that I linked above and the Live ISO defaults to a VG of "turnkey" (you already stated that your installed system uses "turnkeyvm") it should still be possible. FWIW if the VGs are the same, then there will be issues.

So check for volume groups:


If there are multiple volume groups with the same name, it will let you know and you'll need to address that first. This should assist you to resolve that?!

Assuming that the VG of the installed system is 'turnkeyvm' (adjust the below if it's not) then load the VG and mount your root:

vgchange -ay turnkeyvm
mount /dev/turnkeyvm/root /mnt
mount --bind /dev /mnt/dev

Many tutorials recommend also mount binding /dev/pts /proc & /sys but I don't think it's necessary although if you get errors, then try that (i.e. the mount bind line above and swap the /dev and /mnt/dev for each of the other locations, e.g. mount --bind /dev/pts /mnt/dev/pts).

There are 2 ways to resolve this AFAIK, but the one I'm familiar with is to ditch the separate boot partition. If you want to play with the other approach, be my guest. So first up, set up the boot dir and (re)install grub. This assumes that the drive which your system should boot from is /dev/sdX, swap it out for what it really is, if you're not sure, run "vgdisplay" again which should hopefully make it clear.

chroot /mnt
mkdir -p /boot/grub
grub-mkconfig -o /boot/grub/grub.cfg
grub-install /dev/sdX
grub-install --recheck /dev/sdX

Hopefully that all looks good. Then to make sure that you have the current busybox-initramfs package, install it (obviously you'll need networking for this, hopefully you do...) This is still in your chroot.

apt-get update
apt-get install busybox-initramfs

Now also make sure that the old /boot partition won't get mounted at boot, make sure it's not in the /etc/fstab file, if it is comment it out (i.e. put a '#' at the start).

Then once all that's done, exit the chroot, unmount and reboot. Fingers crossed you should be all good now... (if you mounted other stuff e.g. /dev/pts, unmount them too).

umount /mnt/dev
umount /mnt

Hopefully you should now be all good...

ddonovan's picture

It doesn't seem to be affecting anything at this point, so I'll keep those instructions handy in case I need them.

Right now I'm attempting another migration to a different server with a fresh 14.2 image.  We'll see how that goes.

Add new comment