Fyi the link from the jefftk.com version of this post to the LessWrong crosspost is broken -- it has an extra consecutive slash in it, https://lesswrong.com//posts/6jKECJocj8o7nxGmd. It seems to be only this post, not any of the other posts that I checked.
Fixed, sorry!
(Manually typed an extra slash when adding the reference: lw//posts/6jKECJocj8o7nxGmd when I should have had lw/posts/6jKECJocj8o7nxGmd)
+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.
About a year ago I moved my rhythm stage setup over to run on a Raspberry Pi. I really like having a small light box that does just this one thing. Currently I have two of them, one for the whistle synth and one for everything else.
Because I wanted some insurance against failures at gigs, both boxes are configured identically, and decide which role to take on based on what inputs they receive. This means that if one of them fails I can use the other, for either bass whistling or midi silliness depending on which I need more.
When Kingfisher played our first dance weekend a month ago, this did happen. I think the SD card on one of the boxes was corrupted by a bad shutdown. Since I have extra SD cards, I decided to make some SD card clones.
On my Mac this looked like:
$ diskutil list /dev/disk0 (internal): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme 500.3 GB disk0 1: Apple_APFS_ISC 524.3 MB disk0s1 2: Apple_APFS Container disk3 494.4 GB disk0s2 3: Apple_APFS_Recovery 5.4 GB disk0s3 /dev/disk3 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +494.4 GB disk3 Physical Store disk0s2 1: APFS Volume Macintosh HD 15.4 GB disk3s1 2: APFS Snapshot com.apple.os.update-... 15.4 GB disk3s1s1 3: APFS Volume Preboot 446.8 MB disk3s2 4: APFS Volume Recovery 822.2 MB disk3s3 5: APFS Volume Data 251.1 GB disk3s5 6: APFS Volume VM 1.1 GB disk3s6 /dev/disk4 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: FDisk_partition_scheme *31.3 GB disk4 1: Windows_FAT_32 boot 268.4 MB disk4s1 2: Linux 31.0 GB disk4s2Seems like the SD card is /dev/disk4.
Best to unmount it before reading from it, and required before writing to it.I made an image:
Swap the SD card for another,
diskutil unmountDisk /dev/disk4again, then write the image:Pop the card out, put it in the Raspberry Pi, and it works!
I compressed the image to save for later:
Looking forward to playing Spark in the Dark a week from Saturday with a little more tech redundancy!
Comment via: facebook