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

Fix image creation for Tesla firmware 2019.5.x #125

Closed
wants to merge 3 commits into from

Conversation

marcone
Copy link

@marcone marcone commented Mar 11, 2019

As of firmware 2019.5.x, Tesla expects a partitioned device for storing
dashcam recordings. While this is not required for the music drive, this
change modifies both camera and music images to use a partition table
with a single primary partition formatted as FAT32, instead of formatting
the entire device/file..

As of firmware 2019.5.x, Tesla expects a partitioned device for storing
dashcam recordings. While this is not require for the music drive, this
change modifies both camera and music images to use a partition table
with a single primary partition formatted as FAT32, instead of formatting
the entire device/file..
@rtanaka
Copy link
Contributor

rtanaka commented Mar 15, 2019

@cimryan - can you please review this pull request?

@ghost
Copy link

ghost commented Mar 17, 2019

I pointed the setup config to @therealmarcone's branch and tested this out as well as manually adding his changes from PR #126. Worked well for me. Model 3 on 2019.5.15.

@AngusThermo-Pyle
Copy link

This PR does get filesystems that work on newer firmware, however it breaks the fsck /mnt/cam, which needs to be fsck /dev/loop0 style which means that as soon as the filesystem is powered off abruptly, which Tesla likes to do with USB ports, it never recovers. Testing now with the /dev/loop0 /dev/loop1 fsck.

@marcone
Copy link
Author

marcone commented Apr 1, 2019

Why does it break the fsck? Since the filesystem is mounted on /mnt/cam with the correct offset, "fsck /mnt/cam" should just work, no? (not near a pi right now, can't check)

@AngusThermo-Pyle
Copy link

fsck from util-linux 2.29.2
fsck.fat 4.1 (2017-01-24)
Logical sector size is zero.

I'd assume that this is because of the partitioning. fsck /dev/loop0 works fine. I've modified my archiveloop to use /dev/loop for now, but there should be a way to get the /dev/loop address from the mountpoint in order to avoid hardcoding.

Incidentally, this may be the solution to the reports of filesystems becoming randomly inaccessible over time. I was seeing the cam icon and music drive vanishing randomly during the day and tracked it down to the fsck failure. I also rsync my music from a music archive when the clips are copied, so my install is already a bit custom.

Apparently fsck does not work with partitioned filesystem images where the
actual filesystem is mounted wih an offset, so fsck the underlying loopback
device instead.
@marcone
Copy link
Author

marcone commented Apr 2, 2019

Added a change that looks up the loopback used for the mountpoint being checked, then runs fsck on that instead.

so music drive can be fsck'd too.
@marcone marcone closed this Jun 12, 2020
@marcone marcone deleted the partitions branch June 12, 2020 19:40
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

Successfully merging this pull request may close these issues.

3 participants