On Fri, 10 Dec 2021 11:31:32 +0800
Coiby Xu <coxu(a)redhat.com> wrote:
Hi Philipp,
On Thu, Dec 09, 2021 at 06:57:28PM +0100, Philipp Rudo wrote:
>Hi Coiby,
>
>On Wed, 8 Dec 2021 10:25:33 +0800
>Coiby Xu <coxu(a)redhat.com> wrote:
>
>> grubby --info=kernel-path or --add-kernel=kernel-path accepts a kernel
>> path (e.g. /boot/vmlinuz-5.14.14-200.fc34.x86_64) instead of kernel release
>> (e.g 5.14.14-200.fc34.x86_64). So we need to know the kernel path given
>> a kernel release. Although for Fedora/RHEL, the kernel path is
>> "/boot/vmlinuz-<KERNEL_RELEASE>", a path kernel could also be
>> /boot/<machine-id>/<KERNEL_RELEASE>/vmlinuz. So the most reliable
way to
>> find the kernel path given a kernel release is to use "grubby
--info".
>>
>> Note these helper functions doesn't support CoreOS/Atomic/Silverblue
>> since grubby isn't used by them.
>>
>> Signed-off-by: Coiby Xu <coxu(a)redhat.com>
>> ---
>> kdumpctl | 30 ++++++++++++++++++++++++++++++
>> 1 file changed, 30 insertions(+)
>>
>> diff --git a/kdumpctl b/kdumpctl
>> index f42a8c6..0b8dc0f 100755
>> --- a/kdumpctl
>> +++ b/kdumpctl
>> @@ -1351,6 +1351,36 @@ get_dump_mode_by_kernel()
>> fi
>> }
>>
>> +_filter_grubby_kernel_str()
>> +{
>> + local _grubby_kernel_str=$1 _kernel_path
>> + _kernel_path=${_grubby_kernel_str#kernel=}
>> + _kernel_path=${_kernel_path#\"}
>> + _kernel_path=${_kernel_path%\"}
>> + echo -n "$_kernel_path"
>> +}
>> +
>> +_find_kernel_path_by_release()
>> +{
>> + local _release="$1" _grubby_kernel_str _kernel_path
>> + _grubby_kernel_str=$(grubby --info ALL | grep
"^kernel=.*$_release")
>> + _kernel_path=$(_filter_grubby_kernel_str "$_grubby_kernel_str")
>> + [[ -e "$_kernel_path" ]] || derror "kernel $_release
doesn't exist" && return 1
>> + echo -n "$_kernel_path"
>> +}
>> +
>> +_get_current_running_kernel_path()
>> +{
>> + local _release _path
>> +
>> + _release=$(uname -r)
>> + if _path=$(_find_kernel_path_by_release "$_release"); then
>> + echo -n "$_path"
>> + else
>> + return 1
>> + fi
>> +}
>
>I don't see a benefit in having _get_current_kernel_path.
>
>_find_kernel_path_by_release $(uname -r)
>
>does exactly the same but is in my opinion much easier to understand.
Currently, there are two places that this function is needed. And there
is a special case that's waiting to be dealt with. That's setting the
kernel crashkernel when osbuild is building an system image e.g. .qcow2
and the package is installed inside a sandbox. In this case, current
running kernel doesn't exist. So that's why I abstract it to a function
here.
Sure, when this function helpts with the implementation of the CoreOS
support it totally makes sense to keep it.
Thanks for the explanation
Philipp
[1]
https://bugzilla.redhat.com/show_bug.cgi?id=2024976
>
>Thanks
>Philipp
>
>> reset_crashkernel()
>> {
>> local kernel=$1 entry crashkernel_default
>