-
Notifications
You must be signed in to change notification settings - Fork 490
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
Conversation
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..
@cimryan - can you please review this pull request? |
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. |
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. |
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) |
fsck from util-linux 2.29.2 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.
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.
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..