▲ 389 ▼ Some bad code just broke a billion Windows machines (www.youtube.com) submitted 2 years ago by TimeSquirrel@kbin.melroy.org to c/technology@lemmy.world 119 comments fedilink hide all child comments Cybersecurity firm Crowdstrike pushed an update that caused millions of Windows computers to enter recovery mode, triggering the blue screen of death. Learn ...
[–] MeekerThanBeaker@lemmy.world 44 points 2 years ago (6 children) Probably includes a bunch of virtual machines. permalink fedilink source parent hideshow 6 child comments replies: [–] Joelk111@lemmy.world 21 points 2 years ago (5 children) Yeah, our VMs completely died at work. Has to set up temporary stuff on hardware we had laying around today. Was kinda fun, but stressful haha. permalink fedilink source parent hideshow 5 child comments replies: [–] dan@upvote.au 9 points 2 years ago (4 children) Could you just revert VMs to a snapshot before the update? Or do you not take periodic snapshots? You could probably also mount the VM's drive on the host and delete the relevant file that way. permalink fedilink source parent hideshow 4 child comments replies: [–] EncryptKeeper@lemmy.world 10 points 2 years ago (1 child) Yes you can just go into safe mode on an affected machine and delete the offending file. The problem is it took a couple hours before that resolution was found, and it has to be done by hand on every VM. I can’t just run an Ansible playbook against hundreds of non-booted VMs. Then you have to consider in the case of servers, there might be a specific start up order, certain things might have to be started before other things and further fixing might be required given that every VM hard crashed. At the minimum it took many companies 6-12 hours to get back up and running and on many more it could take days. permalink fedilink source parent hideshow 1 child comment replies: [–] dan@upvote.au 4 points 2 years ago Makes sense - thanks for the details. permalink fedilink source parent [–] UnsavoryMollusk@lemmy.world 1 point 2 years ago This is assuming you have those access. Some companies can sometimes be a bit .... Stupid. permalink fedilink source parent [–] Joelk111@lemmy.world 1 point 2 years ago* Yeah, like the other person said, corporate IT is responsible for that stuff. I guess they're working through the weekend to try to get it fixed. permalink fedilink source parent
[–] Joelk111@lemmy.world 21 points 2 years ago (5 children) Yeah, our VMs completely died at work. Has to set up temporary stuff on hardware we had laying around today. Was kinda fun, but stressful haha. permalink fedilink source parent hideshow 5 child comments replies: [–] dan@upvote.au 9 points 2 years ago (4 children) Could you just revert VMs to a snapshot before the update? Or do you not take periodic snapshots? You could probably also mount the VM's drive on the host and delete the relevant file that way. permalink fedilink source parent hideshow 4 child comments replies: [–] EncryptKeeper@lemmy.world 10 points 2 years ago (1 child) Yes you can just go into safe mode on an affected machine and delete the offending file. The problem is it took a couple hours before that resolution was found, and it has to be done by hand on every VM. I can’t just run an Ansible playbook against hundreds of non-booted VMs. Then you have to consider in the case of servers, there might be a specific start up order, certain things might have to be started before other things and further fixing might be required given that every VM hard crashed. At the minimum it took many companies 6-12 hours to get back up and running and on many more it could take days. permalink fedilink source parent hideshow 1 child comment replies: [–] dan@upvote.au 4 points 2 years ago Makes sense - thanks for the details. permalink fedilink source parent [–] UnsavoryMollusk@lemmy.world 1 point 2 years ago This is assuming you have those access. Some companies can sometimes be a bit .... Stupid. permalink fedilink source parent [–] Joelk111@lemmy.world 1 point 2 years ago* Yeah, like the other person said, corporate IT is responsible for that stuff. I guess they're working through the weekend to try to get it fixed. permalink fedilink source parent
[–] dan@upvote.au 9 points 2 years ago (4 children) Could you just revert VMs to a snapshot before the update? Or do you not take periodic snapshots? You could probably also mount the VM's drive on the host and delete the relevant file that way. permalink fedilink source parent hideshow 4 child comments replies: [–] EncryptKeeper@lemmy.world 10 points 2 years ago (1 child) Yes you can just go into safe mode on an affected machine and delete the offending file. The problem is it took a couple hours before that resolution was found, and it has to be done by hand on every VM. I can’t just run an Ansible playbook against hundreds of non-booted VMs. Then you have to consider in the case of servers, there might be a specific start up order, certain things might have to be started before other things and further fixing might be required given that every VM hard crashed. At the minimum it took many companies 6-12 hours to get back up and running and on many more it could take days. permalink fedilink source parent hideshow 1 child comment replies: [–] dan@upvote.au 4 points 2 years ago Makes sense - thanks for the details. permalink fedilink source parent [–] UnsavoryMollusk@lemmy.world 1 point 2 years ago This is assuming you have those access. Some companies can sometimes be a bit .... Stupid. permalink fedilink source parent [–] Joelk111@lemmy.world 1 point 2 years ago* Yeah, like the other person said, corporate IT is responsible for that stuff. I guess they're working through the weekend to try to get it fixed. permalink fedilink source parent
[–] EncryptKeeper@lemmy.world 10 points 2 years ago (1 child) Yes you can just go into safe mode on an affected machine and delete the offending file. The problem is it took a couple hours before that resolution was found, and it has to be done by hand on every VM. I can’t just run an Ansible playbook against hundreds of non-booted VMs. Then you have to consider in the case of servers, there might be a specific start up order, certain things might have to be started before other things and further fixing might be required given that every VM hard crashed. At the minimum it took many companies 6-12 hours to get back up and running and on many more it could take days. permalink fedilink source parent hideshow 1 child comment replies: [–] dan@upvote.au 4 points 2 years ago Makes sense - thanks for the details. permalink fedilink source parent
[–] dan@upvote.au 4 points 2 years ago Makes sense - thanks for the details. permalink fedilink source parent
[–] UnsavoryMollusk@lemmy.world 1 point 2 years ago This is assuming you have those access. Some companies can sometimes be a bit .... Stupid. permalink fedilink source parent
[–] Joelk111@lemmy.world 1 point 2 years ago* Yeah, like the other person said, corporate IT is responsible for that stuff. I guess they're working through the weekend to try to get it fixed. permalink fedilink source parent