EXOS on GNS3 not booting past BusyBox

[wkb289]

Trying to boot EXOS v32.6.3.126 on GNS3 v2.2.50 running as a VM on Hyper-V and cannot get past BusyBox. I don't see anything on the tutorial site about this. The only warning I see during boot is about the CPU:

Warning. Could not determine the CPU Family.
model name      : QEMU Virtual CPU version 2.5+

Attached is the full boot screen via telnet (it's a text doc; rename and take off the csv extension).

I've tried building the template using both what's built-in to GNS3 and downloading from the Github tutorial page. Files: exos.gns3a/exosvm.gns3a, EXOS-VM_v32.6.3.126.qcow2

Qemu is set to /usr/bin/qemu-system-x86_64.

The VM has ExposeVirtualizationExtensions set to true in Hyper-V.

[Sietse]

I have found that runing qemu with -cpu Haswell-V2 works.

But extreme, please add lvm64 and qemu2.5 CPUs to the supported cpu's.

[Gabriel_G · Accepted solution]

Hmm,

I'm not sure what your issue is exactly, I'm not having this problem with VMWare 32.6 so it could be hyper-V specific?

Regardless, the 'press c to continue' prompt is similar to a prompt that you see during a rescue image installation:
https://extreme-networks.my.site.com/ExtrArticleDetail?an=000098366

This makes me think that some input is being provided to the switch during bootup getting it into a pre-boot menu.
Or potentially the pre-boot environment is having some error leading to the prompt?

[wkb289]

I was just trying different commands in BusyBox and typed exit then it booted........ How can it be configured to boot without having to do that? You first have to press c to continue then exit.

c) continue with boot process
~> c
...
BusyBox v1.31.1 () built-in shell (ash)
Enter 'help' for a list of built-in commands.
/bin/sh: can't access tty; job control turned off
~ # exit
...
init started: BusyBox v1.31.1 ()
udevd: Starting version 244.5+
Starting ExtremeXOS 32.6.3b126
...
login:

[sdargoeuves]

I am facing the same situation, and I'm using libvirt to run the qcow2 image. Indeed, if you do `c` then `exit` on the BusyBox prompt it will boot normally.

In a manual process it's not too much of an issue, but the problem is that I am currently not able to create a functional vagrant box, or a vrnetlab docker image, and I am assuming it's related to this. Is there any way to disable this to ensure we will boot normally?

During the boot process, I see a TUI prompt asking if I want to boot from a different disk, using either serial or VGA, and the default is on serial.

It happens with the 3 different images available on github. I'm curious if anyone else has faced this, and if there is a permanent workaround, so future boots won't go through that BusyBox?