Shrinking NOOBS on Pi

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”.

http://sysmatt.blogspot.com/2014/08/backup-restore-customize-and-clone-your.html

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.

/media/pi/boot
/media/pi/data
/media/pi/root

like this:

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.

In Conclusion

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.

Subscribe to feed

About E.M.Smith

A technical managerial sort interested in things from Stonehenge to computer science. My present "hot buttons' are the mythology of Climate Change and ancient metrology; but things change...
This entry was posted in Tech Bits and tagged , , , , , . Bookmark the permalink.

7 Responses to Shrinking NOOBS on Pi

  1. Larry Ledwick says:

    Still collecting pieces to build what I want, but keeping an eye on your posts about the R Pi 2.
    Like I mentioned a while back I have two of the R P1 2’s but one is a china manufacture which I would rather not use for a high security build. Will probably park it to a testing role. Will be ordering some more stuff soon but life keeps getting in the way.

  2. E.M.Smith says:

    @Larry:

    I doubt that their is any buggerage in the R.Pi even from China. The design team in Britain will be taking a close look at ‘samples’ and has they are hacker boards, folks all over the world will be looking at things like packets and web traffic. Add in that the odds of one of these going anywhere they Chinese Govrernment wants to crack (government, businesses) and it’s just not worth the time and budget. Much much more can be gained by hiding viruses in USB sticks.

    (At one company a batch of thousands with custom shape and colors were ordered for a marketing campaign. About 1 in 10 was loaded with a virus payload. We tested 100% of the batch by hand, and shipped the “loaded” ones back to China. I have no idea what happened at the “business” level per the contract and, er, “compensation”… but I’m pretty sure once it was all done they were informed no more business would be arriving… Part of why I prefer SC cards where their is little incentive to put a virus in a camera… and LOTS of folks are looking at the bit flow in ‘devices’ and lots of reformatting is done and…)

    I’d be quite happy to use the one from China for things like testing installs, doing general webserfing and data gathering from public sites. I might even be willing to use it for things like DNS server and bittorrent server. All places where it is exposed to the internet anyway.

    My hard-core back room stuff would not go onto it and it would not be running at the same time. Yes, I’m quasi paranoid about China source… but that’s the result of experiences… Though maybe if I could suck out the ROM and do a bit compare with the non-China one…

  3. Larry Ledwick says:

    I can send both of them to you if you want to do a compare and contrast test series with it and a UK board. If you want to try that just email me a shipping address. I have no urgent time table to use them (have others on order) and would be glad to support the discovery process.

  4. E.M.Smith says:

    @Larry:

    I’m already “booked up” on projects for a month or three… If I haven’t bought one by then, I’ll holler. Or if I figure out how to do a “suck the bits out of the ROM” I’ll post ;-)

    No sense taking possession of the boards if I don’t know how to get the bits out yet… (Likely from the expansion pins… It’s basically just suck the ROMs / ASICs out and see what’s in them Do a bit compare between the two.)

    Time passes as he spends 10 minutes trying to find some page saying “Raspbian ROM dump”… then finally decides to look at the boot process and find out when it hits ROM and finds:

    https://thekandyancode.wordpress.com/2013/09/21/how-the-raspberry-pi-boots-up/

    The SoC (or System-on-Chip) contains the ARM CPU, the VideoCore Graphics Processor, ROM (Read-Only-Memory) chips, the SDRAM and so many other things. Basically, think of a SoC as your Motherboard and CPU compressed together into a single chip.

    When you power on your Raspberry Pi, the first bits of code to run is stored in a ROM chip in the SoC and is built into the Pi during manufacture! This is the called the first-stage bootloader. The SoC is hardwired to run this code on startup on a small RISC Core (Reduced Instruction Set Computer). It is used to mount the FAT32 boot partition in your SDCard so that the second-stage bootloader can be accessed. So what is this ‘second-stage bootloader’ stored in the SD Card? It’s ‘bootcode.bin’. You might have seen this file if you had mounted the SD Card in Windows. Now here’s something tricky. The first-stage bootloader has not yet initialized your ARM CPU (meaning CPU is in reset) or your RAM. So, the second-stage bootloader also has to run on the GPU. The bootloader.bin file is loaded into the 128K 4 way set associative L2 cache of the GPU and then executed. This enables the RAM and loads start.elf which is also in your SD Card. This is the third-stage bootloader and is also the most important. It is the firmware for the GPU, meaning it contains the settings or in our case, has instructions to load the settings from config.txt which is also in the SD Card. You can think of the config.txt as the ‘BIOS settings’ (as is mentioned in the forum). Some of the settings you can control are (thanks to dom):

    Basically the 1st stage bootloader is in the SOC so not hackable. As long as the SOC is from a proper set of masks (and they pretty much must be), it is clean. All it does is have barely enough smarts to get to the 2nd stage boot loader and THAT comes from the SD card that comes from the Raspberry Pi folks web site. Outside of Chinese reach.

    I vaguely remember reading this once about 2 years ago and thinking it was more or less ‘hack proof’ at the ROM level… As LOTS of these chips go into routers and embedded systems that are heavily attacked, folks put effort into make them ‘sturdy’…

    Essentially, you are trusting the SOC vendor (Broadcom) and the Pi Foundation. Even on Chinese boards. I can live with that. While it would still be possible to make a counterfeit SOC, and substitute it, you are putting a lot of expensive effort into something with near zero potential for return. Even then, it just hands things over to stage 2, and loses control anyway… Very hard to work around that.

    I’m not seeing a way to work past it. Maybe someone else can, but to me it looks pretty bullet proof.

  5. Larry Ledwick says:

    Thanks! That answers lots of my questions about the boot process.
    There are some differences in appearance on the boards, I will have to see if they both have the same SOC chip installed or if the PRC manufacture device has radically different chips on the board and any identifying markings on the chips. A quick look both have similar appearing Broadcom chips on them but slight difference in the numbers on the chips. Might be just different series of production or slightly different model versions. Pretty busy at work right now so not much time to fiddle with a deep dig project on the Pi boards myself.

  6. E.M.Smith says:

    @Larry:

    It would be “darned hard” to bugger the Broadcom chips. Not only is the boot incredibly dim (meaning not much to work with…) but the only thing it does is load the next stage, that then loads a 3rd stage. BOTH of them go into the GPU, not the CPU, and anything in the CPU space gets overwritten with the OS is loaded, that then nukes anything in the GPU space. In the end, it is a self scrubbing process of sorts. (Many ‘old school’ boots are like that).

    Compare the “modern” PC where the OS is essentially a guest of EUFI that is lurking around all the time, and where it is wide open in a “one target globally for Billions of users” kind of way. Or Chrome which is “all your data are belong to us and all your traffic flows throught us” by design to Google (and through them the NSA).

    Now the Pi has nearly a zero “user base” of anything of interest in that context. Just not a “target of interest”. It uses a “strange chipset” compared to the Wintel world. AND, it has a half dozen operating system targets all of which are pretty hard to crack compared to MSWindoz that comes pre-cracked. Major “line of attack” would be phishing and browser weaknesses, not chip buggering. MUCH easier to get you to click on the “I want free stuff” or “Asian Lady want meet you much!” link and put a Javascript bug in your browser.

    Buggering the Broadcom SOC would be very very hard, very very expensive, return nearly nothing, and have a very high probability of being discovered as this is a ‘hacker board’ and all sorts of folks are poking it at the bit and bite level. Also note that since there are a half dozen OS targets, they each can do something different, and they can change at whim (not just on a MS release schedule of once each few years) it would also be very very hard to keep it working correctly with ALL those targets, while having a buggered boot. Something is very likely to crash or hang and they your board ends up in the “Return to engineering to debug” pile… and you get caught.

    With that said, if you want to put up the serial numbers from the two SOC variations I’d be willing to do a search on them and see what the difference is. Chips do ‘rev’. More often than you might think. Things get a little faster, or some strange ‘edge case’ is found in the design that the OS ‘patches around’ but you rev the chip anyway to fix that mistake. Or one has a bit mre memory than the other. Or a bit more speed. Or a different layout mask as a sllight change of trace routing gave a few percent more yield of die that worked. Or… So just having different marks does not of neccessity say something is wrong. A quick check of release notes for the two chips would likely clear it up. (Some of the things wrong in some early Intel CPUs on any given number series can make your hair stand on end. Remember the “Repentium” bug where it could not do math right all the time?…)

  7. Larry Ledwick says:

    Yes remember the Pentium bug very well had a friend who get bit hard by it. He worked in a county assessment office and they figured tax assessments on property to about 6 decimal places. He got a new computer (so it would be faster) and discovered all his assessments changed (Ooops). He was one of the first reporters of the issue as I understand it.

    I am not really worried about a buggered chip just curious.

Comments are closed.