Add --param flag to bss boot image set to set the name of the kernel parameter the image is passed with

[Wafffle77]

Pull Request Template

Thank you for your contribution! Please ensure the following before submitting:

Checklist

• My code follows the style guidelines of this project
• I have added/updated comments where needed
• I have added tests that prove my fix is effective or my feature works
• I have run make test (or equivalent) locally and all tests pass
• DCO Sign-off: All commits are signed off (git commit -s) with my real name and email
• REUSE Compliance:
  • Each new/modified source file has SPDX copyright and license headers
  • Any non-commentable files include a <filename>.license sidecar
  • All referenced licenses are present in the LICENSES/ directory

Description

Adds a --param/-p flag to the bss boot image set command to allow for using a different kernel parameter name when setting the boot image. The flag defaults to "root" so previous behavior is retained. I'll get documentation added once the behavior is confirmed to address #102 properly.

Example:

ochami bss boot image set -p rd.live.image <image>
ochami bss boot image set --param rd.live.image <image>

Implements #102

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

---

For more info, see Contributing Guidelines.

[synackd]

I ran

ochami bss boot image set --mac <mac> --param rd.live.image <image>

for a <mac> that has an existing root= parameter and it added the rd.live.image= param to the end, but kept the existing root= parameter.

I'm thinking we should ensure the root= is deleted. This should be straightforward with k.DeleteKarg("root").

[synackd]

Being able to modify arbitrary kernel cmdline args would be useful. I've opened #105 to track this. For the scope of this PR, implementing the changes above should be sufficient.

[Wafffle77]

Should we make the boot image parameter deletion use the --param flag as well, instead of hard coding "root"? Otherwise I think we run into the same issue you're describing where the parameter isn't properly removed, but with the name of the old image parameter instead. Would it be better to maybe scrap this PR in favor of #105 for just manipulating arbitrary parameters, since that provides the same functionality in a more flexible manner?