I’d made a NOOBS install onto a 64 GB mini-SD card some 1/2 year back. Then, I’d expected that to be the ‘whole system’. And, for a while, it was. I filled it with about 50 GB of software archives and temperature data stuff and then some. But time passes.
This last 6 months, I’ve moved all the data off of an ‘old’ Western Digital USB drive. It was “only” 111 GB and I’m buying TB sized drives now. So “what’s the point”? of a drive like that…
It got a reformat to have a 2 GB swap partition and the rest ‘user space’ as ext4 file system (journalling and not prone to data loss). Moving data over, and adding Real Swap ™ to the Pi was a pretty nice step forward. It did need a powered hub, but I had one for that purpose.
So my 64 GB mini-SD card was about 7 GB full. The rest, empty blocks.
Aside from just generally being a ‘waste of space’, I could use that 64 GB chip for other things.
But a NOOBS install is simple to do, but complicated on the SD card. There were something like 7 partitions and about 6 ‘unallocated’ spaces between them. (No idea why, but they seem to like leaving 4 MB gaps between partitions). Then there were the three file system types to sort out. FAT16, FAT32, EXT4 (and on some older ones, other EXT types).
I put it off. The Raspberry Pi boot process is “different” and complicated in some ways. It starts on a FAT file system, then moves to the EXT one, and devices are not all the usual /dev/sdxn pattern. Those mmcblk0px ones… (I think that decodes to ‘multi media card, block, card#, partition#) Yes, I know, using ‘sd’ for SCSI Disk is also a bit arcane since it isn’t a scsi disk either…
But today I “bit the bullet” and did the deed. This page was helpful. Largely in getting me the ambition to “go for it”.
It is very useful, but IMHO a bit more complicated than needed. He uses command line ‘gparted’ for example, when there is a nice GUI one. He uses ‘dmesg’ to search the message log for the mount information of the “destination SD card” (while being a bit unclear about was he looking for source or destination card…). Why not just stick it in the USB adapter, have it auto mount, and do a ‘df’ to see the device in the listing? I do that all the time.
But clearly his goal was to make a script of it. So command line is better than the graphics tools for that goal.
My goal was a ‘one off’. So I read it for ‘what do you do’, then did something similar but different.
In the end, it was very easy.
Insert destination SD card. Note /dev/sd? identifier. Open graphical ‘gparted’ from the Menu:Preferences drop down. (Why it’s hidden there I have no idea… if not installed, do an apt-get install gparted.) Look at the two chip layouts (running, to be cloned, and destination). Format and make partitions on the destination that are what you need. (A FAT16 first partition of 60 MB with label boot, and a ‘rest of space’ EXT4 with label root then quit.) Remember to set the flags on the FAT16 to have ‘lba’ set.
He has several warnings about cloning from an active file system, then does it. I just shutdown, put in a different boot system chip, moved the 64 GB to the USB adapter. Sucked out the ‘goods’. Swapped in the 8GB and stuffed them back. Shutdown, swap chips, reboot. I’m using it now to make this posting.
He used an interesting command to do the copy. I’m pretty sure with my approach some simpler ones could be done. As he was running on a live system, he needed to not span file systems and go into places with things like ramdisks or ./proc processes. As mine was not active, I think that didn’t matter (but on the off chance there was a symbolic link and not knowing how they might be handled, I set the ‘one filesystem’ directive).
To copy out from the original /boot /root and /data partitions, I just used the regular defaults you get when the USB adapter shows up.
rsync -av --one-file-system /media/pi/boot /Pi_Archive_dir/Pi_64GB
(where the destination directory is whatever you want, I used a Pi_Archive and sub-directory named for the chip)
The only really tricky bit is remembering to NOT put a trailing slash on /media/pi/root so that rsync will actually create the directory named root and everything doesn’t end up in one pot…
Repeat for /media/pi/root and if you made a 512kB ‘data’ partition when doing NOOBS, for that one as well (if you put any data in it… it is intended for passing data between different OS types).
Then I unmounted those /media… devices, took that chip out, and put in the 8 GB destination chip. Now you ‘stuff it back’ with almost the same commands.
rsync -av --one-file-system /Pi_Archives_dir/Pi_64GB/boot/ /media/pi/boot rsync -av --one-file-system /Pi_Archives_dir/Pi_64GB/root/ /media/pi/root
I chose to do an ‘unmount /media/pi/boot’ and instead mounted them in /mnt/Testing/boot and /mnt/Testing/root just so it was even less likely I’d get the name wrong and hit something else automouted in /media; but that isn’t essential)
Note that there is a trailing / on the ‘from’ directory. That way it does NOT create the boot or root directories. The stuff needs to be ‘top level’ of the partitions… If you cd into the ‘from’ directory first, the commands become much easier to type:
cd /Pi_Archives_dir/Pi_64GB rsync -av --one-file-system ./boot/ /media/pi/boot
All that is left is that there are two places where the number on the mccblk0pX matters. Those have changed, so you need to edit them. cd /media/pi/root/etc and edit fstab. For me, these had been 6 and 7 partitions:
proc /proc proc defaults 0 0 /dev/mmcblk0p1 /boot vfat defaults 0 2 /dev/mmcblk0p2 / ext4 defaults,noatime 0 1
Now you can see that they are p1 and p2. Similarly, cd /media/pi/boot (or /mnt/Testing/boot if you do the remount like I did) and edit cmdline.txt
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
Here, root changed from mmcblk0p7 to mmcblk0p2 and everything else stays the same. Save it and exit.
Shutdown. Swap chips. Reboot. Done.
Really pretty easy once you realize that the goal is not to clone the whole NOOBS environment and all the other OSs installed that you decided to never use again ;-)
Besides, I have a ‘dd’ whole chip clone for that if I ever want one back.
So “Honey! I Shrunk The Chip!” and it’s working fine.
Now on the ‘someday’ list is to do the same thing for the Pi.B+ board doing DNS and bittorrent as I’ve moved all that 50+ GB off to a hard disk there also. That will recover another (relatively expensive) high speed 64 GB Sandisk chip.
Maybe someday, IFF I think it is worth the time, I’ll suck out dedicated chips for the minor OSs on those big chips. I think there are 2 or 3 of them. I basically never use them, but it would be nice to, for example, pull out the Puppy4 install from the bittorent machine chip as I’m pretty sure it will fit on to a 2 GB chip. (That one is a Berryboot chip with even more partitions and maybe a slightly different set of steps / partitions needed. We’ll see…)
Why not just download a new one from The Net? Well, I like to keep old copies of OSs. Sometimes a catastrophic failure in the new one shows up, or you get an old board that no longer works with the oldest online releases, and it’s nice to just pull what works out of a box. Less likely to be an issue with the Raspberry Pi then with the 1001 PC Clone Types… but a habit is a habit for a reason. Besides, in some cases I’ve already customized these a bit. Even if rarely used.
The major lesson here was pretty simple, really. Under all the Berryboot and NOOBS and all, there are just 2 partitions that really matter. Boot and Root. One FAT16, the other EXT4. Make those, copy the stuff over, and go.
So now I have a ‘minimal chip’ with a few layers of stuff out of the way. No greeting boot selector, just “BAM!” right into booting the OS. No wasted space on the chip (for unused partitions, for recovery partitions, for NOOBS or Berryboot processes, for ‘unallocated). It just boots and goes. And with zero need to reinstall software, copy over all my configs or custom bits one by one, nor copy the ‘stuff’ in the user home directory. Launch the browser and it even knew which tabs I’d had open last time ;-)
I still have about 1.9 GB of free space in /root so can add more ‘stuff’ over time, but as I’m moving more “stuff” onto ‘yankable’ USB sticks, it is more likely to shrink than grow. Next step is to make a LUKS encrypted stick and “move onto it”. At that point one tug and all of ‘my stuff’ is encrypted and likely to stay that way… Yes, eventually I’m going to get to a fully encrypted thing… this is more ‘retrofit’ to the old system than ‘how to build new’… the ‘build new’ is that Berryboot with built in encryption and ‘reset’ features. In fact, the ‘stick’, once done, will likely be moved onto that base system. I’m pretty sure that I could just have made the destination partition here a LUKS partition and, once mounted, copy into it as above. Then have /root encrypted. (Guess what I’m doing this weekend ;-)
If you made a big chip your home, with lots of OSs on it you test drove, but never use, now you know how to pull out what you want and leave the rest behind.
If anyone wants more detailed “how to” than the above, just ask, and I’ll put up more examples.