Unable to mount USB Flash memory created on CentOS

Polytropon freebsd at edvax.de
Mon Jul 31 16:00:54 UTC 2017

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
> 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.

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

More information about the freebsd-questions mailing list