Talk:Kernel parameters

From ArchWiki
Latest comment: 19:05 by Hanabishi in topic Persistence after update

What are the benefits in hijacking the cmdline after booting?

I asked at the Kernel & Hardware forum about Kernel parameters#Hijacking cmdline. So far there was one comment. I think the entry in the article will benefits if:

  1. Usage, other then debugging, will be mentioned or negated.
  2. A short example for how such hijacked cmdline can be used, perhaps for actual debugging.

Perhaps such hijacked cmdline is useful with kexec?

As a side note, the procedure in the article might be used in the wiki as an example to the procedure, and usage, of bind mounting.

Regid (talk) 15:44, 9 January 2019 (UTC)Reply[reply]

Persistence after update

Not sure if this is a vanilla Arch thing or not (I'm using EndeavourOS) but with systemd-boot the parameters are reset to default if an update reinstalls the kernel. I had to edit the /etc/kernel/cmdline file and add my parameters into that instead. These are automatically added to the options in the entries file when the kernel is reinstalled. Mub (talk) 22:07, 29 February 2024 (UTC)Reply[reply]

If your boot entries are autogenerated (by kernel-install script I guess) and you edit them manually afterwards, it is fairly obvious that your edits will be lost on next regeneration.
Yes, using /etc/kernel/cmdline is intended way here.
Hanabishi (talk) 22:45, 29 February 2024 (UTC)Reply[reply]
Thanks. Will be helpful to add this to the wiki page so it is more obvious for us nooby users. Mub (talk) 16:45, 2 March 2024 (UTC)Reply[reply]
Well, "don't edit autogenerated files" is a generic advice, not really belongs here.
Does EndeavourOS actually use kernel-install? If so, I think it could be mentioned there. Although, it is not the default for vanilla Arch, so the article imples that users should be aware of how it works and at least read the man first. Which does describe command line configuration - kernel-install(8) § FILES.
Hanabishi (talk) 19:05, 2 March 2024 (UTC)Reply[reply]