i have two 9picpu's. they tftp-boot from the auth+fs. the SD is used for boot loading and the nvram partition. setting up the nvram without a console is tricky; i thought i'd mention it here in case others run into it.

1. using the existing 9pi SD image, edit config.txt and set 'kernel' to 'uboot.img'.

2. on the auth+fs, build a bcm kernel with nvram partition in the kernel (i.e. /boot/nvram)

3. create the /cfg/pxe/<MAC> for the box and initially set the nvram parameter to /boot/nvram.

4. after the first boot, cpu into the rpi and do the auth/wrkey dance with '#S/sdM0/nvram'

5. reset the the nvram in /cfg/pxe/<MAC> to #S/sdM0/nvram

6. rebuild the bcm kernel without the nvram

7. reboot the rpi

i've been contemplating making my auth server a 9picpu booting from local, but SD reliability is the drawback.

On Tue, Nov 18, 2014 at 12:29 PM, Richard Miller <9fans@hamnavoe.com> wrote:

> If you must use a rpi, you should strive to use it as a terminal, and
> like every other Plan 9 terminal it should use the central file server
> without local storage.

That would be my advice too. As an experiment, I set up a 9picpu using
the SD card as local storage, working mostly as a secondary smtp and imap
server. After a bit less than a year, the SD card suffered a catastrophic
failure. When I say catastrophic, I mean I can't find any meaningful data
anywhere in the first 120MB or so of /dev/sdM0/data ... just not-quite-random
looking garbage.

I can't think of any software fault that could wipe out so much of a
disk, with no respect for partition boundaries (the dos partition in
the first 64MB had not been mounted). But I also know too little about
the internals of SD cards to understand how they fail. Maybe some
internal logical-to-physical block mapping table went bad?

Anyway, it's just one anecdotal data point, but I wouldn't be happy
running any plan 9 machine with an SD card as the main filesystem.