# Fedora bhyve VM dies during boot?



## `Orum (Aug 4, 2018)

I'm trying to virtualize one of our "black box" embedded systems to run under bhyve, and run into an issue where it dies during boot.  The original machine has a VIA EPIA board, and although I don't remember exactly what model it is (as I'm not at work right now), it's very old.  To give you a bit of an idea, it has only IDE ports--no SATA, and it is probably a 32-bit system.  I've since managed to image and restore the disk into a bhyve VM by booting to some software, and following the vm-bhyve wiki, gotten it to start booting.  The problem is, after it starts booting, it suddenly dies.

First, let me show you the current config I'm using:

```
guest="linux"
loader="grub"
grub_run_partition="msdos1"
cpu=1
memory=1G
network0_type="virtio-net"
network0_switch="data"
disk0_type="ahci-hd"
disk0_name="disk0.img"
disk0_opts="sectorsize=512"
grub_run0="linux /boot/vmlinuz-2.6.18-1.2798.fc6 root=/dev/mapper/VolGroup-lv_root"
grub_run1="initrd /boot/initrd-2.6.18-1.2798.fc6.img"
grub_run2="boot"
uuid="redacted"
network0_mac="redacted"
```
To debug, I've commented out the grub_runX lines, and run the commands manually via the `vm console` command, which at least shows me the booting process, presumably right up until it crashes:

```
Linux version 2.6.18-1.2798.fc6 (brewbuilder@hs20-bc2-3.build.redhat.com) (gcc version 4.1.1 20061011 (Red Hat 4.1.1-30)) #1 SMP Mon Oct 16 14:54:20 EDT 2006
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009ffff (usable)
BIOS-e820: 0000000000100000 - 0000000040000000 (usable)
128MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000f0000
Using x86 segment limits to approximate NX protection
DMI 2.4 present.
Using APIC driver default
ACPI: PM-Timer IO Port: 0x408
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 6:10 APIC version 16
ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 0 already used, trying 1
IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-31
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
Enabling APIC mode:  Flat.  Using 1 I/O APICs
ACPI: HPET id: 0x80860701 base: 0xfed00000
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 50000000 (gap: 40000000:c0000000)
Detected 3092.599 MHz processor.
Built 1 zonelists.  Total pages: 262144
Kernel command line: console=ttyS0 BOOT_IMAGE=/boot/vmlinuz-2.6.18-1.2798.fc6 root=/dev/mapper/VolGroup-lv_root
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c079f000 soft=c077f000
PID hash table entries: 4096 (order: 12, 16384 bytes)
Console: colour EGA 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1034168k/1048576k available (2105k kernel code, 13776k reserved, 844k data, 240k init, 131072k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
hpet0: at MMIO 0xfed00000 (virtual 0xf8800000), IRQs 2, 8, 0, 0, 0, 0, 0, 0
hpet0: 8 32-bit timers, 16777216 Hz
Calibrating delay using timer specific routine.. 6196.92 BogoMIPS (lpj=12393849)
Security Framework v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 512
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 256K
CPU: L3 cache: 8192K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 12k freed
ACPI: Core revision 20060707
CPU0: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz stepping 07
```
...and then it's gone.  `vm list` simply shows it in the "Stopped" state, and I don't see anything interesting in `dmesg`.  Any ideas on where to go from here, or how to better debug this?


----------



## nihr43 (Aug 5, 2018)

2.6 is ancient.  see if you can boot that image in virtualbox or kvm.  or see if you can boot something else with 2.6 in bhyve (like debian 4.0 from my googling)


----------



## `Orum (Aug 5, 2018)

nihr43 said:


> 2.6 is ancient.


I'm aware.  If things go according to plan, I'd like to update it, but ideally _after_ I get it booting in bhyve.  The main reason is that reverting changes if something goes wrong is a lot easier if it's a VM (as I don't think ext2 has snapshots).  Additionally, there's no real shell on the system, or at least that I've found now.  Right now if you log in, you get a menu with a whopping 3 options: A) Change the IP address B) Change the password and C) Exit.  I imagine I can find some old binary and drop it on there by booting to a different disk, but no matter how you slice it it's going to be a PITA.

I'll try and get Debian booting, and see if I can get a more verbose debug log from that.

*Edit:* Alternatively I may just try and rip all of the applications it's running off of it and moving them to a more standard installation.  Pretty sure that will be far from a cake-walk though.


----------



## usdmatt (Aug 5, 2018)

Unless things have changed I don’t think bhyve will run 32 bit systems. I’m not sure you’ll get a working disk either unless the guest has ahci or virtio support.


----------



## `Orum (Aug 5, 2018)

usdmatt said:


> Unless things have changed I don’t think bhyve will run 32 bit systems.


I know that the _host_ system has to be x86-64, but I believe guests can still be 32-bit.  Interestingly, it's hard to actually find any official word on this, and the best I could find was this Wikipedia chart.  I did look at the original board today and it's an EPIA-ML board, which uses a VIA C3/Eden, which is 32-bit.


usdmatt said:


> I’m not sure you’ll get a working disk either unless the guest has ahci or virtio support.


I suspect this is the real problem.  I'm going to restore the image to a physical SATA disk, and see if it boots.

I did find one more piece of information from the log, which at least gives the exit code: "bhyve exited with status 134", but I'll have to dig through the code to find out what that means.

*Edit: *I've given up trying to get it to boot, but I'm almost certain it's because it lacks any form of SATA/AHCI driver.  Instead I'm just going to try and move the apps it's running to another OS, hopefully FreeBSD.


----------



## usdmatt (Aug 6, 2018)

I was going by this mailing list post, which is fairly old, but I've never heard any different

https://lists.freebsd.org/pipermail/freebsd-virtualization/2013-November/001741.html

If the kernel is loading I'd expect to just hit the Linux equivalent of `mountroot>` if the disk controller wasn't supported.


----------



## `Orum (Aug 7, 2018)

Well that post is almost 5 years old now, so things might have changed.  I wish it were mentioned in the man page for bhyve(8)...


usdmatt said:


> If the kernel is loading I'd expect to just hit the Linux equivalent of `mountroot>` if the disk controller wasn't supported.


The main reason I suspect the issue is with SATA is due to it failing to mount filesystems after I restored it to physical machine with a SATA HDD.  It did eventually get to prompt similar to that, but even after fiddling around with countless grub v0.97 configurations, and checking its /etc/fstab I couldn't get it to fully boot.

Perhaps it's a blessing in disguise though, as I did find that it has bash on it, so I reset the password for root and can now pull things off of it with relative ease.  The real trick may be getting its old ruby code working with more current versions though.


----------

