On 06/29/2018 04:33 PM, Lars Seipel wrote: > On Mon, Jun 25, 2018 at 03:17:53PM -0400, Kyle Marek wrote: >> On 06/25/2018 02:49 PM, Lennart Poettering wrote: >>> But it's useful for unattended systems in general, be it servers or >>> appliances: if a boot fails there generally should be a way to recover >>> the system through rebooting without manual interfering. Quite >>> frankly, it's quite surprising we haven't implemented anything like >>> that on Fedora/RHEL at all yet, as it's a major piece in making >>> unattended system updates less risky. >> I'm still not a fan. I'm not convinced that an issue that is correctable >> by booting an old kernel could be caused by a system being left >> "unattended". Systems should never automatically reboot due to a kernel >> update, and kernel updates really should be given administrator >> attention simply *because* of the potential boot issues. > Why not? If the administrator can arrange for reliable automated updates > across machines (in a rolling fashion, stopping the process and > reverting to the previous version on update failures), why would she > want to baby-sit every single machine? > > You probably don't want to do this if all you have is a single machine > but for fleets of mostly-interchangable servers (hosting VMs or > containers), doing it this way makes perfect sense *if* it is reliable. Kernel updates are different. You *have* to reboot in order to run the new kernel (except for security updates applied with kpatch) and a broken kernel has the potential to simply lock up without even launching /sbin/init, for example. In these situations, administrators have to manually reboot the machine. If this is the case, they can also pick the kernel they want to boot from the boot menu. No amount of unattended failed-boot-check logic in the bootloader can run without user intervention when a broken kernel is still running/just sitting there. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/KXOUMHPWKIQPLEWJSWAS5OREZX3NQITN/
