QEMU cannot boot locally built Linux kernel anymore
Clash 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
arch-linux linux-kernel qemu
 |Â
show 1 more comment
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
arch-linux linux-kernel qemu
1
Are you rebuilding the same sources after switching toolchains? If so, did you do amake 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 myqemu
uses (the same as here), and it looks likehandle_resume()
is called with a status value of 0 (as in the output), which callshandle_resume32()
, thentryReboot()
andqemu
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. InGeneral setup
, what do you have for the compiler optimization level? Did you enable any GCC plugins? What isStack protector buffer overflow detection
set to? Also, inProcessor type and features
, what is the selected processor family?
â ErikF
Aug 9 at 9:57
 |Â
show 1 more comment
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
arch-linux linux-kernel qemu
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
arch-linux linux-kernel qemu
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 amake 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 myqemu
uses (the same as here), and it looks likehandle_resume()
is called with a status value of 0 (as in the output), which callshandle_resume32()
, thentryReboot()
andqemu
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. InGeneral setup
, what do you have for the compiler optimization level? Did you enable any GCC plugins? What isStack protector buffer overflow detection
set to? Also, inProcessor type and features
, what is the selected processor family?
â ErikF
Aug 9 at 9:57
 |Â
show 1 more comment
1
Are you rebuilding the same sources after switching toolchains? If so, did you do amake 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 myqemu
uses (the same as here), and it looks likehandle_resume()
is called with a status value of 0 (as in the output), which callshandle_resume32()
, thentryReboot()
andqemu
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. InGeneral setup
, what do you have for the compiler optimization level? Did you enable any GCC plugins? What isStack protector buffer overflow detection
set to? Also, inProcessor 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
 |Â
show 1 more comment
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.
add a comment |Â
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.
add a comment |Â
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.
add a comment |Â
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.
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.
edited yesterday
Goro
2,16941848
2,16941848
answered yesterday
Martin Wilck
463
463
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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 likehandle_resume()
is called with a status value of 0 (as in the output), which callshandle_resume32()
, thentryReboot()
andqemu
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 isStack protector buffer overflow detection
set to? Also, inProcessor type and features
, what is the selected processor family?â ErikF
Aug 9 at 9:57