Why Multi-Boot and Time To New Distro Boot

This posting was prompted by a comment here by Bill S:


Bill S says:
7 May 2016 at 12:38 am (Edit)

Please tell me you are retired! I have yet to finish failing to install arch linux on my Pi 3 and you have moved on to Gentoo.

You can feel the “OMG it’s taking me days (weeks?) and he’s done in a flash…” and the implicit “what’s wrong with me” or “wow he’s good”. (Or has all day every day and is retired). I responded with a less than stellar praise of my own history as a “professional” at this… but that’s only part of the story, and a very easy part to indulge. “I’m SPECIAL, [apply praise now!]” is the easy, often wrong, and always to be avoided answer to such things.

Yes, I do have a lot of decades of Unix / Linux experience. Yes, I’ve built it from source tarballs, from tape, from 20 inch diameter platters, from all sorts of antique media in antique ways. Does that help? Not really. It has 2 benefits, IMHO. First off, IF I run into something odd in the hand-holdy tools, I can better guess what’s really going on ‘under the skin’ and how to fix it / work past it. Since that rarely happens on well used tools, like on the Pi, that’s cold tea at best. Second, I’m less likely to be scared off from “just try it” at any given point. Having had to “recover” from some Aw-Shit or another hundreds of times a year (yeah, ‘the fixer’ gets to do that… welcome to ‘consulting’… not all of the A.S. of my making…) it rapidly becomes “ho hum”.

It was that “ho hum” point that is the only bit that really matters. That is what I ought to have addressed, and didn’t.

It really is the case that in OS installs “We have nothing to fear,…. but fear itself”.

What’s the worst thing that could happen? While it is theoretically possible to kill hardware with software (there’s a wiki on that… and it can be done, but is fairly rare), in reality it essentially never happens. Could you force clock setting so high you overheat the chip on 100% duty cycle? Sure. I could also take out a hammer and bash it to bits. Neither one will happen without intentional action beyond the normal.

IF (or maybe I ought to say when… I still do it from time to time) you “blow the install” or “blow the config”, at worst you need to “scrub it and start over”. At most you lose time. Typically not much of that. An install that takes 2 days can cost you at most 2 days from a restart (but even then you rarely restart from the very end, so more typical would be a couple of hours).

For the Raspberry Pi, the install process is so well done, and so fast, and with plenty of opportunities to “checkpoint” (drop a marker where you can restart from that point) that I’d guess the actual install time is a couple of hours, and most of that spent waiting for a download of the Operating System Code if you are on a modest speed wire. Do that download to a nice safe disk, make a copy, you now have a checkpoint to avoid that step. Once you have a basic installed system, you can “clone the chip”. Now you have a checkpoint should you blow up the config or the cat eats the chip. IFF you managed to blow the whole thing, with no checkpoint / restart markers, it’s still just an hour or two and most of that can be spent watching TV, or reading a book, while some process runs.

That’s the stuff I ought to have said.

So with that in mind, I’m going to do, and TIME, a couple of basic system installs to a chip and post those times here. Just so it is clear exactly what the “size of risk” would be, in time. I’m also going to annotate the places where I see it as a “checkpoint”. Describe what I do to make that a checkpoint/restart mark, and describe how to fallback/recover to that point. I’m going to do one NOOBS install, and one BerryBoot. While, in general, I like BerryBoot more, for many things NOOBS is fine. You also find a lot of the “off road” recipes involve bits from NOOBS, so both matter. They are just two different ways to get the Operating System loaded onto the board and running. Two views of the Boot Loader process.

Which brings up the question of “Why more than one?”

Since it IS so fast and so easy to boot an OS, having a ‘spare’ makes for a very nice recovery tool. Hang your system so it won’t boot? No problem, boot the other one and use it to fix the first one. It is always the case that I have “more than one way to boot a system” if at all possible. On VAXen we would have two disks with boot partitions and OS copies. (Sometimes a third, especially when doing upgrades). Lose a disk? Boot the second one. Having different release levels means if a bug in an upgrade bites you, you are one reboot away from recovery. Having different OSs means if one is missing a trick on some feature you need for repair, the other likely is not. Say an update blows a bit in the C Compiler and now it can’t compile the C Compiler… Well getting a “source patch” for that bug is not going to do much good. You are back in “load binary blobs” land, or… boot something else with a working C compiler and use that one to fix the first one.

Raspberry Pi makes this “multi-boot” process seamless, fast, and easy. One of my major complaints about MS Windoze was the very strong “Does not play well with others!” behaviours it has. The internet history is full of tails of woe of multi-boot problems and system death when one of the systems was Windo$e. I can’t help but remember a M.S. “help” site advice about a bug in their OS I was researching “This behavior is by design”. Might their ‘sharing hostile’ behaviour also be by design? Who knows… BUT, the important thing to realize is that for Unix / Linux that just isn’t the case. Multi-boot is common and things usually play well together. (Sometimes they argue, like Seamonkey and Firefox wanting to use the same places to store things – since they are basically variations of the same software – but that’s more the odd case than the norm).

Especially for NOOBS and BerryBoot, they have simple one or two clicks “add another OS” options, and they work very well. For BerryBoot, almost all the time is spent in wait states on your internet speed. Plenty of time to watch a favorite show or make a pot of tea. So I’ll often “load up a chip” with Debian, Fedora, Ubuntu, Puppy, etc. even if I never intend to configure and use them on that chip. They are just “spares”. Since a 16 GB Class 10 chip was on sale at Best Buy this weekend for $9, it isn’t like a 1 GB image is a big cost. About 60 ¢ and maybe an hour? Later, IFF you ever want or need it, you can just ‘boot and start playing’ (or configuring) it.

For me, I like to put a set of ‘build scripts and config files’ on an external disk with my home directory full of my tools. For the Pi, that can be a USB disk, a USB dongle/thumbdrive, or an SD card in a USB adapter. Yes, you could also use NFS Network File System file server to supply them… but that’s more config and fuss especially on a new boot than just “stick in the USB drive used for build tools”. So add another $5 and get a USB thumb drive to hold your build stuff and “life is good”.

Now to configure and build any given system (of a type you have seen before) largely becomes “mount the USB drive, cd to the build-script, run it”. That shaves hours (sometimes days if you need to ‘go fish’ to remember the name of a package to install on that box) of configuration time. Having a copy of your config files ‘stashed’ on that dongle also means you can rapidly recover from a system crash. That /etc/fstab with 2 dozen entries for your 6 disks with both an NFS and EXT partion each, plus swap, with custom flags?

cp /BUILD/debian/DDriver/ETC_FSTAB /etc/fstab

And it is recovered.

Thus my tendency to make a “build script” for any new OS I install and capture the config files in a little USB stick. Next time I’m in the neighborhood, and need that build again, even if things have changed or my needs change, it is a quick edit of the script and a couple of already fleshed out config files and I’m “good to go”. (Then a bit of polish and tune and ‘grab a new copy’ of that particular OS to install, IF I want a newer copy).

Realistically, in many ways that “constantly checkpoint, script your builds, and grab copies of config files” is really the essence of “my experience” advantage. Not some grand deep tech knowing unavailable without decades of experience. (I mean, do you REALLY benefit from knowing how to unpack a boot compiler [compiler compiler in some cases] from the first section of a 9 track tape to then use it to compile the core tools and OS on the tape including the production compiler and libraries for a VAX 780?)

So it is a couple of tricks, a “belt AND suspenders” attitude, and doing checkpoints that’s 90%+ of it. Something that can be learned in about an hour.

Once you learn them, it’s easy to get used to having a couple of OS varieties kicking around. Each one has a personality. Sometimes you need one, sometimes the other. A new WD 2 TB USB disk would not let me change partitions using gparted. It just had to be checked on a Windows box first (chkdsk F: /f or some such) and TWICE at that. Then gparted would let me touch it. So I have a couple of old boxes with XP and W7 on them for things like that. Shut off almost all the time. Similarly, Fedora has a tendency for things to work well and work together, but be ‘hostile’ to letting me do things my way. (SystemD having put that on steroids as now “everything you know is wrong” and things behave oddly at times.) Yet it is a nice ‘sanity check’ at times. Boot it, try the browser, maybe read a man page for some bit that’s not well documented on some other release, etc. etc. But you better like Their Way. Oh, and things are often a release or two back from others. Great for ‘just works’ stability, bad for “I want that new feature or bug patch”. Ubuntu is Debian with an attitude. Yeah, more stable than Debian, but you get things like Unity shoved suddenly down your throat. Debian was a wonderfully flexible playground. Now headed off to SystemD land, so getting cranky. So it goes. Each a flavor. Sometimes I want Chocolate and boot Puppy. Sometimes Vanilla and boot Fedora. Or Strawberry and it’s Debian time… or Chocolate Mint and Ubuntu…

It is also important to expand your horizons. One ought to ‘drink widely’ and know why you chose one over another. To do that, it is best to try them. The cost is low, the experience valuable.

Those are a few of the reasons “why so many OSs?”, but there are more. I won’t spend more time on it, but realize that a moving target is harder to hit (and as Sys Admin you are a target…so “old habits”) and when someone decides to take your system, when that’s 2 dozen of them scattered all over, hard to figure out which one matters… (or know you found it). I suspect that any ‘raid’ on my place would cart off the 4 PCs (with nothing but old Windows on them) and ignore the RPi Chips, if they even knew what they were. (Certainly missing the encrypted blob in The Cloud).

That, and ‘terminal curiosity’ ;-) is why I don’t just “pick one”.

How To, and How Fast

At this point, I’m going to do a new install onto a 32 GB Sandisk Ultra micro-SD card for the R.Pi Model 2. It is almost the same for the other models (the Model 3 is identical for some releases as they have not customized their build to the 64 bit chip, just run it in 32 bit mode).

The Rig I’m using is my R.Pi Model 2. Yes, I’m going to take some re-boots to do things like boot the chip and time that step, then reboot to do the posting. Yes, it would likely be better to do this showing use of a PC, but mine are too out of date to be a decent example. This is more about the timing than the exact steps of downloading a file on Debian vs Arch vs Windows 7, or 8, or 10 (why no 9? Seems that someone coded things to look for 9 back in the W-95 days and did it poorly…)

In the interest of fewer reboots, I’m going to interleave both the BerryBoot and the NOOBs download processes and chip first boot processes. If that doesn’t ‘work for you’, well, I can unscramble them later. ;-)

Overall, the process is:

Download the bootloader of your choice (BerryBoot / NOOBS). Put it on an SD card. Stick that in the Pi and boot it, click to select your OS of choice (or multiple of them), wait while things download, reboot and launch one of the OSs, test drive it or configure it. Finish and do a final backup copy.

At various times there are obvious “checkpoint / restart” places. Right after the NOOBS or BerryBoot image is downloaded. Save it to a disk and you don’t need to download again. I have several saved versions from about 1.4 to 1.9 for NOOBs. Similarly, once the OS or OSs are on the chip, duplicate the chip with the tool of your choice. No more need to download the OS again. I’ve got a packrat library of about 500 GB of various Linux / BSD / whatever OS images. I really don’t like being dependent on a download, and especially for old and “obsolete” hardware, that archive becomes very valuable. (Maybe someday I’ll donate it to the Software Museum ;-) Disk is cheap, time is dear. Download time the most dear of all.

The Downloads Of BerryBoot and NOOBS

NOOBS is the “New Out Of Box Software”. It is a very handholdy bit of code that does things like repartition your SD card for you and unpack the operating system getting it ready to run. A very nice and simple to use, efficient package.

BerryBoot stores the OS image in a more compressed form, so fits more images on a chip (SD card). It also lets you checkpoint the OS any time you want, and fall back to earlier checkpoints. Nice, very nice. However, that comes at a cost of a bit of speed. Not that most folks would notice, but if raw speed is your thing, IMHO a NOOBS system gets up to speed a bit faster and may do file writes faster. (No need to save them in an overlay layer and all that).

In practice, both are fast enough and easy. So now I’m going to download both, time it, and put all that here.

First, NOOBs. It comes in two versions. One with Raspbian built in. Bigger, but once it is installed, you can be done. One that just knows how to find things on the Net. Useless without an internet connection. So if you tether to Starbucks, download the big one… if you know you don’t want Raspbian, the little one; but at first boot assure you have an internet connection.

As I’m now on a relatively fast download link, YMMV on elapse times. In prior experience, it was an hour or two to download a modest sized OS. Now it is often limited on their server speed, not my wire. In any case, just look at the elapsed time and file size and adjust to your wire speed.

NOOBS is here:


And here:


For the gory details and some source bits, and likely other places too. Once it is installed and booted, you can get the OS copies from here:


Berry Boot here:


and here:


And likely other places too.

Time To Download

Note that NOOBS has both a “download” link and a Torrent link. Torrent will likely be way faster, but I’m going to test a direct download since a real Nooby is unlikely to have Torrent set up. I’m also not going to test from Sourceforge or github. They have “big pipes” but also a lot of users so I’m not sure what I’d be testing. (Anyone who cares, and isn’t looking for the tissue box ;-) feel free to post numbers…)

Timing is not by 1/10 second stopwatch it will be by my looking at the time display on my screen. It could easily be off by a whole minute. If you are obsessing over 3 minutes vs 4, you have other problems…

Offline and network install
Version: 1.9.0
Release date: 2016-03-18
Download Torrent
Download ZIP

Network install only
Version: 1.9
Release date: 2016-03-18
Download Torrent
Download ZIP

SO, NOOBs Lite, 27.2 MB direct from vendor: I’d guess it was about 5 seconds. A LOT more time was spent in click boxes and saying “Yes, save it to disk” than the actual download time. Now put that copy somewhere that you can get to it “forever”: and you can save those 5 seconds a few times ;-) Overall elapsed time with window clicks, well under a minute.

NOOBs, 1 GB, takes longer. Interesting… my download has hung at the 860 MB level:

sh-4.3$ ll NOO*

-rw-r–r– 1 chiefio chiefio 28541649 May 11 18:00 NOOBS_lite_v1_9.zip
-rw-r–r– 1 chiefio chiefio 0 May 11 18:03 NOOBS_v1_9_0.zip
-rw——- 1 chiefio chiefio 64897299 May 11 18:04 NOOBS_v1_9_0.zip.part

sh-4.3$ while true
> do
> ls -lh NOOBS_v1_9_0.zip.part
> sleep 60
> done
-rw——- 1 chiefio chiefio 119M May 11 18:05 NOOBS_v1_9_0.zip.part
-rw——- 1 chiefio chiefio 188M May 11 18:06 NOOBS_v1_9_0.zip.part
-rw——- 1 chiefio chiefio 258M May 11 18:07 NOOBS_v1_9_0.zip.part
-rw——- 1 chiefio chiefio 326M May 11 18:08 NOOBS_v1_9_0.zip.part
-rw——- 1 chiefio chiefio 396M May 11 18:09 NOOBS_v1_9_0.zip.part
-rw——- 1 chiefio chiefio 464M May 11 18:10 NOOBS_v1_9_0.zip.part
-rw——- 1 chiefio chiefio 534M May 11 18:11 NOOBS_v1_9_0.zip.part
-rw——- 1 chiefio chiefio 603M May 11 18:12 NOOBS_v1_9_0.zip.part
-rw——- 1 chiefio chiefio 672M May 11 18:13 NOOBS_v1_9_0.zip.part
-rw——- 1 chiefio chiefio 741M May 11 18:14 NOOBS_v1_9_0.zip.part
-rw——- 1 chiefio chiefio 810M May 11 18:15 NOOBS_v1_9_0.zip.part
-rw——- 1 chiefio chiefio 860M May 11 18:15 NOOBS_v1_9_0.zip.part
-rw——- 1 chiefio chiefio 860M May 11 18:15 NOOBS_v1_9_0.zip.part
-rw——- 1 chiefio chiefio 860M May 11 18:15 NOOBS_v1_9_0.zip.part
-rw——- 1 chiefio chiefio 860M May 11 18:15 NOOBS_v1_9_0.zip.part
-rw——- 1 chiefio chiefio 860M May 11 18:15 NOOBS_v1_9_0.zip.part
-rw——- 1 chiefio chiefio 860M May 11 18:15 NOOBS_v1_9_0.zip.part
-rw——- 1 chiefio chiefio 860M May 11 18:15 NOOBS_v1_9_0.zip.part
-rw——- 1 chiefio chiefio 860M May 11 18:15 NOOBS_v1_9_0.zip.part
-rw——- 1 chiefio chiefio 860M May 11 18:15 NOOBS_v1_9_0.zip.part
-rw——- 1 chiefio chiefio 860M May 11 18:15 NOOBS_v1_9_0.zip.part
-rw——- 1 chiefio chiefio 860M May 11 18:15 NOOBS_v1_9_0.zip.part
-rw——- 1 chiefio chiefio 860M May 11 18:15 NOOBS_v1_9_0.zip.part

This is in the “Downloads” directory. So it was cooking along about 70 MB / minute, then at 12 minutes in, hit a wall. Why? Don’t know… This is the kind of thing that folks bang into. Nothing to do with you, much of the time. Other times it is you.. During these 20+ minutes, I made coffee, had breakfast, brushed my teeth… Cost to me of a ‘start over’? Nearly nothing. So I’ll just do another download…

But why would it fail?… Oh, look, my USB stick is full:

sh-4.3$ df .

Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sdd3       26627132 25103760    147732 100% /USB/ext

SO, want to save yourself a half hour?
Check your home directory Download location for 1 GB free first…

BTW, yes it says 147732 blocks available. Those are available to the root user. As I’m doing this is Joe Schmno, the 100% is my limit… After moving some stuff off to another disk:

[root@ARCH_pi_64 ext]# df .

Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sdd3       26627132 23545544   1705948  94% /USB/ext

Still kind of full, but with 1.7 GB free, ought to be enough. Though in reality I’ve chosen to select “other locations” from the bottom left of their download screen and put it on a 500 GB disk that’s got 295 GB free.

So why put this into the posting? Because when folks run into this kind of stuff, and it isn’t in the model on their web page, they think themselves dumb or less competent or just clueless. That just isn’t true. This isn’t a fake example. I didn’t set out to show this. This is just what happened. To me, an expert. It happens to ALL of us. The only difference is I’m jaded about it and just “flow around it” having done it a thousand time before, and knowing I’ll forget to check free space a hundred times again in the future…

OK, after the restart (note that part way through I shifted to the -h Human Readable size on the ls command):

sh-4.3$ ll NOOBS_v1_9_0.zip*

-rw-r--r-- 1 chiefio chiefio        0 May 11 18:45 NOOBS_v1_9_0.zip
-rw------- 1 chiefio chiefio 41266355 May 11 18:45 NOOBS_v1_9_0.zip.part

sh-4.3$ while true
> do
> ls -l NOOBS_v1_9_0.zip.part 
> sleep 60
> done
-rw------- 1 chiefio chiefio 62696627 May 11 18:46 NOOBS_v1_9_0.zip.part
-rw------- 1 chiefio chiefio 111389875 May 11 18:47 NOOBS_v1_9_0.zip.part
-rw------- 1 chiefio chiefio 184036531 May 11 18:47 NOOBS_v1_9_0.zip.part
-rw------- 1 chiefio chiefio 234925235 May 11 18:49 NOOBS_v1_9_0.zip.part
-rw------- 1 chiefio chiefio 295382195 May 11 18:50 NOOBS_v1_9_0.zip.part
-rw------- 1 chiefio chiefio 346107059 May 11 18:51 NOOBS_v1_9_0.zip.part
-rw------- 1 chiefio chiefio 413052083 May 11 18:52 NOOBS_v1_9_0.zip.part
-rw------- 1 chiefio chiefio 490941619 May 11 18:53 NOOBS_v1_9_0.zip.part
sh-4.3$ while true
> do
> ls -lh NOOBS_v1_9_0.zip.part 
> sleep 60
> done
-rw------- 1 chiefio chiefio 490M May 11 18:53 NOOBS_v1_9_0.zip.part
-rw------- 1 chiefio chiefio 559M May 11 18:54 NOOBS_v1_9_0.zip.part
-rw------- 1 chiefio chiefio 628M May 11 18:55 NOOBS_v1_9_0.zip.part
-rw------- 1 chiefio chiefio 697M May 11 18:56 NOOBS_v1_9_0.zip.part
-rw------- 1 chiefio chiefio 766M May 11 18:57 NOOBS_v1_9_0.zip.part
-rw------- 1 chiefio chiefio 835M May 11 18:58 NOOBS_v1_9_0.zip.part
-rw------- 1 chiefio chiefio 905M May 11 18:59 NOOBS_v1_9_0.zip.part
-rw------- 1 chiefio chiefio 974M May 11 19:00 NOOBS_v1_9_0.zip.part
ls: cannot access 'NOOBS_v1_9_0.zip.part': No such file or directory
ls: cannot access 'NOOBS_v1_9_0.zip.part': No such file or directory
sh-4.3$ ls -l NOOBS_v1_9_0.zip 
-rw-r--r-- 1 chiefio chiefio 1069732233 May 11 19:01 NOOBS_v1_9_0.zip

So 19:01 end time, 18:45 start. About 15 to 16 minutes. IIRC, it was about an hour on my old slower network. 1000 MB in 15 minutes is about 70 MB/min or 1 MB / second; call it 10 Mbits / second. Not bad. Original slow ethernet speed.

Now am I stressing over the hour I “lost”? Was I waiting with bated breath through the whole thing? (Well, perhaps baited breath, I had a tin of kippers for breakfast ;-)

Nope. During the first run was breakfast, while the 2nd run I was watching Closing Bell on CNBC and having a light snack. In theory I’m “sick in bed”… In short, MY interaction time was about 2 minutes all told (not counting time writing this posting). Who cares about the elapsed time? You have a life, live some while the machine copes as best it can!

At this time, NOOBS gets copied to an SD card, as per their directions, then you just boot it up and click boxes. It is a zip, so you get to unzip it with your favorite unzipper tool. I’m not going to spend a lot of time on that bit, as it will vary based on the platform you are using and is pretty trivial anyway. To boot Debian with the big NOOBS, just click and go. I am going to shut down this machine, boot Debian and time it, add Arch and time it, then boot Arch. Arch is much smaller than Debian so the time is way less. The Config bits were already covered in “build script” postings.

When I have those timings, I’ll come back and add them to this posting. Yes, I’m posting it 1/2 done. Think of it as a live demonstration…

Here’s what the SD card looks like with the stuff unpacked and copied onto it. I think it took about 2 minutes, but may have to do it again to get the timing better.

[root@ARCH_pi_64 ext]# mount /dev/sde1 /SD  
[root@ARCH_pi_64 ext]# df /SD

Filesystem     1K-blocks      Used Available Use% Mounted on

/dev/sde1       31154688   1047776  30106912   4% /SD

[root@ARCH_pi_64 ext]# ls /SD
BUILD-DATA		    bcm2708-rpi-b.dtb	 defaults	   recovery.elf
INSTRUCTIONS-README.txt     bcm2709-rpi-2-b.dtb  os		   recovery.img
RECOVERY_FILES_DO_NOT_EDIT  bcm2710-rpi-3-b.dtb  overlays	   recovery.rfs
bcm2708-rpi-b-plus.dtb	    bootcode.bin	 recovery.cmdline  recovery7.img

The operating system itself is under ./os and you can add others to the boot process by clicking a button and NOOBS puts them there too. That is what I’m going to do for a “Rapid to get to Bootable” Gentoo; though I’ll be doing it ‘long hand’. (Gentoo normally uses GRUB or Lilo as the boot loader, the process I’m going to do swaps in a Raspbian kernel and NOOBs boot loader with a Gentoo Userland. Then I can use Gentoo to build a new from source Gentoo and make it all more pristine later. But that’s the next project, not for now…)

[root@ARCH_pi_64 ext]# cd /SD/os
[root@ARCH_pi_64 os]# ls -l
total 32
drwxr-xr-x 3 root root 32768 Mar 18 16:56 Raspbian
[root@ARCH_pi_64 os]# ls -l Raspbian/
total 1016416
-rwxr-xr-x 1 root root       1662 Mar 16 19:51 Raspbian.png
-rwxr-xr-x 1 root root   11403300 Mar 18 16:56 boot.tar.xz
-rwxr-xr-x 1 root root        349 Mar 18 16:52 os.json
-rwxr-xr-x 1 root root        420 Mar 16 19:51 partition_setup.sh
-rwxr-xr-x 1 root root        414 Mar 18 16:52 partitions.json
-rwxr-xr-x 1 root root       4667 Mar 18 16:52 release_notes.txt
-rwxr-xr-x 1 root root 1029148804 Mar 18 16:56 root.tar.xz
drwxr-xr-x 2 root root      32768 Feb 23 21:59 slides_vga
[root@ARCH_pi_64 os]# 

To add another OS not already in NOOBs, you can borrow some of this structure, put the other OS /boot in a boot.tar.xz compressed wad, the /root in root.tar.xz, and configure the partitions and such in those files. That’s all for later, though. To just boot Raspbian, or use an existing in NOOBs OS, you get to ignore all this and it “just works”.


This is a 33.7 MB file, so will be very fast to download. It looked to me like it was about 5 to 8 seconds, but the time tools were not that precise. “Nearly instant” for all practical purposes. It is a zip, so you get to unzip it with your favorite unzipper tool.

Again, you get to unzip it, and then stuff it onto a chip.

OK, at this point I’ve got to shut down and time the boot / load OS etc. etc. I’ll be back after those are done and add that information. I will likely also take a nap at some point, and think about lunch. Notice that I wedge in this Sys Admin stuff around a normal Day In The Life? You don’t need to set aside 4 hours to bring up your new Raspberry Pi, it can be “during commercials” or “start it before your shower, finish it after”. As of now, I’ve got my “checkpoints” of those downloaded zip files, and their unpacked versions; so I could even stop now and come back in a few days. Next month, IF I wanted to try Ubuntu, it would just be “copy NOOBs from disk to SD card and boot” then download that OS. No need to bother downloading a new NOOBS or BerryBoot until I feel like it. For me, that’s usually about once / year.

OK, nap time ;-) (well, really ‘after the market close’ financial shows ;-)

Booting NOOBs

For NOOBS, I stuck the chip in the Pi Model 2 and powered on. In about 1 minute, it had formatted the SD card, unpacked itself, and was prompting for what OS I wanted to install. IF you want more than one, they all must have their check boxes checked NOW. Click on one, and then install, you don’t get to pick another one…

As I was interested in testing the speed, having a giant ball of all of them was “sub optimal”. I just did the biggest one, Debian. Yes, the same one we just put on a NOOBs card ready to go. I wanted to test the networked NOOBs Lite speed. It was essentially identical. One minute to get to the “choose your OS selector”, 15 or 16 minutes of download, then a reboot directly into Debian. About 17 minutes all told, I was looking at a Debian desktop. IIRC, that was about 1:20 on my old slower network. Your bounds ought to be similar unless you are on a 56 kb modem somewhere… As all the other OS choices for NOOBs are smaller than Debian (and generally special purpose, like media centers), those installs will go faster.

At this point one would run the Debian Build Script for about an hour… and be fully build / populated in keeping with particular needs in your build script. You can use the desktop while that install of software runs, since it is just adding pieces to an already finished running OS.

The NOOBs also changes around a bunch of partitions on the chip. I have a bunch of other disks attached, so my drive letter is ‘way out there’, while if you put the SD card in a USB adapter, it would likely end up /dev/sda or /dev/sdb if you have a USB stick installed too.
I “became root” by saying “su” (under Arch and then enter the root password) or “sudo bash” (under Raspbian) and took a look at the partitions on the device. The “file” command lets you do that.

[root@ARCH_pi_64 chiefio]# file -s /dev/sdd1
/dev/sdd1: DOS/MBR boot sector, code offset 0x0+2, OEM-ID “MSWIN4.1”, sectors/cluster 32, reserved sectors 102, Media descriptor 0xf8, sectors/track 63, heads 255, hidden sectors 8192, sectors 2280871 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 557, serial number 0x34636230, label: “RECOVERY ”

[root@ARCH_pi_64 chiefio]# file -s /dev/sdd2
/dev/sdd2: DOS/MBR boot sector; partition 1 : ID=0x83, start-CHS (0x3ff,3,16), end-CHS (0x3ff,3,16), startsector 4697, 65534 sectors; partition 2 : ID=0x5, start-CHS (0x3ff,3,16), end-CHS (0x3ff,3,16), startsector 70231, 59965442 sectors, extended partition table
[root@ARCH_pi_64 chiefio]#

[root@ARCH_pi_64 chiefio]# file -s /dev/sdd3
/dev/sdd3: cannot open `/dev/sdd3′ (No such file or directory)
[root@ARCH_pi_64 chiefio]# file -s /dev/sdd4
/dev/sdd4: cannot open `/dev/sdd4′ (No such file or directory)

[root@ARCH_pi_64 chiefio]# file -s /dev/sdd5
/dev/sdd5: Linux rev 1.0 ext4 filesystem data, UUID=fed282bc-0703-4ff0-80a5-fa1c6aa2a6b9, volume name “SETTINGS” (extents) (huge files)

[root@ARCH_pi_64 chiefio]# file -s /dev/sdd6
/dev/sdd6: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID “mkfs.fat”, sectors/cluster 4, root entries 512, Media descriptor 0xf8, sectors/FAT 128, sectors/track 16, heads 4, hidden sectors 2359296, sectors 129024 (volumes > 32 MB) , serial number 0xdd3cb80f, label: “boot “, FAT (16 bit)

[root@ARCH_pi_64 chiefio]# file -s /dev/sdd7
/dev/sdd7: Linux rev 1.0 ext4 filesystem data, UUID=3c552d6f-3498-4b33-ab15-b8acac294308, volume name “root” (extents) (large files)

[root@ARCH_pi_64 chiefio]# file -s /dev/sdd8
/dev/sdd8: Linux rev 1.0 ext4 filesystem data, UUID=bba7be83-66fd-4bdd-811c-4b1ae38278d7, volume name “data” (extents) (large files) (huge files)

[root@ARCH_pi_64 chiefio]# file -s /dev/sdd9
/dev/sdd9: cannot open `/dev/sdd9′ (No such file or directory)

[root@ARCH_pi_64 chiefio]# mount /dev/sdd5 /SD
[root@ARCH_pi_64 chiefio]# ls /SD
cache installed_os.json lost+found noobs.conf os wpa_supplicant.conf

[root@ARCH_pi_64 chiefio]# mount /dev/sdd1 /SDms
[root@ARCH_pi_64 chiefio]# ls /SDms
BUILD-DATA bcm2708-rpi-b.dtb defaults recovery.elf
INSTRUCTIONS-README.txt bcm2709-rpi-2-b.dtb os recovery.img
RECOVERY_FILES_DO_NOT_EDIT bcm2710-rpi-3-b.dtb overlays recovery.rfs
bcm2708-rpi-b-plus.dtb bootcode.bin recovery.cmdline recovery7.img

What this shows is that your one partition SD card now has several partions. The first one is a “RECOVERY” partition. The second one looks like a boot sector MBR. 3&4 are empty I have a hard time saying they don’t exist, since #5 does…) while 5 looks like the /boot file system and 6 looks like /root. User data can be passed between systems on the “data” partition, which is a totally optional partioni picked by ‘click box’ at first boot / install time. But IIRC, the normal user / home directory space is in that “root” file system.

At this point you can make a full image of the card with one simple Linux command. Note that this maex an EXACT image, so if the card is a 64 GB card wqith 2 Meg on it, the image will take 64 GB of disk space in your archive. Use sparingly… The only active line is the last one, the rest of this is a script wrapper to make it easier to use. It expects to be called with one parameter of the drive letter (in my example above, ‘d’, by default ‘c’), and an optional file name (my default is set to /ArchiveDisk/Pi_Chip_Images/Dup_outDATE where I have a little script named ‘mydate’ that gives me YrMonthDay:

echo dd bs=4M if=/dev/sd${1-c} of=/ArchiveDisk/Pi_Chip_Images/${2-Dup_out`mydate`} 
echo -n Ctl-C to exit or 'return' to continue:
read ANS

dd bs=4M if=/dev/sd${1-c} of=/TempsArc/Pi_Chip_Images/${2-Dup_out} 

It also does a ‘df’ so you can see what your present disks are (so as to reduce errors) and shows you the final command it is about to execute. Then gives you a chance to quit.

Overkill? Yeah, probably. For the above chip I couod have just typed:

dd bs=4M if=/dev/sdd of=/ArchiveDisk/Pi_Chip_Images/Dup_Of-New_Test

or whatever paths I chose fo storage. But why type all that if I can just say:

duppi d


FWIW, this is what is in “mydate” and it could just be directly put between the back quotes, but I use it in several plasces: date +%d%b%Y

OK, now for another break and I’ll get that Berry Boot “bringing up Arch” example done…

Booting BerryBoot

At this point I’m going to scrub the card and install Berry Boot on it. More on that in an hour or so.

Using “gparted’ I removed the old partitions on the card, then added a new ntfs partition. About 3 minutes.

When I went to unzip the berryboot file I found that Arch does not have “unzip” installed by default. (Depbian does, IIRC) so I got to do:

[root@ARCH_pi_64 BB]# pacman -S unzip
resolving dependencies…
looking for conflicting packages…

Packages (1) unzip-6.0-12

Total Download Size: 0.11 MiB
Total Installed Size: 0.28 MiB

:: Proceed with installation? [Y/n] y
:: Retrieving packages…

That took a few seconds. Next was to “unzip” the archive. I made a directory named BB (just because I like short names) and made a copy of the bboot.zip file in it. Then unziped it.

[root@ARCH_pi_64 BB]# time unzip berryboot-20160313-pi2-pi3.zip
Archive: berryboot-20160313-pi2-pi3.zip
creating: overlays/
inflating: overlays/ads7846-overlay.dtb
inflating: overlays/at86rf233-overlay.dtb
inflating: overlays/bmp085_i2c-sensor-overlay.dtb
inflating: overlays/dht11-overlay.dtb
inflating: overlays/enc28j60-overlay.dtb
inflating: overlays/gpio-ir-overlay.dtb
inflating: overlays/gpio-poweroff-overlay.dtb
inflating: overlays/hifiberry-amp-overlay.dtb
inflating: kernel_rpi2_aufs.img

real 0m2.346s
user 0m1.940s
sys 0m0.390s
[root@ARCH_pi_64 BB]#

So a few more seconds. Now I could have just doen the unzip ON the card, but this way I get to keep an unzipped copy for my checkpoint…

Next copy the files to the card.

[root@ARCH_pi_64 BB]# ls
LICENSE.berryboot	bcm2710-rpi-3-b.dtb		cmdline.txt   fixup_x.dat	    start.elf
bcm2708-rpi-b-plus.dtb	berryboot-20160313-pi2-pi3.zip	config.txt    kernel_rpi2_aufs.img  start_cd.elf
bcm2708-rpi-b.dtb	berryboot.img			fixup.dat     overlays		    start_x.elf
bcm2709-rpi-2-b.dtb	bootcode.bin			fixup_cd.dat  shared.tgz
[root@ARCH_pi_64 BB]# df

Filesystem      1K-blocks      Used Available Use% Mounted on
dev                430344         0    430344   0% /dev
none             61128740  18057136  39943388  32% /
tmpfs              440852         0    440852   0% /dev/shm
tmpfs              440852       516    440336   1% /run
tmpfs              440852         0    440852   0% /sys/fs/cgroup
tmpfs              440852        52    440800   1% /tmp
/dev/sde3        26627132  23554844   1696648  94% /USB/ext
tmpfs               88172         4     88168   1% /run/user/500
/dev/sdd1        31165436     66936  31098500   1% /SD
/dev/sda3      1910600300 917414284 896110048  51% /Archive/ext

[root@ARCH_pi_64 BB]# cp -r * /SD 
[root@ARCH_pi_64 BB]# cd /SD
[root@ARCH_pi_64 SD]# ls
LICENSE.berryboot	bcm2710-rpi-3-b.dtb		cmdline.txt   fixup_x.dat	    start.elf
bcm2708-rpi-b-plus.dtb	berryboot-20160313-pi2-pi3.zip	config.txt    kernel_rpi2_aufs.img  start_cd.elf
bcm2708-rpi-b.dtb	berryboot.img			fixup.dat     overlays		    start_x.elf
bcm2709-rpi-2-b.dtb	bootcode.bin			fixup_cd.dat  shared.tgz
[root@ARCH_pi_64 SD]# rm berryboot-20160313-pi2-pi3.zip 

Note that I was lazy and let the machine just copy over the zip file, then deleted it later. I probably ought to have moved it somewhere else first, but…

Now it’s time to shutdown again, install Arch and a couple of other OSs, and time that.

IIRC, it was about the same time (being download speed limited) as for the NOOBs install, for each of Fedora, Ubuntu, Debian, but about 15% of that long for Arch as it was smaller. Back in a bit.

OK, that was fun…

While doing the chip partitioning, Arch didn’t give me a choice of “Fat32”. I thought I rememberd it had to be Fat32, but hey, I was already in gparted, so did the ntfs thing.

Well, that would not boot, natch. So a quick chip swap and I booted the Fedora partition on my Daily Driver chip. Why? Because I remembered it had two nice behavious missing in Arch (as of my current state of Arch build…)

First, it does a nice “sense and auto mount on disk / USB stick / SD Chip insertion. No need to hunt around, find the partition name, do a mount, etc. etc. Then just a quick “drag and drop” to copy the Berryboot files over (again)…

Second, the Fedora gparted does have all the file system types available including Fat32. So is this just some level of “Add more stuff to Arch” needed in my Arch build script? Or is it a “missing from Arch, join the devo team? Don’t know and didn’t want to find out now… I knew I’d used Fedora for this and it was quick and easy. So a 1 minute boot, about that reformat the chip, and drag / drop later, I’m booted on the new 32 GB Berryboot chip. With no OSs installed.

Off of the “other” tab, I installed Puppy and Arch. Arch is 199 or so GB and took 3 minutes to load. I could just stop there, reboot, and launch arch and call it “done!” for an Arch install. (Well, plus running a build script to add the bits I wanted…). But this was for timing, and BBoot makes it way easy to add other os images, so I did. Basically it is “click edit” if booting or skip that if doing first installs (that tosses you into the BBoot menu), click the OS you want to install, and then “yes” and wait. How long? It varies wth the OS. Not just the size.

Arch  199 mb  3 min.
Puppy 123 mb  12 min.
Debian 1315 mb  14 min.
Fedora 1175 mb  12 min.

At least this time for this chip.

In the middle of loading those, the spouse decided she had car trouble so I got to do car diagnostics. About 1/2 hour of elapse time is from that… (Fix: Put more tranny fluid in the transmission…)

FWIW, Puppy has matured some at the current release level. Screen is nicer and Chrome works. In fact, I’m posting this update from the Chromium browser inside Puppy. Nice, fast, comfortable. This is less prone to typing lag than Firefox under Fedora or Debian, so might easily become my favored posting platform on the Pi. (For now).

In Conclusion

So there you have it. I’ve got 5 releases installed under 2 different boot loaders in just a few hours, while doing all the usual and customary things of life, while coping with a head cold. Oh, and making a way too long posting during the process ;-)

Hopefully this will show how it isn’t all that hard to bring one of these up, and doesn’t take too long either. Format an SD card. Crag an image onto it. Boot it. Click what you want, reboot, and done. Then optionally run a config script to customize it. (I’ve not customized Puppy, yet I’m using it…)

With that, I’m going to start thinking about dinner ;-) Maybe later I’ll actually go back through this and take out some of the ‘be right back’ interim stuff and clean out the typo’s too ;-)

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.

8 Responses to Why Multi-Boot and Time To New Distro Boot

  1. Pouncer says:

    “While it is theoretically possible to kill hardware with software (there’s a wiki on that… and it can be done, but is fairly rare),”
    Ha! I learned otherwise way back and the hard way.

    Remember an MS-DOS command mis-named “Recover” ?

  2. E.M.Smith says:


    What part of “fairly rare” does not apply to an obscure command on a dead OS?


    But no, I’ve had at most about 5 hours of MS-DOS time and that was at least 35 years ago…

  3. whoknows says:

    ““While it is theoretically possible to kill hardware with software (there’s a wiki on that… and it can be done, but is fairly rare),”
    Ha! I learned otherwise way back and the hard way.”

    From Wikipedia:

    “The program removed all subdirectories and all entries in the root directory, and then created new files with names such as “FILE0001.REC” in the root directory, corresponding to the valid allocation chains that were found in the FAT area (excluding disk clusters that were tested and found to have hardware errors). A formerly bootable disk would no longer be bootable after Recover had executed. The range of circumstances in which Recover was genuinely useful was quite limited, and well‐meaning DOS users sometimes created havoc by running Recover under the misconception that it was a file undelete utility.[2]”

    No, it did not kill hardware unless the hardware was about to die already.

  4. beng135 says:

    OK, I KNOW you’re always doing a dozen things at once, but when are you going to make a customized but adaptable Linux distro (based on some commercial distro) to download for us amateurs? :) I’d pay a bit for it. Maybe you already have one (Smithian? Smithora? Chiefo?)

  5. E.M.Smith says:


    That is sort of what I’m doing. Security oriented (probaly compiled locally from source with optional binary package system). TOR built in though not as paranoid as Tails. Hardware target the Raspberry Pi and similar. Browser and file transfer included, with VPN and NAT router functions. 2nd iteration to use fuse and squashfs to protect /usr and other binaries spaces, reduce size; and RAMdisk to speed it up and make history volatile by default (prompt to ask if any history ought be saved).

    That’s the goal so far. When? Schedule? Likely about a year. Sooner if folks have interest.

    Present status: Rough goals defined (above list). Skills refreshed (recent postings on build scripts for example, and multiple boot loaders mastered, squashfs and unionfs examples). Literature search of other projects done and base tech assessed. (TrueCrypt, Tails, Puppy, Rescue Systems, …), Target base “upstream” candidates selected (Arch, Gentoo, and LFS) with comparative competative evaluation underway (present step). Early build process layout begun (started drawing build process chart and steps – on paper so no posting). Oh, and target hardware designated and aquired. Also discovered distcc as a speedup to the build process, explored it, and demonstrated basic tool chain function; rebuild of cleaner distcc based tool chain platform with multilib for cross compile / uClibc build underway on those 2 new SD chips. Expect to lay out prototype build process and test distcc build in the next week or two, likely on Arch, but perhaps on Gentoo, build engines. LFS Linux From Scratch as a first test case since it is so well defined and tested (I.e. failures likely mine or my build engine) hopefully within 2 weeks, then final candidate upstream chosen and trial build started.

    At that point, my Not Done List bites:

    External spec and feature list
    Project plan
    Sourceforge and github accounts absent
    No marketing at all
    No devo roadmap

    Didn’t know anyone would be interested in that kind of project mgt stuff, but there it is.

    So what would you want in a new distribution?

    That can influence the build base upstream choice. High hardware flexibility pushes toward Knoppix and related (Crunchbang, Puppy,…). Secure and small with “you build it all” from source, but narrow software choices, mostly to learn; is LFS. Very Secure straightjacket, Tails. Highly flexible, reasonably small, Arch. Highly flexible, very secure, you build from source, small hardened uClibc system, with lots of options, but technically challenging, and fast, Gentoo.

    Right now I’m making the tool chain and build monster, but then I’m going to up my skills and test it on LFS. Then I’m leaning toward Arch or Gentoo as the starting point. Followed by a retrofit of Knoppix style RAMdisk, hardware detect, squashsf, etc. as needed.

    So what would other folks like to see?

  6. Larry Ledwick says:

    I would be happy to send you a few bucks for developing such a quick and easy plug and play secure online browsing desktop distribution for the Pi family. Mostly for the peace of mind knowing that someone that I trust and who actually had a clue put it together and likely covered all the important bases.

    I think in the current environment of ever escalating attack profiles on line, a secure minimalist distribution that was “good enough” for most online browsing and day to day web surfing is a great idea. The low power consumption and cost of the Pi families also make it within the reach of just about everyone.

    All I really need on my daily desk top is Firefox some sort of low end word processor so I can do routine documents, maybe thunderbird (although I tend to do email on a separate system not on the daily desk top), and the ability to watch common online videos and open a pdf document.

    That’s it — would cover 98% of everything I do online.

  7. beng135 says:

    Larry’s suggestions above are similar to mine. I have an old machine, so the kernel would have to be “generic” to handle a range of equipment (anyone w/enough motivation could recompile/optimize their kernel — even I’ve done that). But as you outlined your goals above, I’m reminded how difficult those goals could be — very hard to satisfy everyone.

  8. Steve C says:

    I’m following these installation-oriented posts with interest, despite the pi- and berry- based nature – usually a week or two later at the moment, so by the time I might comment you’ve built and commissioned the darn thing so there isn’t a lot of point commenting myself. (Bill S +1!)

    My own hardware is basically a timeline of assorted x86 boxes that have turned up over the years. They all came with some form of Windows, although TBH the Cyrix 200 Win95 machine does take an astonishingly long time to run up. Anything that could help turn a miscellany of machines (realistically, not including boxes quite that historic!) into a semi-usable home network is of interest, and the insights born of those ‘thousands of times’ are interesting and instructive even when I haven’t got nearly that far yet. myself Thanks!

    I tend to agree with both Larry and Beng above – a decently secure structure for day to day use, plus maybe a “howto” coax a working machine out of “whatever’s lying around” (within reason … ) and you’ve given us hours of better-informed fun.

    Plus of course whatever occurs to you … network setup, performance tweaks (I discovered “swappiness” a while ago, and it worked just like it ought!), Scripting for Fun and Profit, whatever. I have a pdf called “Linux System Administrator’s Guide” – these posts about how stuff does or doesn’t pan out in practice are acting as a “Linux System Administrator’s Training Manual”. ;-)

    I really agree with you re systemd. I didn’t teleport over here from Windows land to have to learn how to fight another great blob of “Abandon All Hope, Ye Who Enter Here” at the heart of the system. I was attracted by the whole shape and ethos of Linux – the careful organisation of many small but worryingly capable programs – and when a guy who’s done all this stuff ‘thousands of times’ finds that commands basic since the year dot don’t work, then that system is broken. End.

    Seen the “Argument from System Complexity” which seems to be the main “justification”. Well, that’s a fair argument for a frighteningly complicated installer, but the damn thing shouldn’t remain deep in the underworks breaking the system.

    Having said which, my Mint just keeps on truckin’. All the updates have worked fine, nothing has broken, the Debian installer has worked every time and Wine has run all the Windows progs I’ve tried on it. Life is good.

Comments are closed.