You are here
[ copied from docs page ]
I've just downloaded the latest TKL VMDK for Redmine, and I'm trying to run it in Virtual Box 4.2. I unpacked the VMDK, and attached it to a new VM, with 1G of RAM and PAE enabled. It boots grub, and then autoboots to a 3.2.0-4-amd64 kernel (even though my laptop is a Celeron), tells me it's trying to load the initrd, and then hangs there forever.
Is there something else obvious that perhaps I'm missing in the VM creation? The Vbox install is tested and runs Win7 ok on this machine. There's a 4.3 release out, and I'll go get that, but I don't expect that will actually fix this category of problem...
For the record, I have since downloaded the OVF and imported it, and it hangs in the same place, whether in normal or Recovery mode boot.
Sorry: The host OS is Win7/64
Sorry: The host OS is Win7/64
You might need to use 32 bit version
To run any 64 bit OS in VirtualBox you need a CPU that supports virtual extensions (i.e. VT-x for Intel chips) and I doubt Celerion does. If it does, then perhaps you'll need to enable it in the BIOS?
You can get the 32 bit Redmine VMDK direct from SourceForge.
D'oh
I'm assuming if the bios had the VT-X knob I'd have had it on, but I'll check. If not, I'm fine running the 32 bit one for testing. Thanks.
Core too? What about the ISO build?
Did you try deploying TurnKey Core to see if this is specific to Redmine? Also, you can try deploying from the ISO build. Just tell VBox to insert the ISO into the virtual CDROM.
Yup, the -686 version boots
Yup, the -686 version boots fine.
I do see, though, that the Redmine firstboot script fails to validate plushacked email addresses (for the Redmine admin account); this is a hobbyhorse of mine. Is that likely to be Redmine's failure or Turnkey's, and where is the best place for me to hang a bug?
Great news!
As for the issue, do you mean email addresses with a '+' in them? If so there is already a bug noted (back in January) on the TurnKey Issue Tracker. Feel free to log any other bugs, issues or feature requests you have there. I'm generally pretty active over there too and will make sure that it get's tagged appropriately.
Back to your original issue though, it sounds like VBox isn't providing a 64 bit virtual CPU to the VM. As I mentioned, I doubt that a Celerion CPU even supports VT-x. Unlike AMD, Intel didn't make it a standard feature across it's CPU range; in an old PC I have a medium range Core2Quad chip that doesn't support it (when most Core2Duo chips did)! Also FWIW it's usually disabled by default in BIOS when PCs ship so if you haven't already enabled it manually then it's probably disabled (that is if it exists). Obviously it also relies on the motherboard supporting it (which most do). I have also come across motherboards that support it (and have the setting in BIOS) but when teamed with a CPU that doesn't, thus adjusting the setting it in BIOS will make no difference... So you'll need to research your CPU model on the Intel site.
One other final thing that I didn't consider previously is that IIRC you have to make sure that you have selected the OS type in VBox as x64. I don't recall if Debian (OS in VBox) has a x64 option but I know Ubuntu does so perhaps try that...
Apparently the only C900 that
Apparently the only C900 that supports VTx is the 927ue, which I don't know if i have. The bios on this G71 laptop doesn't have a knob for much of anything, and VTx certainly ain't on that list. TKL builds are going to be troublesome to run on VBox anyway, though, since you have the choice of bridging... in which case the build can't pull a DHCP address cause you've already got one, or NAT... in which case you have to manually build the DNAT's back into the box so you can play with it.
I concur with the bug, though i disagree with the suggested fix; it's always good to validate data at entry which can be validated, and RFC 5322 addresses certainly fall in that category. :-)
My Linux latop is a Thinkpad x61, and I'm pretty sure it does this right; I'll try it there.
Sounds like your out of luck for x64
But the 32 bit version should be adequate. They're essentially the same, although the 64 bit versions are a little more memory efficient. I imagine that this server probably won't be having a huge load anyway, so that may not even be a concern...
As for networking, it depends what your intention is. If this is for your own dev work then you could just go with 'host only' and add a NAT network as well (to get updates and install additional software.
Otherwise you could just use a 'bridged' connection and set a static IP (within TKL). Although you may have to adjust it, depending on the network you are connected to at the time (i.e. if you connect your laptop to a network that uses a different subnet, or if there is an IP conflict with another PC on the LAN).
The other option (as you noted) would be to use 'NAT' networking and set up port forwarding. Personally I'd also set up a 'host only' connection then you'll only need to forward the port you want to use for the Redmine services that you want to be available (and everything else, such as SSH, etc can be handled from your laptop via the 'host only' network). The only issue would be if you want to use those ports for something else (on your laptop or another VM).
TBH I'm not quite sure what you're referring to by "manually build the DNAT's back into the box". I haven't played with NAT much in VBox but I found it pretty straight forward (I just forwarded a couple of ports using the VBox GUI).
VirtualBox networking
I'm sorry; I guess I didn't show my work all that well there.
ISTM that for the purpose at hand -- using TKL images in VBox to learn about the packages -- that you need connectivity out from the image to the net, and that you need connectivity into the image from the host machine.
The host machine is (probably) usually a laptop, and it's on some LAN or WLAN somewhere with an address externally assigned by DHCP.
The image is configured by default to use DHCP to pick up its own address, so it won't work in Bridged mode, because you've already got one -- or such was my experience; the DHCP ask failed.
You don't want to use Host Only because then the image can't get to the outside world. On Redmine, that probably only impacts autoupdate, though I could imagine that on other images it would matter mode.
And if you use VBox's NAT setting, then the image is behind a simulated NAT router, and if you want to get to it to do the testing you installed it for, you have to manually set up DNAT configurations in the VM definition... and I don't know whether the address the fakeNAT assigns to the machine is deterministic or not, so you might have to do that *every time you boot it*, if that NAT address is different.
If VBox always assigned the same address, then the last option is probably best.
Since I've learned that Redmine's ticketing system doesn't have as fundamental a thing as "Disposition" on closed tickets, I can see that I'll need to look through and probably grab some extension plugins, so I care if it can get out for that reason as well.
IIRC bridged mode should allow it to get an IP from DHCP
TBH bridged is all I've ever used as a general rule. And I don't recall any issues getting an IP from DHCP (although I haven't tested recently & I tend to set static IPs anyway...)
Host only is fine (as long as you just want access on your laptop) but you'll also want a NAT vNIC to allow you to get updates etc (i.e. you don't need to configure port forwarding or anything cause you'll only use it for outgoing connections).
TBH I haven't played with NAT much but it's definitely a PITA if it's your only network connection for a server. Although AFAIK it should save the settings and reapply them when you restart. Personally it's not the way I'd go...
Add new comment