[systemd-devel] Please pass 'fsck.mode=force' on the kernel command line rather than creating /forcefsck on the root file system

[Reindl Harald]

Am 16.08.2013 11:13, schrieb Colin Guthrie:
> 'Twas brillig, and Reindl Harald at 15/08/13 22:04 did gyre and gimble:
>> Please pass 'fsck.mode=force' on the kernel command line rather than creating /forcefsck on the root file system
>>
>> please drop this deprectaion, it is disturbing and useless
>>
>> if you want a forced fsck for *whatever* reason you do *not* want
>> to edit the grub-config and need to remove it after pass to prevent
>> on the next boot a unintented fsck
> 
> And besides, if you did write the config, why would you want to "prevent
> on the next boot an unintended fsck"... surely the whole point in
> writing the config is that it was an *intended* fsck, not an unintended one?

you missed the "after pass"

>> nor do you want to struggle with
>> the boot-menu on remote-machines
>
> Fair enough, but lots of remote machines have consoles that let you pick
> even the boot options these days. It's not that crazy.

and lots of simple setups are not that perfect IT with
firewalls in front of them - hnece the linux machine may
be the firewall an dyou do not want ILO on WAN

>> this warning is pointless and useless
> 
> If I suspect my root partition has corruption and I want to do an fsck,
> the first thing I'll do is remount it ro, as fast as I possibly can. The
> *last* thing I want to do is write more data to it potentially making
> any corruption worse.

and if i am on a virtual machine the first thing i do is make a snapshot
including the current RAM, type "touch /forcefsck" and look what happens
and if it's no good i restore the snapshot

> Having a file to trigger the fsck on the same filesystem I want to check
> is braindead. A kernel command line arg is a much safer and more
> sensible approach.

see above, form the in summary 40 Fedora setups including testing-machines
there are exactly 6 physical and the rest is virtualized

> So no, it's not pointless and it's not useless

my problem with such deprecations is that systemd-guys tend to remove
things sooner or later and there are *a lot* of good reasons as explained

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20130816/291dca8b/attachment-0001.pgp>