QEMU cannot boot locally built Linux kernel anymore

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












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










share|improve this question



















  • 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?
    – Andy Dalton
    Aug 8 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)
    – rgouicem
    Aug 8 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?
    – ErikF
    Aug 8 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.
    – rgouicem
    Aug 9 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?
    – ErikF
    Aug 9 at 9:57














up vote
1
down vote

favorite












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










share|improve this question



















  • 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?
    – Andy Dalton
    Aug 8 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)
    – rgouicem
    Aug 8 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?
    – ErikF
    Aug 8 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.
    – rgouicem
    Aug 9 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?
    – ErikF
    Aug 9 at 9:57












up vote
1
down vote

favorite









up vote
1
down vote

favorite











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










share|improve this question















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







arch-linux linux-kernel qemu






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Aug 9 at 12:18

























asked Aug 8 at 15:48









rgouicem

83




83







  • 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?
    – Andy Dalton
    Aug 8 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)
    – rgouicem
    Aug 8 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?
    – ErikF
    Aug 8 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.
    – rgouicem
    Aug 9 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?
    – ErikF
    Aug 9 at 9:57












  • 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?
    – Andy Dalton
    Aug 8 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)
    – rgouicem
    Aug 8 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?
    – ErikF
    Aug 8 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.
    – rgouicem
    Aug 9 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?
    – ErikF
    Aug 9 at 9:57







1




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?
– Andy Dalton
Aug 8 at 16:00




Are you rebuilding the same sources after switching toolchains? If so, did you do a make clean before the rebuild with the new toolchain?
– Andy Dalton
Aug 8 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)
– rgouicem
Aug 8 at 16:05




@AndyDalton: yes. But the problem was there even when only using my local toolchain (I built nothing, everything comes from the archlinux package repositories)
– rgouicem
Aug 8 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?
– ErikF
Aug 8 at 18:12




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?
– ErikF
Aug 8 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.
– rgouicem
Aug 9 at 9:30




@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.
– rgouicem
Aug 9 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?
– ErikF
Aug 9 at 9:57




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?
– ErikF
Aug 9 at 9:57










1 Answer
1






active

oldest

votes

















up vote
0
down vote



accepted










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.






share|improve this answer






















    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













     

    draft saved


    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f461314%2fqemu-cannot-boot-locally-built-linux-kernel-anymore%23new-answer', 'question_page');

    );

    Post as a guest






























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    0
    down vote



    accepted










    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.






    share|improve this answer


























      up vote
      0
      down vote



      accepted










      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.






      share|improve this answer
























        up vote
        0
        down vote



        accepted







        up vote
        0
        down vote



        accepted






        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.






        share|improve this answer














        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.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited yesterday









        Goro

        2,16941848




        2,16941848










        answered yesterday









        Martin Wilck

        463




        463



























             

            draft saved


            draft discarded















































             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f461314%2fqemu-cannot-boot-locally-built-linux-kernel-anymore%23new-answer', 'question_page');

            );

            Post as a guest













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?