cf2012.img crashes using qemu-system-i386 (QEMU 2.8)

[eugeneia]

When I try to boot cf2012.img using QEMU 2.8 I get the following:

$ qemu-system-i386 -boot a -fda cf2012.img
WARNING: Image format was not specified for 'cf2012.img' and probing guessed raw.
         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the restrictions.
qemu-system-i386: Trying to execute code outside RAM or ROM at 0x8998c426
This usually means one of the following happened:

(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine)
(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end
(3) Your guest kernel has a bug and crashed by jumping off into nowhere

This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine.
If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point.

Execution cannot continue; stopping here.

My system is Linux 4.4.38 #2 SMP Sun Dec 11 16:18:36 CST 2016 x86_64 Intel(R) Core(TM) i3-4010U CPU @ 1.70GHz GenuineIntel GNU/Linux, i.e. I built the image on a 64 bit host.

[narke]

I built on my 64-bit Debian and it works.
Which distribution do you use?

[narke]

OK, I tested it on Ubuntu 16.04 LTS and I got the same message as you. It seems that qemu's some command line options have changed, now if you run it with the new options format it should run: qemu-system-i386 -drive format=raw,file=cf2012.img,if=floppy

Can you please confirm that it works?

[eugeneia]

I am on Slackware 14.2, I still get the exact same error using

qemu-system-i386 -drive format=raw,file=cf2012.img,if=floppy

Which QEMU version did you use?

[narke]

On Ubuntu 16.04 LTS the version is 2.5 (on Debian it's older). I will install a Slackware in a virtual machine in the next days and see what happens.

[eugeneia]

I am guessing its really related to QEMU 2.5 vs 2.8, so it might be easier to build 2.8 and try with that: http://wiki.qemu-project.org/download/qemu-2.8.0.tar.bz2

[narke]

You are probably right, I will try it this week-end.

[narke]

It works with qemu up to version 2.5.1.1 but doesn't works from version 2.6 onwards. I will ask on qemu mailing list what changed to make it break.

[narke]

I have filed a bug report, let's see what they have to say.
https://bugs.launchpad.net/qemu/+bug/1671173

[vielmetti]

There is a known issue at multiarch/qemu-user-static#18 with some versions of Java crashing with some 2.8 versions of QEMU. This is fixed with the 3.x QEMU. Can you try with that?

[eugeneia]

I afraid I am still getting this error with QEMU 3.0:

[nix-shell:~/Documents/colorForth]$ qemu-system-i386 --version
QEMU emulator version 3.0.0
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

[nix-shell:~/Documents/colorForth]$ qemu-system-i386 -drive format=raw,file=cf2012.img,if=floppy
Gtk-Message: 13:36:42.978: Failed to load module "pantheon-filechooser-module"
qemu-system-i386: Trying to execute code outside RAM or ROM at 0x8998c426
This usually means one of the following happened:

(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine)
(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end
(3) Your guest kernel has a bug and crashed by jumping off into nowhere

This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine.
If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point.

Execution cannot continue; stopping here.

[vielmetti]

Hm. There is also a QEMU 4.0.0 just out in the past week:

https://www.qemu.org/2019/04/24/qemu-4-0-0/

[narke]

I updated with 2019 version which was released in April thanks to Howerd Oakford.
Just do make; make qemu, and it works.
Tested with qemu v3.1.

[eugeneia]

Thanks that solves it! ❤️

[pupppymu]

Sorry, I am a rookie about OS, when I try to run xv6 source code on qemu 2.11.1, I meet a problem about this, it's about this, I want to know if my problem could be solved as yours, thank you.
my problems are as follows:
qemu-system-i386 -hda obj/kern/kernel.img -serial mon:stdio -gdb tcp::26000 -D qemu.log
WARNING: Image format was not specified for 'obj/kern/kernel.img' and probing guessed raw.
Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions.
qemu-system-i386: Trying to execute code outside RAM or ROM at 0x457e0000
This usually means one of the following happened:

(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine)
(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end
(3) Your guest kernel has a bug and crashed by jumping off into nowhere

This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine.
If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point.

Execution cannot continue; stopping here.

GNUmakefile:157: recipe for target 'qemu' failed
make: *** [qemu] Error 1

[narke]

Hello,
It would be probably better to open a ticket on your github project and we can check it together.
It maybe a problem with a pointer dereference.

[wa1tnr]

colorForth ran okay for 'quite some time' and explored it nicely (have used the floppy diskette based system pretty much what Chuck had published, before).

I 'did something wrong' (possibly related to qemu grabbing mouse and keyboard, and me losing the context, mentally, and a keyboard flub) and Debian (Bullseye) methodically shutdown.

When I cold booted this AMD64 machine the boot volume passed fsck - so it must have shutdown correctly.

$ cat /proc/cpuinfo | sed 5q | tail -1
model name : Intel(R) Core(TM) i5-2400S CPU @ 2.50GHz

$ uname -a
Linux abcdef 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64 GNU/Linux

$ nasm -v
NASM version 2.15.05

$ qemu-system-i386 --help | sed 1q
QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-11+deb11u1)