Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flash drive won't mount? #20

Closed
Plut0nio opened this issue Jul 17, 2020 · 12 comments
Closed

Flash drive won't mount? #20

Plut0nio opened this issue Jul 17, 2020 · 12 comments

Comments

@Plut0nio
Copy link

I'm trying to get this software to work properly with my Pi 3 Model B+ and a PNY 64 GB USB 3.0 flash drive so I can play games off the flash drive using OPL (ver. 1815) on my slim PS2. However, for whatever reason, the flash drive doesn't appear to get mounted. I found this out after browsing the share folder through SMB and then browsing the same folder directly on the Pi's microSD card plugged into my laptop. In both those cases, the DVD and CD folders were empty while the ART folder contained files for Tobal 2 and X - Unmei No Sentaku. On my flash drive, the DVD and CD folders contain 20 ISOs and 1 ISO respectively, while the ART folder contains the art for all those games. My Pi detects the flash drive as a USB device, as lsusb returns Bus 001 Device 006: ID 154b:00d2 PNY, but for some reason, the microSD card's share folder is shared instead. Why is this happening? I've tried all 3 formats compatible with Windows so far for my flash drive: FAT32, NTFS, and exFAT. Thanks.

@toolboc
Copy link
Owner

toolboc commented Jul 17, 2020

The first suspicion that comes to mind is general incompatibility of some USB drives. Are you able to manually mount the drive using instructors mentioned here?

Another thing to consider is whether the power supply is able to provide enough voltage for the USB drive and the pi. This post provides a few ways to diagnose if your pi is operating under low voltage.

@Plut0nio
Copy link
Author

The first suspicion that comes to mind is general incompatibility of some USB drives. Are you able to manually mount the drive using instructors mentioned here?

Another thing to consider is whether the power supply is able to provide enough voltage for the USB drive and the pi. This post provides a few ways to diagnose if your pi is operating under low voltage.

I am using a 2.5 amp power supply, so I don't think that power delivery is an issue here. I am able to manually mount the drive and share it's contents through SMB. Pretty sure that the problem is that the drive isn't being automatically mounted on boot for whatever reason. Therefore, it falls back to the share directory on the microSD card. I don't want to have to configure this manually through SSH every time I turn on the Pi. I tried this method for mounting the flash drive permanently, but it broke the installation and I had to re-write the image to the card to get it working again.

@toolboc
Copy link
Owner

toolboc commented Jul 17, 2020

Since the issue is specific to the drive you are using, it's a bit difficult to diagnose on the other side. The mechanism for auto-mounting USB drives is contained here, it may be possible to modify this to work with your device. Does the drive auto-mount if you hot-plug it after booting? Have you tried using a different USB drive to see if the issue still exists?

@Plut0nio
Copy link
Author

I tried a 32 GB Kingston USB 2.0 flash drive, and if I remember correctly, the Pi was actually able to mount it to a directory, but the SMB share was still set to the directory on the microSD card instead. Hot-plugging didn't seem to work with the 64 GB flash drive when I first tried doing that, but I'll try doing it again when I get home, but this time, I'll try to look closer at what's going on in the SSH terminal. I'll also try hot-plugging with the 32 GB drive.

It should also be noted that a year or two ago, I tried using my same Pi with the same 64 GB drive (formatted to NTFS) to play games through Ethernet on my slim PS2 with OPL by installing and configuring OpenMediaVault on my Pi according to this tutorial, and it actually worked. I was able to view, boot, and play games off the flash drive on my Pi wired to my PS2 through Ethernet. So this might be an issue with how psx-pi-smdshare handles certain flash drives compared to OpenMediaVault.

@toolboc
Copy link
Owner

toolboc commented Jul 17, 2020

I've verified with a generic USB stick and latest image release that the auto-mounting / sharing feature is working as intended on my end, but am curious as to why this would not work with either of your Kingston flash drives.

First a brief overview of how automount-usb.sh works:

The automount-usb.sh script is ran one time during execution of setup.sh. After this initial run, it will install ntfs-3g for NTFS filesystem support in addition to pmount for USB hot plug support. After this, two systemd rules are created which direct the OS to run a handler script when a USB disk is inserted and removed from the USB port. On insertion, a script located at usr/local/bin/automount.sh will execute, essentially this script will perform the initial mounting of the drive via pmount, then recreate the samba share to point to this new mount point. When a drive is removed, it will trigger the execution of /usr/local/bin/samba-init.sh, this has an effect of defaulting back to sharing from the internal SD card.

Now we can look at ways to diagnose these mechanism with your USB drives:

When you plug in your USB drive, it should be mounted to a path at /media/sd*1 (The value of * will depend on the character assigned to the drive by the OS). You can verify this by listing directory contents of /media/sd*1. If you see this, it confirms that the drive was successfully mounted by the systemd insertion handler via pmount. If this fails, we need to look at why pmount is failing to mount the drive, the command in question would be the following: runuser pi -s /bin/bash -c "/usr/bin/pmount --umask 000 --noatime -w --sync /dev/${PART} /media/${PART}". Where ${PART} is the name of the drive as it exists in /dev i.e. sd*1.

If the mounting of the drive is successful, but you still do not see the drive over SMB, then we need to look at the recreated samba share point. The recreated share point will still be served over SMB at a path named share but instead of mounting from the SD card path, it will mount using the path that was created by pmount when the drive was inserted. To diagnose this, take a look at /etc/samba/smb.conf after plugging in the USB drive and verify that Path = /media/$PART. Where $PART is the name of the drive as it exists in /dev i.e. sd*1.

If you have verified both of these mechanisms to be successful, you should be able to see the contents of your USB drive are now served at the SMB path //SMBSHARE/share.

@toolboc
Copy link
Owner

toolboc commented Jul 17, 2020

While testing, I did notice that USB drives do not automatically get shared on boot. This is because a crontab entry is created which essentially falls back to sharing the SD on boot. Ideally, if a USB drive is plugged in on boot, we should share the USB drive and not the SD. This has been addressed in d49fda3. I have published an updated release containing this fix.

@Plut0nio
Copy link
Author

Plut0nio commented Jul 17, 2020

I updated my psx-pi-smbshare installation. My 32 GB Kingston USB 2.0 flash drive now gets automatically mounted and shared every time it gets plugged in. My 64 GB PNY USB 3.0 flash drive, however, doesn't. I have to mount the 64 GB drive to (for example) /media/usb manually, then set that as the value of the Path variable in /etc/samba/smb.conf manually, and finally restart Samba (sudo service smbd restart) to get it to share the contents of the drive.

I'm not sure why my 64 GB drive isn't being mounted automatically, and I'm not sure how I can troubleshoot this. Should I just straight up run the command runuser pi -s /bin/bash -c "/usr/bin/pmount --umask 000 --noatime -w --sync /dev/${PART} /media/${PART}" with the 64 GB drive plugged in and see what happens?

Below are the outputs of different disk info-related commands for both my flash drives. Hopefully, these will be useful for debugging. Thanks.

Kingston 32 GB (works fine)

lsblk

NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdf           8:80   1 28.9G  0 disk
└─sdf1        8:81   1 28.9G  0 part /media/sdf1
mmcblk0     179:0    0 14.9G  0 disk
├─mmcblk0p1 179:1    0 43.1M  0 part /boot
└─mmcblk0p2 179:2    0 14.8G  0 part /

sudo blkid

/dev/mmcblk0p1: LABEL="boot" UUID="A365-6756" TYPE="vfat" PARTUUID="282a0537-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="90a83158-560d-48ee-9de9-40c51d93c287" TYPE="ext4" PARTUUID="282a0537-02"
/dev/mmcblk0: PTUUID="282a0537" PTTYPE="dos"
/dev/sdf1: LABEL="NEW VOLUME" UUID="4631-D11F" TYPE="vfat" PARTLABEL="Basic data partition" PARTUUID="2d2538b1-a216-4eaa-bac6-904ea3fe0371"

sudo fdisk -l

Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram1: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram2: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram3: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram4: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram5: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram6: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram7: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram8: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram9: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram10: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram11: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram12: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram13: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram14: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram15: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/mmcblk0: 14.9 GiB, 15931539456 bytes, 31116288 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x282a0537

Device         Boot Start      End  Sectors  Size Id Type
/dev/mmcblk0p1       8192    96453    88262 43.1M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      98304 31116287 31017984 14.8G 83 Linux


Disk /dev/sdf: 28.9 GiB, 31001149440 bytes, 60549120 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 6537B96A-5706-4153-BCA0-00FED9036840

Device     Start      End  Sectors  Size Type
/dev/sdf1   2048 60547071 60545024 28.9G Microsoft basic data

PNY 64 GB (does NOT automatically mount)

lsblk

NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdg           8:96   1 59.1G  0 disk
mmcblk0     179:0    0 14.9G  0 disk
├─mmcblk0p1 179:1    0 43.1M  0 part /boot
└─mmcblk0p2 179:2    0 14.8G  0 part /

sudo blkid

/dev/mmcblk0p1: LABEL="boot" UUID="A365-6756" TYPE="vfat" PARTUUID="282a0537-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="90a83158-560d-48ee-9de9-40c51d93c287" TYPE="ext4" PARTUUID="282a0537-02"
/dev/mmcblk0: PTUUID="282a0537" PTTYPE="dos"
/dev/sdg: LABEL="PS2 PI" UUID="A663-F44E" TYPE="exfat"

sudo fdisk -l

Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram1: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram2: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram3: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram4: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram5: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram6: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram7: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram8: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram9: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram10: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram11: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram12: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram13: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram14: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram15: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/mmcblk0: 14.9 GiB, 15931539456 bytes, 31116288 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x282a0537

Device         Boot Start      End  Sectors  Size Id Type
/dev/mmcblk0p1       8192    96453    88262 43.1M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      98304 31116287 31017984 14.8G 83 Linux


Disk /dev/sdg: 59.1 GiB, 63484985344 bytes, 123994112 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot      Start        End    Sectors  Size Id Type
/dev/sdg1       4294967295 8589934589 4294967295    2T ff BBT
/dev/sdg2       4294967295 8589934589 4294967295    2T ff BBT
/dev/sdg3       4294967295 8589934589 4294967295    2T ff BBT
/dev/sdg4       4294967295 6854241533 2559274239  1.2T ff BBT

@toolboc
Copy link
Owner

toolboc commented Jul 17, 2020

@Plut0nio,

I'm glad to hear the 32GB disk is working!

Thanks a ton for providing detailed debug info, at first glance I noticed that when looking at the output of fdisk -l for the 32GB and 64GB disks, that something looks off.

The 32GB disk is recognized as gpt with a vfat filesystem and a single partition at (/dev/sdf1)

Disk /dev/sdf: 28.9 GiB, 31001149440 bytes, 60549120 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 6537B96A-5706-4153-BCA0-00FED9036840

Device     Start      End  Sectors  Size Type
/dev/sdf1   2048 60547071 60545024 28.9G Microsoft basic data

The 64GB disk is recognized as dos (MBR) with a BBT filesystem and four partitions at (/dev/sdg1, /dev/sdg2, /dev/sdg3, and /dev/sdg4 ) with enormous sizes (2T!?)

Disk /dev/sdg: 59.1 GiB, 63484985344 bytes, 123994112 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot      Start        End    Sectors  Size Id Type
/dev/sdg1       4294967295 8589934589 4294967295    2T ff BBT
/dev/sdg2       4294967295 8589934589 4294967295    2T ff BBT
/dev/sdg3       4294967295 8589934589 4294967295    2T ff BBT
/dev/sdg4       4294967295 6854241533 2559274239  1.2T ff BBT

This makes me wonder if this drive would report the same result with a stock Raspbian image.

Does the 64 GB disk also fail to mount when formatted with a gpt partition table? For more information on the difference between GPT and MBR see: https://www.howtogeek.com/193669/whats-the-difference-between-gpt-and-mbr-when-partitioning-a-drive

This could also be an issue with pmount. What happens when you run the following (Assuming the 64GB drive is mapped to /dev/sdg*)?
runuser pi -s /bin/bash -c "/usr/bin/pmount --umask 000 --noatime -w --sync /dev/sdg1 /media/sdg1"

After running this command, navigate to /media/sdg1 to check if the drive mounted appropriately. If this command fails, it should provide output that will give a clue as to the root cause of failure.

@Plut0nio
Copy link
Author

Shortly after I posted my disk command outputs, I decided to reformat my 64 GB drive from MBR exFAT to GPT exFAT (my 32 GB drive was already GPT, so I left that drive alone) to see if it that would make it work. And lo and behold, my 64 GB drive was finally automatically mounted and shared by the Pi! Thank you very much for the help. I might try fooling around with an MBR-formatted flash drive and seeing what happens if I try to mount it with that runuser command, but I'm just glad that this finally works.

@toolboc
Copy link
Owner

toolboc commented Jul 18, 2020

Huge congrats! Thanks for working with me together on this, no doubt others will find this info useful and major props on uncovering the issue of automount not working on boot.

Glad everything is working, going to close the issue. Feel free to reopen the issue if tests prove anything of interest.

@toolboc toolboc closed this as completed Jul 18, 2020
@VersatileNinja
Copy link

Very curious what was the root cause for this particular issue. I happen to use a 8gb usb 2.0 corsair flash drive and my raspberry pi never had an issue detecting it for my ps2 games during testing. It is FAT32 and MBR partition style.

Very glad this issue got fixed, as I recommended to op to make a github ticket. :)

@toolboc
Copy link
Owner

toolboc commented Jul 18, 2020

Thanks for suggesting the idea to OP to create the issue @VersatileNinja. This project aims to be user-friendly + issue-free and you’ve been a great contributor to the cause.

If I had to guess, the root cause is either some odd combination of MBR with an unsupported filesystem OR a temporarily corrupted drive given the weird output from ‘lsusb-l’.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants