SD image too big for another SD Card

[simplesi]

Its always the simple things that do you in.

Just spent the weekend getting software setup on my master RPi with 8GB SD card.

Used Windiskimager to save image to my PC - stuck in new 8GB card - tried using Windiskimager to restore the saved image - its say not enough room on the card!!

I used MiniTool Partion Wizard to delete SD card partition - recreated a Fat32 one - same result

Help please!!!

Simon

[pluggy]

Boot PC using Ubuntu CD, use gparted to shrink ext4 partition on original SD card slightly. Try again.....

[alexeames]

What he said. I was going to suggest the same. It's a faff, but you can shrink the partition before you backup the image. Or, if you don't want that faff every time, just make the original card partition a little bit smaller and leave it that way so it will fit on all 8 Gb cards.

[Dweeber]

Curious, I see everyone saying use gparted to shrink a partition, but you never really see instructions on how to do that.

I tried last night to do that by putting the image (MicroUSB in SDCard adapter) into a USB thumb drive, plugging it into a running RPi and using parted (gparted is just a graphical front end to parted) on the RPi....

Resizing Smaller, was not allowed because ...

Error: File system has an incompatible feature enabled. Compatible features are has_journal, dir_index, filetype, sparse_super and large_file. Use tune2fs or debugfs to remove features.

Not really familiar with using tune2fs or debugfs or if doing so would result in the loss of the data on that partition.

So anyone have actual step by step instructions on how to reduce a partition so that the end result is a smaller image?

Ref:

Code: Select all

root@raspi01:~# parted
GNU Parted 2.3
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print 
Model: Generic- SD/MMC (scsi)
Disk /dev/sda: 15.9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
 1      4194kB  62.9MB  58.7MB  primary  fat16        lba
 2      62.9MB  15.5GB  15.5GB  primary  ext4

(parted) resize 2                                                         
WARNING: you are attempting to use parted to operate on (resize) a file system.
parted's file system manipulation code is not as robust as what you'll find in
dedicated, file-system-specific packages like e2fsprogs.  We recommend
you use parted only to manipulate partition tables, whenever possible.
Support for performing most operations on most types of file systems
will be removed in an upcoming release.
Start?  [62.9MB]?                                                         
End?  [15.5GB]? 4052MB                                                    
Error: File system has an incompatible feature enabled.  Compatible features are has_journal, dir_index, filetype, sparse_super and large_file.  Use tune2fs or debugfs to remove features.
(parted)

Listing that partition using tune2fs

Code: Select all

root@raspi01:~# tune2fs -l /dev/sda2
tune2fs 1.42.5 (29-Jul-2012)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          f10ba0bd-17e0-4800-b0af-19bb2ed45acd
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              950272
Block count:              3773248
Reserved block count:     188596
Free blocks:              3265143
Free inodes:              877602
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      111
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Tue Sep 18 04:24:13 2012
Last mount time:          Sun Oct  7 21:46:24 2012
Last write time:          Sun Oct  7 21:47:15 2012
Mount count:              81
Maximum mount count:      -1
Last checked:             Tue Sep 18 04:24:13 2012
Check interval:           0 (<none>)
Lifetime writes:          6213 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      79632134-b68d-41f0-b73e-79c5105e7398
Journal backup:           inode blocks

The only solution that I've ever had work is to never expand the partition/filesystem to the full size of the card, which is why I wrote the rpi-wiggle script.

But if I did expand it using the expand ability in raspi-config, there was no easy way going back.

[simplesi]

Well, I tried reducing the size of the ext4 partition using GParted on liveCD Ubunutu machine and it let me do it OK but WinDiskImager still won't copy the image onto a new SD card

(This was at work so couldn't spend a lot of time on it!)

I think I'm going to have to get a machine setup properly with Linux so that I can use DD to get the image off the old card and back onto a new one!
:lightbulb moment: I wonder if RedoBackup (which I use all the time to image Win machines) will let me do a backup of the SD card ,save on it on a machine and then re-boot and restore it onto the new SD Card ??

Simon

[milhouse]

Well, I tried reducing the size of the ext4 partition using GParted on liveCD Ubunutu machine and it let me do it OK but WinDiskImager still won't copy the image onto a new SD card

Yeah, I guess that is to be expected. Even if you reduce the partition size by 100MB, WinDiskImager is still going to look at the whole SD card (as it doesn't care or know about any partitions - particularly Linux partitions - that may be present) and in your case it's still going to create an 8GB image, even when the cumulative size of all partitions is now closer to 7.9GB (for example). You'll just have 100MB of zeroes (more likely garbage) tacked on at the end of that 8GB image which WinDiskImager will still try to write out to the smaller sub-8GB card. A shame you can't force WinDiskImager to proceed with the write as although it would fail while writing out the last 100MB, the rest of the already written/committed data would be just fine.

Hindsight is a wonderful thing, and I guess one option would have been to use the smaller card to install and configure Raspbian, then from this card create the image that could be subsequently written to practically any "8GB" card.

Alternatively, dd is your friend and should allow you to write your "oversized" image to the smaller card, and you can safely ignore the errors when dd runs off the end of the smaller card. Although thinking about it, now that you've reduced the size of the partition you should be able to create a new image using dd and sized down so that it will fit without errors on the smaller card (eg. "bs=1M count=7950" would read or write an image of 7950MB irrespective of how big the source/target SD card might be).

A third and final option might be to plug the smaller card into a USB adapter (after performing a basic install of Raspbian on it), then plug it into the Pi while booting from the larger card, and then tar/untar the content of the root filesystem (from the larger SD card) over to the smaller card (or do this on a PC with two USB adapters etc.). Slow and tedious, but perhaps a last resort if you get stuck using dd (though I can't think why you should).

[simplesi]

Redobackup wouldn't deal with the situation either - wouldn't try and fit the orig SD image onto the new SD card

At the moment, I'm trying a simple

dd if=/dev/sdb2 of=/mnt/backup/sdcard.img

(the orig SD card has 2 partitions on it (????) so just trying to get at 2nd one (Which I've resized down to 7GB) )


(This is on a machine with RedoBackup running as its just a cut-down linux liveCD with a special prog on it)

Simon

[simplesi]

yeah - didn't think that one thru properly - RPI needs the FAT16 partition to boot!

Now simply doing a DD on the whole of /dev/sdb

Simon

[simplesi]

At last got it copied
(Should have just doen this to start with of course)

So basically not all 8GB SD cards are the exact same size

So if your working SD card is bigger than the one you want to copy it to then you need to get a Linux machine up and running (or use a LiveCD/USB stick)

Use GParted to resize the ext4 partition down in size (say by 0.5GB) and then use a simple dd command and copy the whole SD card to an image file on the Linux machine, swap SD cards and use dd and send that image file to the SD card

e.g
dd if=/dev/sdb of=/mnt/backup/sdcard.img
and
dd if=/mnt/backup/sdcard.img of=/dev/sdb
(EXAMPLE ONLY DO NOT JUST USE WITHOUT CHECKING WHAT sdb is on your machine!)

Of course, maybe best way is to get 2 SD card readers from the pound shop and just use
dd if=/dev/sdb of=/dev/sdc
(SAME CAVEAT APPLIES)

the 2nd dd will give an error as the image file will be too big for the new SD card but the error can be safely ignored.

Simon

[JollyRoger]

The solution to this problem is to use version 1 of Win32diskimager, which you can find here (at the bottom of the page):
https://launchpad.net/win32-image-writer/+download
There is a bug in this first version, which means it will write a larger disk image onto a smaller SD card, carrying on writing until it runs out of space on the card, at which point it gives an error message. But the card will still work on the Pi, provided you have previously used gparted or whatever to reduce the partition size to fit the card.

[RomanG]

I run in to similar problem, I had a backup image with older kernel and needed to restore it so that I could troubleshoot ALSA issues.
The problem was that the other 4GB SD cards that I have were slightly smaller than the one from which the image backup was made.

The original card had size of 3965MB and spare cards that I have were 3963MB or 3904MB respectively.
So clearly, writing the backup image to either one of these cards would result in a corrupted file system.

Here is how I solved this problem.

First, create a copy of your backup image to play with
In my case:

Code: Select all

cp pi_30112012.img test.img

Searching google I found that image files can be mounted as a block devices using losetup command:

Code: Select all

sudo losetup -f --show test.img
/dev/loop1

Let's see what we got:

Code: Select all

sudo fdisk -l /dev/loop1

Disk /dev/loop1: 3965 MB, 3965190144 bytes
255 heads, 63 sectors/track, 482 cylinders, total 7744512 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000714e9

      Device Boot      Start         End      Blocks   Id  System
/dev/loop1p1            8192      122879       57344    c  W95 FAT32 (LBA)
/dev/loop1p2          122880     7744511     3810816   83  Linux

As you can see, this image is 3965MB and 7744512 sectors (512b x 7744512 = 3965190144b)
Also geometry of the card is important to note, 255 heads and 63 sectors.
The last sector of the last partition is Total sectors - 1, so there is no spare room left on the card.

Now, let's have a look at the target SD card

Code: Select all

sudo fdisk -l /dev/mmcblk0

Disk /dev/mmcblk0: 3963 MB, 3963617280 bytes
128 heads, 63 sectors/track, 960 cylinders, total 7741440 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1            8192     7741439     3866624    6  FAT16

The target SD card is 3963MB and 7741440 sectors, so it is smaller than the image by 3072 sectors or 1572864b. Also note the geometry of the card showing 128 heads and 63 sector. For some reason this is incorrect as this card has 255 heads and 63 sectors. For some reason fdisk does not show this always correctly. At another occasion, it showed this card with 4 heads and 16 sectors. Not sure why...

We need to shrink second partition of the image, otherwise if we attempt to write image to the card, it will result in a corrupted file system
let's mount the second partition of the image as a loopback device so that we can resize it
image starts at sector 122880, which is 512*122880=62914560b

Now that we have the offset for mounting the second partition of the image,
we can now use with losetup’s -o argument to set an offset

Code: Select all

sudo losetup -f --show -o 62914560 test.img
/dev/loop2

scan for errors before resizing the image

Code: Select all

sudo e2fsck -f /dev/loop2

e2fsck 1.42 (29-Nov-2011)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/loop2: 80300/245760 files (0.2% non-contiguous), 604445/952704 blocks

using resize2fs we can shrink the partition, using -p option to show progress and specifing new size which is
slightly smaller than the new SD card

-p Prints out a percentage completion bars for each resize2fs operation, so that the user can keep track of what the program is doing.

size parameter may be suffixed by one of the following the units designators: 's', 'K', 'M', or 'G', for 512 byte sectors, kilobytes, megabytes, or gigabytes, respectively.

We need to scale dovwn the image by 3072 sectors, lets go with 4096 sectors just to be sure. Image size is End - Start = 7744512 - 122880 = 7621632 sectors, substracting 4096 sectors, the new size is 7621632 - 4096 = 7617536 sectors

Code: Select all

sudo resize2fs -p /dev/loop2 7617536s

Resizing the filesystem on /dev/loop2 to 952192 (4k) blocks.
The filesystem on /dev/loop2 is now 952192 blocks long.

Now that the filesystem was resized, loopback devices are no needed anymore:

Code: Select all

sudo losetup -d /dev/loop1 /dev/loop2

To write the modified image to the SD card, use command:
(this may take a while, depending on the speed of your card, in my case it took more than 30 minutes)

Code: Select all

sudo dd if=test.img of=/dev/mmcblk0

dd: writing to `/dev/mmcblk0': No space left on device
7741441+0 records in
7741440+0 records out
3963617280 bytes (4.0 GB) copied, 1908.13 s, 2.1 MB/s

As you can see, there is an error message 'No space left on the device', but because we re-sized the file system, card will be useable and Raspberry Pi will boot up without any issues.
However, if you attempt to look at the partition(s) on the card with a tool such us parted or gparted, it will end up with an error "...partition extends beyond end of device..."
To correct this, we need to modify MBR (Master Boot Record) of the SD card.
First, we will extract the first sector from the card which contains MBR

Code: Select all

dd if=/dev/mmcblk0 of=sd.mbr bs=512 count=1

This will create a file sd.mbr which we will need to edit with a hex editor (I did this on my laptop using Ubuntu 12.04LTS Live CD and tried GHex and Bless Hex editors, I liked Bless Hex better, but that's just my preference).
To play with the MBR in the hex editor, you need to know what values at which address need to be modified, Wikipedia has very good reference material about MBR.
http://en.wikipedia.org/wiki/Master_boot_record
From there you can see that Partition entry #1 starts at address 0x1BE and Partition entry #2 starts at address 0x1CE.
Layout of the partition entry is described here http://en.wikipedia.org/wiki/Master_boot_record#PTE
Values for the CHS address of last absolute sector in partition, LBA of first absolute sector in the partition and number of sectors in partition need to be calculated and changed.
I can explain this in more detail if someone is interested.

Once MBR was modified, it can be written back to the sd card

Code: Select all

dd if=sd.mbr of=/dev/mmcblk0 bs=512 count=1

running:

Code: Select all

sudo fdisk -l /dev/mmcblk0

Disk /dev/mmcblk0: 3963 MB, 3963617280 bytes
4 heads, 16 sectors/track, 120960 cylinders, total 7741440 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000714e9

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1            8192      122879       57344    c  W95 FAT32 (LBA)
/dev/mmcblk0p2          122880     7741439     3809280   83  Linux

We can see that the end sector of last partition is less than total number of sectors.
If we run now parted or gparted, the card partitions will be recognized and can be further manipulated by using these tools.

I hope this helps to someone

Cheers,
Roman

[Colly]

Ouch! I've been checking my half dozen "identical" 16GB SD cards, all RiData 16GB class 10's and they ALL work fine, HOWEVER... They do NOT end up formatted to the same size as each other !!
I do believe that after using the raspi-config option to 'resize partition' to use the full SDcard, many people will experience the problems I've had and end up with complaints such as "Win32DiskImager creates an img too big to restore" and "kernel panic, cannot mount file system". My SDcards show a chs geometry of 2007, 255, 63 and I can NOT figure out how my one working web server 16GB SDcard, after the resize, ended up with 32,372,735 sectors, each 512B. Right? 2007 * 255 * 63 only equals 32,242,455. I have about 130,000 too many sectors! Could it be because each cylinder was reported as 8255kB? Shouldn't those be only 8192kB?
I believe, for now, that I would advise AGAINST using the resize option in raspi-config until or unless someone adds an option to it asking "how big do you really want it to be expanded to?"
***
For now, I have NO other SD cards, except for the working web server card, that have 32,372,735 sectors on them. I will not be able to back it up to a useable image file, or restore it, until I teach myself how to SHRINK that last partition a few megabytes. In fact, I'll probably just shave a 1/2 GB off, THEN back it up and see if the image will fit on any or all of my other SD cards. Learning how to use fdisk and parted are things I'm sure I'll find useful later anyway.
I do NOT believe the fault is with Win32DiskImager, even though people keep reporting this "size" bug. I think they just don't yet realize that the SD cards are really no more alike than potato chips.
Once you start checking your own "identical" SD cards, you'll be amazed at the variety of sizes you get. MiniTool Partition Wizard Home Edition v7.7 has been most revealing. So has HDD Raw Copy Tool. SDformatter and Win32DiskImager seem to be just fine, but cannot make a destination SD card larger than it is. Nor can ANY other utility. Whatever raw physical sector count your SD card shows, is ALL YOU GET and so far, I haven't even found two that match! Now to go search on how to use parted to manually shrink a partition.... (sure glad I have plenty of these SD cards to fiddle around with.)
**
I realize someone has posted instructions on how to shrink the partitions earlier in this thread, but I need to do it dynamically in the SDcard that's booted up in the RPi. The MiniTool Partition Wizard won't do it in my Windows 7 PC and I don't have any Linux boxes except my RPi. Could I maybe insert the SDcard in a USB card reader and plug it into a RPi running Wheezy and follow some sort of instructions like the ones above (to slightly shrink the last partition)?

[simplesi]

Live Linux CD is what you need in this case then

regards
Simon
PS TO RASPI_CONFIG PEOPLE - DONT USE ALL OF THE SD CARD - KNOCK OFF SAY 200MB PLEASE

[pluggy]

You're aware that SD card sizes vary anyway ?. They can't manufacture them all perfect so they size the cards afterwards and block out any bits that don't work. Some will have more bits blocked out than others so the size varies slightly. Theres nothing wrong with the resize option in raspi-config its just a shell script if you care to look and you can work out what it does for yourself. Your kernel panic problems are almost certainly corrupted card problems. I reckon many of your problems would disappear if you lost the Class 10 fixation.

The Pi has always exhibited more tendency to corrupt higher class cards. Lower class cards will often read as fast or faster than higher class cards and reading is what matters. I have 5 Pis and a bag full of SD cards, for use in them. All class 4, never had a corrupted card, and I often do things like depriving them of power without shutting them down first. Its fairly easy to resize a partition before you make an image of it and then truncate the .img file so it doesn't give an error when you restore it to a smaller card.

[pluggy]

Live Linux CD is what you need in this case then

regards
Simon
PS TO RASPI_CONFIG PEOPLE - DONT USE ALL OF THE SD CARD - KNOCK OFF SAY 200MB PLEASE

And if they did that, we'd get 5 people a week querying why it doesn't use all the available space on the SD card.

[simplesi]

What's 200MB between friends

I think it'd be worth it - maybe ask if want to leave wiggle room or not then?

And we need someone to make the equivalent of ReDoBackup that just sorts this out for people without need to be medium level filesystem expert

Simon

[RaTTuS]

if you're dding of the whole disk then it wont help
if you do separate partitions then it will

[simplesi]

I mean type as in load LiveCD and press a few buttons

Simon

[simplesi]

Now I come to think about it, can we not simply plug a £1 shop USB SD card reader into an RPi and get it to do the DD ing itself?

Simon

[azeam]

Now I come to think about it, can we not simply plug a £1 shop USB SD card reader into an RPi and get it to do the DD ing itself?

Simon

"dd:ing" an image of a running os is not a good idea at all, better to unmount the sd card and do it externally.

[pluggy]

Somewhat akin to a tree surgeon cutting off the branch he's hanging from....

[simplesi]

I knew there must be was a reason not to - it was too simple otherwise

Ok - back to Plan A, we need an RaspberryPi Live CD that makes sure total size of all partitions is <200MB (or whatever headroom needed) less than notional card size, if not - resizes the main ext4 one.

Then put your computer back to "normal" and use Win32DiskImager as normal.

Obviously the LiveCD could do the copying as well but it would need access to local file system which might be problematical but a nice to have feature for V2

So - just need a Linux Guru who'd wants a bit of fame to pop along and code it up

Simon

[pluggy]

A Ubuntu 12.04 CD will do everything you need to do with a Pi. Most Linux Distros on CD now work as live CDs. Ubuntu is a close match to Debian and a lot friendlier. It does parted, gparted, dd, truncate, fdisk, etc as well as being able to see both partitions on a Pi SD card.

http://www.ubuntu.com/download/desktop

You could even install it as dual boot alongside that Redmond OS I can't quite remember the name of.....

[simplesi]

A Ubuntu 12.04 CD will do everything you need to do with a Pi.

Well, we know that but I'm thinking that a RedoBackup type remix would help the not so DD,Gparted savvy users

it'd be a lovely little project for some young, linux guru wanabee

Simon

[Colly]

You're aware that SD card sizes vary anyway ?. They can't manufacture them all perfect so they size the cards afterwards and block out any bits that don't work. Some will have more bits blocked out than others so the size varies slightly. Theres nothing wrong with the resize option in raspi-config its just a shell script if you care to look and you can work out what it does for yourself. Your kernel panic problems are almost certainly corrupted card problems. I reckon many of your problems would disappear if you lost the Class 10 fixation.

The Pi has always exhibited more tendency to corrupt higher class cards. Lower class cards will often read as fast or faster than higher class cards and reading is what matters. I have 5 Pis and a bag full of SD cards, for use in them. All class 4, never had a corrupted card, and I often do things like depriving them of power without shutting them down first. Its fairly easy to resize a partition before you make an image of it and then truncate the .img file so it doesn't give an error when you restore it to a smaller card.

yup - NOW I'm aware they vary. I should have realized before, but it was brought home by the mischance that the one good web server image I made, got expanded to the largest of all my SDcards so now I can't restore its image to another card. I'll just have to create a fresh one all over again and when I made the first one, my build responded to some of the steps a little differently than the example in the Tinkernut video on how to do it - I had to work around those differences, but got it working - and don't quite remember what I did for the workarounds (more the fool because I didn't take notes while I was doing it - I will THIS time though.)
As for corrupted cards - I've never had any corrupted if they ever booted up once. The kernel panics were all resulting from the fact that the image restores never had enough bytes to restore to in the slightly smaller cards, so their files systems simply failed to mount when they hit the "bad block" (exceeded the physical space on the too-small sdcards.) ALL the images I've built on this brand of class 10 cards has worked through many power ups and shutdowns. I usually never unplug them, but on the rare instances when I have, I simply made sure the system wasn't actually doing anything when I did so. My RaspBMC images work fine. My Wheezy images work fine. And I'm very careful to either tell RaspBMC to "Power off system" or else I login with SSH (on the headless RPi's) to issue: "sudo shutdown -h -P -t 3 now" which seems to safely shut everything down and power off the RPi. I wait then until the little activity LED goes out before unplugging. I never overclock beyond the medium 800Mhz, though someday I may risk toasting one of my RPi's if I ever buy some heatsinks to put on it first. My RiData SDHC "Lightning Series" Class 10 cards were not only some of the least expensive I could find online, they've all worked quite reliably. I did try a couple of class 4 16GB sd cards I got at Big Lots for a good price, but they seemed noticeably slower, though I haven't done any actual benchmarking tests. So far, I have 7 RPi's - 3 with RaspBMC being used on monitors (7", 19", and 50"), one (#4) (my original and only revision 1 board) being dedicated as a headless web server, one (#5) given to my wife to build a server on, one (#6) on a Pi Plate to fiddle with the RTC and 16x2 LCD, one (#7) in a clear box case, used for showing at the PC club meetings. I dedicated the revision 1 board as my web server because it will never need the MPG2/WVC1 decode keys.
*
I think from here on, when I go to build a new image, I will NOT use the expand2fs option until AFTER I create the first backup image of the working build. I've also discovered how fast you can eat up space on even terabyte drives by making backups of 16gb images that are mostly empty diskspace! Silly, now that I think of it. I will create my working images, configured the way I like them with the added stuff I want, and then back those up while they are working correctly, but still small, so the images won't waste space on my main desktop. I've been cutting adhesive mailing labels into 1/4" by 3/4" strips to label my SDcards so I don't get them mixed up. I stick the labels on the back of the sdcard (same side as the contacts, but opposite end) and I can easily read them while they're inserted in the RPi's even in the VESA mounts. I've also numbered each of my RPi's on the top of the Ethernet socket with a permanent marker, so I know which RPi gets which mpeg keys, in case I eventually get over the 6 or 7 key limit. So far, I've only bought 4 sets of keys, so I just have them all strung together on each card with RaspBMC.

I love my Raspberry Pi's and I love Linux, where the only true limits are the imagination of their users.