Here's an intro to using rsync for back-up on the Pi. Once the initial back-up is created, keeping it up to date this way is much much faster than constantly ripping the entire image. You can do this to a local hard drive or over a network.
You actually do not want a complete copy of a running system as a back-up, since some of the stuff ostensibly in the ...
This question is answered as part of the answer to other questions, but it deserves canonical treatment here so it does not have to keep being repeated.
You can't mount the image as a whole because it actually contains two partitions and a boot sector. However, you can mount the individual partitions in the image if you know their offset inside the file. ...
Just use the unxz program:
Note: the original file will be removed. Only the .img file will remain.
If you want to keep the original archive, use
unxz --keep kali-1.1.0-rpi2.img.xz
I finally found a resource that is explaining my question.
Yes, truncating is possible!
Summary of the process:
Extracting the partition information from the image using fdisk:
$ fdisk -lu image.img
Disk image.img: 4096 MB, 4096000000 bytes, 8000000 sectors
Units = sectors of 1 * 512 = 512 ...
A working script from the Raspberry Community made by a member there.
You can reuse and tweak the code how ever you like.It is well documented and self explanatory.
# Setting up directories
echo "Starting RaspberryPI backup process!"
# First check if pv package is installed, if not, install it ...
losetup provides partition probing through -P. Using this makes mounting partitions of a full disk image such as the Raspbian SD card image very easy:
losetup -P /dev/loop0 raspbian.img
mount /dev/loop0p2 /mnt
mount /dev/loop0p1 /mnt/boot
On Linux or OSX I use dd to make a backup from SD card. Reverse if and of (i.e. to where they point - source and destination) afterwards to restore, but be careful not to restore to a wrong disk. It will be destroyed without a warning!!!
First use fdisk to get the device id of you SD card (check the size)
then I use dd to make a diskimage (...
To take pictures in 0.025s with picamera you'll need a frame-rate greater than or equal to 80fps. The reason for requiring 80 rather 40fps (given that 1/0.025=40) is that currently there's some issue which causes every other frame to get skipped in the multi-image encoder so the effective capture rate winds up as half the camera's framerate.
The Pi's camera ...
you need to recompile a kernel in order to do that.
create your image with no more than 224 colors, and 80x80px in size.
Save the image as png, and run the following (provided you have netpbm installed and kernel source in /usr/src/linux):
$ pngtopnm logo.png | ppmquant -fs 223 | pnmtoplainpnm > logo_linux_clut224.ppm
$ cp logo_linux_clut224.ppm /...
You mention in a comment to RooTer that A) you have reduced the initial partition size with gparted, but dd still copies the whole card, and B) that you want to include both partitions in the image.
Issue "A" is easy to explain: you are still copying the whole card because that's what /dev/mmcblk0 refers to. The individual partitions are of course /dev/...
In this answer, I demonstrate what to do step-by-step for people to understand the logic behind the solution and to be able to apply steps in their other problems.
But firstly, it should be stated that it is a generic (not raspi specific) problem to migrate filesystems from an SD card to a smaller (but big enough for data) SD card.
A laptop ...
I have adapted @goldilocks answer on rsync for back-up on the pi.
I backup to an ext4 partition on a HDD mounted on the Pi.
If the HDD is not mounted, rsync would copy to the mount directory (until the SD Card is full).
If the HDD is not mounted in rw mode copious error messages are produced.
Neither of these is desirable, so I check that my partition is is ...
So the best way I have found is to use GParted (you can either use a Linux-based OS, or boot from a GParted Live USB). It is simple enough to find detailed instructions on how to do each of these steps in detail, but here is the general method I have found to work:
Run GParted, find your SD card in the device list and shrink the main partition to as small ...
There are several programs to take screenshots. I use scrot, a command line utility wich is quite complete. In your case:
sudo apt-get install scrot
scrot -s and click on the midori window. You will get a timestamp-based png in the working directory of your terminal. See man scrot for more options!
I recently had to make a backup image for my Raspberry Pi 3 Model B and found an incredibly helpful guide from Beebom.
The guide outlines the process for cloning and restoring a Pi SD image for all three operating systems. (Windows - Linux - MacOS). For this detailed and helpful guide visit:
How to Clone Raspberry Pi SD Card on Windows, Linux and macOS.
Ok so I finally found an answer and I wish to share it with you guys.
My guess is that the creators created the compressed file from an expanded image by mistake.
The fact that the compressed file is nearly 1.1 GB, compared to 8.1 GB of the extracted files, proves this. Empty space will compress to a couple of bytes. If there were additional packages, there ...
You could try epeg. It's designed exactly for the job you need - to create fast thumbnails from jpeg files. The only problem is, you need to compile it yourself as there is no package for it for RaspberryPi. It's a library but it comes with a simple test tool that you can use.
The exists a nice tool called pishrink which reduces the size of a dd image as much as possible by shrinking the root partition. If you start up the restored image the first time the partition is expanded to it's maximum size again. If you run Windows just use your Linux on your Raspberry to shrink the image.
Linux / OSX
Download the image from here
Extract the .xz file using any of the following methods
tar xf CentOS-Userland-7-armv7hl-Minimal-1511-RaspberryPi2.img.xz
The Unarchiver (OSX)
Install from Mac App Store here
Use the disk cloning command dd to copy the img contents to your ...
Not quite. You would overwrite the partition tables when you re-image it and replace said tables with the ones from the image. After your imaging program is done, it would release the file handle to the image file, but since the partition where the file is stored technically doesn't exist anymore, your program can't read it again. In theory, it would work ...
I have three Pis running in my local net and need to backup them on a regular base with cron when they are up and running. That's why I created a script which is able to create dd, tar and rsync backups and to restore them. I prefer to use rsync for my backups but other folks prefer dd or tar. It's used by a lot of people already. Hope it's useful for others ...
I had the same requirements as 1 and 2 to distribute a customized OS. After looking around I found many commands, but not a single tool to create a compact .zip file from an SD card, so I wrote mkimg.sh, which works like this:
sudo bash mkimg.sh /dev/sda sdcard.img.zip
This takes the unmounted device at /dev/sda, shrinks down the filesystem and partition, ...
From the picamera docs (Section 4.3. Capturing to a PIL Image):
from PIL import Image
# Create the in-memory stream
stream = io.BytesIO()
with picamera.PiCamera() as camera:
# "Rewind" the stream to the beginning so we can read its ...
This is a synthesis of the answers above and elsewhere that worked for me - back up your image in case you make a mistake:
Firstly make the image file bigger (here we're adding 1GB to the end):
truncate -s +1G ./image.img
Next map the whole image as a loop device so we can poke at the partition table
sudo losetup /dev/loop0 ./image.img
For future ...
TL;DR: uninstall PIL, install and link libjpeg-dev, and reinstall PIL.
The general solution is to install libjpeg-dev before installing PIL:
sudo apt-get install libjpeg8-dev
However, PIL still doesn't know where to find the shared library. Following the general solution (above) doesn't work since the Pi is ARM-based, not intel32/64. Still, it isn't hard ...
The 8GB is only the guideline size of a card. Because of the nature of flash memory and management of dead cells there are slight variations in actual usable space.
This usable space will also decrease as the card gets older and older. With SSD's and SD cards like this it is a good idea to leave a small amount of space that is unused. I would say about 1% ...
Indeed not all SD cards are the same exact size. You'd have to shrink the partition to make it fit on the smaller SD. I had a similar problem myself. What I did was have a separate SD with (in my case) Raspbian. And I plugged in my SD I wanted to resize, using a USB card reader.
Before you can safely shrink you partition, you need to make sure there is no ...