[SOLVED] Sharing ext4 file system between Cromebook and Linux

jeenuv · 12-23-2018, 06:45 AM

I've recently come across some weirdness regarding ext4 file system. This involves a Chromebook and a Linux host, but are essentially Linux systems.

A single ext4 partition was created on a USB drive from a Chrombook (via. chrosh). The Chromebook does recognize the drive when plugged in, is able to read and write etc. - the usual stuff.

However, if were to plug that drive into a Linux machine, mount, and read/write some files, ejects, then then plug that back into Chromebook (some file sharing, essentially), the Chromebook no more recognizes the drive. Not only would it not auto mount, but will print this error when I try to mount it via chrosh:

Code:

mount: /media/removable/foo: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error.

The weird thing is that the file system is not corrupted nor ivnalid - I can continue to use the drive on a Linux machine, but not on Chromebook. Even weirder, this doesn't happen with ext3.

I've tried it with multiple USB drives, so can't be a problem with the drive itself.

So I guess my question is: how could normal file system operations from a different host turn the disk unusable on a Chromebook?

Happy to provide more info if required. Thanks in advance.

smallpond · 12-23-2018, 07:01 AM

Sounds like a good chance for some detective work. After making a USB on Chrome, copy it to a second one. Write a file using "echo Hello > /mnt/USB" on each system and compare the differences between the two superblocks using tune2fs and cmp. Post the results back here.

Edit: seems there is a recent report of fs corruption in the 4.19 kernel. What are you running?

rknichols · 12-23-2018, 08:39 AM

Perhaps there is some ext4 feature that is causing the problem if it is actually used. Run

Code:

tune2fs -l /dev/{X} | grep -E 'features|flags'

(with the appropriate substitution for "{X}") with the newly created filesystem, and then again with the filesystem in a state that the Chromebook will not accept.

pan64 · 12-23-2018, 09:04 AM

Yes, it looks like a filesystem driver problem. Is there any other way (= other host) to check this drive?

jeenuv · 12-23-2018, 10:52 AM

Thanks for your replies. I've done some comparisons on the output of dumpe2fs: when Chromebook is happy to mount the drive, the Journal features shows "(none)". When I mount the drive on my Linux laptop, it seem to amend these features to "journal_64bit journal_checksum_v3". With these journal features, Chromebook no more accepts or mounts the FS when I plug it back.

I ran fsck on the partition just after Chrombook refused, and it displayed clean, so I don't think it's corrupting anything.

Besides, when I format the partition as ext3, the journal features remains on both machines as "(none)".

Do you think the Linux host modifying the journal features could be the problem? I don't see any differences in the dump otherwise, other than super block sizes, check sums, and last mounted paths.

smallpond · 12-23-2018, 11:24 AM

Normally, the superblock format would not be modified after the FS is created, but due to a bug in the V2 checksum, it automatically gets updated to V3. The change is described here:

https://github.com/endlessm/linux-me...c95abc7caee365

I guess Chrome doesn't have this fix.

jeenuv · 12-23-2018, 11:34 AM

FWIW, the Chrome book says that it's 3.8.11, and my Linux host, 4.15.0. Given it's the only difference between dumps, and that the Chrome kernel is rather old, maybe this is the problem indeed. I'll stick to ext3 for now.

I'll mark this thread as solved, then. Thanks for your help!