However, the problem with this is that it is only suitable for only one client, since there would be much space needed on the nfs server for different clients and because it would be causing heavy network load. That's why I would like to load only one file to the Pi containing the whole root filesystem which would then be inside some kind of ramdisk or something comparable, causing no more network load.

Is there any possibility to accomplish this? Has anyone done something like this before?
An SD card would absolutely not be an option for my purpose and due to the amount of clients an nfs server wouldn't be either.

thanks four answer. As far as I understood, initrd/initramfs just delivers the most basic filesystem, which the system needs to boot. How can I deliver the whole/the remaining filesystem to the Pi, making him store everything inside the ram, that would normally be on the sd card? I couldn't find any solution searching the web, but it is definitely done with desktop pcs like this. Maybe I just don't know what to search for

You can share most of the filesystem between all the clients, and keep just the variable bits in either local RAM or on a small per-client area on the server. With a gigabit network, it's not going to be troubled by 10 pi's at 100Mb each.

To keep it all 100% in local RAM, a crude but easy to use approach is to take an SD card, delete /usr and everything obviously not needed from /bin, /sbin and /lib. Once it's cut down to a reasonable size - and still boots - turn what's left into an initial ramdisk, get it booting and then add whatever apps you actually need.

Other approaches could include starting with the network installer and hacking it to suit your purpose, or some variant of the old-school hack on passing 'init=/bin/sh' on the kernel command line.

By the way, the boot isn't by way of 'PXE'; it only gets mentioned because the Pi sends out a packet saying it's a PXE client, but it's not really - it always uses 'bootcode.bin' (even if the network server tells the Pi it should use a PXE program as a result, the Pi ignores it and requests 'bootcode.bin').

Chrysor wrote:and thought of some small linux distributions. Would they still be too big because of the memory usage of the GPU?

The development version of my Nard SDK might work. It's not entirely finished yet, but it can boot into a RAM standalone system. It's console based, but there is a framebuffer where one can display JPEG images etc.http://www.arbetsmyra.dyndns.org/nard/

asandford wrote:Iv'e found that PXE & iSCSI has less overhead and demand on network resources than NFS (I've been able to swap the cable from the onboard NIC to a USB gigabit adapter, and it just carried on).

hazeii wrote:You can share most of the filesystem between all the clients, and keep just the variable bits in either local RAM or on a small per-client area on the server. With a gigabit network, it's not going to be troubled by 10 pi's at 100Mb each.

Maybe I should've mentioned that I'm talking about theoretical amounts of devices above 1000. You might see that using any network based file system would clearly cause too much traffic. Furthermore, since Raspberries tend to destroy SD Cards from time to time, using them would cause another problem I wouldn't want to deal with.

hazeii wrote:To keep it all 100% in local RAM, a crude but easy to use approach is to take an SD card, delete /usr and everything obviously not needed from /bin, /sbin and /lib. Once it's cut down to a reasonable size - and still boots - turn what's left into an initial ramdisk, get it booting and then add whatever apps you actually need.

I'll give that a try, but I haven't been able to find out how to create such an initial ramdisk using for example mkinitramfs. Can you tell me which tool to use for this?

so I managed to create an initial ramdisk image, but I'm unsure how to proceed now in order to test it. When I boot my Pi from network, it loads the bootloader and more files including the cmdline.txt file, where it is specified, that /dev/mmcblk0p2 is the root device. This is untrue of course and must be changed. But I have no clue to what it needs to be changed. Let's say I'd change it to /dev/ram0 or sth like that, then there still must be something mounted there already, right?
I also put the line "ramfsfile=initrd.img" inside the config.txt file, but it seems like the Pi wants to mount the root filesystem first, because I'm getting this output line while booting: "Waiting for root device /dev/mmcblk0p2..."

You actually don't need the 'root=' argument if you're going to run everything from the (initial) ramdisk. Basically the kernel will pick up the initial ramdisk from the entry in config.txt , load that as the initial root filesystem and (by default) try to run /sbin/init (which can be a shell script - see 'initrd.txt' in the kernel docs for details).

If you don't actually have anything set to run on the initial ramdisk, the kernel will continue as normal (with the ramdisk as the root filesystem). As long as you have a shell in your ramdisk, add "init=/bin/sh" to cmdline.txt and the kernel will run that.

A very simple ramdisk can contain nothing but a single program (together with any libraries it depends on). In the old days there would always be a statically linked shell in /bin, so 'init=/bin/sh' could be used to recover the system.

What it sounds like you have is the initial ramdisk loading but with nothing running from it, so the kernel continues (and tries to mount the SDCARD filesystem).