On Fri, Oct 25, 2019 at 12:33 AM Richard Weinberger <richard@xxxxxx> wrote: > > ----- Ursprüngliche Mail ----- > >> U-boot, for example. Of course it does not so for any filesystem, but whe= > > re > >> it is needed and makes sense. > > > > Really? uboot does journal replay on ext3/4? I think at this point the > > most common file system on Linux distros is unquestionably ext4, and > > the most common bootloader is GRUB and for sure GRUB is no doing > > journal replay on anything, including ext4. > > For ext4 it does a replay when you start to write to it. That strikes me as weird. The bootloader will read from the file system before it writes, and possibly get the wrong view of the file system's true state because journal replay wasn't done. > > Yeah that's got its own difficulties, including the way distro build > > systems work. I'm not opposed to it, but it's a practical barrier to > > adoption. I'd almost say it's easier to make Btrfs $BOOT compulsory, > > make static ESP compulsory, and voila! > > I really don't get your point. I thought you are designing a "sane" > system which can tolerate powercuts down an update. > Why care about distros? > The approach with Linux being a "bootloader" is common for embedded/secure > systems. I want something as generic as possible, so as many use cases have reliable kernel/bootloader updates as possible, so that fewer users experience systems face planting following such updates. Any system can experience an unscheduled, unclean shutdown. Exceptions to the generic case should be rare and pretty much be about handling hardware edge cases. -- Chris Murphy
