Unable to mount USB Flash memory created on CentOS

[Polytropon]

On Mon, 31 Jul 2017 11:49:52 -0400, James B. Byrne wrote:
> When I try to verify the flash drives I see this:
> 
> # e2fsck /dev/da1
> e2fsck 1.43.4 (31-Jan-2017)
> 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/da1
> . . .
> 
> So I redid the command using the partition values instead:

Fully correct. You need to specify the "thing" that holds the
ext2 file system, in this case, a partition (slice).



> # e2fsck /dev/da0s1
> e2fsck 1.43.4 (31-Jan-2017)
> CA_HLL_2016_BKUP has gone 267 days without being checked, check forced.
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> Error writing file system info: Invalid argument
> 
> CA_HLL_2016_BKUP: ***** FILE SYSTEM WAS MODIFIED *****
> 
> However, the device remains unmountable in Mate.

Why "however"? The file system hasn't been repaired, and that's
why it cannot be mounted. I think there should have been an
additional message saying something like "file system still
dirty, re-run fsck".

But I _highly_ recommend using a Linux _native_ fsck program,
maybe even from a live system CD, DVD, or USB stick. The ext2
tools on FreeBSD aren't that advanced or "stable" that I would
trust them with lower-level file system repairs.

After the file system has been repaired _and_ marked clean,
you should be able to mount it. Do _not_ expect it to work in
the current inconsistent state.



> This issue is not critical as I am able to manually mount both devices
> and have successfully moved their contents onto new media.  But I do
> find it annoying that Mate, or whatever process caused the initial
> problem, was able to create the problem and yet there is no
> self-evident way of correcting whatever injury was done to the
> filesystems.

I think the automounter buried within the desktop system is
responsible here, but there is no way to really be sure.



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...