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.
>
>
>