+1 for documenting neat little hacks. I’d recommend putting it into a script you drop into a repo on github, just so you always have it, and it makes a neat way to publish/share it easily. Beware, it’s a DEEP rabbit-hole to try to autodetect the right devices and temporary spaces to use for copying. Note also that if your rPi model has USB ports, adding a second (or third) SDCARD adapter is easy—you can’t boot from it, but you can image cards from the pi itself, which is a little easier (especially if you need to mount and update the image) than from a mac.
When I worked in a team that was developing for rPi (peripherally—my main role was server software, but I’m a hacker and can’t keep my nose out of things), I set up an imaging server for various rPi models—individual workstations used a config file to specify the sdcard device, and pulled the image from a central server. The image had been customized to find the local config on first boot (as part of DHCP, based on MAC address), and we just regenerated new images each week, never updating any devices at all, just re-imaging them.
Eventually, we got smarter, and built a self-installing image, so the image was like 20MB, enough for first boot and download/install the “real” image, then reboot into that image. This also made re-imaging doable in-place, just by booting into the imaging partition.
I’d recommend putting it into a script you drop into a repo on github, just so you always have it, and it makes a neat way to publish/share it easily. Beware, it’s a DEEP rabbit-hole to try to autodetect the right devices and temporary spaces to use for copying.
These seem to be in conflict? I find writing down what commands I ran and how is often a good sweet spot for something I do rarely, and then I don’t have to worry about automating edge cases.
you can image cards from the pi itself, which is a little easier
I don’t have much of a reason to do this: my pi is a turnkey music-making box, not a general purpose computer. I’d much rather work on my mac, which is set up for development, has a monitor and keyboard, etc.
+1 for documenting neat little hacks. I’d recommend putting it into a script you drop into a repo on github, just so you always have it, and it makes a neat way to publish/share it easily. Beware, it’s a DEEP rabbit-hole to try to autodetect the right devices and temporary spaces to use for copying. Note also that if your rPi model has USB ports, adding a second (or third) SDCARD adapter is easy—you can’t boot from it, but you can image cards from the pi itself, which is a little easier (especially if you need to mount and update the image) than from a mac.
When I worked in a team that was developing for rPi (peripherally—my main role was server software, but I’m a hacker and can’t keep my nose out of things), I set up an imaging server for various rPi models—individual workstations used a config file to specify the sdcard device, and pulled the image from a central server. The image had been customized to find the local config on first boot (as part of DHCP, based on MAC address), and we just regenerated new images each week, never updating any devices at all, just re-imaging them.
Eventually, we got smarter, and built a self-installing image, so the image was like 20MB, enough for first boot and download/install the “real” image, then reboot into that image. This also made re-imaging doable in-place, just by booting into the imaging partition.
These seem to be in conflict? I find writing down what commands I ran and how is often a good sweet spot for something I do rarely, and then I don’t have to worry about automating edge cases.
I don’t have much of a reason to do this: my pi is a turnkey music-making box, not a general purpose computer. I’d much rather work on my mac, which is set up for development, has a monitor and keyboard, etc.