1:32 a.m.
Hi Philipp,
On Wed, Feb 16, 2022 at 02:20:11PM +0100, Philipp Rudo wrote:
Hi Coiby,
[...]
> Thanks for the suggestion. I will eliminate this risk in v2. Btw,
I've
> implemented the unit tests [1] for this function. But it's better to adopt
> a less error-prone way.
Thanks!
> [1]
https://src.fedoraproject.org/fork/coiby/rpms/kexec-tools/c/4f7ccd4245ea0...
Great, it is always good to have more test cases. A few small comments
though:
1) For the test cases where you update the crashkernel= value I think
it would make sense to not only verify that the line contains the
new value but also that it no longer contains the old value.
2) I think you should also add test cases with multiple crashkernel=
entries on the commandline because that is where your regex in v2
will fail (see below).
3) I think you should also add a test case that adds/updates a boolean
entry (like e.g. 'quiet'). That's an other case where your regex
fails (see below).
Thanks for the suggestions! I've added new tests with a slight change.
The tests would not verify the old value is removed but only make sure
the updated entry appear in the end.
Note current implementation doesn't fully support updating boolean as it
couldn't tell if it's a boolean parameter. I will
state in the comment that the user has to explicitly call say
"_update_kernel_cmdline_in_grub_etc_default quiet 1".
> >Furthermore the if-block can be simplified to a single sed call, i.e.
> >
> >sed -i -e "/^GRUB_CMDLINE_LINUX=/ {
> > s/[[:space:]\"]$para=[^[:space:]\"]\+//g;
> > s/\"$/ $para_val\"/
> > }" $GRUB_ETC_DEFAULT
> >
> >i.e. on the line that starts with GRUB_CMDLINE_LINUX=, remove all occurrences of
$para,
> >then add a new $para_val to the end of the list.
>
> I notice there could be three issues with the above code,
> 1. you mean -E instead of "-e", right?
No, I actually meant -e. I admit it is not strictly necessary but more
a habit of mine to always add it.
You can also add -E if you like and use extended regex (and use +
instead of \+). But in my opinion that doesn't make much of a difference
here and is more a matter of taste.
Thanks for the clarification!
> 2. If the parameter is right in the beginning i.e.
> GRUB_CMDLINE_LINUX="crashkerlel=xxM ...", the first '"'
would be
> removed
Right... I totally missed that...
> 3. the parameter is always moved to the end. Of course, this is not a
> real problem as there should be no functional difference.
Yes, for the command I gave above that doesn't make a difference. But
can make one as the command line parser in the kernel always takes the
last value it finds. So when you don't remove the entry or there are
multiple identical entries you have to make sure that the new/updated
one is the last on the command line. Otherwise the kernel won't pick
the new value.
Thanks for bringing this pitfall to my attention!
> In v2, I will use the follow code,
>
> # If the parameter already exists, replace it with new value.
> # Otherwise insert it to the end
> sed -i -E "/^GRUB_CMDLINE_LINUX=/ {
>
s/([[:space:]\"])crashkernel=[^[:space:]\"]*(.*)$/\1${_para_val}\2/;
^^^^^^^^^^^
$para ?
Oh, thanks for catching this issue!
> # t: jump to a label only if a s/// command has succeeded.
> # Since there is no label, it would jump to the end i.e.
> # skip the last command if the parameter already exist
> t;
> s/\"$/ ${_para_val}\"/
> }" "$GRUB_ETC_DEFAULT"
As said above I see two problems with this regex:
1) It will fail when there are multiple entries as it will only update
the first match. E.g. consider the line
GRUB_CMDLINE_LINUX="foo=1 foo=3"
after running '_update_kernel_cmdline_in_grub_etc_default foo xxx' it will
become
GRUB_CMDLINE_LINUX="foo=xxx foo=3"
which is not what you want.
2) For boolean values it doesn't remove already existing entries so you
can end up with multiple once. E.g. consider the line
GRUB_CMDLINE_LINUX="quiet"
after running '_update_kernel_cmdline_in_grub_etc_default quiet' it will
become
GRUB_CMDLINE_LINUX="quiet quiet"
It's not a real problem but while we are on it we can make it right ;)
So, how about this command
# Update the command line /etc/default/grub, i.e.
# on the lines that start with 'GRUB_CMDLINE_LINUX=' do
# 1) remove all occurences of $para=$val
# 2) remove all occurences of $para
# 3) remove duplicate spaces left over by 1) or 2)
# 4) remove space at the beginning of the string left over by 1) or 2)
# 5) remove space at the end of the string left over by 1) or 2)
# 6) add the new entry for $para at the end of the command line
sed -i -e "/^GRUB_CMDLINE_LINUX=/ {
s/\<$_para=[^[:space:]\"]*\>//g;
s/\<$_para\>//g;
s/[[:space:]]\{2,\}/ /g;
s/\(\"\+\)[[:space:]]\{1,\}/\1/g;
s/[[:space:]]\(\"\+\)\{1,\}/\1/g;
s/\"$/ $_para_val\"/
}" "$GRUB_ETC_DEFAULT"
Thanks for sharing this regex! I notice two issues,
1) as catched by the unit tests, this regex fails to address
the case "ckcrashkernel=220M" i.e. when the given parameter is suffix
of another parameter
2) this regex would delete all values for a parameter that allows
multiples values specified, e.g. efivar_ssdt
efivar_ssdt= [EFI; X86] Name of an EFI variable that contains an SSDT
that is to be dynamically loaded by Linux. If there are
multiple variables with the same name but with different
vendor GUIDs, all of them will be loaded. See
Documentation/acpi/ssdt-overlays.txt for details.
After playing with grubby which allows "crashkernel=20M crashkernel=30M
crashernel=SPECIFIED_VALUE", I would prefer a simpler solution,
# Update the command line /etc/default/grub, i.e.
# on the line that starts with 'GRUB_CMDLINE_LINUX=',
# 1) if given parameter appear in the end, replace it with new entry
# 2) otherwise, insert the entry in the end
sed -i -E "/^GRUB_CMDLINE_LINUX=/ {
s/([[:space:]\"])${_para}=[^[:space:]\"]*[[:space:]]*\"$/\1${_para_val}\"/;
# t: jump to a label only if a s/// command has succeeded.
# Since there is no label, it would jump to the end i.e.
# skip the last command if the parameter already exist
t;
s/\"$/ ${_para_val}\"/
}" "$GRUB_ETC_DEFAULT"
Thanks
Philipp
> >
> >With that you need to duplicate parts of the regex when you try read
> >values from the command line. But all in all I think that will be
> >easier to maintain compared to your approach.
> >
> >Thanks
> >Philipp
> >
>
--
Best regards,
Coiby