You are not logged in.
It seems that recent arch boot CDs (have tried archlinux-2014.01.05-dual.iso and archlinux-2014.03.01-dual.iso) don't like running in VirtualBox in a Debian-based (and possibly others?) host system. It shows the initial splash screen with boot menu, but choosing either i686 or x64 boot option results in the VM showing just a frozen cursor an a blank screen, then pegging the CPU at 100%. I've tried all manner of settings for the VM: IO APIC on/off, PAE exposed or not, VT-X / Nested paging on/off, changing the number of virtual CPUs, all the different chipset and ATA controller types, etc.; every combination of settings I've tried results in that frozen black screen.
An older Arch boot CD (archlinux-2012.11.01-dual.iso) works fine, as does every other bootable CD I've tried (Windows XP, 8 [64 and 32-bit], other Linuxes, etc.).
I've tried "noacpi noapic nomodeset irqpoll", this still resulted in the frozen black screen.
I've encountered this on two different variants of Debian as the host system: Ubuntu 12.04 LTS, and plain Debian 7 (Wheezy). I think I've tried a 4.3 and 4.1 variant of VirtualBox (can't remember the exact version from the Ubuntu system but am reasonably sure it was a 4.3 from backports; the Wheezy system has VirtualBox 4.1.18), so this problem doesn't seem specific to a particular kernel module build or host kernel.
I have not tried different host systems besides Debian yet, but I'll be able to try on a Windows host tomorrow.
Any other suggestions for things I could try?
Edit: This thread seems the most similar to my problem: https://bbs.archlinux.org/viewtopic.php?id=176966
Last edited by thetrivialstuff (2014-03-30 22:42:20)
Offline
Yes, I installed Arch by downloading bootstrap image, then chroot in bootstrap environment, then arch-chroot into target environment (twice chrooting). I didn't believe it is even possible until I figured it out.
https://wiki.archlinux.org/index.php/In … ting_Linux
rm -rf /
Offline
Yes, I installed Arch by downloading bootstrap image, then chroot in bootstrap environment, then arch-chroot into target environment (twice chrooting). I didn't believe it is even possible until I figured it out.
https://wiki.archlinux.org/index.php/In … ting_Linux
Good to know -- but in this case I'd really like to get the CD working somehow, because the Arch CD is my favourite rescue CD toolkit -- I often use it just for checking filesystems, moving partitions around, etc. on systems where I'm not actually installing Arch :)
Offline
thetrivialstuff,
it's a longshot, but can you check if virtualbox was setup to emulate EFI or Bios ?
The setting should be somewhere under extended features in virtualbox
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Online
thetrivialstuff,
it's a longshot, but can you check if virtualbox was setup to emulate EFI or Bios ?
The setting should be somewhere under extended features in virtualbox
That was one of the settings I've already tried, unfortunately -- actually, I suspect VirtualBox's EFI mode to be kind of buggy; I've never had it work stably anywhere (e.g. a distro will boot once, then break until you turn EFI off and back on, that sort of thing).
Anyway, when I turn EFI mode on the VM just immediately exits and says "Aborted." Here's the last bit of VBox.log afterwards:
00:00:00.778 HWACCM: 32-bit and 64-bit guests supported.
00:00:00.778 HWACCM: VMX enabled!
00:00:00.778 HWACCM: Enabled nested paging
00:00:00.778 HWACCM: EPT root page = 000000009c86d000
00:00:00.778 HWACCM: Unrestricted guest execution enabled!
00:00:00.778 HWACCM: enmFlushPage 1
00:00:00.778 HWACCM: enmFlushContext 1
00:00:00.778 HWACCM: TPR Patching disabled.
00:00:00.778 HWACCM: Using the VMX-preemption timer (cPreemptTimerShift=5)
00:00:00.778 HWACCM: VT-x/AMD-V init method: GLOBAL
00:00:00.785 VM: Halt method global1 (5)
00:00:00.786 HaltedGlobal1 config: cNsSpinBlockThresholdCfg=2000
00:00:00.786 Changing the VM state from 'CREATING' to 'CREATED'.
00:00:00.786 SharedFolders host service: adding host mapping
00:00:00.786 Host path '/VM_disks/Immigration', map name 'Immigration', writable, automount=true, create_symlinks=false
00:00:00.786 Changing the VM state from 'CREATED' to 'POWERING_ON'.
00:00:00.787 Changing the VM state from 'POWERING_ON' to 'RUNNING'.
00:00:00.790 EFI Panic: Unexpected trap!!
00:00:00.790
00:00:00.790 !!Assertion Failed!!
00:00:00.790 Expression: <NULL>
00:00:00.790 Location : /tmp/buildd/virtualbox-4.1.18-dfsg/src/VBox/Devices/EFI/DevEFI.cpp(372) int efiIOPortWrite(PPDMDEVINS, void*, RTIOPORT, uint32_t, unsigned int)
00:00:00.790 Unexpected trap during early EFI bootstrap!!
Offline
I often use it just for checking filesystems, moving partitions around, etc. on systems where I'm not actually installing Arch
Are your boot problems when trying to boot into an existing guest, setup with someOS ?
Or do they occur when you try to boot a guest with no OS yet ?
If the second, try choosing either archlinux or archlinux(64) when virtualbox asks you what type of system to emulate.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Online
Are your boot problems when trying to boot into an existing guest, setup with someOS ?
Generally, yes; when I'm trying to boot from the Arch CD it's because I want to do maintenance on an existing install of something else. In the most recent cases a Windows XP guest, and trying to access a btrfs partition that was created with a version of btrfs too new for the debian system I was on :P
try choosing either archlinux or archlinux(64) when virtualbox asks you what type of system to emulate.
...You know, that's one setting I don't think I tried. I'm gonna be really embarrassed if that works :P I'll try it when I get home from work.
In the mean time, I just got the Arch CD to boot with no problems on a Windows 8.1 64-bit host running VirtualBox 4.3.4 -- and it didn't matter what guest OS type I picked; it booted when I set it to XP as well as Arch Linux. So, it's possible that whatever's causing this issue was fixed in a recent version of VirtualBox; I might try installing the latest one from backports.
Thanks for your help.
Last edited by thetrivialstuff (2014-04-01 21:31:07)
Offline