2

Since yesterday, I can no longer launch qemu with an external kernel compiled on my laptop (running Arch Linux).

If I compile a vanilla Linux kernel (version 4.13, from Linus Torvalds' github repo), then try to boot qemu this way:

qemu-system-x86_64 --enable-kvm -boot c -kernel arch/x86/boot/bzImage

This starts the display, showing this SeaBIOS output refreshing every 2-3 seconds:

   Booting from ROM...
   Probing EDD (edd=off to disable)... ok
   early console in extract_kernel
   input_data: 0x0000000002c773b4
   input_len: 0x000000000090c470
   output: 0x0000000001000000
   output_len: 0x000000000173a968
   kernel_total_size: 0x00000000025a7000

   Decompressing Linux... Parsing ELF...

If I add these flags to qemu to enable SeaBIOS debugging output:

-chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios

I get this output that keeps repeating: https://pastebin.com/mZKeM6r5

Funny thing, if I compile the same kernel, with the same configuration file on another machine (running Debian) and copy the bzImage to my machine, it boots just fine. So I guess something happened in my toolchain. There was an update of gcc recently, but going back to the previous version of the package (the one I had when there was no problem) does not solve my problem.

As a temporary workaround, I thought I could compile on the Debian machine using distcc to avoid copying files back and forth, but the problem still occurs, so I guess the problem is in the final steps of the compilation process (from linkage to the end, since these happen on my laptop).

Additional info:

  • gcc version on my laptop (ArchLinux): 8.2.0 (pkg version = 8.2.0-2)
  • gcc version on my Debian machine: 6.3.0 (pkg version = 4:6.3.0-4)

Edit: completed SeaBIOS output

Improve this question
6
  • 1
    Are you rebuilding the same sources after switching toolchains? If so, did you do a make clean before the rebuild with the new toolchain? Commented Aug 8, 2018 at 16:00
  • @AndyDalton: yes. But the problem was there even when only using my local toolchain (I built nothing, everything comes from the archlinux package repositories) Commented Aug 8, 2018 at 16:05
  • The output from pastebin shows that the VM is trying to resume from the S3 power state. What happens if you force a full shutdown of the VM? Commented Aug 8, 2018 at 18:12
  • @ErikF: If I try to force a shutdown, it keeps rebooting, but I guess it never catches the shutdown signal since it's already rebooting. Also, the source code you linked to is an old version of seabios. I checked the source of the version my qemu uses (the same as here), and it looks like handle_resume() is called with a status value of 0 (as in the output), which calls handle_resume32(), then tryReboot() and qemu reboots. Commented Aug 9, 2018 at 9:30
  • It sounds like the issue is likely with an auto-generated setting based on compiler version/architecture then. In General setup, what do you have for the compiler optimization level? Did you enable any GCC plugins? What is Stack protector buffer overflow detection set to? Also, in Processor type and features, what is the selected processor family? Commented Aug 9, 2018 at 9:57

1 Answer 1

Reset to default
3

I had the same problem. In my case, it was caused by the binutils update to 2.31. Judging from the date you posted your question, it's not unlikely that you had just installed the arch linux binutils update to 2.31 from August 2nd, which matches nicely.

You need this commit for kernels earlier than 4.16.

binutils 2.31 has changed the defaults of the linker (ld) such that the default for max-page-size was decreased from 2MiB to 4kiB. This change breaks the x86_64 kernel, unless said commit is applied.

Improve this answer
1
  • This answer had a low score, but upvoting and commenting as this worked for me. Thank you very much. Commented May 24, 2021 at 11:37

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.