Make base flashable image #39
Comments
|
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:
|
|
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. |
|
Weird, email update didn't post. Trying again: 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. |
|
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. |
|
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 |
|
I see two potentially separable proposals:
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. |
|
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 |
|
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: This may already be addressed but just popping here for reference. Archive log (obv time zone is off, not entirely sure why): |
|
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. |
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. |
|
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:
LMK if it does/doesn't work for you please, feedback needed! :) Worked great just now; I've only tried it with campercent=100. |
|
A few thoughts:
I'll try to test this tonight and see how it goes. |
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 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.
It's set to check:
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 |
|
I just tried to boot up the new image with the config file. I manually supplied a I had a failure in Errors on screen (copied as best I could...). The login prompt appears after the last line:
Contents of /boot/teslausb-headless-setup.log
Manually executing the offending line worked properly:
I'll try to run through another test later. Perhaps I missed a step? |
|
@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! :) |
|
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. |
|
@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 |
|
@cimryan check out updated setup-teslausb. Main changes:
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.) |
|
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. |
|
Awesome! They shouldn't need any bash scripts at this point, the |
|
Oh, right. Cool! |
|
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: Flash the image, and put (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 Notes (background, not needed for setup):
LED flashes to setup stage mapping (although sometimes it's not perfect? LMK): @firedfly @cimryan for testing. :) (And whoever else!) (and pi-gen changes are here ) |
|
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. |
|
@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 EDIT: |
|
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. |
|
@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. |
|
I did replace the values with fakes except for the 2 characters that would be bordering the problem whitespace. |
|
Alrighty; @skipfire thanks for catching that! ( I added a good old fashioned 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 😄 ). |
|
I've merged into u/rtgoodwin/headless-patch. I'll work on merging to master tomorrow. |
|
Merged! |
Working on this as a test project to ease a lot of setup. Please mark enhancement.
The text was updated successfully, but these errors were encountered: