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.

Sign up for GitHub

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

Jump to bottom

USB drive is not accessible by Dashcam #207

Open
myzar472 opened this issue Aug 30, 2019 · 42 comments
Open

USB drive is not accessible by Dashcam #207

myzar472 opened this issue Aug 30, 2019 · 42 comments

Comments

@myzar472
Copy link

Running the latest marcone/teslausb release on a M3 running v9.0 (2019.32 9d0d19a). This is a fairly new update that I received this week.

Since the update to 2019.32, I keep getting a USB drive is not accessible by Dashcam error message. It says to Reformat the drive to a supported format.

error

When this happens, a red exclamation mark appears on the top right and the recording icon turns white with a small X. Unplugging and re-plugging fixes the issue, but it repeats after a few minutes of being plugged in.

top

Logs are attached.
diagnostics.txt
@raushel
Copy link

raushel commented Aug 30, 2019 •
edited

I started getting this on .32 as well on my model 3. I might have 3 Sentry events, but come back to the car with the error message and only one folder created on the Pi.

Restarting the pi (pulling power) and letting it restart will reconnect the drive, but the 2 recordings while it wasn’t writing are lost. Doesn’t always happen either, but 2/3 Times when I parked today (all had 1-3 sentry events).

Update: Adding my Diagnostics.txt after 3rd occurrence today (making it 3/4):
diagnostics.txt

@curiousgrge
Copy link

I'm having similar issues with .28 and 2 days ago I upgraded to most recently version using teslausb selfupdate. My message says the same except it says 'not readable' rather than accessible. And the following message about formatting is slightly differerent. Most likely same error but they changed the message for the newer firmware.

I brought this up in my message here:
#161 (comment)

This wasn't happening until I decided to upgrade teslausb. How about an option to roll back to an earlier build?

@kdvlr
Copy link

kdvlr commented Sep 3, 2019

Same here. I upgraded teslausb and I am getting hit with the same error. If I unplug and use, sometimes I get the error about USB being too slow. I use a Sandisk extreme, so I don't think the SD card speed is the issue. The USB being too slow is a Model 3 error AFAIK, it does not seem to impact the S and X.

@Phontana
Copy link

Phontana commented Sep 5, 2019 •
edited

I have the same issue since updating TeslaUSB to the latest version 2 days ago. In my Model 3 with version 2019.28.3.1 I have only seen the warning about the USB stick being too slow though.

@curiousgrge Exactly the same here. It didn't happen before I decided to update TeslaUSB.

@marcone
Copy link
Owner

marcone commented Sep 7, 2019

The setup script als runs "apt-get upgrade", so updates both the teslausb scripts and Raspbian. It would be interesting to see if starting from scratch with an older version of teslausb has the same problems (which could mean the problem is with Raspbian) or not (which could mean the problem is with the newer teslausb scripts)
I'm not sure how to go about making the script install an older version though. I'll look into that.

@Phontana
Copy link

Phontana commented Sep 7, 2019

I will try starting from scratch today and let you know what my results are.

@myzar472
Copy link
Author

myzar472 commented Sep 7, 2019

I did a scratch install using an Etcher image and the old configuration file I had. The setup file shows as finished. I'm going to leave it on overnight and see what the results will be. Keep your eyes peeled for an edit to this post.

@marcone
Copy link
Owner

marcone commented Sep 7, 2019 •
edited

There are several things that might be worth trying in order to diagnose this problem:

  • install the latest teslausb from scratch. If that fixes it then the problem is with the upgrade path.
  • use an older version of teslausb. If that fixes it then there's a problem with the latest scripts.
  • use an older version of Raspbian. If that fixes it then there's a problem with the latest Raspbian.

The following seems to work to install an older version of teslausb:

  • find which version you want to install in the list of commits and note its SHA. For example 58434ff9d44d930e9b91c8b9c2dd0560feb0d761 will install teslausb as it existed two months ago, on July 7 2019
  • in teslausb_setup_variables.conf, use that SHA as the BRANCH, e.g.
    export BRANCH=58434ff9d44d930e9b91c8b9c2dd0560feb0d761
  • start setup as usual. It will download the initial setup script at the specified version, then fail and stop.
  • ssh into the Pi, and edit /root/bin/setup-teslausb, changing the line that sets HEAD_VERSION to HEAD_VERSION=$BRANCH
  • reboot to restart/continue setup
    You should now have an older version of teslausb installed, but with an updated Raspbian.

To prevent setup from updating all the Raspbian packages, add export UPGRADE_PACKAGES=false to the teslausb_setup_variables.conf. If you start with the prebuilt image, then this should give you something close to the June 2019 version of Raspbian, though the packages that are downloaded at setup time might still be more recent versions.

You can also combine the two approaches to get an old version of teslausb on an older version of Raspbian.

@kdvlr
Copy link

kdvlr commented Sep 8, 2019

I tried an older version of teslausb on my Pi0 and it was working perfectly. I think it might be useful to have a latest and stable branch with the default as stable.

@myzar472
Copy link
Author

myzar472 commented Sep 8, 2019 •
edited

I tested 06152019 (latest release at this time) over the weekend with no issues. All I did was flash and restore my old config.

I have a gut feeling this issue may have to do with an apt dist upgrade or a RPI firmware update.

I feel like I might have done both myself in SSH. If flashing a new release to SD reverts both, then either one of the two could have caused issues. If one of the two does not revert on flashing from scratch, then whichever was reverted was likely was the culprit.

@raushel
Copy link

raushel commented Sep 8, 2019 via email

@skyred
Copy link

skyred commented Sep 9, 2019

I installed the latest version (from scratch), which was about 3 days #86 (comment) . Yesterday, I ran into the same problem, see screenshot below

IMG_20190909_085251

@Phontana
Copy link

Phontana commented Sep 9, 2019

I reinstalled from scratch 2 days ago and so far it is working as before, without issues.

@curiousgrge
Copy link

curiousgrge commented Sep 9, 2019 •
edited

I installed the latest version (from scratch), which was about 3 days #86 (comment) . Yesterday, I ran into the same problem, see screenshot below

I've had similar problem after reinstalling from scratch. Seemed to work for a few days then I would occasionally get the message. It would also not delete a previous archive as it would download it again when I could get it working.

So this time I reinstalled again and haven't quite tested it yet but here are a few things I noticed.:

Favorites are retained somehow.
Not sure if this is a rufus writing issue but after changing out my partition size again for dashcam and music, it didn't take and retained my previous size. So I deleted the associated *.bin files and for good measure *.conf files.
If you are unable to mount the CAM and MUSIC partitions through your PC, use both connectors to correct that.

@marcone Is there a simple method of mounting the music partition through Linux so I can copy my music back through the SD card reader rather than the slow USB port of the Raspberry Pi? It took me over 2.5hrs to copy music back through USB and much longer if through WiFi.

edit: Just noticed the latest commit. Will this bugfix resolve this issue? I'm not using API.

@marcone
Copy link
Owner

marcone commented Sep 9, 2019

To access the "music partition" when the card is just plugged in to a card reader, you have to first mount the /backingfiles partition, then mount the music_disk.bin disk image.

The latest commit fixes an issue introduced 2 days ago, so if you installed on Saturday or Sunday, you may want to run setup again.

@GCustom
Copy link

GCustom commented Sep 9, 2019

my selfupdate command returns "already up to date" but I updated Sunday

@marcone
Copy link
Owner

marcone commented Sep 9, 2019

selfupdate only updates the setup-teslausb script itself, and so "already up to date" only indicates that that script is already the latest version.
You generally want to run "setup-teslausb selfupdate", then run "setup-teslausb" (without the selfupdate)

@GCustom
Copy link

GCustom commented Sep 9, 2019

yes, that did the trick, thank you.

I'm looking at getting the Raspberry Pi 4, is this natively supported by this project? (I realize the last comment I saw you said you don't have one to test on)

@marcone
Copy link
Owner

marcone commented Sep 10, 2019

Not currently supported, and I don't have a way to test it, but some people are trying to get it to work: #240

@GCustom
Copy link

GCustom commented Sep 10, 2019 via email

@GCustom
Copy link

GCustom commented Sep 10, 2019 via email

@skyred
Copy link

skyred commented Sep 10, 2019

You generally want to run "setup-teslausb selfupdate", then run "setup-teslausb" (without the selfupdate)

I had the chance to do this today, and it fixed my problem above!

@skyred
Copy link

skyred commented Sep 15, 2019

Just want to provide more information about this error: I almost ran into this error every day in the past week. Mostly, I unplugged and replugged the board to the card, then the error was gone, and the board was working again. Except one time, rebooting wouldn't fix the problem, and I had to take the board back, then did "setup-teslausb selfupdate", and "setup-teslausb", which fixed the issue.

@skyred
Copy link

skyred commented Sep 16, 2019

Even though I can re-run the setup to fix the problem, my board seems never store sentry mode videos in "recent" folder, anymore.

@marcone
Copy link
Owner

marcone commented Sep 16, 2019

Sentry videos are stored in SavedClips, not RecentClips. Is that what you meant?

@skyred
Copy link

skyred commented Sep 16, 2019

Sentry videos are stored in SavedClips, not RecentClips. Is that what you meant?

Yes, I meant no video saved in "SavedClips". Also, I noticed there are many files (I don't remember the names at the moment, but they are not regular files, my guess is they are temporary files) saved at the root of the CAM drive

@marcone
Copy link
Owner

marcone commented Sep 17, 2019

Are those the "FSCK0001.REC" files? Those are files that fsck recovered. In some cases they're complete and playable files, it's just the file names are missing.

@skyred
Copy link

skyred commented Sep 17, 2019

Yes, exactly.

@marcone marcone mentioned this issue Sep 22, 2019
Closed
@dieb11
Copy link

dieb11 commented Sep 23, 2019

Hi all. Im not using a Pi, but just plugging in a USB drive straight into de jack, and I am getting this same error. The only thread I have found on the net that shows this error is this one.. I´ve tried multiple drives and all give me the same problem, and have tried the same drives on a different tesla and it work correctly. Any idea what could be happening or how I can fix it?

@txex95
Copy link

txex95 commented Sep 23, 2019

@dieb11 might be worth a call to the service center. Could be a problem with the port itself.

@Phontana
Copy link

After a few weeks the issue came back and I got the same message again. Since v10 has some Sentry Mode improvements, I went back to a traditional stick and that one hasn’t had any issue so far.

@bdoooh
Copy link

bdoooh commented Oct 13, 2019

Since V10 and a fresh install and tried multiple MicroSD cards, this issue is coming up.

@FrancoisBerg
Copy link

I have the same error message with my M3 (2019.32.12.2). (USB drive is not accessible by Dashcam) It's functionning with this version ?

@felizf
Copy link

felizf commented Oct 27, 2019

I've been lurking this thread, any fix so far?

@tkunstek
Copy link

tkunstek commented Nov 3, 2019 •
edited

I was finally able to repeat this issue. Effectively, when hooking my pi back up to USB, it mounted the music portion on Mac OS, but not the cam partition.

Log: diagnostics.txt

The interesting tad-bit:
Sun 3 Nov 18:35:00 GMT 2019: Mounting /mnt/cam... Sun 3 Nov 18:35:00 GMT 2019: Mounted /mnt/cam. Sun 3 Nov 18:35:00 GMT 2019: Ensured cam file is mounted. Sun 3 Nov 18:35:00 GMT 2019: Running fsck on /mnt/cam... Sun 3 Nov 18:35:00 GMT 2019: | fsck from util-linux 2.33.1 Sun 3 Nov 18:35:03 GMT 2019: | fsck.fat 4.1 (2017-01-24) Sun 3 Nov 18:35:03 GMT 2019: | Long filename fragment "2019-10-31_15" found outside a LFN sequence. Sun 3 Nov 18:35:03 GMT 2019: | (Maybe the start bit is missing on the last fragment) Sun 3 Nov 18:35:03 GMT 2019: | Not auto-correcting this. Sun 3 Nov 18:35:03 GMT 2019: | /TeslaCam/RecentClips/20A050~6.MP4 Sun 3 Nov 18:35:03 GMT 2019: | Contains a free cluster (1074098). Assuming EOF. Sun 3 Nov 18:35:03 GMT 2019: | /TeslaCam/RecentClips/20A050~6.MP4 Sun 3 Nov 18:35:03 GMT 2019: | File size is 29579466 bytes, cluster chain length is 0 bytes. Sun 3 Nov 18:35:03 GMT 2019: | Truncating file to 0 bytes. Sun 3 Nov 18:35:03 GMT 2019: | Performing changes. Sun 3 Nov 18:35:03 GMT 2019: | /dev/loop1: 508 files, 383885/2125556 clusters Sun 3 Nov 18:35:03 GMT 2019: Finished fsck on /mnt/cam.

So, TeslaUSB does not fix all types of problems automatically. Perhaps something we can improve in future builds.

I could not get fsck to fix this error automatically. I had to first find the offset:
`
root@teslausb:/backingfiles# parted cam_disk.bin
GNU Parted 3.2
Using /backingfiles/cam_disk.bin
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit
Unit? [compact]? B
(parted) print
Model: (file)
Disk /backingfiles/cam_disk.bin: 69668356096B
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 1048576B 69668356095B 69667307520B primary fat32 lba

(parted) q
`

Then mount the file to loopback
losetup -o 1048576 /dev/loop6 /backingfiles/cam_disk.bin

Attempt to fix via fsck
fsck /dev/loop6

And even attempt to delete the file by hand
mount /dev/loop6 /cam rm -rf /mnt/cam/TeslaCam/RecentClips/2019-10-31_15

Even those steps did not correct the issue with not mounting the cam to usb

@garricn
Copy link

garricn commented Dec 1, 2019

I’m seeing this same issue and I am not using teslausb. I’m using a Samsung SD straight via USB to SD adapter.

@Phontana
Copy link

Phontana commented Dec 2, 2019 •
edited

@garricn I'm seeing this issue the last few days with a Samsung SD as well. This seems not directly related to teslausb, although the issue occurred more often when I was using teslausb.

@j450h1
Copy link

j450h1 commented Feb 26, 2020 •
edited

Here is the output from dmesg. Any of this look familiar?

   96.506949] lo_write_bvec: 3353 callbacks suppressed
[   96.506961] loop: Write error at byte offset 1048576, length 512.
[   96.506976] print_req_error: 3353 callbacks suppressed
[   96.506981] print_req_error: I/O error, dev loop1, sector 0
[   96.506992] buffer_io_error: 3353 callbacks suppressed
[   96.507000] Buffer I/O error on dev loop1, logical block 0, lost sync page write
[  100.654899] print_req_error: I/O error, dev loop1, sector 24452408
[  100.655031] print_req_error: I/O error, dev loop1, sector 24452415
[  100.655264] print_req_error: I/O error, dev loop1, sector 32841008
[  100.655382] print_req_error: I/O error, dev loop1, sector 32841022
[  100.655649] print_req_error: I/O error, dev loop1, sector 41229616
[  100.655764] print_req_error: I/O error, dev loop1, sector 41229629
[  100.741763] loop: Write error at byte offset 1049088, length 512.
[  100.741784] print_req_error: I/O error, dev loop1, sector 1
[  100.741800] Buffer I/O error on dev loop1, logical block 1, lost async page write
[  100.742345] loop: Write error at byte offset 1048576, length 512.
[  100.742360] print_req_error: I/O error, dev loop1, sector 0
[  100.742373] Buffer I/O error on dev loop1, logical block 0, lost sync page write
[  101.675336] Mass Storage Function, version: 2009/09/11
[  101.675356] LUN: removable file: (no medium)
[  101.675515] LUN: removable file: /backingfiles/music_disk.bin
[  101.675614] LUN: removable file: /backingfiles/cam_disk.bin
[  101.675623] Number of LUNs=2
[  101.689483] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11
[  101.689501] g_mass_storage gadget: g_mass_storage ready
[  101.689517] dwc2 20980000.usb: bound driver g_mass_storage
[  101.852112] dwc2 20980000.usb: new device is high-speed
[  102.104328] dwc2 20980000.usb: new device is high-speed
[  102.166364] dwc2 20980000.usb: new address 17
[  102.177933] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage
[  113.016589] Mass Storage Function, version: 2009/09/11
[  113.016611] LUN: removable file: (no medium)
[  113.016779] LUN: removable file: /backingfiles/music_disk.bin
[  113.016873] LUN: removable file: /backingfiles/cam_disk.bin
[  113.016883] Number of LUNs=2
[  113.023332] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11
[  113.023351] g_mass_storage gadget: g_mass_storage ready
[  113.023367] dwc2 20980000.usb: bound driver g_mass_storage
[  113.156541] dwc2 20980000.usb: new device is high-speed
[  113.218702] dwc2 20980000.usb: new device is high-speed
[  113.280967] dwc2 20980000.usb: new address 18
[  113.294362] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage
[  255.589211] Mass Storage Function, version: 2009/09/11
[  255.589232] LUN: removable file: (no medium)
[  255.589393] LUN: removable file: /backingfiles/music_disk.bin
[  255.589495] LUN: removable file: /backingfiles/cam_disk.bin
[  255.589504] Number of LUNs=2
[  255.603420] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11
[  255.603438] g_mass_storage gadget: g_mass_storage ready
[  255.603454] dwc2 20980000.usb: bound driver g_mass_storage
[  255.744002] dwc2 20980000.usb: new device is high-speed
[  255.817046] dwc2 20980000.usb: new device is high-speed

@marcone
Copy link
Owner

marcone commented Feb 27, 2020

Well those I/O errors certainly don't look good. Looks like you have a bad card, and are possibly using a charge-only cable instead of a true USB cable.

@j450h1
Copy link

j450h1 commented Feb 27, 2020

thanks @marcone. I will try a different cable (although it was working fine for quite a while) and, if that doesn't work, a different microsd card and reinstall everything.

@j450h1
Copy link

j450h1 commented Feb 27, 2020 •
edited

Update: turns out cable was fine. Reflashing with the latest image (same 64 gb microsd card) did the trick. Here is some of the latest dmesg output:

[   23.383250] brcmfmac: power management disabled
[   25.154335] random: crng init done
[   25.154359] random: 7 urandom warning(s) missed due to ratelimiting
[   26.704149] Bluetooth: Core ver 2.22
[   26.704371] NET: Registered protocol family 31
[   26.704384] Bluetooth: HCI device and connection manager initialized
[   26.704418] Bluetooth: HCI socket layer initialized
[   26.704438] Bluetooth: L2CAP socket layer initialized
[   26.704524] Bluetooth: SCO socket layer initialized
[   26.743330] Bluetooth: HCI UART driver ver 2.3
[   26.743353] Bluetooth: HCI UART protocol H4 registered
[   26.760127] Bluetooth: HCI UART protocol Three-wire (H5) registered
[   26.760550] Bluetooth: HCI UART protocol Broadcom registered
[   29.257115] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   29.567519] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   29.567537] Bluetooth: BNEP filters: protocol multicast
[   29.567572] Bluetooth: BNEP socket layer initialized
[   30.073973] FS-Cache: Netfs 'cifs' registered for caching
[   30.075180] Key type cifs.spnego registered
[   30.075233] Key type cifs.idmap registered
[   30.083357] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[   30.344321] CIFS VFS: Error connecting to socket. Aborting operation.
[   30.344351] CIFS VFS: cifs_mount failed w/return code = -101
[   32.826684]  loop0: p1
[   35.625567]  loop1: p1
[   39.912339]  loop1: p1
[   41.503419]  loop1: p1
[   79.120846] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[   83.065918] Mass Storage Function, version: 2009/09/11
[   83.065939] LUN: removable file: (no medium)
[   83.066103] LUN: removable file: /backingfiles/music_disk.bin
[   83.066204] LUN: removable file: /backingfiles/cam_disk.bin
[   83.066213] Number of LUNs=2
[   83.069607] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11
[   83.069625] g_mass_storage gadget: g_mass_storage ready
[   83.069641] dwc2 20980000.usb: bound driver g_mass_storage
[   83.091385] dwc2 20980000.usb: new device is high-speed
[   83.455960] dwc2 20980000.usb: new device is high-speed
[   83.709315] dwc2 20980000.usb: new device is high-speed
[   83.761676] dwc2 20980000.usb: new address 5
[   83.774733] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage

@salanki
Copy link

salanki commented May 11, 2020

Did anyone else solve this problem or figure out a root cause? It just started happening to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests