Make base flashable image

[rtgoodwin]

Working on this as a test project to ease a lot of setup. Please mark enhancement.

[rtgoodwin]

For now the latest image will be at the beta releases page or on the main repo when/if it gets moved there. And the relevant Readme.

OUTDATED: ~Ok this is ready for testing and feedback:~

~https://github.com/rtgoodwin/teslausb/tree/headless-patch/headless-scripts~

~~Also handled #37 in this method; it's a few line patch to the archive script that can probably be re-used regardless. PLEASE PROVIDE FEEDBACK and SUGGESTIONS. If it works for you, or doesn't, please comment on this issue. 😄 You do need a Mac or Linux machine for using the initial script to prep the SD card. I didn't make a Windows version of the initial script, because I (still) don't have Windows. It's pretty self-explanatory though; basically a move and modification of a bunch of items from setup-teslausb into setup-PiForHeadlessBuild.sh and setup-teslausb-headless. We can merge the core logic when decided on the best structure.~~

[cimryan]

Skipping the ssh phase is cool.

I'm having trouble imagining the experience for a Windows user. Pi-gen seems like it would require a significant setup of its own on Windows.

[rtgoodwin]

Weird, email update didn't post. Trying again: +++ Oh definitely don’t want end users messing with pi-gen. We take the image as far as we want and freeze it. I just put the background there in case others wanted to do similar development or understand how it works to drive more changes.

LMK if there are thoughts on more to push into the image, or alternate ways of tracking progress. Trying to find the balance between having to rebuild the image frequently vs keeping some pieces easily updateable (ie outside the image). It’s not hard but is sufficiently long and annoying to rebuild it. :)

If we feel we’re fairly stable with most of the scripts (which is the only reason I have them outside currently, for changes), I can make a flashable image requiring only the config file and put it up for people to play with. There’s nothing stopping that now, I just wanted to get opinions and some testers on the ideal experience.

[rtgoodwin]

I started working on an "only config file(s)needed" image last night. It'll be a bit, but it's quite doable. I spent a lot of time worrying over error checking but only so much can be done. Basically user just has to create a .conf and the wpa_supplicant file and then boot. I think that's doable.

[rtgoodwin]

I'm looking at other things to reduce instability.

I've had the CAM drive disappear twice in car (using the existing image and steps) as indicated by the Dashcam icon disappearing randomly while driving. In that vein, is it really needed to unmount the USB share to archive? (And thus the checks for it to be reachable etc.) The original Reddit post did it ti

I know you don't want R/W going on at the same time on the partition but the same files wouldn't be being modified (since saved files by default are already written out). And since the cam using rolling date and times in the filename, the presence or removal of files shouldn't affect anything while keeping the drive alive.

@cimryan and others, thoughts on this? Certainly would make a flashable image easier to use and test if we could just note the archive wasn't reachable but the USB share functionality stayed solid. My tentative thinking is to dumb it down to always mount and if the loop tries to archive and it isn't reachable, touch a file ARCHIVE_UNREACHABLE in the CAM folder.

[cimryan]

I see two potentially separable proposals:

1. Leave the g_mass_storage module loaded at all times.
2. Leave the backing file mounted at all times.

Have you determined that the cause of the camera icon disappearing is the unloading of the g_mass_storage module?

Fundamentally my concern with accessing the backing file through two different file system layers simultaneously is that it's unsupported, and the problem with taking a dependency on unsupported behavior, even if you test it thoroughly, is that you never know what sort of environmental change may cause a break.

Concretely, in my limited experience, changes written through the g_mass_storage interface don't show up with predictability until the backing file is umounted and remounted.

[rtgoodwin]

Didn't get much sleep yesterday...your point is absolutely valid about both sides having access.

Great question, I don't know for sure that g_mass_storage is the issue, I just know that it disappeared, and my thought was something that went awry with the archive loop, and started thinking through how to make that more solid. I can maybe add some logging to test that...I'll just have to think through where to put it. I do know that I am frequently finding FSCK records which suggests to me something is happening to make the disk dirty, but that could be the Tesla bug. ;)

Have to do some thinking on this, both re: stability and re: easily testable/flashable image. Open to continued thoughts.

Edit: I see you just massively updated the loops, AND a pending rsync PR, so some of this might have been addressed/made moot. I will for the moment focus on optimizing the base image so it can be used with just a config file while those merges get sorted, and we can keep this discussion going.

[rtgoodwin]

Interestingly, the CAM drive just dropped offline from my laptop and then came back. It had been sitting here all morning just fine (Pi -> USB -> USB C adapter -> Macbook).

dmesg, if it helps:

 22.114225] Key type cifs.spnego registered
[   22.114264] Key type cifs.idmap registered
[   23.108469] CIFS VFS: ioctl error in smb2_get_dfs_refer rc=-5
[   23.187917] CIFS VFS: ioctl error in smb2_get_dfs_refer rc=-5
[   29.495414] Mass Storage Function, version: 2009/09/11
[   29.495433] LUN: removable file: (no medium)
[   29.495588] LUN: removable file: /backingfiles/cam_disk.bin
[   29.495597] Number of LUNs=1
[   29.502515] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11
[   29.502531] g_mass_storage gadget: g_mass_storage ready
[   29.502547] dwc2 20980000.usb: bound driver g_mass_storage
[   29.758452] dwc2 20980000.usb: new device is high-speed
[   29.814241] dwc2 20980000.usb: new device is high-speed
[   29.869712] dwc2 20980000.usb: new device is high-speed
[   29.925474] dwc2 20980000.usb: new device is high-speed
[   29.981098] dwc2 20980000.usb: new device is high-speed
[   30.036501] dwc2 20980000.usb: new device is high-speed
[   30.091878] dwc2 20980000.usb: new device is high-speed
[   30.147005] dwc2 20980000.usb: new device is high-speed
[   30.202893] dwc2 20980000.usb: new device is high-speed
[   30.294282] dwc2 20980000.usb: new address 62
[   31.530578] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage
[   36.392990] NOHZ: local_softirq_pending 40
[   83.283559] CIFS VFS: Free previous auth_key.response = da6fb6c0
[  162.242991] NOHZ: local_softirq_pending 40
[  214.443100] random: crng init done
[  214.443123] random: 7 urandom warning(s) missed due to ratelimiting
[ 2812.762568] CIFS VFS: Free previous auth_key.response = d91553c0
[ 6412.810366] CIFS VFS: Free previous auth_key.response = d9155d80
[10012.965266] CIFS VFS: Free previous auth_key.response = d9155d80
[13074.123515] Mass Storage Function, version: 2009/09/11
[13074.123536] LUN: removable file: (no medium)
[13074.123706] LUN: removable file: /backingfiles/cam_disk.bin
[13074.123717] Number of LUNs=1
[13074.126921] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11
[13074.126938] g_mass_storage gadget: g_mass_storage ready
[13074.126952] dwc2 20980000.usb: bound driver g_mass_storage
[13074.285932] dwc2 20980000.usb: new device is high-speed
[13074.297598] dwc2 20980000.usb: new address 63
[13075.619448] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage

This may already be addressed but just popping here for reference.

Archive log (obv time zone is off, not entirely sure why):

Thu  3 Nov 17:17:03 GMT 2016 : Starting...
Thu  3 Nov 17:17:03 GMT 2016 : Archiving...
Thu  3 Nov 17:17:03 GMT 2016 : Starting...
Thu  3 Nov 17:17:03 GMT 2016 : Ensuring cam archive is mounted...
Thu  3 Nov 17:17:03 GMT 2016 : Mounting /mnt/archive...
mount error(16): Device or resource busy
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Thu  3 Nov 17:17:04 GMT 2016 : Failed to mount /mnt/archive.
Thu  3 Nov 17:17:04 GMT 2016 : Sleeping before retry...
Thu  3 Nov 17:17:05 GMT 2016 : Retrying...
Thu  3 Nov 17:17:05 GMT 2016 : /mnt/archive is already mounted.
Thu  3 Nov 17:17:05 GMT 2016 : Ensured cam archive is mounted.
Thu  3 Nov 17:17:05 GMT 2016 : Disconnecting usb from host...
Thu  3 Nov 17:17:05 GMT 2016 : Disconnected usb from host.
Thu  3 Nov 17:17:05 GMT 2016 : Running fsck...
fsck from util-linux 2.29.2
fsck.fat 4.1 (2017-01-24)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
 Automatically removing dirty bit.
/TeslaCam/recent-front-2018-10-23_08-26.mp4
  File size is 2191379 bytes, cluster chain length is > 2195456 bytes.
  Truncating file to 2191379 bytes.
Performing changes.
/backingfiles/cam_disk.bin: 146 files, 27556/1758813 clusters
Thu  3 Nov 17:17:08 GMT 2016 : Finished running fsck.
Thu  3 Nov 17:17:08 GMT 2016 : Ensuring cam drive is mounted...
Thu  3 Nov 17:17:08 GMT 2016 : Mounting /mnt/cam...
Thu  3 Nov 17:17:08 GMT 2016 : Mounted /mnt/cam.
Thu  3 Nov 17:17:08 GMT 2016 : TeslaCam folder exists
Thu  3 Nov 17:17:08 GMT 2016 : Ensured cam drive is mounted.
Thu  3 Nov 17:17:08 GMT 2016 : Moving clips to archive...
Thu  3 Nov 17:17:08 GMT 2016 : Moved 0 file(s).
Thu  3 Nov 17:17:08 GMT 2016 : Finished moving clips to archive.
Thu  3 Nov 17:17:08 GMT 2016 : Unmounting cam drive...
Thu  3 Nov 17:17:10 GMT 2016 : Unmounted cam drive.
Thu  3 Nov 17:17:10 GMT 2016 : Connecting usb to host...
Thu  3 Nov 17:17:10 GMT 2016 : Connected usb to host.
Thu  3 Nov 17:17:10 GMT 2016 : Finished archiving.
Thu  3 Nov 17:17:10 GMT 2016 : Waiting for archive to be unreachable...
Tue 23 Oct 18:11:12 BST 2018 : Archive is unreachable.
Tue 23 Oct 18:11:12 BST 2018 : Waiting for archive to be reachable...
Tue 23 Oct 18:11:12 BST 2018 : Archive is reachable.
Tue 23 Oct 18:11:12 BST 2018 : Archiving...
Tue 23 Oct 18:11:12 BST 2018 : Starting...
Tue 23 Oct 18:11:13 BST 2018 : Ensuring cam archive is mounted...
Tue 23 Oct 18:11:13 BST 2018 : /mnt/archive is already mounted.
Tue 23 Oct 18:11:13 BST 2018 : Ensured cam archive is mounted.
Tue 23 Oct 18:11:13 BST 2018 : Disconnecting usb from host...
Tue 23 Oct 18:11:13 BST 2018 : Disconnected usb from host.
Tue 23 Oct 18:11:13 BST 2018 : Running fsck...
fsck from util-linux 2.29.2
fsck.fat 4.1 (2017-01-24)
/backingfiles/cam_disk.bin: 121 files, 27524/1758813 clusters
Tue 23 Oct 18:11:14 BST 2018 : Finished running fsck.
Tue 23 Oct 18:11:14 BST 2018 : Ensuring cam drive is mounted...
Tue 23 Oct 18:11:14 BST 2018 : Mounting /mnt/cam...
Tue 23 Oct 18:11:14 BST 2018 : Mounted /mnt/cam.
Tue 23 Oct 18:11:14 BST 2018 : TeslaCam folder exists
Tue 23 Oct 18:11:14 BST 2018 : Ensured cam drive is mounted.
Tue 23 Oct 18:11:14 BST 2018 : Moving clips to archive...
Tue 23 Oct 18:11:14 BST 2018 : Moved 0 file(s).
Tue 23 Oct 18:11:14 BST 2018 : Finished moving clips to archive.
Tue 23 Oct 18:11:14 BST 2018 : Unmounting cam drive...
Tue 23 Oct 18:11:15 BST 2018 : Unmounted cam drive.
Tue 23 Oct 18:11:15 BST 2018 : Connecting usb to host...
Tue 23 Oct 18:11:15 BST 2018 : Connected usb to host.
Tue 23 Oct 18:11:15 BST 2018 : Finished archiving.
Tue 23 Oct 18:11:15 BST 2018 : Waiting for archive to be unreachable...
root@teslausb:~#

[cimryan]

In this case it seems that a loss of connectivity to the archive server caused the script to switch out of the "waiting for archive to be unreachable" state. It's actually switching out of the "waiting for archive to be reachable" state that's more interesting, I think, because it's after leaving that state that the drives will be dismounted. That transition would occur when the Pi thinks it's able to connect to the archive server, which seems unlikely to occur when the Pi is out driving around.

[rtgoodwin]

It's actually switching out of the "waiting for archive to be reachable" state that's more interesting,

I agree, especially since in this case I'm sitting at a desk on the home network with extremely strong wireless (far closer and zero walls, vs being in the car). I can't rule out some wireless weirdness of course, although the laptop the Pi is connected to never seems to drop signal. I'm going to download the latest archive scripts and let it run a while and see what happens/look for correlations.

[rtgoodwin]

For now the latest image will be at the beta releases page or on the main repo when/if it gets moved there. And the relevant Readme.

OUTDATED: New version to test (10-24 image

Give this flashable image a try. (Be sure to click the ... on Dropbox and download the .zip file if needed.) Write to card, reinsert it into PC so it mounts boot folder. Then create in boot a file called teslausb_setup_variables.conf and put the vars in it like so (no quotes on any):

export archiveserver=your_archive_name_or_ip
export sharename=your_archive_share_name
export shareuser=username
export sharepassword=password
export campercent=100
export SSID=your_ssid
export WIFIPASS=your_pass

• Boot it in your Pi, give it a bit, watching for a series of flashes (2, 3, 4, 5, maybe 6) and then a reboot and/or the CAM to become available on your PC/Mac.
• The Pi should be available at teslausb.local over Wifi (if it works) or USB networking (if it doesn't). Takes about 5 minutes for me. You should see in boot the TESLAUSB_SETUP_FINISHED and WIFI_ENABLED files as markers of success too.
• I forgot to create the TeslaCam folder, so you'll need to do that before taking to your car.

LMK if it does/doesn't work for you please, feedback needed! :) Worked great just now; I've only tried it with campercent=100.

[firedfly]

A few thoughts:

• I'm assuming when the Pi boots, it will download the setup-tesla usb script and run it? If so, it would be useful to expose the GitUser and GitBranch that you want to use for running the setup script.
• I set my Pi up for connecting to two wifi networks. Are the SSID and WiFIPASS variables required? Can I still manually create the wpa_supplicant.conf file?

I'll try to test this tonight and see how it goes.

[rtgoodwin]

@firedfly

• Currently I pre-download the scripts before cooking the image, to minimize the chances of failure in a headless setup, and to ensure upstream changes haven't borked something. :)

I may make that an option at some point when the setup script (or my version of it for headless) is stable enough to trust that the scripts can download and be re-run and not repeat steps, etc. For example, when rsync/SFTP gets merged in, I'll want to ensure that the "headless" version of that setup can be created and not break any current options/combinations. The loop and archive scripts could probably be downloaded automatically since they're quite self-contained. Anyway, all this can/could change if we can move to a "headless-ready" main setup script/process.

I'd also be happy to add (back) the option to copy scripts from /boot/somedir if you/user want to put your own there. The headless prep script did that before: download and put them in the boot dir to copy over during setup, but I moved to just downloading them and refreshing the image for stability, and TBH the experience of a single .conf file is pretty compelling to me. :) The prep script is still there for me to refer to if needed or for another purpose if desired.

Overall, I want to minimize any chance that it doesn't come up with networking configured and ready to troubleshoot, but also have it tightly looped to do its best to do setup if not already completed.

• The image will still take a wpa_supplicant file if present.

It's set to check:

1) "did the user pass in SSID/WIFIPASS?". 2) "is there a /boot/WIFI_ENABLED file? If not, maybe the user still needs to setup wifi 3) if both are met, removes the wpa_supplicant file with one with the new info and reboots

This is checked on every boot in case you goof or change network details. If the conditions aren't met, the image takes its normal path to suck in the wpa_supplicant.conf file from /boot.

I think that kind of gives the best of both worlds...simple for simple setups, and anyone advanced enough to need two networks can create the wpa_supplicant file.

Open to feedback, and thanks for testing! I'll make sure the latest changes to pi-gen are pushed up later today so you can look over the scripts. It's just a little bit of extra stuff in rc.local, some patching moved to the image side (changing hostname, hosts, enabling ssh, config file, cmdline.txt) and then the modified (and heavily commented out) teslausb-setup-headless in my repo.

[firedfly]

@rtgoodwin

I just tried to boot up the new image with the config file. I manually supplied a wpa_supplicant.conf file and my archive server is not reachable (expected an error about that).

I had a failure in create-backingfiles.sh when using campercent=100. I'm seeing the error on the monitor connected to the Pi--can't find these errors logged anywhere. The backing files partition was created and mounted. However, the backing file was not created.

Errors on screen (copied as best I could...). The login prompt appears after the last line:

Writing superblocks and filesystem accounting information: done

/ 100 ")syntax error: invalid arithmetic operator (error token is "line 26: 5504860 * 100 [ 84.741828] rc.local[448]: /root/bin/tmp/create-backingfiles.sh: line 28: CAM_DISK_SIZE: unbound variable [FAILED] Failed to start /etc/rc.local Compatibility. See 'systemctl status rc-local.service' for details. Starting Hold until boot process finishes up... Starting Terminate Plymouth Boot Screen...

Contents of /boot/teslausb-headless-setup.log

root@teslausb:~/bin# more /boot/teslausb-headless-setup.log Wed Oct 24 13:07:31 BST 2018 : Detecting whether to updated wpa_supplicant.conf Wed Oct 24 13:07:31 BST 2018 : Starting setup. Wed Oct 24 13:07:31 BST 2018 : Setting up teslausb functionality Wed Oct 24 20:08:32 BST 2018 : SETUP STAGE 2: Verifying environment variables... is reachable...:32 BST 2018 : Verifying that the archive server 192.168.10.18 is unreachable. Try specifying its IP address instead.ver 192.168.10.18 Wed Oct 24 20:08:32 BST 2018 : Continuing setup, but you may need to edit /etc/fstab to verify your archive mount entry is correct Wed Oct 24 20:08:32 BST 2018 : SETUP STAGE 3: Check available space. Wed Oct 24 20:08:41 BST 2018 : Verifying that there is sufficient space available on the MicroSD card... Wed Oct 24 20:08:43 BST 2018 : There is sufficient space available. Wed Oct 24 20:08:43 BST 2018 : Fixing the modules-load parameter in /boot/cmdline.txt... Wed Oct 24 20:08:43 BST 2018 : Fixed cmdline.txt. Wed Oct 24 20:08:43 BST 2018 : SETUP STAGE 4: Create backing files and final config changes. Wed Oct 24 20:09:02 BST 2018 : Mounting the partition for the backing files... Wed Oct 24 20:09:02 BST 2018 : Mounted the partition for the backing files.

Manually executing the offending line worked properly:

root@teslausb:~# /root/bin/tmp/create-backingfiles.sh "100" "/backingfiles" Allocating 5504860K for /backingfiles/cam_disk.bin... mkfs.fat 4.1 (2017-01-24)

I'll try to run through another test later. Perhaps I missed a step?

[rtgoodwin]

@firedfly Major edit of comment, since I wasn't seeing it all before for some reason, just half a log file. Odd. So you're getting (size 100) which is definitely not right, but I didn't change anything about those scripts. (Should be size 1 obviously, 100 / 100.) I'll re-download the latest ancillary scripts to see if something changed. Now, why it worked just fine for me, same SD size and everything, is rather curious. I'll probably also add some setup logging into the partition/files creation since that is one of the most prone bits to fail.

And just to confirm, you DID expect the archive to be unreachable? I.e. wifi is up but you're not at your server, or Wifi didn't come up? ("Expected an error about that" could be read as "I got the expected error" or "I would have expected an error (about X or Y)".)

LMK if you see it again; I'll test it again on my side but also improve the logging and release a new image. VERY much appreciated! :)

[rtgoodwin]

Well, that was a dumb bug, variables weren't actually available. Cutting a new one with quite a bit more logging, checking for stages of setup to not repeat them, and protection against undefined variables where I can. Stand by.

[rtgoodwin]

@cimryan going to restart looking at this, was sick the past day or so. Going to take a bit to re-arrange, I think I will fall back to @firedfly suggestion of downloading scripts at run time. That means I will want to use the main setup-teslausb script, and will want to add some conditional checks into it to detect headless setup. Will try to do it cleanly.

[rtgoodwin]

@cimryan check out updated setup-teslausb. Main changes:

• check for HEADLESS_SETUP
• adapt main setup echo to output to setup log if headless is enabled (but also echo in case you're re-running the script)
• pull in .conf variables if HEADLESS_SETUP
• a check (or two?) to escape certain steps if running from the image (like configuring the hostname)

LMK if ok with this direction; I think it'll work ok. Again this assumes you get wifi up and running, but that's pretty much always going to be the case until/unless we add a path that pre-downloads all the scripts. (Which is doable, for the edge case. Maybe something like OFFLINE_SETUP=true.)

[cimryan]

This looks like a good approach. I encourage you to proceed.

I wonder if our Windows users can use this process. It's possible to run bash scripts on Windows; I'm not sure how much configuration will need to be done. I'll start experimenting.

Meanwhile, this approach preserves the current process, for everyone, which is great.

[rtgoodwin]

Awesome! They shouldn't need any bash scripts at this point, the .conf file will just get pulled in by the image. I might be a little lost there.

[cimryan]

Oh, right. Cool!

[rtgoodwin]

For now the latest image will be at the beta releases page or on the main repo when/if it gets moved there. And the relevant Readme.

OUTDATED: ~Give this one a try~ ~(again make sure to download the zip not the img, though both should work.)~

Flash the image, and put teslausb_setup_variables.conf in the boot dir:

export archiveserver=your_archive_name_or_ip
export sharename=your_archive_share_name
export shareuser=username
export sharepassword=password
export campercent=100
export SSID=your_ssid
export WIFIPASS=your_pass
export HEADLESS_SETUP=true
export REPO=rtgoodwin
export BRANCH=headless-patch

(setup to track my branch for testing since it has the changes to the main setup file)

Pop in Pi Z W and boot!

You can always ssh in and tail -f /boot/teslausb-headless-setup.log for progress. I usually wait until I can ping it over wifi, but to each their own.

Notes (background, not needed for setup):

• It does the bare minimum it needs to setup wifi, then grab and start executing the main script with the variables above. Even if it fails, or you didn't provide the conf file, it's still a ready bootable image for Pi Zero W with USB networking enabled and available at teslausb.local
• If HEADLESS_SETUP=true, then the setup script is run in headless mode. I think I might change the first boot procedure to check for this to be "true" overall, instead of just looking for TESLAUSB_SETUP_FINISHED, so the image is useful for either headless or regular setup.
• I have only tested with CIFS so far though I don't think rsync should fail.
• It's set to use the new variable to determine whether to flash LEDs for progress
• For reasons unknown to me, wget is reaaaaally slow on my setup or sometimes hangs. Using curl for now in the setup script. They should be functionally equal in this usage, and it's much faster.
• If it doesn't finish (return to flashing LED normally after a few minutes and CAM mounts), you can always ssh in and run /etc/rc.local and both scripts seem to be solid enough to re-run safely. Just give it some time to finish. :)
• Need to still export the setup_progress function down into the ancillary scripts just for visibility.
• I need to start putting the images somewhere other than Dropbox too when solid. I think it's in great shape now, but some nice touches as mentioned above are probably useful.

LED flashes to setup stage mapping (although sometimes it's not perfect? LMK): 2 = verify variables 3 = grab scripts 4 = create backing partition/files 5 = done and remount/reboot

@firedfly @cimryan for testing. :) (And whoever else!)

(and pi-gen changes are here )

[skipfire]

I gave this a try and no success and it's been a lot more than 5 minutes. The specified log file does not exist, listing all the files from boot here. The LED is just solid green and the WIFI is not connected and looking at the wpa_supplicant.conf file there is a newline between the end of my SSID and the double-quote.

bcm2708-rpi-0-w.dtb     bcm2710-rpi-3-b-plus.dtb  fixup_cd.dat  kernel.img        start.elf
bcm2708-rpi-b.dtb       bcm2710-rpi-cm3.dtb       fixup.dat     LICENCE.broadcom  start_x.elf
bcm2708-rpi-b-plus.dtb  bootcode.bin              fixup_db.dat  LICENSE.oracle    System Volume Information
bcm2708-rpi-cm.dtb      cmdline.txt               fixup_x.dat   overlays          TESLAUSB_SETUP_STARTED
bcm2709-rpi-2-b.dtb     config.txt                issue.txt     start_cd.elf      teslausb_setup_variables.conf
bcm2710-rpi-3-b.dtb     COPYING.linux             kernel7.img   start_db.elf      WIFI_ENABLED

[rtgoodwin]

@skipfire well that's a headscratcher. I just freshly flashed it and ran it again.

Wait...did you add the HEADLESS_SETUP=true to the conf file? The logging function checks for that now to write the log.

Can you paste the wpa_supplicant file and conf file? (Obviously redact any personal information, but if there's any kind of special character or spacing in your values it would be good to know.) Thank you for testing!

EDIT: I updated the image in previous comment to 10-27 date with a much safer method of generating the wpa_supplicant.conf file. I also added sample .conf.sample files but make sure you have all the variables noted in the comment, especially my branch/repo and the HEADLESS_SETUP=true set. The .conf.sample is meant as a "reference" file to see how many use cases this base image can cover and maybe get rid of all the extra setup steps. :) Tested here 2x, LMK!

[skipfire]

I did not have the last 3 lines as I used what you pasted on the other thread, though since the wpa_supplicant.conf file was populated it had obviously started running, and it has a couple of the marker files there. My guess is that it got stuck when the WiFi didn't connect as it could not pull down the next file run sequence. I'm guessing that the newline may have been a windows vs linux new line without a trim in place to clean them out.

teslausb_setup_variables.txt

[rtgoodwin]

@skipfire I think you're right, very good catch! 😄I guess it never showed up elsewhere since...well I don't have a Windows machine so I haven't been running those setup scripts tbh.

I don't know if you obfuscated the values you just sent over to me, but you might want to remove that text file if not. Fixing the whole line ending thing now in a new image.

[skipfire]

I did replace the values with fakes except for the 2 characters that would be bordering the problem whitespace.

[rtgoodwin]

Alrighty; @skipfire thanks for catching that! ( I added a good old fashioned dos2unix to cover this scenario.)

Please check out https://github.com/rtgoodwin/teslausb/releases for the v.9-beta1 release (or later, if I make more changes when you read this). Instructions are the same as previous posts, but I've also started writing out the Readme to be applicable to using the image for both headless and manual modes of setup (as that's my goal at this point) and it should cover it. LMK if it doesn't.

@cimryan I think the image is actually ready to go for manual setup as is; if you can check it out I'd appreciate it. With the Readme info (obviously just the relevant parts), I think it's a candidate for replacing the first part of setup now, or at least being an option. If you do absolutely nothing but flash the image, it will come up as USB networked and ready to go. From there it's a choice to automate the wifi if you want (just add those vars) or the full setup (add all the vars), minus RSYNC since that still requires manual intervention at the moment. I feel like this may be the way to go moving forward even for regular setup; starting from an image encourages people to write carefully tested scripts that will handle automation well. (And gets rid of a bunch of setup, and manual setup scripts 😄 ).

[cimryan]

I've merged into u/rtgoodwin/headless-patch. I'll work on merging to master tomorrow.

[cimryan]

Merged!