• When the Imager starts, it apparently checks if it's up to date because buried in the executable are strings like "There is a newer version of Imager available. Would you like to visit the website to download it?" [I'm too lazy to try to read the C++ source code to see how this is done.]
  
• The list of OSes offered is downloaded from an RPi site (and the sites of 3rd party OSes) so they should stay up to date.
  
• In particular, the info about moOde and the moOde image itself are downloaded from our sites so they should stay up to date
  
• The Imager caches the last OS it downloaded. This is a big point to me because I hate seeing repeated downloads when I'm burning multiple copies. On my Linux box, the downloaded file is stored as ~/.cache/Raspberry Pi Imager/lastdownload.cache
  
• Since that file could be overwritten by a different download, I prefer to save it separately with its real name, image_2023-03-14-moode-r830-arm64-lite.zip, for example, and use it in Imager as a Custom OS but YMMV.
  

(03-27-2023, 06:14 PM)Nutul Wrote: This is very nice, indeed.
It would be fantastic if it also allowed the whole configuration from the command line... ;-)

(03-27-2023, 08:35 PM)TheOldPresbyope Wrote:

(03-27-2023, 06:14 PM)Nutul Wrote: This is very nice, indeed.
It would be fantastic if it also allowed the whole configuration from the command line... ;-)

I get that...but AFAICT tell it's complicated. Maybe if I were proficient in C++ I would think otherwise. Check the github issues log for some related discussion.

The Imager creates a firstrun.sh file in the /boot directory and all the magic about the first user/pw and its home directory, as well as SSH, WiFi, etc., gets done by it during, you guessed it, first boot. Then it deletes itself.

This isn't all that different from what traditionally happened with the moodecfg.ini file, if present. Obviously, though, firstrun.sh is executed directly in the shell. To an extent they overlap in functionality. If the .ini file is present at first boot now, settings in it may supersede some settings made by firstrun.sh---notably hostname and WiFi configuration. Still, I continue to add in moodecfg.ini because it gives me more control over moOde as opposed to just Raspberry Pi OS.

I'm thinking that for my own use I may cobble together a solution of my own strictly for moOde which would flash a new player where all my "standard" settings remain the same except for the hostname (and renderer names based on it)---but I sure wouldn't want to offer it up and then have to support it

Regards,
Kent


PS - Boy does it get boring watching the progress bar creep forward as I repeatedly flash uSD cards to test what's going on. I need to get myself some super-fast cards.

Quote:download the image / patch it / flash it.

(03-27-2023, 09:45 PM)TheOldPresbyope Wrote:

Quote:download the image / patch it / flash it.

What I have in mind, skip Imager cuz I don't need a universal tool, just a little script so my fingers don't have to leave my hands, as an old joke used to go.

(03-27-2023, 09:45 PM)TheOldPresbyope Wrote:

Quote:download the image / patch it / flash it.

What I have in mind, skip Imager cuz I don't need a universal tool, just a little script so my fingers don't have to leave my hands, as an old joke used to go.

(03-27-2023, 10:47 PM)TheOldPresbyope Wrote: Ah, yes, the backup file. Sorry I didn't mention it.

Typically, though, my heaviest usage is in flashing new players (constantly popping out "virgin" players to test one user issue or another) rather than bringing forward a backed-up system. Different strokes for different folks!

Regards,
Kent