Infrastructure R.Pi Build Progress

Just a quick note about the status of building out compute infrastructure using the Raspberry Pi.

This is related to making a very secure and private Tails like R.Pi as a secure workstation; but is more of ‘all that back room work’ most folks don’t think about.

I have two Raspberry Pi boards in use at present. A third one, a R.Pi B+ model, didn’t survive the trips to / from Florida. Likely as I didn’t have any anti-static protection on it and Florida has a LOT of lightning and the associated charge. The one in the antistatic bag did fine. I had expected to use three boards for all this, but in fact 2 is more than enough.

The first board, a R.Pi B+ model, is doing most of the infrastructure. The second, a R.Pi Model 2, is acting as the workstation. I’ve covered the performance of it before. Adequate, not great, some small type ahead in WordPress editing, and not quite doing sound / video as I want; but that will improve as software gets debugged (and / or I update the system ;-)

This posting is mostly about the use of the B+ as infrastructure server.

Up until now, I’d had the Powered USB Hub on the R.PiM2 along with all the disks. I’ve been unpacking a decade worth of backups and storage grabs from various computers as they neared End Of Life (or in some cases after brief resurrection). Over the years, having backed up A to B, then B (with A) to C, then C dying, dumped the wad back on A, that… We’ll, it doesn’t take too may “powers of 2” and we’re talking Terabytes. So it was time to take out some trash. I’ve been at it for a couple of weeks now, and likely still have a couple of more to prune down to what is really useful. That went faster on the M2.

But I’d also launched a data scrape for temperature data. Due to little clue how big the source was, what I expected to take a day or two is still running. I’m presently at 322 GB used for temperature site data and rising… That tended to ‘lock down’ the M2 and the associated terminal / screen as it ran for days. Which precluded using other computers with ‘the good screen’ and precluded advancing on development as the machine was ‘working’.

So for the last couple of days I’ve “bit the bullet” and did the back end work to make the infrastructure more supportive of my varying work style.

The Model B+

First up, I moved the Powered HUB and the disks onto the R.Pi B+. I expected the thing to sag under the load, but it is doing just fine. In fact, it worked reasonably well for the last couple of days of ongoing unpacking.

The only really big thing I noticed was that when doing an ‘unzip’ or ‘gunzip’ or similar, it tends to “peg” the CPU at full (and other processes slow down). When running NFS Network File Services it spawns somewhere over 1/2 dozen nfsd daemons and if you try to run a couple of decompresses, a heavy NFS transfer, and a disk to disk copy; well the poor dear does it, but things bog down. So you learn to only have a couple of things going on at once.

I could have the wget scrape, a modest NFS file transfer, and one unzip going and that was about fully loaded. The M2 would just put the uncompress function on one CPU, NFS on another, and the minor loads like the wget and everything else on a third and still be only about 65% CPU used. One unzip or decompress and the B+ took all available cycles. The scheduler does a good job of it, though, so the NFS slows down or the unzip, but terminal response stayed OK. Just don’t expect this little board to serve a compressed file system on the fly to 1/2 dozen clients while archiving the news… and playing your favorite songs…

What all do I have on it now?

Well, it is an NFS file server for 3 TB of data (soon to be 4 TB I think), it is doing 2 wget site scrapes, I have DNS running from it, and it is doing sporadic Bittorrent Server service for 26 GB of old Linux (soon to be upgraded to more like 500 GB and newer versions too ;-) along with Samba (Microsoft file services) running but not tested yet, and an Apache Web Server that works, but only has one generic page and isn’t being hit with traffic at all other than when a mangled URL hits.

That seems to be a decent load level for it. When not heavily trafficked, it is running about 30% to 50% CPU, and only goes to 100% with decompressing, large file moves locally, or very heavy NFS traffic (usually in combination). I’m quite happy with it as ‘The Infrastructure Box’. (On the ‘someday’ list is to buy a replacement for the dead board, and duplicate the OS/SD-chip from this one, put it all in a metal ammo-can, depot it somewhere safe and have the whole thing ready to go if I ever need an instant “back in service” effort. Also put an encrypted copy of the data in ‘The Cloud’ somewhere obscure.)

The Model 2

This machine is now freed up for further development work. I’ve also moved my “home directory” onto a USB dongle. It can move between machines so that I always have “the usual tools” available. It can go on the Chromebox, the ASUS, or the Pi as the mood hits. Also, the ‘disk farm’ is now NFS mounted on any machine that needs it.

While I’ve not found how to mount NFS files onto the Chromebox, that hasn’t been an issue, really. It’s a low priority. I did find that you can get a terminal server with Ctrl-Alt-T and that you can install an SSH server app. (They have removed SSH from CROSH the Chrome Shell – a mistake IMHO). So yesterday I had the Chromebox on The Good Monitor enjoying videos and music (something it does very well…) while having two SSH Terminals open in tabs on the Pi.B+ doing file management. All near silent.

Today, I’ve moved the monitor to the R.PiM2 and I’m doing this posting with a few, more usable, Terminal Windows opened. A real Linux with real terminal windows works much better than tabs on the Chrome browser, IMHO. And this, too, is essentially silent. I also don’t have to wonder if the “App” in Chrome is creaming off my login and password and shipping it to Google… Not that I think they care about my 2 TB of temperature data, Linux antique release archive, and canonical collection of dead Windows Machines Software… but it’s the principle of the thing… So while it is nice to know I can do Systems Management from a SSH App in the Chromebox, I’d rather use a system that can be shown locked down.

I do still get the Boot Rainbow screen saying the power supply provided is a touch weak (likely the same one shipped with the prior Pi models and they didn’t think that the 4 core might need more…) but it has not made the little rainbow square in the upper right when running to say it’s weak once booted. Oddly, some afternoons I’d get that when it had a loaded USB hub on it. Just about peak A/C demand time. I suspect the power company was sagging volts by a few then. We’ll see what happens this afternoon. Only on hot days did that happen, and not enough to crash the box. It could also just be that the little power brick doesn’t take hot days well and sags then. Further testing for “someday”. Just realize that an Industrial Power Brick would be better if you intend to load up a Model 2 with stuff and work. The provided one is “ok I guess”, but will go to the next B+ I buy when I’ll also get that oversized power brick.

I have my TBs of data mounted via NFS on the “machine du jour” and today that is the Model 2. I’ve also had them mounted to the ASUS box. USB ‘home directory’ dongle moving between both. One ‘trick’: Make a generic home directory so you can log in and use the box without the dongle. Then mount the dongle file system over the top of it when desired. Now all your history and browser cache and such moves with you. Unmounted, the box looks like a normal generic Linux, with a sparse home directory. Mounted, it is ‘your space’. Pull the power and the dongle and it goes back to ‘generic uninteresting’. (This is not complete privacy as some fingerprints are left in system logs and such, but far better than the usual “all my stuff is here, paw through it” and vastly better than the Microsoft “We stash stuff EVERYWHERE for your PRISM Program staff”… A good and easy “big lumps done” step, though.

Then, with lightly used files on the NFS server, you can have the deeper archives available everywhere. Next step there being to put that server a bit remote from the obvious workspace. (Eventually with encryption on the disks, but that might take a more beefy board. We’ll see in a few weeks.) The final step being to have that data served as encrypted blobs from The Cloud and only decrypted at point of use, but that’s a bit further out for me.

In Conclusion

That status as of now is pretty good. One dirt cheap R.Pi B+ is doing essentially all the infrastructure work and doing it well. I’ve got about $120 all told in that setup, and most of that is the fat disk.

My desktop is ‘behind a firewall behind the boundary router firewall’ and working well. Someone would need to break through the first router and not be noticed as they tried to break through the second one. Hard as the blinking lights would show traffic when I’m not doing anything… (Yes, I have blinky lights on each wire on the routers ;-) and I watch them…

The Model 2 is adequate for a desktop, but “someday” I’m going to get a larger single CPU in something (maybe that Cubieboard) as it does bog a bit on video. Or maybe software improvements will fix that as they make better use of the GPU / FPU hardware (Graphics Processing Unit, Floating Point [math] Unit). For most stuff, it’s fine. (And since the Chromebox is destined to be media server in the living room anyway, lets just say that Netflix can go there instead… and Google can know what the spouse likes to watch on TV…)

The entire shop can be built out for around $300 including the $120 spent on disks and WiFi router. So far the R.Pi portion is about $100 for both boards and kit. Not too bad, IMHO. Add the Chromebox as media station and it’s still under $480. With TB of disk, 2 levels of network and firewall, infrastructure services, and workstation. I’m good with that. And at those price points, duplicating some of the hardware in an iron EMP shield ammo-box (water tight seal too) depot it where The Gendarmes will not be hoovering up everything (like a friends attic or basement) and put an encrypted wad of data on ‘the cloud’ as backup and you are pretty much ‘good to go’ for recovery in one or two days (potentially as short as hours…) post “event” (natural or otherwise).

There is still a good chunk of more work to do. It all needs a good polish and final write up (with things like how to config NFS for those unfamiliar with it). I also have more ‘services’ to install and turn on (and just get running better, like that temperature SQL database load…) and it needs another week or three of trash removal from old archives. (I expect to recover about 1/2 the disk space at least). But even just as it stands now it’s very workable.

Oh, and I need to dust off one of my deprecated UPS Uninterruptable Power Supply boxes, replace some batteries, and make the power supply “Democrat Proof”. (Not a political comment. Just an observation that California under Republicans has stable electricity and under Democrats we have rolling brown outs and blackouts. Which reminds me, we had a power failure a few weeks back and my generator didn’t start. Need to clean the carb and tune it up for winter.) As this is all very low power equipment, even one of the small cheap UPS boxes ought to be plenty. Or maybe just get a fat stack of 5 NiCad batteries and call it done… since it all runs on 5 VDC, it is a bit silly to go through all those AD / DC / AC / DC swaps… wall, UPS, UPS inverter, powerbrick… But that’s for “someday”.

The key point here, really, just being that I’m now “living the vision” as I’m essentially moved onto a USB dongle that gets plugged into the Machine Du Jour, which is mostly the R.PiM2 and only the ASUS when doing GIStemp development and / or something that demands XP or a 64 bit Intel processor power. Chromebox mostly just media server (and mediocre SSH / Terminal access).

We’ll see where the tight spots are in this shoe and what it takes to stretch them. For now, though, it’s comfortable enough.

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.

19 Responses to Infrastructure R.Pi Build Progress

  1. p.g.sharrow says:

    Poor little $40 Pi is a bit slow trying to do everything at once! That is the idea ;-), just add more machines. Now, the Monitor is the expensive hardware problem.
    Willowing and manicuring the needed software is the real cost in this endevour…pg

  2. Paul Hanlon says:

    Hi ChiefIO,

    That’s a great setup you have there. It really is quite amazing what these little boards (that can), can do. I’ve been trying to think of a use case that justifies me going out and buying an RPi2 and their new screen, and I think I’ve found one. An overhead camera for doing Instructables, using the little Camera module to take the actual video.

    I saw a tutorial where an Anglepoise light stand was used with an articulated head that had a mobile phone on it. Being able to move the screen independently of the camera, and have it all in the one area, would be really useful.

    The output would be in H.264, which can be converted into MP4 (using the extra oomph of the Pi 2), and then sent to my main PC. Apparently there is an even simpler way of just wrapping the .h264 file into an MP4 container.

    If I could get the arm stable enough, I could even try and emulate this, a “microscope” using the lenses from a laser pointer or DVD burner. Now that would be cool, and at €200 all in, it shouldn’t break the Bank of Hanlon either, and I can still detach the Pi and use it for something else.

  3. John Andrews says:

    Hey Chief, if you are going to stack a bunch of batteries together, be sure to put a current limiting resistor in there. Batteries can dump a lot of current and do real damage if you don’t do that. I know, I know, you know that. Just saying.

  4. E.M.Smith says:

    @John: Some decades back I used two capacitors, each about the size of a large coke can, to power the ignitors in model rockets. The battery pack would make the wire glow and usually light the rocket motor. The near zero internal resistance effective in the caps for a few milliseconds would vaporize the nichrome ignitor and gave a 100% ignition rate:-)

    Better Living through massive power and applied physics 8={)

    I’ve also done light welding using two car batteries in series… fun, in a don’t ever short it out kind of way… Once welded a pair of pliers between the lugs on on battery, by accident… but they came lose as the local lead melted… only 1st degree burns on the hand… I have a quick “let go” reflex 8-)

    Withvthat said, what I’ve envisioned is just a surge servicing battery stack. The PiM2 very rairly lights the low volts rainbow. It is short term, either on head seeks or maybe 4 cores on turbo clock. So it would be enough battery for about a 5 second surge of 5 V (really only the 1/2 volt of sag…) then charging for the next 10 to 20 seconds before the next sag. I could likely get by with N cells, but as AA are cheaper, they are about the limit of max power I’d need. So a stack of 5 cheap AA or AAA NiCads in a carrier with mini USB in for the existing Pi power supply and standard USB out for all those generic power cables I own…

    As it is all std USB cables and plugs at all of 5.5 VDC max and AA cell max power, I’m not real worried. More of a power filter than big battery block. Only Big Power compared to the 5 W Pi demand.

    But I’m more likely to just buy one first iff they are for sale. BTW, worked in Advanced Linear at a semiconductor company once. Still have a pile of 5 VDC volt regulator TO3? cans somewhere in the garage. The regular power transistor package.. It’s been too long… can’t remember if the number was 3 or 5… inch or so long metal flat cans, two screws and a few leads… So if I fry a board from surge, I’ll use 6 Vdc of batts, a charger, and a regulator for the replacement board…

    Who said engineering can’t be fun? Worst case, I’ve made a new rocket ignitor :-)

  5. E.M.Smith says:

    Just occurred to me…

    The first real electronic thing I built was a power supply. 5U4 tube diode with 5 VAC filament, 300 VDC plate, choke inductor, ripple capacitor and surge resistor IIRC.

    Fun thing was that you could short the output until the plate glowed red and it was still fine.

    Probably when my attitude about testing first formed…

    “If it still works, you haven’t really fully tested it, now have you.” -E.M.Smith

    Still have my old RCA Tube manual on the shelf…

  6. Steve C says:

    @E.M. – “you could short the output until the plate glowed red and it was still fine” … A pal of mine way back got hold of (IIRC) an Eimac 35-T transmitting bottle. The data sheet instructions specified that it should be mounted behind a hole in the front panel, and the transmitter tuned until the (approximately thimble-sized) anode glowed cherry red – that was its normal operating condition! In some ways, tech was a lot more fun back then.

    On the 5V from batteries front, there are quite a few “buck/boost” converter circuits around on t’internet. They can keep your output voltage at 5V (or whatever) whether that’s more or less than what the battery happens to be at the time. I’ve been looking at them with a view to making a more bustproof 12.6V supply for taking my radio gear out portable – even though that involves trying to make an RF-quiet one. Worth checking out.

  7. Larry Ledwick says:

    Well I just bit the bullet and ordered a raspberry pi 2 and metal case from Amazon, to set up a linux desk top for daily browsing. I am getting tired of windows constantly pushing windows 10 and having to click on their “upgrade now” banner. I dropped a few extra bucks on a good solid metal case for it.

  8. E.M.Smith says:


    I’m here for any questions you have. Let me know if you need any help.

    @Steve C:

    Turns out that there’s a boat load of 5 VDC battery charger / booster things for cell phones with USB charging and they work just dandy. COSTCO had a set of 2 for $30 (but I decided I wanted one twice as big…) so any “charge your cell phone” booster that has a couple of amps out works. No need to invent anything.

  9. Larry Ledwick says:

    I do have one question on NOOBS, it looks like it does not offer a Centos version for the Pi.
    Not even sure if a full install of Centos will load on the pi, but since all the systems where I work use Centos, I was wondering if there was a simple way to go directly to a lean version of Centos?

    How does Rasparian compare to Centos (other than Centos’s tendency to tell you what you are going to do, rather than give you options.

    This item from early this year makes it sound like efforts are underway to build a R Pi ARM build of Centos, but it is likely still a work in progress. (have not invested a lot of time looking for newer stuff)

    My first instinct is to just get the default Rasparian to run and wait for the code wizards to finish beating this horse into submission.

    This item also makes me curious about that ODROID C1 chip and where it stands as far as your high security build concept?

  10. E.M.Smith says:

    Well, I’ve just done a “from scratch” NOOBS based install of Raspbian onto an 8 GB “chip” and then used my build script to install all the stuff I’ve identified as “my system”. Along the way found that IceApe is replace by IceWeasel…

    I’ve then made a directory /SQUASH_FileSystems into which I did “mksquash” for each of /bin /etc /lib /usr /sbin and then mounted them all as Read Only Loopback file systems. I’m using it right now to do this comment.

    Speed is good and it’s still got free space:

    root@raspberrypi:/media/pi/root# df
    Filesystem 1K-blocks Used Available Use% Mounted on
    /dev/root 6577688 5018480 1202040 81% /
    devtmpfs 469756 0 469756 0% /dev
    tmpfs 474060 0 474060 0% /dev/shm
    tmpfs 474060 6620 467440 2% /run
    tmpfs 5120 4 5116 1% /run/lock
    tmpfs 474060 0 474060 0% /sys/fs/cgroup
    /dev/mmcblk0p5 61302 19886 41416 33% /boot
    tmpfs 94812 4 94808 1% /run/user/1000
    /dev/mmcblk0p3 27633 929 24411 4% /media/pi/SETTINGS
    /dev/sda3 27633 444 24896 2% /media/pi/SETTINGS1
    /dev/sda6 61302 57554 3748 94% /media/pi/boot
    /dev/sda5 499656 676 462284 1% /media/pi/data
    /dev/sda7 59805812 5645820 51098952 10% /media/pi/root
    /dev/loop0 1032320 1032320 0 100% /usr
    /dev/loop1 3840 3840 0 100% /bin
    /dev/loop2 49920 49920 0 100% /lib
    /dev/loop3 3840 3840 0 100% /sbin
    /dev/loop4 896 896 0 100% /etc

    so about 1.2 GB still on the free list. Yet to do is to make a squashfs of the home directory and layer on top of it a writable RAM disk, but for now, I’m going to just use it “as is” and mount my home dir read / write from a removable media.

    At this point it ought to be Very Hard for malware to infest the typical systems files. The are all “read only” and inside a compressed wad anyway. (Though not yet doing the encryption thing… it is likely overkill for systems space that’s generic anyway).

    As /etc is in the mix, making changes like editing /etc/fstab are, er, not gonna work. For those it will take at least an “unmount, remake squashfs, remount” and perhaps even a shutdown to have it lot go of those mount points (depending one what is ‘constantly in use’.)

    I’d guess this is about 1/2 way to being the moral equivalent of a “Live-CD” build in terms of being non-writable so fairly secure. “Crap” in browsing sites (like cookies and whatever) can still be written into my home directory (for now…) and that’s still a vector for infection; but I’m sort of OK with that for now.

    I’ll be living on this chip for a while and see how it wears. I’ll also need to see if it self assembles after a reboot or if I’ve got more to do ;-)

    I still have the prior 64 GB chip as standby (and with the other variety OSs installed on it) and I’ve got the ability to mount it (via adapter) as a USB drive and copy over bits if needed.

    In general, I’d say for a “just browsing and such” chip, an 8 GB looks big enough for this use. (Eventually it could be even smaller as the squashfs files are smaller than the generic install and at this point I have both still on the chip). In this mode the squashfs is mounted ‘on top’ of the regular files (hiding them). That also means that if the mount fails, or if I block the mount, then I get the original name space back. ( i.e. I can rename usr.sqsh to usr.donot_mount and then reboot and it will fail to mount as fstab is looking for usr.sqsh and that will leave the original /usr there to run from). That’s nice feature while test driving just in case something breaks… but at the expense of keeping those original file spaces around, if unreachable.

    For more general purpose use (such as installing GIStemp or a music library or…) I say at least a 16 GB chip is needed.

    Having several chips, each for a different purpose, prevents a lot of risk. For example, if one chip is hardened a bit (like this one with RO file systems) and used for browsing around and posting things, but an entirely different chip is used for banking and paying bills, any crap that crawls in via browsing can never get to the chip used for banking. As it’s about 1 minute to shutdown one chip, swap, and reboot another, and the chip costs about $8, it’s pretty simple and pretty easy “insurance” against being hacked by browsing to the wrong place…

    I’ll be doing this from here on out (even if I don’t mention it). So this chip will be my general “browse and blog” system and the 64 GB gets retired for “R&D and Experimentation” while another chip, likely a 16 GB, will be similarly set up as this one, but only used for “financial things with big name organizations and never retail shopping”. (Eventually I’ll work out an NFS mounted space for things like my “usual tools” so they are on all systems. For now I’ve just made sure I loaded them into /usr/local/bin prior to making the usr.sqsh copy)

    One more minor step…

  11. Larry Ledwick says:

    Crap forgot to add the link, was referring to this link (forgot to book mark it had to go find it again):

  12. E.M.Smith says:


    The chip set ought not to change the security methods.

    In NOOBS, there is a Fedora clone available. As Centos is just Fedora that’s been stripped of some bits, is older and more “proven” and with a more industrial kit of base installed parts, you ought to find the Fedora install comfy…

    Look for “Pidora” in the list of systems.

    I installed it, and Raspbian (and a few others …) into my 64 GB chip. You can install several and swap between them at boot time.

    I tried it and don’t remember thinking much other than “Yeah, it’s Fedora …”

    Maybe when I go to do the reboot of this 8GB_RO_sqsh chip I’ll try the Pidora again just to remind myself what I thought of it …

  13. E.M.Smith says:

    Oh Yeah… now I remember… Pidora was working from NOOBS as an install at first, but then got taken out for the Model2 as it had not been ported there yet, and when I tried to launch it it didn’t work. This link implies they have a working one now:

    So it’s a straight “instal and run”on the Model 1 family, but for Model 2 (as of Feb, maybe different now) it was a special out of tree build:

    [As per pmca’s answer, a dedicated “pi remix” version of F21 is now available. I’m leaving this as my accepted answer because I would still prefer to use the upstream distribution and deal with the kernel and firmware myself. However, if you are new to the pi, or find this a bit sketchy, you are probably better off using the remix.]

    Yep, Fedora 21 works. However, the pi 2 still requires a special out-of-tree kernel, and you need the firmware and bootloader, so you should start with an existing pi 2 image; here I’m using raspbian (make sure it is a version subsequent to 1-31-2015). There’s an alternative to ripping stuff from Raspbian, see the note about /opt/vc at bottom — but using a Raspbian card at first is simpler.

    The Xorg GUI server works using the fbdev driver, as it does on raspbian. The repo won’t have pi specific things such as oxmplayer, but they can be compiled from source. For raspicam, see the /opt/vc note.

    You’ll also have to do your own kernel and firmware updates. This is simple enough — you just need the rpi-update script from the raspbian image (it’s in /usr/bin and has no dependencies other than curl and the shell). There is a slight potential complication with that, see step #6.

    then there’s a list of steps…

    also from about Feb has a list of steps too:

    The recent release of the Raspberry Pi 2 uses a newer version of the ARM architecture spec, the ARM Cortex-A7 uses ARMv7 whereas the previous model ARM11 uses ARMv6. The great thing about this is the majority of Linux distros already provide an Image for this architecture. More importantly, Fedora already have images.

    There is a slight caveat to the above statement however, that being they won’t just work with the Pi 2. The process isn’t that difficult either just a few steps:

    Download the image you require, for this we’ll go with the Fedora 21 minimal –
    Flash the image to an SD card xzcat Fedora-Minimal-armhfp-21-5-sda.raw.xz |dd of=/dev/mmcblk0 bs=1M
    Make sure the card is unmounted
    fdisk the card:
    remove partition 1
    add a new partition where the old partition 1 was, with type B (FAT32)
    write and exit
    mkfs.vfat /dev/mmcblk0p1
    Clone the Pi firmware repository – git clone
    Mount the card again
    mkdir /mnt/sdcard
    mount /dev/mmcblk0p3 /mnt/sdcard
    mount /dev/mmcblk0p1 /mnt/sdcard/boot
    Copy the contents of the boot directory from the repository you just cloned to the new boot directory and the kernel modules to the lib/modules directory on the main root partition
    cp -r firmware/boot/* /mnt/sdcard/boot/
    cp -r firmware/modules/3.18.7-v7+/* /mnt/sdcard/lib/modules/
    Edit the fstab file to reflect the new UUID of the partition and change from being an ext to a vfat type
    blkid /dev/mmcblk0p1 – this will give the UUID of the partition
    vi /mnt/sdcard/etc/fstab and edit the line which contains /boot to contain the above info
    Create a /mnt/sdcard/boot/cmdline.txt file containing the following:

    dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p3 rootfstype=ext4 elevator=deadline rootwait

    Create a /mnt/sdcard/boot/config.txt file containing the following:
    #uncomment to overclock the arm. 700 MHz is the default.
    arm_freq=700# NOOBS Auto-generated Settings:
    save and close any open files on the sd card then unmount and ensure all writes are complete
    umount /mnt/sdcard/boot
    umount /mnt/sdcard
    You should now be able to remove the SD card from your PC and boot it in your new shiny Raspberry Pi 2

    I’m sure it won’t be long before dedicated images are available, but for now this seems to work for me. I haven’t tried any more than the minimal install, with these your mileage may vary.

    Note: Please remember this will only work on the newer Raspberry Pi 2.


    Extra steps suggested by Tim Bosse

    14. Install rpi-update.
    Install binutils and tar.

    Download and setup rpi-update.

    # curl -L –output /usr/bin/rpi-update && sudo chmod +x /usr/bin/rpi-update

    15. Run rpi-update as root.

    I find this is important to run any time you get kernel updates from Fedora repos.

    I have a wireless USB dongle that I use.

    16. Install NetworkManager-wifi and NetworkManager-tui (because I find nmcli not so much fun).

    I’ve created an image based on steps 1-13 it’s fairly rough and ready so YMMV

    As it’s been 8 months since then, it might well be in a newer version of NOOBS already…

  14. E.M.Smith says:

    Well, some issues…

    It looks like “wicd” the wireless daemon, seems to have issues with either a read-only /etc or a read-only /usr. For whatever reason it wasn’t working.

    I then got it working by removing the mount overlay for those two, but in the process found that the “Edimax” WiFi dongle wasn’t playing well with the Best Buy house brand USB hub. No idea if it is the hub or the dongle or the combo. Moving it to the R.PiM2 directly fixed it, whatever it was.

    So now I get to go back and try to figure out “what’s the problem” with wicd and is it via /usr or /etc. (I’d unmounted both before discovering the hub issue…)

    Or maybe it’s just that I need to have the dongle working and wicd running before I snap a static copy of those file systems…

    Just be advised that “wireless” has some quirks to it with read-only config. Then again, doesn’t wireless always have quirks with it?…

    Next up (along with this debugging) will be looking to make that writable union file system overlay. In fact, it will be part of the debugging to figure out if it is a static config issue, or some kind of “writing to usr” or “writing to /etc” stupidity. (By now all systems code writers ought to be well aware that VARiable stuff goes into /var since that is why /var was added. To allow all the other spaces to be static and gather the dynamic stuff into one place.

    For the next day or two, when “fooling around with it”, that’s what I’ll be doing. Tuning the exact static file systems needed, making a dynamic writable overlay and getting comfortable with that, and making wireless work more seamlessly. (I’m also on the hunt for a reasonably cheap 5 VDC external USB cell phone battery / charger with 2+ amps output and a couple of hours run time so I can make it a combo micro-UPS and portable pi station… but that’s tertiary at the moment).

    I know, I could just drop straight to the “end game” and use one of the “make your Pi SD card read only” cookbook pages; but this is as much about me learning the tools and options (even those not in the cookbook pages) as it is about having a read only SD card.

    Now, back to fiddling with the pi…

  15. Larry Ledwick says:

    I was looking around on web pages related to Raspberry Pi builds and security and found this tutorial on initial setup changes to lock down the system a bit more than its out of the box configuration. Seems to be a good starting point for a discussion on basic changes to lock down a system. Although I work in a unix environment other people are responsible for server setup and security so this is going to be new ground for me (understand many of the concepts etc. but never actually locked a system down) and will have to learn my way around the actual commands.

    This might be a specific post topic worthy of discussing at some point.

    For a personal web browsing system other than http and https what do you really NEED to have active service wise?

    For normal users is there really a good reason to allow anyone to ftp or sftp to your browser system?

  16. E.M.Smith says:

    I am in the process of making dedicated chips (systems) for dedicated uses. At under $8 each it is dirt cheep. The general rule is that if you don’t need a service, remove it. A dedicated browser system would have a trimmed kernel (not for the typical nooby to do…) with network support, windows system, and browser; and nothing more.

    Then you make the file systems read only and have some watchdogs to do things like check that hash values don’t change.

    In reality, most folks want to save downloads and do things like email, so the spec gets wider… Things like ssh, ftp, and related get removed first, not left laying around…

    I’m downloading Kali for the Pi right now ( Penetration testing system) and an easy thing to do is run it against your setup.

    I’ll work up a basic posting on this in the next week or so.

    One great feature of the Pi is that you can build a pristine system, then clone a golden master. Then you just flash a new fresh copy for each use. IFF anything hacks in, it must happen during that use, but then gets flushed when flashed again.
    dd if=/golden/master of=/dev/workingSD bs=64k
    and its clean again. As hacks take time then exploits come later the window is shut most of the time just from this…

    I do a slow form of this in that I’m often shifting systems… rotating shields as it were.

  17. E.M.Smith says:


    I’m posting this comment from a Fedora / Mate release running on the Raspberry Pi Model 2 using FireFox. The “top” command reported Firefox as going to over 100% at one point during the page loading while the total CPU use was well under that – indicating that it is using more than one core (so is multiprocessor aware).

    I’ve not done anything else yet, but so far it’s quite nice.

    I got this install of Fedora via the use of Berryboot. ( web search berryboot and install it, then just select Fedora as one of the OS options). I’ve loaded somewhere around 8? total operating systems onto one 8 GB SD card with room to spare. (It impliments a squashfs file system structure for storing OS images, near as I can tell so far).

    This is the 2nd one from the chip I’ve booted. (Already booted Puppy… still have Ubuntu, Android, Debian (Wheezy or Jessy your choice…), Kali (for security sweeps) and a couple of more to test drive. (Guess what I did last night… it takes about an hour to download one of the larger OS choices…) Interesting is that under “applicances” it now has a built in PXE boot appliance (with something like a 25 operating system images limit) so my “build a PXE server” has just turned into “configure the Pi to do it”… and I think another Raspberry Pi just went onto my buy list. It’s way over $30 of my time to build a PXE server and I’m not getting a Round Tuit so that’s the lazy path…

    At any rate, if you like Centos, this looks just like it so far. (All of about 5 minutes… but CentOS is just a specialized Fedora…)

  18. E.M.Smith says:

    Well, the only “odd thing” I’ve run into so far is that both the Ubuntu / Mate and Fedora / Mate images seem to not know how to detect and mount a USB drive. I suspect someone made the assumption that a Raspberry Pi user would be living off the SD card and mounting network files; as both of them DO look for “Microsoft Network” file services… So I presume I’ll need to find a way to customize them to include NFS mounts and USB detection / mounting.

    But as a general purpose browser, it’s working fine. Seems faster than the other NOOBS install of Raspbian even though it’s supposed to be the same browser.


    During the shutdown / update the Pi-B+ process, I discovered the cause of the failure to find the USB disks. It was PIBKAC. Problem Is Between Keyboard And Chair….

    I’d unplugged everything to swap SD cards in the Pi_M2 and when I powered it up again, everything looked and acted fine. USB disk had blue ‘power’ light LED on, and both mouse and wireless keyboard were working through the same hub. But all was NOT right.

    I’d forgotten to plug in the power supply to the USB hub. Just enough power was ‘leaking through’ from the Pi to light the lights and power the low power mouse and keyboard dongle, but not enough to make the USB disks “go”. Once I put power back to the “powered hub” Fedora found the disks Just Fine. Ending one more “mystery”…

    But leaving me wondering just how much can be powered through an un-powered “powered hub”… and adding one more thing to the “must check” list… “Even if the power on light is lit the power may not be on for USB hubs and devices.”

    Sigh. And here I thought I’d learned enough this week… 8-}

Comments are closed.