Phillip Moore's picture

Hello, I need to upgrade from our current Turnkey 12 in which we have MediaWiki installed to the latest Turnkey 14 which supports the latest PHP version needed for the latest upgrade of MediaWiki.

I am trying to create a virtual machine that boots to the ISO to install the OS.  I'm currently trying to use Turnkey 14.1 Core.  I have also tried using the OVA and got the same result.  During boot, I get an error "fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge" and then the server hangs.  I try pressing "ALT+F2" and try to get to a login prompt, but everything is just stuck on the boot screen.  I have attached a screenshot of where the install/boot hangs.  I'm not sure how to get around this?  Any ideas?  I got this same exact issue after installing a virtual machine from an OVA file too with Turnkey 14.1 Core.

I'm using Oracle VM which is based off of XEN.

Sincerely,

 

Phill Moore

Forum: 
Jeremy Davis's picture

Out of interest I did a bit of googling. TBH I couldn't find anything directly helpful. However I did find a number of (totally irrelevant) posts e.g. here on GitHub which include the same log entries as you, but still booted successfully. That leads me to think that something else is going on. My suspicion is that whatever it is getting stuck on is not even being written to the screen.

But perhaps my suspicions are wrong? If you think it may be something to do with those messages, perhaps the advice in this thread might be worth a try?

If that's a dead end, I'd be inclined to test an amd64/x86_64 Debian Jessie (8.4) ISO and see if that installs/boots ok. If it works ok, then at least we've whittled it down to a TurnKey issue (although IMO it's unlikely as we use the vanilla Debian kernel). If Debian has the same issue then it's obviously something to do with Debian itself and we'll need to log a bug against the kernel.

The other things I'd be inclined to try would be testing different virtual hardware config. E.g. I've never used Oracle VM but KVM offers a ton of different CPU options.

Phillip Moore's picture

I will get back to you on this with my findings.  I too am curious about installing a regular Jessie ISO.  Also, with the link you sent, it won't work for me.  I cannot type in anything or do anything when it boots. I'm going to try it again though.  Our oracle personel has made an update on the repository, and maybe something was just locked that they had fixed.

Phillip Moore's picture

Ok, Debian 8 fails to install on Oracle VM Server/Manager.  Too bad they do not support Debian too.  The previous version worked well, but not the latest stable :(

Jeremy Davis's picture

Unfortunately it's not giving you exactly the same error so it's hard to know if it the same issue just manifesting differently or whether it's a completely separate problem.

I did a little more googling and found lots of people talking about Debian issues with (Oracle) VirtualBox (which is weird as I've never had issues with Debian on VBox) but nothing specifically relating to Oracle VM. I have no idea if they share any code (i.e. VirtualBox vs Oracle VM) so they may well all be totally irrelevant.

Does Oracle VM have any support forums or mailing list at all? Might be worth following up there as TBH I have no ideas...

Phillip Moore's picture

Yeah, completely understand.  I'll inform our Oracle guy and see if he wants to send in support request, but or if he can find any more info on this.  Otherwise we will have to move away from Debian (my favorite distro) and move over to Oracle's Redhat linux or something.

One thing that does work is installing the previous version of Debian, and then changing the repositories to upgrade to Jessie.  Though I think I saw somewhere that you aren't supposed to do that with turnkey.

Also, I'm trying to install the i386 Debian now to see if that has any other results

 

Phillip Moore's picture

Also, the Oracle guy told me that Oracle VM Server uses XEN for virtualization.  When I look at the commands for XenServer, it looks the exact same for XenServer.  I looked up if XenServer people were having Debian 8 issues and they were all having the same issues.  Their fix was just to install Debian 7 and then upgrade to 8, lol.

I just finished trying the 32bit version (i386) and it failed with the same error.  For now, my solution will be to install Debian 7 and upgrade to 8.

Thanks for your help!

Jeremy Davis's picture

That's a sucky workaround! But thanks for the extra info. It is interesting to hear that Oracle VM is essentially a fork of XenServer. We have hosting partners that use (vanilla) Xen but perhaps they are using older versions of it and it's a recent regression? Or perhaps there is something that XenServer includes/doesn't include which causes this?

FWIW there is no fundamental reason why you couldn't install the previous version of TurnKey and upgrade. As I said it's Debian under the hood so should work fine.

The reason why we don't recommend that as the "preferred" option is simply because not all of our tweaks are packaged. Some of our tweaks and updates are provided via filesystem overlays (or scripts) at build time. If you upgrade from a previous version you won't get any of those.

The other problem with installing an earlier version of TurnKey and upgrading is that we no longer have any old versions available for download! :(

We have a policy of only keeping the current and previous stable releases. Although there was a little internal confusion over exactly what that meant. When I agreed to the policy I thought it meant the last stable point release of the current and previous versions (i.e. latest v13.x release & latest v14.x release). But obviously Liraz understood it differently when he cleaned the mirror last!

Regardless, Liraz was a little overzealous when he last cleaned anyway as we now only have the current release...

Good luck with it all and please let us know if you discover a better workaround (or better yet a proper fix).

Phillip Moore's picture

Well, we do have the v13 Turnkey Core ISO, so that shouldn't be a problem.  We may just have to miss out on the tweaks I guess.  The main issue is to test out the backup and restore to make sure that will work fine still.  We currently use HelpSpot, and they recommend Debian 8 for their automated install scripts.  With Debian 8, we can install all requirements without any special PHP/MySQL installs from anything other than their distro's repository.  I was looking at Ubuntu, but 14.04 repository's do not support the version of PHP and MySQL and 16.04 uses PHP 7 which HelpSpot isn't supported on yet.  Also, we have another MediaWiki server that we usually keep up to date with the latest version, but we now how to upgrade to Debian 8 (I think) to support their latest PHP requirements too.  Also, I can't actually upgrade the latest MediaWiki until they update their LDAP authentication plugin too.  I was just going to upgrade the server behind it to get it ready until it is updated.

Once a better solution appears, I can keep this thread updated.

Phillip Moore's picture

small update:

If you install Wheezy and upgrade to Jessie, the Oracle VM Server (Manager) will still not display the console and it hangs in the same spot.  Though, the server will actually startup and you can still SSH into the machine, etc.  I ended up creating a VM Template of the server.  Before that, I made sure to setup DHCP and install winbind.  Since if I make a server I will not know what IP it gets, I use winbind to bind the hostname to the windows network so I can then just ping the hostname to get the initial server address.  I then created a script that changes the hostname in all necessary files and restart networking, smdb, nmdb services to apply updates.  It also runs the hostname command to change the hostname w/o rebooting.  I have a list of files it looks at to do the replacement.  So then you have to be careful that your hostname is not text that already exists in the files, lol.

Mike Tudor's picture

Hello,

I have a same issue. We are using XEN HVM and after mounting ISO image and connecting to VNC we get to the install screen. However, after proceeding to either install or boot, vnc shows info up to acpiphp slot 11 registered and then just freezes.

Then we added 

console=tty1 console=ttyS0

to the boot options and were able to access serial console via xl console.

We also tried without installation (using turnkey premade disk image) but we found out that although VM works, vnc still hangs.

It is very wierd because any other debian live image works without problems on the same system

Jeremy Davis's picture

None of us behind the scenes have access to a Xen/XenServer/OracleVM hypervisor so it's really hard to check any of this stuff ourselves.

Having said that, now I think about it, when we were working on the v14.0 release, we had to tweak the config for the container build to support Proxmox's built-in NoVNC client. I wonder if that is related?

Mike Tudor's picture

Could be, please give me the instrunctions and I will give it a try for sure.

Thanks!

Jeremy Davis's picture

I started having a quick look through the git log see what we introduced/changed for the container build for v14.0 but couldn't see any explicit mention from a quick glace (it may be there though and I just missed it...).

FWIW it should be in the "container" patch. That is what we apply to the contents of the ISO to create our LXC container build. Code is here: https://github.com/turnkeylinux/buildtasks/tree/master/patches/container

Mike Tudor's picture

Also, I can confirm that direct drivers passthrough works great with Xen PVonHVM and if you connect turnkey to the S0 console and let the boot process finish (without being interrupt by a graphics console), everything boots and works out of the box.

Overall I like this project very much and appriciate your time and effort. So far we have only noticed this little glitch with VNC on Xen HVM but we think that KVM does not have this issue though.

Jeremy Davis's picture

I regularly use KVM and haven't noticed it myself so I'm inclined to agree.

Thanks for posting the additional workaround info for Xen too! :)

Add new comment