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 <9f...@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. > > >
