0

A dd solution is provided:

unzip -p 2015-11-21-raspbian-jessie.zip 2015-11-21-raspbian-jessie.img | dd of=/dev/sdb bs=1M

however dd is contra-indicated with the availability of cat. I would like to constrain the question to answers that do not use ddsolutions. Solutions engaging cat (good) or pv(better) to write to the SD card are preferred over dd.

An image of an SD card was successfully copied to sdcard.image with the cat command and burned to a second SD card:

sudo sh -c 'pv /dev/disk2 >sdcard.image'

/dev/disk2 is the SD card

The SD card image is 32GB and was zipped to an 8GB file: sdcard.image.zip. From the command line, how does one unzip and burn the file? Assume there is not enough space to unzip the image to the Macbook's SSD.

The goal is to avoid writing the 32GB file to the laptop's SSD and burn the compressed image directly to the SD card.

Improve this question
9
  • @Freddy Very close, the idea of unzipping and piping the contents into a write command is what I had envisioned. I should have initially constrained the question to preclude dd solutions given that they are contra-indicated in favor of cat. Commented Jan 27, 2020 at 21:27
  • With unzip as the input you probably do want dd in the pipeline to coalesce part block reads into single block-sized writes. (iflag=fullblock). Commented Jan 27, 2020 at 21:39
  • @roaima: I would guess that the SD card driver would make this unnecessary.  What am I overlooking? Commented Jan 28, 2020 at 4:21
  • @G-Man I'd prefer to write entire blocks rather than dribbles. Efficiency, and reducing the number of consecutive partial writes to the same SSD disk block. Commented Jan 28, 2020 at 7:49
  • @roaima: Well, we agree that doing multiple physical writes to the same physical block of a storage device is a bad thing.  But (1) when I started using Unix, there were two kinds of device nodes (/dev entries→inodes) for storage devices: block special devices (a.k.a. “cooked”), e.g., hd0, and character special devices (a.k.a. “raw”), e.g., rhd0.  The raw device interface permitted more-or-less direct access to the hardware, which was sometimes beneficial (especially in the case of large block sizes) and often deleterious (especially in the case of small block sizes).  … (Cont’d) Commented Feb 3, 2020 at 8:58

1 Answer 1

Reset to default
1 
unzip -p sdcard.image.zip sdcard.image >/dev/disk2/

man unzip provides an explanation of unzip with options shown for MacOS X, and this link is the equivalent for Debian.

FYI, data is 'written' to SD cards because they are an inherently read-write medium; 'burning' is a term used for optical media. If you are copying data out of an archive (zip or otherwise), you are 'extracting' it.

Improve this answer
4
  • The OP has been updated to indicate the SD card is at /dev/disk2/. If /dev/sdb is replaced with /dev/disk2/ should I expect the command to write the .image file to the SD card as it is unzipped? Does the ... act as a wildcard or do I need to replace this with the image filename? Thank you Commented Jan 27, 2020 at 21:16
  • ... just means "gimme the fully qualified path name" a la en.wikipedia.org/wiki/Fully_qualified_name#Path_names Commented Jan 27, 2020 at 21:27
  • The suggested command has been updated with a concrete example: my best guess at what I think you are suggesting. Please adjust as necessessary. Commented Jan 27, 2020 at 21:32
  • How about unzip -p sdcard.image.zip > /dev/disk2/sdcard.image Commented Jan 28, 2020 at 18:11

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.