From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <1a3157d28f8065b3a7072365eb88e464@hamnavoe.com> References: <1a3157d28f8065b3a7072365eb88e464@hamnavoe.com> Date: Tue, 18 Nov 2014 14:11:26 -0800 Message-ID: From: Skip Tavakkolian To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=047d7b41c5765a2d0b0508296091 Subject: Re: [9fans] running plan9 : an ideal setup? Topicbox-Message-UUID: 2bbf5e8e-ead9-11e9-9d60-3106f5b1d025 --047d7b41c5765a2d0b0508296091 Content-Type: text/plain; charset=UTF-8 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/ 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/ 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. > > > --047d7b41c5765a2d0b0508296091 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 nvr= am without a console is tricky; i thought i'd mention it here in case o= thers run into it.

1. using the existing 9pi SD image, e= dit 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 an= d initially set the nvram parameter to /boot/nvram.
4. after the = first boot, =C2=A0cpu into the rpi and do the auth/wrkey dance with '#S= /sdM0/nvram'
5. reset the the nvram in /cfg/pxe/<MAC> t= o #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 drawb= ack.


<= div class=3D"gmail_quote">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.=C2=A0 As an experiment, I set up a 9pic= pu using
the SD card as local storage, working mostly as a secondary smtp and imap server.=C2=A0 After a bit less than a year, the SD card suffered a catastro= phic
failure.=C2=A0 When I say catastrophic, I mean I can't find any meaning= ful data
anywhere in the first 120MB or so of /dev/sdM0/data ... just not-quite-rand= om
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).=C2=A0 But I also know too little abou= t
the internals of SD cards to understand how they fail.=C2=A0 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.



--047d7b41c5765a2d0b0508296091--