Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)
[2019-03-13 18:20] Thorsten Glaser > On Wed, 13 Mar 2019, Dmitry Bogatov wrote: > > > Sorry, I am totally confused. Mind to make a patch? > > Eh, just donât drop support, and at best document that > people should use the new tune2fs option for ext[234]. > > No sense in making a patch, weâve frozen. We are warm in experimental :) -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)
> And, I can't see standalone tune2fs even in unstable: > > $ apt-file find /bin/tune2fs > android-sdk: /usr/lib/android-sdk/tools/bin/tune2fs /sbin/tune2fs is shipped by e2fsprogs. -- Pierre Ynard
Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)
[2019-03-11 19:27] Thorsten Glaser > On Mon, 11 Mar 2019, Dmitry Bogatov wrote: > > So, you propose that we: > > * drop all checks for /forcecheck > > No! > > > * document this fact in NEWS file > > * write documentation, that e[2-4]fs users should use tune2fs tool > >instead > > Yes. Sorry, I am totally confused. Mind to make a patch? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)
On Wed, 13 Mar 2019, Dmitry Bogatov wrote: > Sorry, I am totally confused. Mind to make a patch? Eh, just don’t drop support, and at best document that people should use the new tune2fs option for ext[234]. No sense in making a patch, we’ve frozen. bye, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!
Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)
On Mon, 11 Mar 2019, Dmitry Bogatov wrote: > So, you propose that we: > * drop all checks for /forcecheck No! > * document this fact in NEWS file > * write documentation, that e[2-4]fs users should use tune2fs tool >instead Yes. //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * **!!! NEU !!!** Mit der **tarent Academy** bieten wir ab sofort auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf [www.tarent.de/academy](http://www.tarent.de/academy). Wir freuen uns auf Ihren Kontakt. *
Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)
[2019-03-09 21:57] Thorsten Glaser > > But I really want to have some transition plan to get rid of > > /forcecheck, something like: > > … you might like that tune2fs can now (1.45.0-1, not yet in > buster, officially not likely to make it but we can hope) set > a flag force_fsck that next boot’s auto e2fsck will honour. > I’m assuming this works for ext2/ext3/ext4; ask tytso if unsure. > > So just print a warning (in the first upload after buster) and > recommend using that instead, *AND* document in /usr/share/doc/…/ > that the file should not be used any more, and get the reiserfs > people (and others) to invent something similar. It’s more granular > (per filesystem) and thus better anyway. So, you propose that we: * drop all checks for /forcecheck * document this fact in NEWS file * write documentation, that e[2-4]fs users should use tune2fs tool instead Well, fine, but what about reiserfs and minix? And, I can't see standalone tune2fs even in unstable: $ apt-file find /bin/tune2fs android-sdk: /usr/lib/android-sdk/tools/bin/tune2fs -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)
On Sat, 9 Mar 2019, Pierre Ynard wrote: > /fastboot and /forcefsck are created by `shutdown -f` and `shutdown -F` Oh, I didn’t know that, I just sudo touch them as used to on Unix. > the shutdown binary, it could create /forcefsck or /run/forcefsck, which /run is a tmpfs. > would then be checked by a script in runlevel 0 or 6 that calls tune2fs > on the relevant filesystems. Oh, no, please don’t call tune2fs automatically from anything EVER. Way too dangerous/invasive/… especially when you temporarily have a disc setup that differs from your fstab. Thanks, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!
Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)
> > As you convincingly remarked below, we may want honor `test -f /forcecheck' > > for every filesystem, whose `fsck' supports `-f' option. As far as I > > follow the thread, it is: > > > > ext2 ext3 ext4 reiserfs > > Interesting that acceptance of that parameter is so low. fsck.minix supports it too. I don't use many filesystems and don't have many tool suites installed so I really wouldn't know how widespread it is. > > But I really want to have some transition plan to get rid of > > /forcecheck, something like: > > … you might like that tune2fs can now (1.45.0-1, not yet in > buster, officially not likely to make it but we can hope) set > a flag force_fsck that next boot’s auto e2fsck will honour. > I’m assuming this works for ext2/ext3/ext4; ask tytso if unsure. You may want to look at #470956 for related reasons and discussions. /fastboot and /forcefsck are created by `shutdown -f` and `shutdown -F` respectively. I like the idea that instead of this interface, it should call tune2fs to set that flag. Or rather, if that doesn't belong inside the shutdown binary, it could create /forcefsck or /run/forcefsck, which would then be checked by a script in runlevel 0 or 6 that calls tune2fs on the relevant filesystems. We could use that script any time we want (like in runlevel S too) to print deprecation warnings to assist in the transition. -- Pierre Ynard
Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)
On Sat, 9 Mar 2019, Dmitry Bogatov wrote: > As you convincingly remarked below, we may want honor `test -f /forcecheck' > for every filesystem, whose `fsck' supports `-f' option. As far as I > follow the thread, it is: > > ext2 ext3 ext4 reiserfs Interesting that acceptance of that parameter is so low. > * buster+1: big deprecation warning > * buster+2: /forcecheck is ignored, big warning is printed > * buster+3: /forcecheck is ignored silently. I don’t like this plan… people are used that such a file can exist and gets used, but they use it rarely enough that multiple releases can pass before they need it again. Better to document it. Also… > But I really want to have some transition plan to get rid of > /forcecheck, something like: … you might like that tune2fs can now (1.45.0-1, not yet in buster, officially not likely to make it but we can hope) set a flag force_fsck that next boot’s auto e2fsck will honour. I’m assuming this works for ext2/ext3/ext4; ask tytso if unsure. So just print a warning (in the first upload after buster) and recommend using that instead, *AND* document in /usr/share/doc/…/ that the file should not be used any more, and get the reiserfs people (and others) to invent something similar. It’s more granular (per filesystem) and thus better anyway. bye, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!
Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)
[2019-03-07 15:15] Pierre Ynard > > Sounds reasonable. Will you make patch? > > What does ext* expand to, what's the list of ext filesystem types for > which we want to honor forcefsck? ext2, ext3 and ext4? As you convincingly remarked below, we may want honor `test -f /forcecheck' for every filesystem, whose `fsck' supports `-f' option. As far as I follow the thread, it is: ext2 ext3 ext4 reiserfs But I really want to have some transition plan to get rid of /forcecheck, something like: * buster+1: big deprecation warning * buster+2: /forcecheck is ignored, big warning is printed * buster+3: /forcecheck is ignored silently. It is 6 years plan, oh. But I do not know how to move things gracefully and /fast/. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)
> Sounds reasonable. Will you make patch? What does ext* expand to, what's the list of ext filesystem types for which we want to honor forcefsck? ext2, ext3 and ext4? > What is relations of reiserfs and /forcecheck convention on timeline? > We want to deprecate /forcecheck, and making it respect another > filesystem is move in opposite direction. > > I mean, nobody seems to reported lack of support of /forcecheck on > reiserfs root. Well I suppose it worked fine until sysvinit 2.93-3 two months ago when this was restricted to ext*, so maybe people just haven't run into this and complained yet. I don't know how popular reiserfs is now, but there are certainly systems still using it. My point is also that the assumption that forcefsck was a proprietary feature of e2fsck, was wrong, and maybe there are yet others. -- Pierre Ynard
Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)
[2019-03-05 02:50] Pierre Ynard > reopen 686895 > thanks > > /etc/init.d/checkfs.sh also checks forcefsck to pass -f to fsck, > so it needs to be fixed too. It won't be as simple as checkroot.sh > because fsck -A can apply to any number of filesystems of any type and > checkfs.sh doesn't track specifics when calling it. > > Perhaps the simplest approach, if forcefsck is requested, would be to > add a first pass of fsck -A -f -t ext3,... and then let the normal code > proceed: this saves a lot of complexity and the worst that should happen > is that fsck wastes a bit of time doing a fast and clean second check of > the involved filesystems after the forced slow check. Sounds reasonable. Will you make patch? > Also, I can see that at least reiserfsck too honors -f as --force with > the same meaning, so I suppose it should be added alongside ext*. What is relations of reiserfs and /forcecheck convention on timeline? We want to deprecate /forcecheck, and making it respect another filesystem is move in opposite direction. I mean, nobody seems to reported lack of support of /forcecheck on reiserfs root. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)
reopen 686895 thanks /etc/init.d/checkfs.sh also checks forcefsck to pass -f to fsck, so it needs to be fixed too. It won't be as simple as checkroot.sh because fsck -A can apply to any number of filesystems of any type and checkfs.sh doesn't track specifics when calling it. Perhaps the simplest approach, if forcefsck is requested, would be to add a first pass of fsck -A -f -t ext3,... and then let the normal code proceed: this saves a lot of complexity and the worst that should happen is that fsck wastes a bit of time doing a fast and clean second check of the involved filesystems after the forced slow check. Also, I can see that at least reiserfsck too honors -f as --force with the same meaning, so I suppose it should be added alongside ext*. -- Pierre Ynard
Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)
Hi Dmitry,
Dmitry Bogatov writes:
> control: tags -1 +patch
>
> [2014-11-24 22:30] Petter Reinholdtsen
>> Given that -f is force only for ext*, I suspect a more sensible
>> approach is to only enable forcefsck for ext*, not disable it for
>> btrfs.
>
> Like this?
>
> diff --git a/debian/src/initscripts/etc/init.d/checkroot.sh
> b/debian/src/initscripts/etc/init.d/checkroot.sh
> index 9f70527a..c6c21344 100755
> --- a/debian/src/initscripts/etc/init.d/checkroot.sh
> +++ b/debian/src/initscripts/etc/init.d/checkroot.sh
> @@ -22,6 +22,18 @@ FSCK_LOGFILE=/var/log/fsck/checkroot
> . /lib/lsb/init-functions
> . /lib/init/mount-functions.sh
>
> +_want_force_fsck () {
> + set -- $(findmnt / | tail -n1)
> + case "$3" in
> + # Only ext* file systems support `-f' option to fsck. See #686895
> + (ext*)
> + [ -f /forcefsck ] || grep -q -s -w -i "forcefsck" /proc/cmdline
> + ;;
> + (*)
> + return 1
Do we need ';;' after this line? Otherwise looks good to me.
> + esac
> +}
> +
Yours,
Benda
Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)
control: tags -1 +patch
[2014-11-24 22:30] Petter Reinholdtsen
> Given that -f is force only for ext*, I suspect a more sensible
> approach is to only enable forcefsck for ext*, not disable it for
> btrfs.
Like this?
diff --git a/debian/src/initscripts/etc/init.d/checkroot.sh
b/debian/src/initscripts/etc/init.d/checkroot.sh
index 9f70527a..c6c21344 100755
--- a/debian/src/initscripts/etc/init.d/checkroot.sh
+++ b/debian/src/initscripts/etc/init.d/checkroot.sh
@@ -22,6 +22,18 @@ FSCK_LOGFILE=/var/log/fsck/checkroot
. /lib/lsb/init-functions
. /lib/init/mount-functions.sh
+_want_force_fsck () {
+ set -- $(findmnt / | tail -n1)
+ case "$3" in
+ # Only ext* file systems support `-f' option to fsck. See #686895
+ (ext*)
+ [ -f /forcefsck ] || grep -q -s -w -i "forcefsck" /proc/cmdline
+ ;;
+ (*)
+ return 1
+ esac
+}
+
do_start () {
# Trap SIGINT so that we can handle user interrupt of fsck.
trap "" INT
@@ -203,12 +215,8 @@ Will restart in 5 seconds."
#
if [ "$rootcheck" = yes ]
then
- if [ -f /forcefsck ] || grep -q -s -w -i "forcefsck"
/proc/cmdline
- then
- force="-f"
- else
- force=""
- fi
+ force=""
+ _want_force_fsck && force="-f"
if [ "$FSCKFIX" = yes ]
then
Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)
Control: tags -1 - patch Given that -f is force only for ext*, I suspect a more sensible approach is to only enable forcefsck for ext*, not disable it for btrfs. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)
tag 686895 + patch thanks Hi, I ran into the very same bug. It seems to be a more conceptual problem than btrfs-related, but for making btrfsck work, I added this patch: --- checkroot.sh2014-02-16 23:34:17.349214647 + +++ /etc/init.d/checkroot.sh2014-02-16 23:42:03.19371 + @@ -187,6 +187,12 @@ if [ -f /forcefsck ] || grep -s -w -i forcefsck /proc/cmdline then force=-f + + # btrfsck doesn't know -f + mount | while read dev on path type fs fnord; do + [ x/ = x$path -a xbtrfs = x$fs ] \ +break + done force= else force= fi It checks if / is a btrfs file system and then removes the -f from the fsck(8) command line. I don't know if it's sensible to add something like a blacklist for file systems whose fsck doesn't know -f at this place. Cheers, Julius -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
