On 22 August 2014 18:20, Eric Sandeen <sandeen@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
