On 06/25/2018 02:49 PM, Lennart Poettering wrote: > On Mo, 25.06.18 13:22, Kyle Marek (psppsn96@xxxxxxxxx) wrote: > >>> So think about this one bit ahead. Right now it's clear that even with >>> Grub's relatively large contributor base it'shard to impossible to >>> support modern Linux file systems properly — even just for >>> read-only. See the the XFS debacle as one example, and that the kernel >>> folks made clear they only consider their own in-kernel implementation >>> to be supportable. Now, I'd assume that sooner or later features such >>> as boot counting are something we want for Fedora too (i.e. that we >>> can update the kernel, try to boot the new one a couple of times, and >>> when it fails all the time revert back to an older version, fully >>> automatically; in fact the fedora desktop have very recently started >>> work on that, though they have a weaker model of simply showing the >>> boot menu after failed boots, instead of reverting back). Now, in that >>> model you need to count the attempted boots somewhere. Thus you need >>> write access somewhere (and no, EFI variables don't work for this, >>> they are not suitable for stuff changed on every boot, as their memory >>> is generally not ready to be written too that often). Which hence >>> means you need write access to some file system in some form from the >>> boot loader. And how do you think that's going to work out if already >>> read access to modern file systems is, well, a desaster? >> I think it is better (especially for recovery scenarios) if bootloaders >> operate read-only. I think things like boot counting should be >> disregarded simply to preserve read-only access. > Well, most other big OSes actually do implement boot counting in some > form, even Linux based ones (such as ChromeOS). It would be a pity if > Fedora would make its choices in a way that this can never be > implemented. > > boot counting is currently being worked on by the desktop folks, in > context of the "no boot menu" feature, so that they can reenable the > boot menu if a previous boot failed. Note that I am also opposed to the hidden menu... I'm definitely not a fan for implementing a hidden menu *or* boot count simply because it is implemented elsewhere, let alone the functionality issues I've mentioned with the hidden menu proposal. But back on the side of *writing* to the disk from a boot loader: it's a boot loader. While advanced things like software RAID support end up in boot loaders, it is justified because it is necessary to read the kernel. Reading the kernel into memory is really the defining goal of any bootloader, so anything that will help accomplish that is good. However, when the functionality of the bootloader depends on what the bootloader has *written* during a previous boot, you end up with issues where a disk failure preventing writes will prevent administrators from adding "ro shell=/bin/sh" to their cmdline for recovery because the one bit that determines if a user *can* edit the boot entries is never written by the boot failures like it is supposed to be. > 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. Not to mention that broken kernels may just panic or deadlock, in which case the system isn't automatically rebooting, anyway. _______________________________________________ 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/IFHJDLI4QXFI2BZBZCBXEBQ66FGUIGHC/
