image.bbclass: Disable USE_DEPMOD for the dummy kernel
PATCH 1/1 image.bbclass: Disable USE_DEPMOD for the dummy kernel
The image bbclass will try to find the kernel-abiversion file which is not part of the linux-dummy kernel since there is no actual kernel. In this case using depmod also does not make sense since there should not be any kernel module built.
[YOCTO #7884]
--- meta/classes/image.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
meta/classes/image.bbclass +1 -1
@@ -66,7 +66,7 @@ PACKAGE_INSTALL_ATTEMPTONLY ?= "${FEATURE_INSTALL_OPTIONAL}" EXCLUDE_FROM_WORLD = "1" USE_DEVFS ?= "1" -USE_DEPMOD ?= "1" +USE_DEPMOD ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", "linux-dummy", "0", "1", d)}' PID = "${@os.getpid()}"
Signature · 1 line
2.1.0
Quoted 16 lines · Saul Wold
The image bbclass will try to find the kernel-abiversion file which is not part of the linux-dummy kernel since there is no actual kernel. In this case using depmod also does not make sense since there should not be any kernel module built.
[YOCTO #7884]
Signed-off-by Saul Wold <[email protected]>--- meta/classes/image.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)meta/classes/image.bbclass +0
-0
meta/classes/image.bbclass PACKAGE_INSTALL_ATTEMPTONLY ?= "${FEATURE_INSTALL_OPTIONAL}" · line 70
Quoted 6 lines
meta/classes/image.bbclass +1
-1@@ -66,7 +66,7 @@ PACKAGE_INSTALL_ATTEMPTONLY ?= "${FEATURE_INSTALL_OPTIONAL}" EXCLUDE_FROM_WORLD = "1" USE_DEVFS ?= "1" -USE_DEPMOD ?= "1" +USE_DEPMOD ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", "linux-dummy", "0", "1", d)}'
I'm not convinced this is the right way to solve this. How about we teach the code in rootfs.py not to generate a modules.dep file if there are no kernel modules to generate dependency information for?
Cheers,
Richard
Quoted 19 lines · Richard Purdie
Quoted 18 lines · Saul Wold
The image bbclass will try to find the kernel-abiversion file which is not part of the linux-dummy kernel since there is no actual kernel. In this case using depmod also does not make sense since there should not be any kernel module built.
[YOCTO #7884]
Signed-off-by Saul Wold <[email protected]>--- meta/classes/image.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)meta/classes/image.bbclass +0
-0@@ -66,7 +66,7 @@ PACKAGE_INSTALL_ATTEMPTONLY ?= "${FEATURE_INSTALL_OPTIONAL}" EXCLUDE_FROM_WORLD = "1"
Quoted 9 lines
meta/classes/image.bbclass PACKAGE_INSTALL_ATTEMPTONLY ?= "${FEATURE_INSTALL_OPTIONAL}" · line 70
Quoted 4 lines
meta/classes/image.bbclass +1
-1USE_DEVFS ?= "1" -USE_DEPMOD ?= "1" +USE_DEPMOD ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", "linux-dummy", "0", "1", d)}'I'm not convinced this is the right way to solve this. How about we teach the code in
rootfs.pynot to generate a modules.dep file if there are no kernel modules to generate dependency information for?
I guess we could check for /lib/modules, but I think checking for virtual/kernel is cleaner and safer since we know we don't want to run this for linux-dummy, but if some random recipe happens to create /lib/modules it will break.
Unless you has some other check in mind to verify no modules are created
I also thought about a change to linux-dummy to place an kernel-abiversion, but that had other dangers.
Sau!
Quoted 4 lines
Cheers,
Richard
Quoted 29 lines · Saul Wold
Quoted 19 lines · Richard Purdie
Quoted 18 lines · Saul Wold
The image bbclass will try to find the kernel-abiversion file which is not part of the linux-dummy kernel since there is no actual kernel. In this case using depmod also does not make sense since there should not be any kernel module built.
[YOCTO #7884]
Signed-off-by Saul Wold <[email protected]>--- meta/classes/image.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)meta/classes/image.bbclass +0
-0@@ -66,7 +66,7 @@ PACKAGE_INSTALL_ATTEMPTONLY ?= "${FEATURE_INSTALL_OPTIONAL}" EXCLUDE_FROM_WORLD = "1"Quoted 9 lines
meta/classes/image.bbclass PACKAGE_INSTALL_ATTEMPTONLY ?= "${FEATURE_INSTALL_OPTIONAL}" · line 70
Quoted 4 lines
meta/classes/image.bbclass +1
-1USE_DEVFS ?= "1" -USE_DEPMOD ?= "1" +USE_DEPMOD ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", "linux-dummy", "0", "1", d)}'I'm not convinced this is the right way to solve this. How about we teach the code in
rootfs.pynot to generate a modules.dep file if there are no kernel modules to generate dependency information for?
Quoted 6 lines
I guess we could check for
/lib/modules, but I think checking for virtual/kernel is cleaner and safer since we know we don't want to run this for linux-dummy, but if some random recipe happens to create/lib/modulesit will break.Unless you has some other check in mind to verify no modules are created
Something like "find -name *.ko" on /lib/modules was what I was wondering about. Extrapolating, perhaps this code should iterate any version directories here in case multiple sets of modules for different kernel versions were installed? That way it wouldn't need to know about the kernel-abiversion file?
Quoted 2 lines
I also thought about a change to linux-dummy to place an kernel-abiversion, but that had other dangers.
Right. Unfortunately this file is used to populate KERNEL_VERSION elsewhere and we may also have problems in those places with linux-dummy too :/
Cheers,
Richard
Quoted 23 lines · Saul Wold
The image bbclass will try to find the kernel-abiversion file which is not part of the linux-dummy kernel since there is no actual kernel. In this case using depmod also does not make sense since there should not be any kernel module built.
[YOCTO #7884]
Signed-off-by Saul Wold <[email protected]>---
meta/classes/image.bbclass | 2 +-1 file changed, 1 insertion(+), 1 deletion(-)meta/classes/image.bbclass +0
-0@@ -66,7 +66,7 @@ PACKAGE_INSTALL_ATTEMPTONLY ?= "${FEATURE_INSTALL_OPTIONAL}"
EXCLUDE_FROM_WORLD= "1"
USE_DEVFS?= "1"
meta/classes/image.bbclass
Quoted 2 lines
meta/classes/image.bbclass +1
-1-USE_DEPMOD ?= "1" +USE_DEPMOD ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", "linux-dummy", "0", "1", d)}’
this is an abstraction, it should work on more general metadata then just OE-Core, using hardcoded recipe names doesn't sound right here. Richard’s suggestion on finding the .ko’s is generic, which should be the better and generic solution.
Quoted 10 lines
PID = "${@os.getpid()}"
--
2.1.0--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core