OSDev.org

I ran Qemu with OVMF, a HD image with 20GB and a Linux ISO. I tried three times now (two times with Xubuntu, one time with Manjaro XFCE).

And always the installation from virtual CD onto virtual HD aborts silently and suddenly (after a long time (like an hour or more) of installating files). I get the message "<Process ID> Killed" and no more info.

The qemu command is: What can I do to make this work?

I use Xubuntu 20.04 LTS with qemu-system-x86_64 4.2.1 (Debian 1:4.2-3ubuntu6.11) on x86_64 PC with Legacy BIOS.

Greetings
Peter

I'd first check the obvious issues that can cause any resource intensive app to suddenly get killed: did the host run out of memory and engage OOM killer? or was the disk img sparse and the host ran out of space? etc.

If no obvious issues from these checks. I'd run qemu itself under GDB. Yes it will run fine, even with KVM enabled (which you probably want to enable when running a "real" OS), you can even see that it has launched VCPU number of threads and all of them should be within kvm_cpu_exec () most of the time.

Only extra setup to run qemu under GDB is to ignore (noprint) SIGUSR1 as that is used during qemu's normal operation and happens frequent enough that you don't want to getting notified about it.

Then, sit back, relax, and see what gdb has to say about "aborts silently"

Thanks!

[OK first dealing with the "obvious reasons": ]
I thought it couldn't be "normal" out of memory because then the error message would have said so. That was probably naive. How can I avoid out-of-memory? I already have a swap partition on my host OS. Maybe I should reduce the VM memory to 3GB to avoid that the VM eats up all host system's memory? What else can help getting the installation process done without crashing?

Yes, I'm trying to install a "real" OS (as I mentioned: Xubuntu and Manjaro). Are there some HD images I can download instead of installing it from CD/DVD?

Using "-accel kvm" crashes with a segmentation fault.

Greetings
Peter

"qemu is kil"

"no"

error message would have said so

OOM killer's action is logged in the normal kernel log. It won't be in a position to print anywhere else when it needs to do its work.

How can I avoid out-of-memory?

If OOM is the issue, 2 easy soltuions:
1. Use less memory.
2. Buy more memory.

instead of installing

LiveCD doesn't work for you?


To be honest I've never installed Ubuntu in a VM so if you can't get GDB to watch it for you I'm not too sure what else to try either. But Ubuntu has an active community at https://askubuntu.com/ and I'm sure they'll be able to help with any issue installing it in a mainstream VMM like qemu.

xeyes wrote:OOM killer's action is logged in the normal kernel log.

Didn't know that. Thanks.

xeyes wrote:If OOM is the issue, 2 easy solutions:
1. Use less memory.
2. Buy more memory.

1. Ok, but how to use less memory? I tried it already, of course. I'm running the minimum programs. Just X and jwm and qemu and a X-terminal. (And all the stuff Linux insists on running in the background.)
2. I have 4GB, the maximum for my PC.

xeyes wrote:LiveCD doesn't work for you?

Good idea. I was so fixed on installing on HD that I didn't figure I could use Live CD!! Thanks. THis is probably a working solution, so I mark this thread as solved.

Greetings
Peter

PeterX wrote:qemu-system-x86_64 -pflash OVMF.fd -hda hd.img -net none -m 4g -cdrom linux.iso

PeterX wrote:2. I have 4GB, the maximum for my PC.

I think I see the problem.

klange wrote:

PeterX wrote:qemu-system-x86_64 -pflash OVMF.fd -hda hd.img -net none -m 4g -cdrom linux.iso

PeterX wrote:2. I have 4GB, the maximum for my PC.

I think I see the problem.

That's why I earlier already asked to reduce to 3GB ("-m 3g"). So that's probably a reason, ok, good to know.

My main mistake was probably that I assumed I would get a nice error message if out-of-memory was the reason. Now I know better.

klange wrote:

PeterX wrote:qemu-system-x86_64 -pflash OVMF.fd -hda hd.img -net none -m 4g -cdrom linux.iso

PeterX wrote:2. I have 4GB, the maximum for my PC.

I think I see the problem.

Me too. -m 3g is a good start, but I just want to add that virtualization typically uses much more memory than it gives to the guest. (I'm not sure why.) Years ago, I found VMware using more than 4 times the RAM it gave to the guest. Qemu was much better, but still wanted more memory than I expected. I'd go down to -m 2g or even 1g on a 4GB host. Or, you know, install a Real Operating System as the guest; not the giant puffballs they make these days.

eekee wrote: -m 3g is a good start, but I just want to add that virtualization typically uses much more memory than it gives to the guest. (I'm not sure why.) Years ago, I found VMware using more than 4 times the RAM it gave to the guest. Qemu was much better, but still wanted more memory than I expected. I'd go down to -m 2g or even 1g on a 4GB host.

Thanks for the tip!

eekee wrote:Or, you know, install a Real Operating System as the guest; not the giant puffballs they make these days.

If you mean FreeDOS: No, that's too limited imho. But I agree on the giant puffballs comment

Greetings
Peter

Shouldn't Linux just start swapping pages instead of killing QEMU? Performance would be horrible, but that makes more sense to me.

nexos wrote:Shouldn't Linux just start swapping pages instead of killing QEMU? Performance would be horrible, but that makes more sense to me.

I was kind of relying on that. Especially as I have a swap partition. But I guess in extreme memory situation Linux pulls the emergency brake. That's already better than old Linux which crashed in such situations

Greetings
Peter

I've seen Linux in some extremely heavy swap situations. I don't think I ever saw the kernel panic over memory, but there was something nearly as bad. When the OOM killer was first introduced it would just kill the biggest memory user, presumably on the assumption that it was a runaway process. However, on desktop systems of that era, the biggest memory user was invariably the X server. Killing the X server was nearly as bad as bringing down the entire system. I just turned off the OOM killer.

Detail recalled: With no OOM killer and very heavy swap, processes are somewhat more likely to crash. I'm not entirely sure why.

nexos wrote:Shouldn't Linux just start swapping pages instead of killing QEMU? Performance would be horrible, but that makes more sense to me.

The swap space is added to physically available memory for the purpose of OOM calculation. But if both RAM and swap space have run dry, the OOM killer will run. And the OOM killer will kill the biggest offender first, and on a 4GB system that will be the QEMU instance that is consuming at least 3GB.