Teslausb stops mounting in Tesla after a few weeks #654
Comments
|
You didn't say when you took the diagnostics, but they show that the attached host mounted the drives less than 2 minutes before. |
Thanks for looking into this @marcone. I pulled those files from the Teslausb Viewer on July 6, 2021 at 4:28PM MT. Is there a way to identify whether the mounting was on the computer versus on the Tesla? I guess if it mounted to the Tesla, it would show files being written/processed in the TeslaCam folders. It's definitely bizarre that the device works fine for a couple weeks before this mounting issue begins to plague the device. |
|
I got similiar problems after firmware update 2021.12.25.6, worked perfectly before. |
|
I have updated the car to 2021.12.25.7 but it is still the same behavior, i.e. after a connection to a computer both Music and TeslaCAM is mounted every time. I the do a apt update; apt upgrade and the put the Rasperry PI Zero back in the car. FIrst startup works fine but next time it lokks that the PI is not installed again. Just to be sure I tested with an ordinaru USB-stick and tha works (no surprise). I enclose my diagnostic.txt that was readout 29th of july 2021 at 8 a.m. |
@mane-wt Great that you are replicating the steps I did to debug as well. @marcone is there a way to increase logging specifically to the mounting process to see why it works with a computer versus the Tesla? The next test I am going to do is run Teslasub only for TeslaCAM (No Music) - maybe there's something weird going on with handling two drives? I've been testing running just a normal microsd card in the Tesla without issues for a couples weeks now, and synching my music collection from my NAS to my phone using free Android synching software. |
|
Before removing music, can you check to see if USB is mounted in the car even if the cam isn't working? Mine is doing this and a do the double wheel reboot and the cam starts right up.
From: ***@***.***
Sent: August 1, 2021 12:45 p.m.
To: ***@***.***
Reply-to: ***@***.***
Cc: ***@***.***
Subject: Re: [marcone/teslausb] Teslausb stops mounting in Tesla after a few weeks (#654)
I have updated the car to 2021.12.25.7 but it is still the same behavior, i.e. after a connection to a computer both Music and TeslaCAM is mounted every time. I the do a apt update; apt upgrade and the put the Rasperry PI Zero back in the car. FIrst startup works fine but next time it lokks that the PI is not installed again. Just to be sure I tested with an ordinaru USB-stick and tha works (no surprise). I enclose my diagnostic.txt that was readout 29th of july 2021 at 8 a.m.
diagnostics.txt<https://github.com/marcone/teslausb/files/6913001/diagnostics.txt>
@mane-wt<https://github.com/mane-wt> Great that you are replicating the steps I did to debug as well. @marcone<https://github.com/marcone> is there a way to increase logging specifically to the mounting process to see why it works with a computer versus the Tesla? The next test I am going to do is run Teslasub only for TeslaCAM (No Music) - maybe there's something weird going on with handling two drives?
I've been testing running just a normal microsd card in the Tesla without issues for a couples weeks now, and synching my music collection from my NAS to my phone using free Android synching software.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#654 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AHYTQSKHJUEXIKAZYEPMOJDT2V225ANCNFSM4753E3FQ>.
|
|
@mane-wt your diagnostics show the Pi is making the drive available to the car, but the car chose not to access it: @jun3280net The Pi just emulates a USB drive. It has no visibility into whether it's connected to a PC or a car. |
|
Just to add my experience and offer any assistance with logs etc.: My installation has been working fine for some time but has stopped after my M3 LR was recently upgraded to 2021.12.25.6. Please let me know if I can provide any more information, unfortunately technically I will need guidance, but happy to assist where I can. Bob |
|
After some more testing: |
|
@mane-wt - regarding your "sudo halt" command. Assuming you can SSH into your Teslausb - when it is not mounting in the car, does running the "sudo halt" command, and rebooting the Teslausb get it to mount in the car? On a separate note, I tried to do a reinstall of the Teslausb on the Pi Zero W - as I am wondering if the Music drive might be part of the problem. It seems all of us posting here - have a music drive. That said - I'm wondering if my issues are deeper, as I am no longer able to reinstall any of the Teslausb images. I chased down a few threads related to the "get_script failed, retrying" and updating the "wpa_supplicant.conf" info as explained. No improvement. In fact, I do not even see wlan0 when I run "ifconfig". Is there any way to confirm whether the wireless hardware is actually dead? Thanks
|
|
Update:
Car updated to 2021.12.25.7 this morning, rebooted car and connected
Raspberry Pi - No change.
Regarding jun3280net's comment re the music drive, I was also wondering
about that and if Tesla had introduced some checks for more than one
connected device to prevent the use of hubs etc with the dashcam, it would
be good if someone without the Music partition could confirm?
Bob
…On Tue, 3 Aug 2021 at 01:32, jun3280net ***@***.***> wrote:
@mane-wt <https://github.com/mane-wt> - regarding your "sudo halt"
command. Assuming you can SSH into your Teslausb - when it is not mounting
in the car, does running the "sudo halt" command, and rebooting the
Teslausb get it to mount in the car?
On a separate note, I tried to do a reinstall of the Teslausb on the Pi
Zero W - as I am wondering if the Music drive might be part of the problem.
It seems all of us posting here - have a music drive. That said - I'm
wondering if my issues are deeper, as I am no longer able to reinstall any
of the Teslausb images. I chased down a few threads related to the
"get_script failed, retrying" and updating the "wpa_supplicant.conf" info
as explained. No improvement.
In fact, I do not even see wlan0 when I run "ifconfig". Is there any way
to confirm whether the wireless hardware is actually dead? Thanks
[image: image]
<https://user-images.githubusercontent.com/30555695/127939543-79ae4c83-a8cd-4764-b7d1-e00f317453e1.png>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#654 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEEU3N57QGYYYPUOTSDV6ETT242JRANCNFSM4753E3FQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
|
Hello i've been following from the sidelines. I have a Raspberry Pi Zero. I'm currently on 2021.4.18.10 with a 2021 Model 3 and i'm having the same issue as everyone else. I'm only using Pi zero for Dashcam in the glovebox. I have an external HD for just music and boombox in the center console. So i can confirm no music partition here. |
|
I use a music drive, got 2021.12.25.7 yesterday, and everything still works with my Pi0. |
|
@marcone Hi, anything you can suggest for those of us with the issue to try or any further info we can provide, or do you feel it's a case of waiting for a future Tesla update? |
|
After more testing I am almost convinced that the issue is a result from a corrupt file system. I have tried to connect the Pi to a computer and after the Music drive and the TeslaCam drive have been mounted I just unplugged the Pi in a similar way when the car cuts its power. Like this the Pi won't work in the car. If I instead log in to the Pi with ssh and issues a "sudo halt" command to safely take down the Pi, it works once when connecting it to the car. It is known that the file system on the Pi will be corrupted when the car suddenly cuts power to the Pi. Before when everything worked the Pi fixed the filesystem upon startup but not anymore. Unfortunately it will not work to issue a "sudo reboot" command when the Pi sits in the car. It would be very interesting if it is possible to issue a command to fix the filesystem via ssh when the Pi sits in the car, @marcone do you know such a command? One other theory is that if the Pi, sitting in the car, eventually fixed the filesystem it wont mount the Music drive and the TeslaCam drive even if it has been fixed. Is it possible to repeat the command to try another time to mount the 2 drives, and if so how to do that? (I have a Tesla Model S 2018 if that makes a difference) |
Which one? Teslausb uses multiple partitions, plus disk images, each with their own filesystem. |
|
Both partitions. I always get both Music and TeslaCAM or neither of them. |
|
CAM and MUSIC are only two of the 6 or more filesystems that could be in use at any given time, hence my question. In any case, those two are checked for errors on every boot, before being presented to the car, so the problem shouldn't be caused by corruption of those two. The fact that you only ever get neither or both also points at that, since it suggests that the Pi got "stuck" on something before publishing the drives to the car, like in the case where autofs wasn't starting up in an earlier comment above. |
|
I have the same issue, which only started since I updated to 25.7. A double wheel reboot of the screen fixes the issue 100% of the time. Power cycling the Pi0 in the car doesn't do anything. I submitted a "bug report" in the car, for whatever good it will do. Sorry for not being more helpful, but just adding another data point. Given that this problem only started for me once I got the 25.7 update, logic suggests that Tesla did something in the update that is causing this issue. |
|
For me the problem started with version 25.6 but I also think Tesla did something unfortunately. Despite if it is due to Tesla or not maybe we can do something about it any way? Would it be possible to check all filesystems upon every boot and/or try to mount more than one time after some delay? I really do not want to be without this wonderful functionality. |
|
Yesterday, I checked everything was working fine connected to my PC, ejected the Drives and Halted the Pi, placed it back in the GloveBox, I could see the TeslaUSB online, SSH to it, mount and display the folders and sync Music, also (now I know about it) use the web interface. |
|
The Pi not being on the network and then reappearing on the network kind of sounds like the USB port powered off at some point, and then opening the app caused it to power up again. The archiveloop log would tell if it lost power and restarted. |
Not exactly sure what I'm looking for but for the 5th/6th there were these entries regarding carThu 5 Aug 08:20:49 BST 2021:00:00 not keeping car awake. There was also this weird sequence where the time appeared to go out by just over an hour:Thu 5 Aug 08:05:19 BST 2021:00:00 low space, deleting /backingfiles/snapshots/snap-000216 There are quite a lot of time adjustments, many of quite large amounts throughout my log:Sat 10 Jul 15:20:48 BST 2021:00:00 Time adjusted by 0.041322 seconds after 0.460000 seconds |
|
Look for something like: That indicates the Pi just booted up. The time adjustments happen every time the Pi does an archive operation. In your log-excerpt the larger values likely indicate the Pi was powered off for a while. The small values are just corrections for clock-drift. |
|
Quite a few events, but I can't be 100% sure which ones may be where I've been connecting/disconnecting whilst testing on the PC etc., but definitely on the 5th/6th I didn't, so we are thinking potentially a loss of power, I have Sentry Mode enabled and the logs show every hour so doesn't look like a prolonged loss of power. Hopefully, these extracts help provide some useful information for everyone trying to piece this together and happy to try anything and provide more information, just let me know. I would add since the Pi has been back in the car, it has been available every time I got in the car and stored a few Sentry Mode events so seems to be behaving itself ATM. Mon 26 Jul 07:17:03 BST 2021:00:00 Starting archiveloop at 23.36 seconds uptime... |
|
@marcone I was just thinking about what you said about the large adjustments due to being off for a while but did you notice that the time went back nearly an hour and then adjusted to 15 mins or so of the original time it was logging events at, which indicates to me it wasn't off that long, but I may not be fully understanding? Thu 5 Aug 08:05:31** BST 2021:00:00 low space, deleting /backingfiles/snapshots/snap-000218 Thu 5 Aug 07:17:35 BST 2021:00:00 Trying to set time... |
|
It's really hard to draw any conclusions from what you've posted so far, since it's just been snippets of the log and not the entire log. |
|
@marcone Sorry, I was trying to focus on things I thought looked odd, such as this time anomaly to try and make it easier, but happy to supply the full log, shall I just attach it here? |
|
sure, just attach it here (diagnostics log would be even better) |
|
@marcone |
What improved compatibility? You can only use Raspberry Pi Zero W, Raspberry Pi Zero 2 W, and Raspberry Pi 4B and they all work fine with Buster. I'm sure @marcone will release a One-step-setup flashable image based on Bullseye soon, but why bother now? |
Do you think Buster vs Bullseye is related to the mounting issue? If so, why? If not, please create a new issue for the upgrade. |
I haven't tried an in-place upgrade, but I did try creating a new prebuilt image using Bullseye, and ran into a few networking related issues with the resulting image.
How much free root space did you have before starting the upgrade? |
That would be improved compatibility between the OS and the car's interface, not the OS and the Pi hardware - in order to see if OS generation might impact the non-mount issue. |
As background, 64GB MicroSD card with a 30GB data slice. Installation using 2021-11-06-teslausb.img followed by:
~biweekly to address package obsolescence. This results in 499MB free: Filesystem Size Used Avail Use% Mounted on The upgrade procedure I used was:
dist-upgrade reports: ...though the disk fills mid-upgrade. |
About the same here, but I freed up some extra space by deleting the /lib/modules/ folders that weren't used, and was able to do an in-place upgrade after that. Afterwards bullseye was running the same kernel version as buster was before the upgrade (5.10.103), and no newer one was available with apt. Therefore, I wouldn't expect any differences in behavior of the USB mass storage emulation. |
|
Had my Tesla model 3 in for a service this week. This is what the wrote in my invoice. |
@radhoo2k10 does this mean a raspberry pi 4 connected to the usb3 ports would not have the unmounting issue? Can anyone confirm this? |
|
I have been trying to get a RPi4 to test this myself, but it is sold out everywhere. Is it safe to assume that other folks also don't have RPi4s to try this out with? |
The USB3 ports on the Raspberry Pi 4 are host mode only, they don't do USB OTG. Only the USB-C port does OTG, and it's USB 2.0. |
|
@marcone , is it the same image we should use for rock pi? |
No, a Raspberry Pi image will not work on a Rock Pi. |
|
Can anyone suggest a Rock Pi 4C+ model to get? Cannot find them for sale anywhere.
…________________________________
From: marcone ***@***.***>
Sent: Tuesday, August 9, 2022 1:16:55 PM
To: marcone/teslausb ***@***.***>
Cc: miles267 ***@***.***>; Mention ***@***.***>
Subject: Re: [marcone/teslausb] Teslausb stops mounting in Tesla after a few weeks (#654)
Please remove this device and
connect a USB drive recommended by Tesla that supports USB
3.0 super speed writing
@radhoo2k10<https://github.com/radhoo2k10> does this mean a raspberry pi 4 connected to the usb3 ports would not have the unmounting issue? Can anyone confirm this?
The USB3 ports on the Raspberry Pi 4 are host mode only, they don't do USB OTG. Only the USB-C port does OTG, and it's USB 2.0.
To have true USB3 OTG you need something like an rk3399 based SBC like the Rock Pi 4C+. I'm working on adding support for that.
—
Reply to this email directly, view it on GitHub<#654 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANKVGTCZ2JMXVXFTM3VY6IDVYKOBPANCNFSM4753E3FQ>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Note that I said "I'm working on adding support", i.e. it is not supported yet, so maybe a bit premature to go and buy one. Note that there is only one model of Rock Pi 4C+. There are several models in the Rock Pi 4 series, but only the 4C+ can be powered from a plain USB port (the others need USB PD capable of delivering at least 9V). |
|
@marcone Could one simply plug in the blue USB-A port for 3.0 speed? This would obviously require a separate power input for the Pi4. |
No, see my comment above. |
Hi @marcone have you been able to make any progress on adding Rock Pi 4C+ support to the teslausb image? I'm happy to help test if helpful. Thanks. |
The image is not going to support the Rock Pi. It's an image for Raspberry Pi, and Raspberry Pi and Rock Pi are sufficiently different that making an image that supports both would be difficult, perhaps even impossible. The setup and runtime scripts for teslausb can be made to run on other linux distributions like Armbian, Debian or Ubuntu though, so that's what I'm working towards. |
|
For the Rock 4C+, how are you supplying the 3 Amps its needs without the NVME SSD, and 5 Amps with? None of my USB ports handle that much power, so Cigarette Lighter to USB is all I can think of. |
It doesn't need that much, unless you plug something in to every one of the USB ports that draws the maximum rated power. In practice I see it use about 1A peak and 750 mA at idle with an NVME drive on board (my "v1.2" board has an onboard M.2 slot, but I'm told that they removed that from later revisions of the board). |
|
@marcone does that mean you’ve been testing teslausb on the rock 4c? If so, would love to hear if it solves the mounting issue |
I've never had these mounting issues, so no idea if switching to a rock 4c plus will solve the issue for those that do. |
|
@marcone has there been any further progress made on a Rock Pi 4C compatible image? 🤞 Thanks. |
Try the Armbian minimal image from https://github.com/radxa-build/rock-4c-plus/releases and the instructions from https://github.com/marcone/teslausb/wiki/Installation |
Thanks @marcone please let me know if you'd like for me to start a new thread on this? Would you suggest the Armbian minimal bullseye or jammy image for the Rock Pi 4C+? If I understand correctly, Jammy is Ubuntu, Bullseye is Debian? |
|
Either one should work. I tried the bullseye image yesterday, but have tried jammy in the past. |
|
Just found out last week what was the other issue for me with my Pi4. The SD card slot was loose (manufacturing defect). And last week it came off. So I think my SD card didn't sit in the place all the time exactly as it needed to be. Bought pizero from canalkit in a fancy "all inclusive" package for $80. Working as a charm. Just need longer times to sync the data via wifi. But once in a week I'm leaving it connected to 20k mah power bank and it does it's job overnight (whole week of videos). |
|
I have the same problem since a few days and checking the diagnostics today showed [Fri Oct 20 16:34:35 2023] loop_set_status: loop11 () has still dirty pages (nrpages=2) how to move forward ? |
|
From googling around a bit that "loop_set_status: loop.. () has still dirty pages" error is a few years old, and a fix for it should be in v2.37.1 of the util-linux package. Unfortunately it looks like even current linux distributions are still on v2.36.1. Is that also the version you have? ( |
|
I used your latest-stable image so I assume yes , at the moment I setup your pre-release (bullseye on a new SD-card) and smaller cam partition and will give it a try |
and others
Teslausb installed on Pi-Zero works great after a fresh install. After a couple of weeks, the device begins to experience problems with mounting in the Tesla. It's not clear to me whether this is a result of Teslausb being turned off (Tesla Sleeps) during "archiveloop" process when connected at home. When the car wakes from sleep to drive, Teslausb starts back up, but often does not mount in the Tesla. The lights flash - as normal, but no mounting in the car after a few minutes. Sometimes, if I disconnect Teslausb, and reconnect, it will mount (but this is rare). I've tried rebooting the Tesla MCU - but this makes no difference.
However, while connected to the Tesla (not mounted), I can confirm I can connect to the AP, and even access the new webpage/viewer. I can even reboot from the webpage, (I don't think archiveloop can be forced unless it's connected to the home SSID). Is there perhaps a way to force mount the device, as I can SSH into the device via the AP. If there is a command to do this, can it be built into the Viewer?
It should be noted while Teslausb does not mount in the car, I can confirm it mounts when connected to the computer. It takes about 1 min before the CAM and MUSIC drives show up.
Update : TeslaUSB is plugged into the car via a HUB. The device was has not been mounting as described. Ten minutes into the drive, I plugged in a spare USB key into the HUB to ensure dashcam was recording. Surprisingly, this triggered the mounting of TeslaUSB. I confirmed via the viewer some video recorded today, and the music was available to the car. I have not tried replicating this since - but I'll try again tomorrow assuming Teslausb does not mount again.
Any ideas or thoughts on how to troubleshoot would be greatly appreciated. Thanks
archiveloop.log
diagnostics.txt
teslausb-headless-setup.log
The text was updated successfully, but these errors were encountered: