cimryan / teslausb Goto Github PK
View Code? Open in Web Editor NEWSteps and scripts for turning a Raspberry Pi into a useful USB drive for a Tesla
License: MIT License
Steps and scripts for turning a Raspberry Pi into a useful USB drive for a Tesla
License: MIT License
Not sure if you've had a chance to test on an actual car, but I verified it this morning on a Model 3, v39.7! And great jump on making the setup script; I was going to do that but didn't get to it yet. ๐
Created the Pi Zero W + 64GB MicroSD setup on a Macbook with Mojave; network share is on a USB drive on a Mac Mini High Sierra. I didn't use the full df
size, chose 40GB instead. Some notes...
hosts
(127.0.0.1 entry) and hostname
. Some folks have another raspberrypi on the network and might get confused when they try to reconnect to raspberrypi.local
and wonder where all their changes went. (Like this somebody ๐) Suggest "teslapi" or similar. Simple sed
exercise likely.cifs
version option to 1.0
, or remove it (so it autonegotiates). The default of 3
didn't seem to work for me. I did also try setting the Windows compatibility option on the Mac share. Mac CIFS/SMB is often iffy anyway, so there's probably a "most compatible" setting, and it may change after Mojave even. I'm not going to update the share server to Mojave for a bit though, so, fine for now.I also changed the archive script to copy ....TeslaCam/*
instead of ....TeslaCam/saved*
, since I've seen at least one other pattern in there. (recent-
files) This may not be the smart thing to do, not sure if it messes with the rolling recording, but if the goal is to always archive everything (which makes sense as you obviously won't be viewing in the car...), it seems to make sense. I'll have to do a solid hour drive at some point to validate if the recent-
get compiled down to a single file (which would be a reason to keep them around); just not sure that they do.
So, the dual drives was working great for me for about a day. Now, I see a bunch of USB drives in the media app. The first time I noticed this, I tried to click one of the "drives" just off the top of the screen and I could see my music, but now, even that doesn't work. I suspect the car keeps seeing progressively more and more empty drives and the one with music is now pushed way off the edge of the screen. Or I could be totally wrong.
[(https://imgur.com/BbaiWyu)]
I'm getting this error right before the reboot step. So after reboot, the CAM drive does not show up on windows.
Error: The location 62535680 is outside of the device /dev/mmcblk0.
Question about "sharename", can this be a full path of a samba share or it has to be a folder name in the base of the Shareserver?
I was thinking about the problem of powering the Pi when the car turns off - long enough to upload.
The best solution I could find was this HAT by Alchemy Power. With an 800mAh battery in place, given ~250mA max draw on the Pi, that's still plenty of power even assuming fairly heavy losses. I'm planning to ignore the low battery GPIO - if you shut down on low battery, there's no signal to restart unless you press a button. I'll know more tomorrow when it arrives; for now, it seems to be pretty much the same thing as using a splitter and connecting a USB battery.
Assuming shutdown isn't an option, is there anything useful to do when we know the car's off? (Corollary problem: the car might come back on before we lose power, so there's no guarantee of a clean boot.)
I'm also planning to build a watchdog circuit for this problem unless Tesla ships automatic camera upload before I have time to think about the problem - I'll publish all of my work/research in a fork under the same license, of course!
Following the latest instructions. I finish the "Get a shell on the Pi" section and I'm logged in via SSH. But the next sections starts with "Now that you have Wifi up and running....", but my WiFi is not up and running. I believe earlier instructions required manually starting the wlan interface? Now it's supposed to be automatic?
I run ifconfig and wlan0 is up, but doesn't look connected (no IP Addr or anything).
I checked /etc/wpa_supplicant/wpa_supplicant.conf
and ssid and password look good.
running sudo wpa_cli -i wlan0 reconfigure
gives this error:
Failed to connect to non-global ctrl_ifname: wlan0 error: No such file or directory
What am I doing wrong? I got it up and running last week.
Got Wifi working, but can't get setup-teslausb to run to completion. On second run it stopped because /root/bin existed. Deleted that. Then it stopped because /backingfiles existed. Deleted both /root/bin and its contents, and /backingfiles, and third try got me down to where it downloaded /root/remountfs_rw, and then it quite with the error "The location 65333952 is outside of the device /dev/mmcblk0.
Don't know what to change to fix that..
Maybe we'll do this if people express interest.
Now that we have the /mutable partition we should keep the log from archiveloop and the other runtime scripts there.
Since they'll persist we should also add some primitive log rotation/truncation.
I completed the configuration instructions up to the last part about Get the Pi set up for your Tesla. Windows would never see the Pi as a USB drive. I manually created the TeslaCam directory on the Pi via ssh and tried to connect to my car. The Model 3 never detected the Pi either.
After much debugging, I discovered the issue was with the USB cable I was using. Once I swapped cables, the Pi was detected by Windows as a USB drive and the Tesla started to use it.
TLDR: check your USB cable if your Pi is not detected after configuration
I should start by saying I haven't exactly run the scripts in this repo, but I ran most of what's in the reddit thread. When I set the root fs to read only in fstab, the usb storage becomes read only too, and thus the car is unable to record any dash cam footage. What do I need to do to make the usb storage writable while keeping the root filesystem read only, to avoid corruption?
I am attempting to set this up to upload files to an azure storage file share. I can manually mount the share on the pi, however, it fails when using the same values in the setup script.
What is the reason for using the IP address instead of the name supplied?
I'm planning on modifying this in my repo to skip this and use the name instead of IP. I can PR that change if desired.
Is it possible to just copy over all recorded footage rather than the save*?
Maybe we'll do this if people express interest.
I can work on this one, since I want to update the script that sets up USB networking anyway.
You can put the credentials in /boot/wpa_supplicant.conf before booting the Pi the first time and it will autocopy and configure on first boot.
If you split the dirs out into Windows and Mac/Linux then that will help even more in this case since we can ensure that someone can edit the USB connect script with a *nix compliant editor.
Then just run it, eject the card, and boot your Pi into glorious USB and (assuming you did it right) Wifi options right off the bat.
The car could move out of range of the network in between the time that the check for connectivity is preformed and the attempt to mount the archive is made.
Since you decided to fork, I hope you don't mind I'm opening an issue for you since you made an ideas section of your readme :) A few recent reddit posts on v9 seem to indicate multiple partitions on a USB stick give the ability to have one partition for the "teslacam" storage and a separate one for media/music.
Assuming that split partitioning works, It'd be a great addition here to also sync down a media library to a secondary mountpoint. I just ordered a pi and won't be able to try til it gets here. Happy to try and do this myself and submit a PR
When the archive can't be mounted we can't currently determine whether the problem is the CIFS version or the username/password.
verify-archive-configuration.sh could be replaced with another script, say, "get-archive-configuration" which would return the mount options, or at least the CIFS version.
This script could iterate through the four different CIFS versions that mount.cifs supports, and fail if none of them work instructing the user to check the username/password.
Looks like something is going on in the new method of creating backing files.
Configured the archive scripts.
Fixing the modules-load parameter in /boot/cmdline.txt...
Fixed cmdline.txt.
Error: The location 124735488 is outside of the device /dev/mmcblk0.
I believe this is on mkfs.ext4 -F /dev/mmcblk0p3
.
Here's the mount status:
oot@raspberrypi:~# mount
/dev/mmcblk0p2 on / type ext4 (rw,noatime,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=217624k,nr_inodes=54406,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=44388k,mode=700,uid=1000,gid=1000)
Fdisk -l
root@raspberrypi:~# 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: 59.5 GiB, 63864569856 bytes, 124735488 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: 0x40fa9455
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 97889 89698 43.8M c W95 FAT32 (LBA)
/dev/mmcblk0p2 98304 124735487 124637184 59.4G 83 Linux
and df
:
root@raspberrypi:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 61339276 1078076 57736860 2% /
devtmpfs 217624 0 217624 0% /dev
tmpfs 221940 0 221940 0% /dev/shm
tmpfs 221940 8660 213280 4% /run
tmpfs 5120 4 5116 1% /run/lock
tmpfs 221940 0 221940 0% /sys/fs/cgroup
/dev/mmcblk0p1 44143 22501 21643 51% /boot
tmpfs 44388 0 44388 0% /run/user/1000
From #17
Presumably this is for people that have to use shared Wifi networks.
Imagine that the car is in an accident outside the range of a cell tower. You'd like to get the video onto your phone so you can show the local police what happened. You don't have a laptop in the car.
It should be possible to configure the Pi so that it acts as both a WiFi client and AP at the same time: https://www.raspberrypi.org/forums/viewtopic.php?t=138730
With just that change the scenario would be achievable with a terminal client and an SFTP client running on the phone.
A further enhancement would be to add a simple web server on the Pi which allow one to trigger
A yet further enhancement would be to list the saved clips through the website for direct download to the phone.
Tried to mount a share folder on my Synology NAS. Got the "mount error(95): Operation not supported" error when running setup-teslausb
. Message to the user suggest this: "
Try specifying a lower number for the CIFS version like this: export cifs_version=2
This actually doesn't work. I suggest changing this to:
Try specifying a lower number for the CIFS version like this: export cifs_version=2.0
This works.
I'm a h/w guy and this is my first time really on github... If it's alright with you guys, I would like to try my hand at contributing with this minor change. Would I just open a pull request? Sorry for being a total newb.
It looks like no new log data is getting written for archiveloop or archive-te3slacam-clips and the files are reported as not writeable. I am not seeing any files transfer even though I have clicked the camera to save some and have booted up a couple of times. Both files have the same last timestamp of "Thu 3 Nov 17:17:10 UTC 2016" which appears to be created during the setup, and nothing after that.
Are there other log files to look in for logs to determine what is up?
Where can I find the camera files on the PI to be sure that they are visible to code running on the PI? I wanted to verify that there are files visible to the Pi, but I haven't been able to find them through SSH looking in places like /mnt/cam and everywhere else I can think of. The files do appear on the USB drive when I plug it into my PC.
Ok this didn't end up testing when the commit was all said and done.
sed -i -e "s/rootwait/rootwait modules-load=dwc2,g_ether/" -e "s@ init=/usr/lib/raspi-config/init_resize.sh@@"
fails with sed -e: No such file or directory
I originally had sed -i'.bak'
to create the backup files, per this thread:
https://stackoverflow.com/questions/4247068/sed-command-with-i-option-failing-on-mac-but-works-on-linux
specifically:
There is no portable way to avoid making backup files because is impossible to find a mix of sed commands that works on all cases:
sed -i -e ... - does not work on OS X as it creates -e backups
sed -i'' -e ... - does not work on OS X 10.6 but works on 10.9+
sed -i '' -e ... - not working on GNU
The command works on Mac if I append the .bak
(or choose your extension :) ). I'll PR it and you can test if desired.
Further scripting & automation would be aided by having setup-piForHeadlessConfig.ps1 and setup-teslausb accept command line parameters and prompt for the values only if the command line values are not present.
setup-piForHeadlessConfig.ps1 needs SSID & key
setup-teslausb needs archiveserver, sharename, shareuser, sharepassword, campercent
Perhaps this would help make regression testing easier as well?
Some folks have another raspberrypi on the network and might get confused when they try to reconnect to raspberrypi.local and wonder where all their changes went. (Like this somebody ๐) Suggest "teslapi" or similar. Simple sed exercise likely.
Downloaded new files today (October 23rd around 9:30 EDT) and after running setup-teslausb and rebooting it comes up wtih a USB device not recognzied error. I've tried multiple cables that work for data transfer, using both data and a second on the power to ensure it isn't insufficient power, reflashing and redoing the whole process. Also has this issue yesterday before the commits last night and this morning. Attached is the powershell window, hope I scrubbed it all.
CAM drive not mounting on windows (multiple machines) fresh install
I had to either set the cifs version option to 1.0, or remove it (so it autonegotiates). The default of 3 didn't seem to work for me. I did also try setting the Windows compatibility option on the Mac share. Mac CIFS/SMB is often iffy anyway, so there's probably a "most compatible" setting, and it may change after Mojave even. I'm not going to update the share server to Mojave for a bit though, so, fine for now.
From #5
Is the apt-get update part of make-root-fs-readonly.sh required? I let that step run for a few minutes and it was estimating it had more than 30 minutes remaining to update the package list.
If this is not essential, it may be worthwhile to remove the package update from the script.
Right now the Pi only scans for and fixes corruption while attempting to archive. If the backing files get corrupted by a loss of power, we can probably fix the corruption when the power is restored.
Not all hosts are discoverable by name; for example mine isn't. So the script lines that find the share server IP by resolving the hostname won't work for me.
From #5
I'm still thinking this one through, but it's quite annoying that files are 1min / 30MB in size and having to deal with them after they get copied off. It'd be nice to have an option to combine files within a range (like everything for a given day stamp) before copy.
FFMPEG can concatenate, given a list of files, so it would be something like "for every file with name like %date% and file size == 30.1MB" written to a file and FFMPEG cats them.
This may never make sense unless you're doing the climate control trick, or a passthrough battery trick. You need to ensure file integrity and so on, obviously.
Putting out there to solicit feedback either way.
setup-teslausb
should be able to mount the cam drive and create the TeslaCam
directory automatically. This would eliminate several steps from the setup instructions as the pi would not need to be connected to a PC before being used in a Tesla.
I can make this change tomorrow if there are no objections about its usefulness.
Formatted the card with Etcher
Setup the pi using the Windows Powershell Instructions
Logged in via wifi and setup rclone
Ran setup-teslausb and received this message:
Downloaded /tmp/verify-configuration.sh ...
Verifying that there is sufficient space available on the MicroSD card...
STOP: The MicroSD card is too small.
parted shows the following:
/dev/mmcblk0:64021856256B:sd/mmc:512:512:msdos:SD GC2QT:;
1:32256B:4194303B:4162048B:free;
1:4194304B:50119679B:45925376B:fat32::lba;
1:50119680B:50331647B:211968B:free;
2:50331648B:1866465279B:1816133632B:ext4::;
3:1866465280B:63915950079B:62049484800B:ext4::;
4:63915950080B:64021856255B:105906176B:ext4::;
Working on this as a test project to ease a lot of setup. Please mark enhancement.
Allegedly this is a thing that can happen to Raspberry Pis.
32gb SD card
Went through the following steps:
Had a friend look at it, and it seems like the partitioning might not be giving me enough space to mount the archive? Any tips and what I should try to do next, or if I did something wrong?
Thanks.
So I got this thing setup last night and it seems to work...
I have plug the drive to my Tesla and I see a partial file copied to my TM3 folder in my windows server.
However, this morning I only see that a 5mb file is copy to my shared folder under this name:
saved-front-2018-10-16_01-36.mp4
And this file is incomplete because it is not playable.
So then, I got to the office today and directly plugged the drive into my laptop. I don't even see this file on the drive anymore.
So a couple of questions....(sorry, didn't mean to combine questions):
Thanks!
it does seem like it's eating the IP address somehow.
Originally posted by @rtgoodwin in #8 (comment)
I plan on working this one, just wanted to open it for feedback.
Utilizing apache2 & php, have a simple web UI running on the Pi that can provide some statistics (such as space used/free), mount status, and then enable control of new settings to drive minor variations in script behavior such as copying files instead of moving them. Potentially also add the ability to trigger the copy process manually if it did not fire for some reason.
Tried setup twice with same results, have a 128GB Samsung Evo SD card. The first go round I follow the manual instructions on reddit, the second go round I used the scripted setup here on github. With the same results both times, initial setup goes fine, it shows up as a Ethernet adapter, I get it connected to WiFi, but failure seems to be in the USB storage emulation. It fails to show up on my Windows machine and fails to show up in the Tesla. If I check device manager in Windows I see the error Unknown USB device ( Device Descriptor Request Failed) Hardware ID USB\DEVICE_DESCRIPTOR_FAILURE
Maybe we'll do this if people express interest.
Thanks for the merge!
Just tested and looking good except for a minor change I'll be pushing to the image to default to your master branch. If using the conf sample file you'd probably be fine, but in mine I had fully commented out the repo/branch which made the initial script download fail.
But this prompt happened during a manual run where partitioning which will stop the interactive setup:
Warning: You requested a partition from 63757999616B to 63864569344B (sectors 124527343..124735487).
The closest location we can manage is 63758663680B to 63864569344B (sectors 124528640..124735487).
Is this still acceptable to you?
Yes/No?
First time I've seen this, I'm guessing it's not going to be hit for everyone, or maybe a recent change?
I added the -s
flag ("script"/non-interactive) to parted
in a new branch more_logging
but parted
doesn't consider this a passable error.
Starting to create backing files partition...
Checking existing partitions...
Modifying partition table for backing files partition...
Modifying partition table for mutable (writable) partition for script usage...
Error: You requested a partition from 63757999616B to 63864569344B (sectors 124527343..124735487).
The closest location we can manage is 63758663680B to 63864569344B (sectors 124528640..124735487).
That's from this morning's codebase... do we need a slightly more conservative set of partition boundaries, or maybe it's a calculation bug?
I have been finding that sometimes the files deposited on my server are only 2K in size, and since they are purged from the PI there is no recovery. Given that these may contain important video the default should be to preserve it on the Pi and just copy to the file server, then if there are any problems the originals are still available.
This way, rather than adding scripts to the pi to copy/move files to the server, the server can detect when the pi is accessible and pull the files or sync the music. Also, a user can manually look at files without copying files on the server first.
It would be great to be able to sync media files from multiple networks in addition to their home network such as at work or via a mobile hotspot.
One way to enable this is to provide support for two things:
This would allow one to securely sync their media files to their private network whenever they connected to a predefined list of wireless access points.
I believe you can use the name options to specify something so it doesn't show as "NO NAME" when mounted on a computer. Definitely personal choice.
From: #5
I guess Tesla has a habit of recording corrupted video.....at least 1 file per day sometimes more.
Is there an easy to search and delete them all?
the USB drive still isn't mounting to the host.
root@teslausb:~# mount -a -v
/proc : already mounted
/boot : already mounted
/ : ignored
/backingfiles : already mounted
/mnt/cam : ignored
/mnt/archive : already mounted
/var/log : already mounted
/var/tmp : already mounted
/tmp : already mounted
root@teslausb:~# ls -la /backingfiles/
total 56235672
drwxr-xr-x 3 root root 4096 Oct 17 15:36 .
drwxr-xr-x 23 root root 4096 Oct 17 15:36 ..
-rw-r--r-- 1 root root 57585291264 Nov 3 2016 cam_disk.bin
drwx------ 2 root root 16384 Oct 17 15:36 lost+found
root@teslausb:~# cat /etc/fstab
proc /proc proc defaults 0 0
PARTUUID=7fd599a5-01 /boot vfat defaults,ro 0 2
PARTUUID=7fd599a5-02 / ext4 defaults,noatime,ro 0 1
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that
/dev/mmcblk0p3 /backingfiles ext4 auto,rw,noatime 0 2
/backingfiles/cam_disk.bin /mnt/cam vfat noauto,users,umask=000 0 0
//MYIPHERE/TeslaCamFiles /mnt/archive cifs credentials=/root/.teslaCamArchiveCredentials,iocharset=utf8,file_mode=0777,dir_mode=0777 0
tmpfs /var/log tmpfs nodev,nosuid 0 0
tmpfs /var/tmp tmpfs nodev,nosuid 0 0
tmpfs /tmp tmpfs nodev,nosuid 0 0
Not sure where the mount logic or file creation logic changed to break this.
Originally posted by @rtgoodwin in #30 (comment)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.