3 ms·

Lennart is talking out of his ass, as the implication with CrowdStrike is that the Falcon module would have been running well for a while before the content upd

Lennart is talking out of his ass, as the implication with CrowdStrike is that the Falcon module would have been running well for a while before the content update, and would only have fallen over once the agent looked for the new content update on system and tried to load it. Any assessment systemd could have done would see failure to boot, and would either try to roll back to a kernel with an old agent module version, which would probably do the same thing, or go back to a kernel without the Crowd Strike Module at all if available. Computers aren't magic. They don't know things. They can't bisect their own configuration or intuit what subcomponent caused what behavior. That's your job.

jauntywundrkind 2y ago
I understand the confusion, because the discussion looks like it's about kernel versions. But if you click in, what's being tried monitored & reverted is boot loader entries. From the second sentence in https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/ https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/ : > The Boot Loader Specification describes how to annotate boot loader entries with a counter that specifies how many attempts should be made to boot it. Which include kernel parameters. Which include the root. As a btrfs user, my system could take a snapshot before applying an update, & set that as the fall through loader entry, so that if boot fails I go back to that previous state. I'm again finding myself 100% on Team Lennart here. Again this seems like the obvious right & true path, & like we obviously should be doing this.