|
|
|
|
|
by t_spins
696 days ago
|
|
You would "just pick the previous kernel from the boot menu". That's funny, cause in this case you could "just delete the file causing the issue." Anything can sound easy and simple if you state it that way. How do you access the boot menu for a server running in the cloud, which you normally just SSH into (RDP in Windows' case)? About your last paragraph: we have just started sending out the bitlocker keys to everyone so it can be done by them too. Surely not best practice, but it beats everyone having to line up at the helpdesk. |
|
One small difference, is that choosing the kernel from the boot menu is done before unlocking the encrypted drive, so no recovery keys would be necessary. And yes, choosing an entry from a menu (which automatically appears when the last boot has failed) is simpler than entering recovery mode and typing a command, even without disk encryption.
A better analogue would be a bad update on a non-kernel package which is critical to the boot sequence, for instance systemd or glibc. Unless it's one of the distributions which snapshot the whole root filesystem before doing a package update.