On Friday, 15 April 2016 11:48:06 AM AEST Theodore Ts'o wrote: > So the workaround is this: > > debugfs -w -R "features ^needs_recovery,^has_journal" /dev/sdXX > e2fsck -f /dev/sdXX > tune2fs -O has_journal /dev/sdXX
Thank you for this advise.
> The reason why we haven't really dealt with this case is because it's
> fundamentally a UI issue, and there aren't good answers about the best
> way to deal with this. It would be really easy for e2fsck to just do
> this, but if the external journal is only temporarily unavailable, we
> **really** don't want to be encouraging system administrators to do
> this, because trying to fix the file system without the feature can
> lead to data loss, which could have been avoided if the journal device
> can be brought back (or was just in a non-standard /dev/sdXX name when
> the user fired off the e2fsck -fy command.
I've managed to fix the problem on my own by using the following patch:
~~~~
--- a/misc/tune2fs.c
+++ b/misc/tune2fs.c
@@ -474,9 +474,9 @@
f_flag < 2) {
fputs(_("The needs_recovery flag is set. "
"Please run e2fsck before clearing\n"
"the has_journal flag.\n"), stderr);
- return 1;
+// return 1;
}
if (sb->s_journal_inum) {
if (remove_journal_inode(fs))
return 1;
~~~~
After aplying it "tune2fs -O ^has_journal /dev/sdXX" explicitly warned me
about removing unavailable journal (and prompted for confirmation) so I
believe there are enough warnings already.
> I should just make a decision, probably with a large message with
> warnings in upper case and a question which does NOT honor the e2fsck
> -y option.
That makes sense, thank you.
--
All the best,
Dmitry Smirnov.
---
The surest way to corrupt a youth is to instruct him to hold in higher
esteem those who think alike than those who think differently.
-- Friedrich Nietzsche
signature.asc
Description: This is a digitally signed message part.
