vfat fs without partition fails to mount
|Status:||Closed||Start date:||28 Jun 2015|
|Category:||09 - Testing|
|Severity:||01 - Critical|
I had multiple sticks plugged into the media server during its first field trial. I had problems moving through the video titles on the server. Pulling them out one at a time I finally found one stick that seemed to be causing the problem. But I don't as yet know what that problem is.
#1 Updated by Hammel almost 6 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
Retested at home. Turned out to be the 128MB stick. The other two sticks are 32MB and worked fine together.
I don't yet know what the problem is with the 128MB stick but I did notice it didn't seem to get auto-mounted by blockhandler.sh via mdev. Either the partition is bad or it isn't a supported device file or something. When I plug it in I don't see the kernel recognizing the partition.
#2 Updated by Hammel over 5 years ago
- % Done changed from 10 to 70
Duh. The 128GB stick had the following directory tree:
./... tv avi3
The tv tree has TV episodes, which don't yet work with VideoLib. The avi3 tree didn't have a database. So that's one reason why that stick didn't work. Created avi3's db.
Another problem is that there is no partition table on the stick, just a VFAT file system. I can mount that manually.
For this stick I need to backup the contents, recreate the partition table and filesystem and add the data back on.
For the bigger problem: I need to identify when this happens in blockhandler.sh and act accordingly.
#3 Updated by Hammel over 5 years ago
- Subject changed from Multiple USB sticks don't work to vfat fs without partition fails to mount
One way to check for this in blockhandler.sh is to run blkid on the device before checking the partition. If blkid <dev> shows a vfat partition then mount the device directory. If not, look for partitions in the partition table.
Essentially this is a Windows'ism that I have to work around because end users will probably come from that realm. Now sure what happens with a USB stick stuck in a Mac box will do.
#6 Updated by Hammel over 5 years ago
Looks like blockhandler just needed to test DEVPATH for an empty string. If it wasn't empty, do the old thing. If it is, try to add it using REALDEV.
With this change if you unplug and plug in the USB stick blockhandler sees the DEVPATH and the code path followed is correct for that case now. The difference is what happens on boot. Now, at boot, there is no DEVPATH so the old path is skipped (which tried to handle an mmc mount) and the updated path is the same as the case for plugging in the new stick.
Seems to work. The stick is mounted on reboot and on insertion. Testing other sticks to see that they still work.