Corrupted superblock? But disk still mounts.

Corrupted superblock? But disk still mounts.

[Mark Ballard]

Found bad superblock when trying to rename partition using e2label.

The same problem has prevented me using dumpe2fs, e2fsck and fsck to
try and resolve the problem.

But I can still mount the disk and use it.

The disk is encrypted. It is not the boot disk. The OS - Xubuntu - has
gone helicopter a few times, spiraling out with disk crunching that
locks up the machine for so long that I have been faced with no choice
but to switch it off at the wall. That is not likely to do with this
hick disk being discussed here, but it does mean the hick disk has
been knocked out a few times.

---------------------------------------------

Here's what happens when I attempt to rename:

# e2label /dev/sdb1
e2label: Bad magic number in super-block while trying to open /dev/sdb1
Couldn't find valid filesystem superblock.

Two other partitions on the same disk accepted the rename command.
fdisk -l gives output consistent with normal conditions. The disk is
not using LVM.

---------------------------------------------

Here's what happens when I try and run the disk utilities:

# dumpe2fs /dev/sdb1 | grep –i superblock
grep: superblock: No such file or directory
dumpe2fs 1.42.9 (4-Feb-2014)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb1

# e2fsck /dev/sdb1
e2fsck 1.42.9 (4-Feb-2014)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

# blockdev --getbsz /dev/sdb1
4096

# e2fsck -b 32768 /dev/sdb1
e2fsck 1.42.9 (4-Feb-2014)
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

# fsck.ext4 -v /dev/sdb1
e2fsck 1.42.9 (4-Feb-2014)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb1

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

------------------------------

mke2fs -n listed 14 backup superblocks, running each of through e2fsck
produced the same error bar one:

e2fsck 1.42.9 (4-Feb-2014)
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

One of the backups gave this with e2fsck:

e2fsck 1.42.9 (4-Feb-2014)
e2fsck: Attempt to read block from filesystem resulted in short read
while trying to open /dev/sdb1
Could this be a zero-length partition?

----------------------------

Mark Ballard
Freelance journalist
twitter.com/markjballard
Best tel: +44(0)1474 566 118
Mob  tel: +44(0)79 827 00815
markjballard@googlemail.com
---------------------------------------------------------------------------
---------------------------------------------------------------------------
Public Sector IT Blog:
http://www.computerweekly.com/blogs/public-sector/
---------------------------------------------------------------------------
RSS updates:
http://www.computerweekly.com/blogs/public-sector/atom.xml
----------------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Corrupted superblock? But disk still mounts.

[Eric Sandeen]

On 8/18/14, 1:14 PM, Mark Ballard wrote:
> Found bad superblock when trying to rename partition using e2label.
> 
> The same problem has prevented me using dumpe2fs, e2fsck and fsck to
> try and resolve the problem.
> 
> But I can still mount the disk and use it.
> 
> The disk is encrypted.

How is /dev/sdb1 encrypted?  Usually this is done with something like dm-crypt.
Or is it hardware encryption managed in the bios?  Did you unlock it?

What does "blkid /dev/sdb1" say?

I'm guessing that it's the encryption getting in your way.

-Eric

Re: Corrupted superblock? But disk still mounts.

[Mark Ballard]

> I'm guessing that it's the encryption getting in your way.

Cheers, Eric. Does rather look that way. But for the sake of a user report...

>
> How is /dev/sdb1 encrypted?  Usually this is done with something like dm-crypt.
> Or is it hardware encryption managed in the bios?  Did you unlock it?

Done with crytpsetup using luks.

>
> What does "blkid /dev/sdb1" say?
>

It says Luks.

Re: Corrupted superblock? But disk still mounts.

[Eric Sandeen]

On 8/18/14, 3:23 PM, Mark Ballard wrote:
>> I'm guessing that it's the encryption getting in your way.
> 
> Cheers, Eric. Does rather look that way. But for the sake of a user report...
> 
>>
>> How is /dev/sdb1 encrypted?  Usually this is done with something like dm-crypt.
>> Or is it hardware encryption managed in the bios?  Did you unlock it?
> 
> Done with crytpsetup using luks.
> 
>>
>> What does "blkid /dev/sdb1" say?
>>
> 
> It says Luks.

and not ext4 - so you need to unlock it via mumblemumbleLuksStuffmumblemumble
before you can operate on it with e2fsprogs tools.

# cryptsetup luksOpen /dev/sdb1 <name>... or something.  Sorry, I'm not a LUKS
expert...

Anyway, not an ext4 problem.  Your superblock isn't corrupted, it's encrypted.  :)

-Eric

Re: Corrupted superblock? But disk still mounts.

[Mark Ballard]

Ya. It did look that way. 'Scuse me for not checking first.

But my point is that it may still be a problem for ext4, dumpe2fs,
e2fsck, fsck and presumably gparted and so on.

That is, would it not be polite of them to report the error ...<drum
roll>... accurately?

(No irony intended.)


On 19 August 2014 15:36, Eric Sandeen <sandeen@redhat.com> wrote:
> On 8/18/14, 3:23 PM, Mark Ballard wrote:
>>> I'm guessing that it's the encryption getting in your way.
>>
>> Cheers, Eric. Does rather look that way. But for the sake of a user report...
>>
>>>
>>> How is /dev/sdb1 encrypted?  Usually this is done with something like dm-crypt.
>>> Or is it hardware encryption managed in the bios?  Did you unlock it?
>>
>> Done with crytpsetup using luks.
>>
>>>
>>> What does "blkid /dev/sdb1" say?
>>>
>>
>> It says Luks.
>
> and not ext4 - so you need to unlock it via mumblemumbleLuksStuffmumblemumble
> before you can operate on it with e2fsprogs tools.
>
> # cryptsetup luksOpen /dev/sdb1 <name>... or something.  Sorry, I'm not a LUKS
> expert...
>
> Anyway, not an ext4 problem.  Your superblock isn't corrupted, it's encrypted.  :)
>
> -Eric
>

Re: Corrupted superblock? But disk still mounts.

[Eric Sandeen]

On 8/22/14, 9:19 AM, Mark Ballard wrote:
> Ya. It did look that way. 'Scuse me for not checking first.
> 
> But my point is that it may still be a problem for ext4, dumpe2fs,
> e2fsck, fsck and presumably gparted and so on.
> 
> That is, would it not be polite of them to report the error ...<drum
> roll>... accurately?

Ah, I see.  So you don't like "corrupted" - you'd like to know that it's
something else perfectly valid, just not the thing you were looking for.

Maybe like:

# misc/dumpe2fs /dev/sdc1
dumpe2fs 1.43-WIP (09-Jul-2014)
misc/dumpe2fs: Superblock checksum does not match superblock while trying to open /dev/sdc1
Couldn't find valid filesystem superblock.
/dev/sdc1 contains a xfs file system


# misc/dumpe2fs /dev/sdc
dumpe2fs 1.43-WIP (09-Jul-2014)
misc/dumpe2fs: Superblock checksum does not match superblock while trying to open /dev/sdc
Couldn't find valid filesystem superblock.
/dev/sdc is entire device, not just one partition!

-Eric

> (No irony intended.)
> 
> 
> On 19 August 2014 15:36, Eric Sandeen <sandeen@redhat.com> wrote:
>> On 8/18/14, 3:23 PM, Mark Ballard wrote:
>>>> I'm guessing that it's the encryption getting in your way.
>>>
>>> Cheers, Eric. Does rather look that way. But for the sake of a user report...
>>>
>>>>
>>>> How is /dev/sdb1 encrypted?  Usually this is done with something like dm-crypt.
>>>> Or is it hardware encryption managed in the bios?  Did you unlock it?
>>>
>>> Done with crytpsetup using luks.
>>>
>>>>
>>>> What does "blkid /dev/sdb1" say?
>>>>
>>>
>>> It says Luks.
>>
>> and not ext4 - so you need to unlock it via mumblemumbleLuksStuffmumblemumble
>> before you can operate on it with e2fsprogs tools.
>>
>> # cryptsetup luksOpen /dev/sdb1 <name>... or something.  Sorry, I'm not a LUKS
>> expert...
>>
>> Anyway, not an ext4 problem.  Your superblock isn't corrupted, it's encrypted.  :)
>>
>> -Eric
>>

Re: Corrupted superblock? But disk still mounts.

[Mark Ballard]

No, Eric. I can see it's accurate in its own context. I mean accurate
in relaying enough information to convey the situation accurately to
the user. That requires something like e2label to see a wider context,
and I can see that might actually be an unreasonable expectation. But
this is what I was getting at: information accurate enough to allow
non-educated users to get an instant grip of the environment when they
are forced to go delving under the bonnet (hood) of their computer.
None of the os componenets were made -- or documented -- with that
sort of user in mind: someone with less time and experience than is
really required to work efficiently under there. Yet the application
environment is such a tangle that users are left with little choice
but to get their hands dirty. And when you look under there, you see
that it was made by Heath Robinson but that the drawings were burned
in a fire.

On 22 August 2014 17:09, Eric Sandeen <sandeen@redhat.com> wrote:
> On 8/22/14, 9:19 AM, Mark Ballard wrote:
>> Ya. It did look that way. 'Scuse me for not checking first.
>>
>> But my point is that it may still be a problem for ext4, dumpe2fs,
>> e2fsck, fsck and presumably gparted and so on.
>>
>> That is, would it not be polite of them to report the error ...<drum
>> roll>... accurately?
>
> Ah, I see.  So you don't like "corrupted" - you'd like to know that it's
> something else perfectly valid, just not the thing you were looking for.
>
> Maybe like:
>
> # misc/dumpe2fs /dev/sdc1
> dumpe2fs 1.43-WIP (09-Jul-2014)
> misc/dumpe2fs: Superblock checksum does not match superblock while trying to open /dev/sdc1
> Couldn't find valid filesystem superblock.
> /dev/sdc1 contains a xfs file system
>
>
> # misc/dumpe2fs /dev/sdc
> dumpe2fs 1.43-WIP (09-Jul-2014)
> misc/dumpe2fs: Superblock checksum does not match superblock while trying to open /dev/sdc
> Couldn't find valid filesystem superblock.
> /dev/sdc is entire device, not just one partition!
>
> -Eric
>
>> (No irony intended.)
>>
>>
>> On 19 August 2014 15:36, Eric Sandeen <sandeen@redhat.com> wrote:
>>> On 8/18/14, 3:23 PM, Mark Ballard wrote:
>>>>> I'm guessing that it's the encryption getting in your way.
>>>>
>>>> Cheers, Eric. Does rather look that way. But for the sake of a user report...
>>>>
>>>>>
>>>>> How is /dev/sdb1 encrypted?  Usually this is done with something like dm-crypt.
>>>>> Or is it hardware encryption managed in the bios?  Did you unlock it?
>>>>
>>>> Done with crytpsetup using luks.
>>>>
>>>>>
>>>>> What does "blkid /dev/sdb1" say?
>>>>>
>>>>
>>>> It says Luks.
>>>
>>> and not ext4 - so you need to unlock it via mumblemumbleLuksStuffmumblemumble
>>> before you can operate on it with e2fsprogs tools.
>>>
>>> # cryptsetup luksOpen /dev/sdb1 <name>... or something.  Sorry, I'm not a LUKS
>>> expert...
>>>
>>> Anyway, not an ext4 problem.  Your superblock isn't corrupted, it's encrypted.  :)
>>>
>>> -Eric
>>>
>

Re: Corrupted superblock? But disk still mounts.

[Darrick J. Wong]

On Fri, Aug 22, 2014 at 05:40:02PM +0100, Mark Ballard wrote:
> No, Eric. I can see it's accurate in its own context. I mean accurate
> in relaying enough information to convey the situation accurately to
> the user. That requires something like e2label to see a wider context,
> and I can see that might actually be an unreasonable expectation. But
> this is what I was getting at: information accurate enough to allow
> non-educated users to get an instant grip of the environment when they
> are forced to go delving under the bonnet (hood) of their computer.
> None of the os componenets were made -- or documented -- with that
> sort of user in mind: someone with less time and experience than is
> really required to work efficiently under there. Yet the application
> environment is such a tangle that users are left with little choice
> but to get their hands dirty. And when you look under there, you see
> that it was made by Heath Robinson but that the drawings were burned
> in a fire.

Perhaps just use a little bit of libmagic to spit out what we might be looking
at if the ext4 sb looks wrong?

# dumpe2fs -h /dev/sda2
dumpe2fs 1.42.11 (09-Jul-2014)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sda
Couldn't find valid filesystem superblock:
/dev/sda2: LUKS encrypted file, ver 1 [aes, xts-plain64, sha1] UUID: <snip>

--D

> 
> On 22 August 2014 17:09, Eric Sandeen <sandeen@redhat.com> wrote:
> > On 8/22/14, 9:19 AM, Mark Ballard wrote:
> >> Ya. It did look that way. 'Scuse me for not checking first.
> >>
> >> But my point is that it may still be a problem for ext4, dumpe2fs,
> >> e2fsck, fsck and presumably gparted and so on.
> >>
> >> That is, would it not be polite of them to report the error ...<drum
> >> roll>... accurately?
> >
> > Ah, I see.  So you don't like "corrupted" - you'd like to know that it's
> > something else perfectly valid, just not the thing you were looking for.
> >
> > Maybe like:
> >
> > # misc/dumpe2fs /dev/sdc1
> > dumpe2fs 1.43-WIP (09-Jul-2014)
> > misc/dumpe2fs: Superblock checksum does not match superblock while trying to open /dev/sdc1
> > Couldn't find valid filesystem superblock.
> > /dev/sdc1 contains a xfs file system
> >
> >
> > # misc/dumpe2fs /dev/sdc
> > dumpe2fs 1.43-WIP (09-Jul-2014)
> > misc/dumpe2fs: Superblock checksum does not match superblock while trying to open /dev/sdc
> > Couldn't find valid filesystem superblock.
> > /dev/sdc is entire device, not just one partition!
> >
> > -Eric
> >
> >> (No irony intended.)
> >>
> >>
> >> On 19 August 2014 15:36, Eric Sandeen <sandeen@redhat.com> wrote:
> >>> On 8/18/14, 3:23 PM, Mark Ballard wrote:
> >>>>> I'm guessing that it's the encryption getting in your way.
> >>>>
> >>>> Cheers, Eric. Does rather look that way. But for the sake of a user report...
> >>>>
> >>>>>
> >>>>> How is /dev/sdb1 encrypted?  Usually this is done with something like dm-crypt.
> >>>>> Or is it hardware encryption managed in the bios?  Did you unlock it?
> >>>>
> >>>> Done with crytpsetup using luks.
> >>>>
> >>>>>
> >>>>> What does "blkid /dev/sdb1" say?
> >>>>>
> >>>>
> >>>> It says Luks.
> >>>
> >>> and not ext4 - so you need to unlock it via mumblemumbleLuksStuffmumblemumble
> >>> before you can operate on it with e2fsprogs tools.
> >>>
> >>> # cryptsetup luksOpen /dev/sdb1 <name>... or something.  Sorry, I'm not a LUKS
> >>> expert...
> >>>
> >>> Anyway, not an ext4 problem.  Your superblock isn't corrupted, it's encrypted.  :)
> >>>
> >>> -Eric
> >>>
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Corrupted superblock? But disk still mounts.

[Eric Sandeen]

On 8/22/14, 12:19 PM, Darrick J. Wong wrote:
> On Fri, Aug 22, 2014 at 05:40:02PM +0100, Mark Ballard wrote:
>> No, Eric. I can see it's accurate in its own context. I mean accurate
>> in relaying enough information to convey the situation accurately to
>> the user. That requires something like e2label to see a wider context,
>> and I can see that might actually be an unreasonable expectation. But
>> this is what I was getting at: information accurate enough to allow
>> non-educated users to get an instant grip of the environment when they
>> are forced to go delving under the bonnet (hood) of their computer.
>> None of the os componenets were made -- or documented -- with that
>> sort of user in mind: someone with less time and experience than is
>> really required to work efficiently under there. Yet the application
>> environment is such a tangle that users are left with little choice
>> but to get their hands dirty. And when you look under there, you see
>> that it was made by Heath Robinson but that the drawings were burned
>> in a fire.
> 
> Perhaps just use a little bit of libmagic to spit out what we might be looking
> at if the ext4 sb looks wrong?
> 
> # dumpe2fs -h /dev/sda2
> dumpe2fs 1.42.11 (09-Jul-2014)
> dumpe2fs: Bad magic number in super-block while trying to open /dev/sda
> Couldn't find valid filesystem superblock:
> /dev/sda2: LUKS encrypted file, ver 1 [aes, xts-plain64, sha1] UUID: <snip>

yeah, that's ... what I did, and showed, in my previous email.  ;)

this isn't great because it uses util.o in new places, and that's tough
to do from resize2fs/* etc, but anyway, here's the hack.

I could see how this could be useful (and your more verbose suggestion
above is probably better)


diff --git a/misc/Makefile.in b/misc/Makefile.in
index d3c8f5b..e779ee9 100644
--- a/misc/Makefile.in
+++ b/misc/Makefile.in
@@ -48,9 +48,9 @@ CHATTR_OBJS=	chattr.o
 LSATTR_OBJS=	lsattr.o
 UUIDGEN_OBJS=	uuidgen.o
 UUIDD_OBJS=	uuidd.o
-DUMPE2FS_OBJS=	dumpe2fs.o
+DUMPE2FS_OBJS=	dumpe2fs.o util.o
 BADBLOCKS_OBJS=	badblocks.o
-E2IMAGE_OBJS=	e2image.o
+E2IMAGE_OBJS=	e2image.o util.o
 FSCK_OBJS=	fsck.o base_device.o ismounted.o
 BLKID_OBJS=	blkid.o
 FILEFRAG_OBJS=	filefrag.o
@@ -198,12 +198,13 @@ blkid.profiled: $(BLKID_OBJS) $(DEPPROFILED_LIBBLKID) \
 e2image: $(E2IMAGE_OBJS) $(DEPLIBS)
 	$(E) "	LD $@"
 	$(Q) $(CC) $(ALL_LDFLAGS) -o e2image $(E2IMAGE_OBJS) $(LIBS) \
-		$(LIBINTL) $(SYSLIBS)
+		$(LIBBLKID) $(LIBINTL) $(SYSLIBS)
 
 e2image.profiled: $(E2IMAGE_OBJS) $(PROFILED_DEPLIBS)
 	$(E) "	LD $@"
 	$(Q) $(CC) $(ALL_LDFLAGS) -g -pg -o e2image.profiled \
-		$(PROFILED_E2IMAGE_OBJS) $(PROFILED_LIBS) $(LIBINTL) $(SYSLIBS)
+		$(PROFILED_E2IMAGE_OBJS) $(PROFILED_LIBS) $(LIBINTL) $(SYSLIBS) \
+		$(PROFILED_LIBBLKID)
 
 e2undo: $(E2UNDO_OBJS) $(DEPLIBS)
 	$(E) "	LD $@"
@@ -296,13 +297,13 @@ uuidd.profiled: $(UUIDD_OBJS) $(PROFILED_DEPLIBUUID)
 dumpe2fs: $(DUMPE2FS_OBJS) $(DEPLIBS) $(DEPLIBS_E2P) $(DEPLIBUUID)
 	$(E) "	LD $@"
 	$(Q) $(CC) $(ALL_LDFLAGS) -o dumpe2fs $(DUMPE2FS_OBJS) $(LIBS) \
-		$(LIBS_E2P) $(LIBUUID) $(LIBINTL) $(SYSLIBS)
+		$(LIBS_E2P) $(LIBBLKID) $(LIBUUID) $(LIBINTL) $(SYSLIBS)
 
 dumpe2fs.profiled: $(DUMPE2FS_OBJS) $(PROFILED_DEPLIBS) \
 		$(PROFILED_LIBE2P) $(PROFILED_DEPLIBUUID)
 	$(E) "	LD $@"
 	$(Q) $(CC) $(ALL_LDFLAGS) -g -pg -o dumpe2fs.profiled \
-		$(PROFILED_DUMPE2FS_OBJS) $(PROFILED_LIBS) \
+		$(PROFILED_DUMPE2FS_OBJS) $(PROFILED_LIBS) $(PROFILED_LIBBLKID) \
 		$(PROFILED_LIBE2P) $(PROFILED_LIBUUID) $(LIBINTL) $(SYSLIBS)
 
 fsck: $(FSCK_OBJS) $(DEPLIBBLKID)


diff --git a/misc/dumpe2fs.c b/misc/dumpe2fs.c
index 0b84ece..d11fe4d 100644
--- a/misc/dumpe2fs.c
+++ b/misc/dumpe2fs.c
@@ -38,6 +38,7 @@ extern int optind;
 #include "ext2fs/ext2fs.h"
 #include "e2p/e2p.h"
 #include "jfs_user.h"
+#include "util.h"
 #include <uuid/uuid.h>
 
 #include "../version.h"
@@ -50,6 +51,9 @@ static char * device_name = NULL;
 static int hex_format = 0;
 static int blocks64 = 0;
 
+int journal_size, journal_flags;		/* BLEAH!  BOO util.c!  */
+char *journal_device;
+
 static void usage(void)
 {
 	fprintf (stderr, _("Usage: %s [-bfhixV] [-o superblock=<num>] "
@@ -639,6 +643,7 @@ int main (int argc, char ** argv)
 		com_err (program_name, retval, _("while trying to open %s"),
 			 device_name);
 		printf("%s", _("Couldn't find valid filesystem superblock.\n"));
+		check_plausibility(device_name, CHECK_FS_EXIST, NULL);
 		exit (1);
 	}
 	fs->default_bitmap_type = EXT2FS_BMAP64_RBTREE;
diff --git a/misc/e2image.c b/misc/e2image.c
index e1c63a7..f84b937 100644
--- a/misc/e2image.c
+++ b/misc/e2image.c
@@ -44,6 +44,7 @@ extern int optind;
 #include "e2p/e2p.h"
 #include "ext2fs/e2image.h"
 #include "ext2fs/qcow2.h"
+#include "util.h"
 
 #include "../version.h"
 #include "nls-enable.h"
@@ -72,6 +73,8 @@ static char move_mode;
 static char show_progress;
 static char *check_buf;
 static int skipped_blocks;
+int journal_size, journal_flags;		/* BLEAH!  BOO util.c!  */
+char *journal_device;
 
 static blk64_t align_offset(blk64_t offset, unsigned int n)
 {
@@ -1578,6 +1581,7 @@ int main (int argc, char ** argv)
 		com_err (program_name, retval, _("while trying to open %s"),
 			 device_name);
 		fputs(_("Couldn't find valid filesystem superblock.\n"), stdout);
+		check_plausibility(device_name, CHECK_FS_EXIST, NULL);
 		exit(1);
 	}
 
diff --git a/misc/tune2fs.c b/misc/tune2fs.c
index 5aaea5e..c188182 100644
--- a/misc/tune2fs.c
+++ b/misc/tune2fs.c
@@ -2560,9 +2560,11 @@ retry_open:
 			fprintf(stderr,
 				_("MMP block magic is bad. Try to fix it by "
 				  "running:\n'e2fsck -f %s'\n"), device_name);
-		else if (retval != EXT2_ET_MMP_FAILED)
+		else if (retval != EXT2_ET_MMP_FAILED) {
 			fprintf(stderr, "%s",
 			     _("Couldn't find valid filesystem superblock.\n"));
+			check_plausibility(device_name, CHECK_FS_EXIST, NULL);
+		}
 
 		ext2fs_free(fs);
 		exit(1);

Re: Corrupted superblock? But disk still mounts.

[Eric Sandeen]

On 8/22/14, 11:40 AM, Mark Ballard wrote:
> No, Eric. I can see it's accurate in its own context. I mean accurate
> in relaying enough information to convey the situation accurately to
> the user. That requires something like e2label to see a wider context,

so saying something like:

"invalid superblock.  This is an xfs filesystem."

isn't sufficient?  And here I thought that was a great idea ;)

I'm not sure how much further we could reasonably go in error messages...

At some point we have to assume some degree of administrative skill and
familiarity...

-Eric

> and I can see that might actually be an unreasonable expectation. But
> this is what I was getting at: information accurate enough to allow
> non-educated users to get an instant grip of the environment when they
> are forced to go delving under the bonnet (hood) of their computer.
> None of the os componenets were made -- or documented -- with that
> sort of user in mind: someone with less time and experience than is
> really required to work efficiently under there. Yet the application
> environment is such a tangle that users are left with little choice
> but to get their hands dirty. And when you look under there, you see
> that it was made by Heath Robinson but that the drawings were burned
> in a fire.
> 
> On 22 August 2014 17:09, Eric Sandeen <sandeen@redhat.com> wrote:
>> On 8/22/14, 9:19 AM, Mark Ballard wrote:
>>> Ya. It did look that way. 'Scuse me for not checking first.
>>>
>>> But my point is that it may still be a problem for ext4, dumpe2fs,
>>> e2fsck, fsck and presumably gparted and so on.
>>>
>>> That is, would it not be polite of them to report the error ...<drum
>>> roll>... accurately?
>>
>> Ah, I see.  So you don't like "corrupted" - you'd like to know that it's
>> something else perfectly valid, just not the thing you were looking for.
>>
>> Maybe like:
>>
>> # misc/dumpe2fs /dev/sdc1
>> dumpe2fs 1.43-WIP (09-Jul-2014)
>> misc/dumpe2fs: Superblock checksum does not match superblock while trying to open /dev/sdc1
>> Couldn't find valid filesystem superblock.
>> /dev/sdc1 contains a xfs file system
>>
>>
>> # misc/dumpe2fs /dev/sdc
>> dumpe2fs 1.43-WIP (09-Jul-2014)
>> misc/dumpe2fs: Superblock checksum does not match superblock while trying to open /dev/sdc
>> Couldn't find valid filesystem superblock.
>> /dev/sdc is entire device, not just one partition!
>>
>> -Eric
>>
>>> (No irony intended.)
>>>
>>>
>>> On 19 August 2014 15:36, Eric Sandeen <sandeen@redhat.com> wrote:
>>>> On 8/18/14, 3:23 PM, Mark Ballard wrote:
>>>>>> I'm guessing that it's the encryption getting in your way.
>>>>>
>>>>> Cheers, Eric. Does rather look that way. But for the sake of a user report...
>>>>>
>>>>>>
>>>>>> How is /dev/sdb1 encrypted?  Usually this is done with something like dm-crypt.
>>>>>> Or is it hardware encryption managed in the bios?  Did you unlock it?
>>>>>
>>>>> Done with crytpsetup using luks.
>>>>>
>>>>>>
>>>>>> What does "blkid /dev/sdb1" say?
>>>>>>
>>>>>
>>>>> It says Luks.
>>>>
>>>> and not ext4 - so you need to unlock it via mumblemumbleLuksStuffmumblemumble
>>>> before you can operate on it with e2fsprogs tools.
>>>>
>>>> # cryptsetup luksOpen /dev/sdb1 <name>... or something.  Sorry, I'm not a LUKS
>>>> expert...
>>>>
>>>> Anyway, not an ext4 problem.  Your superblock isn't corrupted, it's encrypted.  :)
>>>>
>>>> -Eric
>>>>
>>

Re: Corrupted superblock? But disk still mounts.

[Mark Ballard]

On 22 August 2014 18:20, Eric Sandeen <sandeen@redhat.com> wrote:
> On 8/22/14, 11:40 AM, Mark Ballard wrote:
>> No, Eric. I can see it's accurate in its own context. I mean accurate
>> in relaying enough information to convey the situation accurately to
>> the user. That requires something like e2label to see a wider context,
>
> so saying something like:
>
> "invalid superblock.  This is an xfs filesystem."
>
> isn't sufficient?  And here I thought that was a great idea ;)
>
> I'm not sure how much further we could reasonably go in error messages...
>
> At some point we have to assume some degree of administrative skill and
> familiarity...

Yes and there's no accounting for the stubborn incontinence of a user
making indignant forays under the bonnet.

It did seem reasonable to me for a moment that these disk utilities
would say, e.g. ... can't operate on encrypted file system'. But I see
how that might not be a reasonable expectation.

The alternative is that users have to think. That's a big ask!-) ...
They've got other things to think about.

Mark.

>
> -Eric
>
>> and I can see that might actually be an unreasonable expectation. But
>> this is what I was getting at: information accurate enough to allow
>> non-educated users to get an instant grip of the environment when they
>> are forced to go delving under the bonnet (hood) of their computer.
>> None of the os componenets were made -- or documented -- with that
>> sort of user in mind: someone with less time and experience than is
>> really required to work efficiently under there. Yet the application
>> environment is such a tangle that users are left with little choice
>> but to get their hands dirty. And when you look under there, you see
>> that it was made by Heath Robinson but that the drawings were burned
>> in a fire.
>>
>> On 22 August 2014 17:09, Eric Sandeen <sandeen@redhat.com> wrote:
>>> On 8/22/14, 9:19 AM, Mark Ballard wrote:
>>>> Ya. It did look that way. 'Scuse me for not checking first.
>>>>
>>>> But my point is that it may still be a problem for ext4, dumpe2fs,
>>>> e2fsck, fsck and presumably gparted and so on.
>>>>
>>>> That is, would it not be polite of them to report the error ...<drum
>>>> roll>... accurately?
>>>
>>> Ah, I see.  So you don't like "corrupted" - you'd like to know that it's
>>> something else perfectly valid, just not the thing you were looking for.
>>>
>>> Maybe like:
>>>
>>> # misc/dumpe2fs /dev/sdc1
>>> dumpe2fs 1.43-WIP (09-Jul-2014)
>>> misc/dumpe2fs: Superblock checksum does not match superblock while trying to open /dev/sdc1
>>> Couldn't find valid filesystem superblock.
>>> /dev/sdc1 contains a xfs file system
>>>
>>>
>>> # misc/dumpe2fs /dev/sdc
>>> dumpe2fs 1.43-WIP (09-Jul-2014)
>>> misc/dumpe2fs: Superblock checksum does not match superblock while trying to open /dev/sdc
>>> Couldn't find valid filesystem superblock.
>>> /dev/sdc is entire device, not just one partition!
>>>
>>> -Eric
>>>
>>>> (No irony intended.)
>>>>
>>>>
>>>> On 19 August 2014 15:36, Eric Sandeen <sandeen@redhat.com> wrote:
>>>>> On 8/18/14, 3:23 PM, Mark Ballard wrote:
>>>>>>> I'm guessing that it's the encryption getting in your way.
>>>>>>
>>>>>> Cheers, Eric. Does rather look that way. But for the sake of a user report...
>>>>>>
>>>>>>>
>>>>>>> How is /dev/sdb1 encrypted?  Usually this is done with something like dm-crypt.
>>>>>>> Or is it hardware encryption managed in the bios?  Did you unlock it?
>>>>>>
>>>>>> Done with crytpsetup using luks.
>>>>>>
>>>>>>>
>>>>>>> What does "blkid /dev/sdb1" say?
>>>>>>>
>>>>>>
>>>>>> It says Luks.
>>>>>
>>>>> and not ext4 - so you need to unlock it via mumblemumbleLuksStuffmumblemumble
>>>>> before you can operate on it with e2fsprogs tools.
>>>>>
>>>>> # cryptsetup luksOpen /dev/sdb1 <name>... or something.  Sorry, I'm not a LUKS
>>>>> expert...
>>>>>
>>>>> Anyway, not an ext4 problem.  Your superblock isn't corrupted, it's encrypted.  :)
>>>>>
>>>>> -Eric
>>>>>
>>>
>