Closed msherif1234 closed 1 year ago
Neither /proc/config.gz
and /boot/config-$(uname -r)
are available on CoreOS. It seems to be in /lib/modules/$(uname -r)/config
.
Additionally evaluate adding an option to give a path to the kernel config.
Neither
/proc/config.gz
and/boot/config-$(uname -r)
are available on CoreOS. It seems to be in/lib/modules/$(uname -r)/config
.Additionally evaluate adding an option to give a path to the kernel config.
Maybe an ENV var that we can set in the container?
Neither
/proc/config.gz
and/boot/config-$(uname -r)
are available on CoreOS. It seems to be in/lib/modules/$(uname -r)/config
. Additionally evaluate adding an option to give a path to the kernel config.Maybe an ENV var that we can set in the container?
Could be too.
I quickly looked into the above and while we can easily fix Retis to check for an extra path, it seems to me libbpf is only looking in those two paths (hard coded). There might be some ways but I didn't see anything that would be acceptable for an easy fix, and the potential solutions all looked a bit complex and would need some thinking. @vlrpl does this ring a bell (asking as you played a bit more with libbpf IIRC)?
In the meantime I would suggest to use the Retis container image with -v /lib/modules/$(uname -r)/config:/boot/config-$(uname -r):ro
instead of -v /boot:/boot:ro
for CoreOS.
Neither
/proc/config.gz
and/boot/config-$(uname -r)
are available on CoreOS. It seems to be in/lib/modules/$(uname -r)/config
. Additionally evaluate adding an option to give a path to the kernel config.Maybe an ENV var that we can set in the container?
Could be too.
I quickly looked into the above and while we can easily fix Retis to check for an extra path, it seems to me libbpf is only looking in those two paths (hard coded). There might be some ways but I didn't see anything that would be acceptable for an easy fix, and the potential solutions all looked a bit complex and would need some thinking. @vlrpl does this ring a bell (asking as you played a bit more with libbpf IIRC)?
libbpf side, it seems to me the same.
I was hoping that bpf_object_open_opts { kconfig, ..default() }
could have been a good candidate (passing down the mem), but looking at the code, unless I'm missing something, that should not work. It is just strictly intended to augment the existing config.
In the meantime I would suggest to use the Retis container image with
-v /lib/modules/$(uname -r)/config:/boot/config-$(uname -r):ro
instead of-v /boot:/boot:ro
for CoreOS.
this is confirmed to work
kernel
config
dump the boot folder