On Sun, Mar 15, 2015 at 7:48 PM, Zbigniew Jędrzejewski-Szmek <[email protected]> wrote: > On Sun, Mar 15, 2015 at 06:48:24PM +0100, Kay Sievers wrote:
>> It is legacy and does not need new features. It worked in the past and >> will continue to work in the future, but it does not need new >> questionable and possibly unreliable or dangerous features. The recent >> merging of fsckd was already the wrong thing to do. > Calling it legacy does not make it go away. If we had a stable non-fsck-using > filesystem available, we could start discussing removing fsck support. > But we don't. It's one thing to remove stuff once we have something > better, and completely different to remove support for widely used > things. Nobody talks about things going away, we just should not add more non-trivial legacy support, that is all. >> >> the kernel command line should be sufficient enough. >> > The kernel command line is not a good fit for a few reasons. >> >> The kernel commandline woked fine in the past and will be fine today, >> especially for such a legacy feature. > Support for /forcefsck (or whatever it was called) was removed with the > promise to provide a replacement which does not require touching the fs. > Kernel commandline is just too unwieldy for users. Writing to the file system content to request a check, which would happen when things are already inconsistent, is a really stupid idea. If the filesytem is too dumb to have that info in the superblock flags to store, to request a forced fsck, it is the problem of the file system to fix and nothing we need to solve in systemd. >> No, they are absolutely not. Changing the EFI flash comes with >> unpredictable risks, the flash is not meant to or designed for be >> written to during any normal operation. > Requesting fsck is not a normal operation. It is just a normal system operation. It needs to be fixed properly if needed, not with dirty work-arounds like this. > If the flash is suitable > to be written whenever the kernel is updated, it should be also OK > to request a fsck through it. For users of many distributions (and > kernel developers certainly), requesting fsck is a much rarer operation. Nobody would write to the flash on kernel updates, we only possibly write to the ESP filesystem. The flash is not meant for such use cases, it is known to brick all sorts of machines, and not to be mis-used for such features. >> To avoid any possible misunderstanding here: >> >> Systemd will not use the fragile EFI flash store to configure services >> or request system operation modes. The kernel command line is good >> enough here. >> >> You will not apply this patch. > I'd prefer to have a discussion and reach conclusions, not the other > way around. Sorry, there is nothing to discuss, systemd will not mis-use the fragile firmware flash for normal operations, and especially not to support legacy features. Kay _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
