Boot all yes config kernel with QEMU
Hi,
I'd like to build and boot an allyesconfig kernel with QEMU. Building is no problem but when I try to boot it I get problems because the host system does not support features requested by the VM.
How does one go about testing an allyesconfig kernel?
Back story: I'm trying to set up some CI infrastructure to run scripts/leaking_addresses.pl against the various stable kernels.
thanks,
Tobin.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20181023/0d83161e/attachment.sig>
Quoted 5 lines · Tobin C. Harding
I'd like to build and boot an allyesconfig kernel with QEMU. Building is no problem but when I try to boot it I get problems because the host system does not support features requested by the VM.
How does one go about testing an allyesconfig kernel?
As you have noticed, there's no guarantee that a allyesconfig kernel will boot in a VM because the VM doesn't support something. Note that you're going to have the exact same issues booting on real hardware - you'll discover that there's configs that won't boot on real hardware either - and even if it boots, you'll probably not have the I/O devices to test even a third of the drivers unless you have a really well stocked test lab.
But then, all(yes|mod|no)config aren't intended for actual booting and testing - they're pretty much build testing all the options in one build.
Basically, one of two things happen after building an all-something-config:
1) The build completes and you get on with your life
2) The build fails, and you get to send an email telling the maintainer that
their driver for the Frobnozz 1300 Widget won't build in =y in kernel 4.21-rc2,
or whatever your build died on.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20181023/c42f2940/attachment.sig>
Quoted 18 lines · valdis.kletnieks at vt.edu
Quoted 5 lines · Tobin C. Harding
I'd like to build and boot an allyesconfig kernel with QEMU. Building is no problem but when I try to boot it I get problems because the host system does not support features requested by the VM.
How does one go about testing an allyesconfig kernel?
As you have noticed, there's no guarantee that a allyesconfig kernel will boot in a VM because the VM doesn't support something. Note that you're going to have the exact same issues booting on real hardware - you'll discover that there's configs that won't boot on real hardware either - and even if it boots, you'll probably not have the I/O devices to test even a third of the drivers unless you have a really well stocked test lab.
But then, all(yes|mod|no)config aren't intended for actual booting and testing - they're pretty much build testing all the options in one build.
Quoted 7 lines
Basically, one of two things happen after building an all-something-config:
1) The build completes and you get on with your life
2) The build fails, and you get to send an email telling the maintainer that their driver for the Frobnozz 1300 Widget won't build in =y in kernel 4.21-rc2, or whatever your build died on.
I love this answer :) thanks Valdis. If you are taking a walk and feel like pondering something; any ideas how I could get the most files possible to show up in /proc and /sys?
thanks,
Tobin.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20181023/d8d8f8a4/attachment.sig>
Quoted 23 lines · Tobin C. Harding
Quoted 22 lines · valdis.kletnieks at vt.edu
Quoted 5 lines · Tobin C. Harding
I'd like to build and boot an allyesconfig kernel with QEMU. Building is no problem but when I try to boot it I get problems because the host system does not support features requested by the VM.
How does one go about testing an allyesconfig kernel?
As you have noticed, there's no guarantee that a allyesconfig kernel will boot in a VM because the VM doesn't support something. Note that you're going to have the exact same issues booting on real hardware - you'll discover that there's configs that won't boot on real hardware either - and even if it boots, you'll probably not have the I/O devices to test even a third of the drivers unless you have a really well stocked test lab.
But then, all(yes|mod|no)config aren't intended for actual booting and testing - they're pretty much build testing all the options in one build.
Basically, one of two things happen after building an all-something-config:
1) The build completes and you get on with your life
Quoted 7 lines
Quoted 3 lines
2) The build fails, and you get to send an email telling the maintainer that their driver for the Frobnozz 1300 Widget won't build in =y in kernel 4.21-rc2, or whatever your build died on.
I love this answer :) thanks Valdis. If you are taking a walk and feel like pondering something; any ideas how I could get the most files possible to show up in /proc and /sys?
It all depends on your hardware/system. /sys reflects the devices in the system at the time, physical and virtual.
If you create 20000 virtual scsi devices, you will have 20000 devices in sysfs along with all of their assorted files and directories. People have used virtual devices to stress-test sysfs since the very beginning.
Hope this helps,
greg k-h