This PR adds split_lock_detect to the preserved_arguments list in anaconda.conf.
Currently, on recent kernels, if an x86 split lock is detected, it can cause the kernel to crash (#AC: crashing the ...
Well, in this case, the actual change is pointless, but also relatively harmless. If the user puts “split_lock_detect=” during install, then it just carries it forward into the installed environment.
It’s frankly a bit weird that they assume a kernel argument during install would not carry over, except in select circumstances. I get it for parameters like “here’s a kickstart file” or “here’s the net configuration to boot with”, which would be filtered out via a blacklist, but they have a whitelist and assume most parameters should be ignored.
But anyway, I can see someone looking at the code change, not recognizing why someone would want that argument, but shrug and say “sure, simple enough, it won’t impact the vast majority of people and those that bother for whatever reason will just see it carried forward”.
But clearly it wasn’t something anyone wanted as it was later reverted, and not kept in because it was supposedly harmless.
I get what you’re saying though. I’m just glad someone in those comments actually analyzed the situation instead of putting their trust in the charismatic LLM. Those people still exist!
Funny part is that if it just stated “sometimes the user needs this argument, and if they need this argument for install they will need it to boot”, they might have shrugged and let it slide. In trying to overexplain, it betrayed that there was no actual understanding behind it.
Well, in this case, the actual change is pointless, but also relatively harmless. If the user puts “split_lock_detect=” during install, then it just carries it forward into the installed environment.
It’s frankly a bit weird that they assume a kernel argument during install would not carry over, except in select circumstances. I get it for parameters like “here’s a kickstart file” or “here’s the net configuration to boot with”, which would be filtered out via a blacklist, but they have a whitelist and assume most parameters should be ignored.
But anyway, I can see someone looking at the code change, not recognizing why someone would want that argument, but shrug and say “sure, simple enough, it won’t impact the vast majority of people and those that bother for whatever reason will just see it carried forward”.
But clearly it wasn’t something anyone wanted as it was later reverted, and not kept in because it was supposedly harmless.
I get what you’re saying though. I’m just glad someone in those comments actually analyzed the situation instead of putting their trust in the charismatic LLM. Those people still exist!
Funny part is that if it just stated “sometimes the user needs this argument, and if they need this argument for install they will need it to boot”, they might have shrugged and let it slide. In trying to overexplain, it betrayed that there was no actual understanding behind it.