Anyone able to boot Ubuntu 16.10 server install cd or netboot iso?

[ck-kc]

I don't seem to be able to do the above at all. Seems like xhyve can't see the ahci-cd device, can't find root filesystem. Also ?uncompression error on initrd.gz...

What should I specify as root on the commandline??

I installed via macports I think (xhyve -v doesn't give me a version number!!!)

My config looks like this:

# Linux
KERNEL="/opt/local/share/xhyve/ubuntu/linux"
INITRD="/opt/local/share/xhyve/ubuntu/initrd.gz"
CMDLINE="earlyprintk=serial console=ttyS0"

# Guest Config
MEM="-m 1G"
IMG_CD="-s 1,ahci-cd,/opt/local/share/xhyve/ubuntu/mini.iso"
IMG_HDD="-s 2,virtio-blk,/opt/local/share/xhyve/ubuntu/hdd.img"
NET="-s 3,virtio-net,vmnet0"
PCI_DEV="-s 0:0,hostbridge -s 31,lpc"
LPC_DEV="-l com1,stdio"
ACPI="-A"

# and now run
sudo xhyve $ACPI $MEM $PCI_DEV $LPC_DEV $NET $IMG_CD $IMG_HDD -f kexec,$KERNEL,$INITRD,"$CMDLINE"

[diclophis]

I can confirm this error

[fay59]

It also happens with 1704.

[fmckeogh]

Dwoz's branch is the most active and works with 17.04.

[bluen]

Yes, it seems to happen with more recent kernels in Ubuntu - 16.04.3 standard kernel (4.4) works, but hwe kernel (4.10) and hwe-edge (4.13) do not.

I can confirm that Dwoz's branch works for those kernels.

[Owersun]

After my investigation I've found out that there are two things involved that caused this. First, the driver for "virtio-blk" device started to be built as a module in newer kernels, and not included in. This means that kernel require initrd to boot, otherwise it will not find the module to initialize image as hdd And secondly there is a bug in xhyve official release available through homebrew (0.2.0) that make initrd not useable. It is described here: https://github.com/mist64/xhyve/issues/116 In short, initrd is loaded to memory offset that is after that overwritten by the kernel itself.

So what is happening is that kernel loads, kernel has no driver for virtio-blk device, and initramfs from where it can take the module is impossible to load use as well.

[kowoba]

So, it should be possible to boot a kernel without initrd?

That too doesn't work for me.

With a 4.17.14 kernel with CONFIG_VIRTIO_BLK=y in the config, and trying to load it using kexec (and I always use kexec these days) from fully working and functioning 4.14.62 kernel (including initrd), xhyve throws "Abort trap: 6" after output looking like this...

vm exit[0]
                reason          VMX
                                        rip             0x000000000009e019
                                                                                inst_length     3
                                                                                                       status           0
                        exit_reason     33
                                                qualification   0x0000000000000000
                                                                                        inst_type      0

        inst_error              0

[Owersun]

I'm also tryin this as well, and yes, it seems there is something else involved additionally to things I've mentioned... Self-built kernel is not bootable at all. Possible that ubuntu disabled some other things in kernel affecting boot process in xhyve.

[kowoba]

Well, I am not using Ubuntu :)

For me, everything was working dandy up to kernel 4.15, and I have tried using plain vanilla kernels from kernel.org, as well as other kernels, but result is always the same. 4.15 and 4.16 kernels used to hang on boot, and not bring xhyve to abort, like the 4.17 kernels do. I have currently just "pinned" kernel sources to 4.14, and as mentioned, 4.14.62 boots perfectly fine, using initrd and all.

[Owersun]

I did the same with pinning kernel that works. Googling resulted in explanation "error_reason 33" means something went wrong in virtualization, some people suggest checking VT-x and VT-d enabled in BIOS, which I cannot do on mac... But as far as I know from hackintosh forums VT-d is the one that is being disabled for mac os to be installed. Also could be a case. Anyway, things that I've mentioned in first post are true, that's for sure, I can test and confirm that they are the case (for ubuntu starting from kernel 4.4.0-109-generic), and the error_reason 33 is something out of my expertise.

[jeremyhu]

Is this still an issue with current master? I'm guessing this is a dupe of #144