[9fans] nvram

[Lyndon Nerenberg]

Okay, it's authsrv(2) that describes the nvram search sequence. And for
whatever reason I had it in my head that these days it was possible to
grab the nvram across the wire, which in hindsight makes no sense
whatsoever. And now that I think about it, my last (2ed) 'diskless' CPU
server had a floppy drive in it for this very reason ...

Doncha just love PC hardware?

--lyndon

[ron minnich]

years back I modified the library so that it could use the cmos nvram.
no more disk. We used this when Andrey
put plan 9 in FLASH.

It was nice to not have any spinning media for nvram.

It gets a little tricky because cmos is not sane in where you can
store bits, but it's doable.

ron

ron

[erik quanstrom]

ya. we use small flash drives from memorydepot.com for this.
but if price is really the limiter, not power or anything else,
you may prefer to use a regular hard drive. or, i think you
could use sdloop to mount a usb key on boot and put your
nvram on that. that might be complicated due to boot ordering
problems.

i guess i need to update this man page. i didn't recall the
search algorithm was documented. thanks for pointing that out.

- erik

[erik quanstrom]

> i guess i need to update this man page. i didn't recall the
> search algorithm was documented. thanks for pointing that out.

sorry for the obtuse reference. now that i've made it on the list,
i'll just explain myself. i made a local change to how
nvram is found because i kept needing to update the search to
add new drives. sata has made it more difficult to just enumerate
the possibilities. a vanilla machine can have 2 ahci controllers
and up to 32 drives per controller. devsd supports up to 16 drives
per controller, which covers existing hardware. that becomes annoying
to enumerate. my test machine has 1 ahci, 2 ide, 1 mv50xx, 2 marvell orion
and 1 loopback controller. since the current approach requires 2 entries per
drive, i changed to this algorithm:

1. read #S/sdctl. gather a list of device ids. example /dev/sdC, /dev/sdE.
2. for each device, probe drives 0-f. example /dev/sdE[0-f]. both
a partition named "nvram" and 9fat/plan9.nvr are probed.

note:
a. probes on other devices are unchanged.
b. i modified sd so that each sd device produces exactly 1 line in #S/sdctl.
the parallel scsi drivers had previously been missing.

bugs:
a. non-sd disks like usb still can't be used with this scheme.
b. probe order depends on the order of sd devices in your kernel
config.

one could argue that you should just plug your nvram drive into a
low-numbered port, but i kept running situations where i couldn't
use the ports i wanted due to chassis constraints. ahci also provides
a mechanism for disabling ports, so it's anyone's guess what ports
are actually available.

this change as worked well on my personal system and at coraid
for the past 6 months. it just works. even on hitherto unknown
controllers like the orion.

- erik

[erik quanstrom]

> years back I modified the library so that it could use the cmos nvram.
> no more disk. We used this when Andrey
> put plan 9 in FLASH.
>
> It was nice to not have any spinning media for nvram.
>
> It gets a little tricky because cmos is not sane in where you can
> store bits, but it's doable.

i don't believe this is safe for an arbitrary (rtc device, bios vendor).
i may have missed something, since some of the bios in question
are obsolete.

http://bochs.sourceforge.net/techspec/CMOS-reference.txt

- erik

[Adriano Verardo]

Hi, all

I boot diskless (very obsolete PC) embedding the nvram data in the kernel.
Basically I implemented a fake-nram driver and declare it in the plan9.ini
It's just a trick but works.

If such a solution could be useful for the community I would be happy
to deliver the source.

adriano

[ron minnich]

On Tue, Jul 28, 2009 at 12:24 PM, erik quanstrom<quan...@coraid.com> wrote:

> i don't believe this is safe for an arbitrary (rtc device, bios vendor).
> i may have missed something, since some of the bios in question
> are obsolete.

Hard to say. newer rtc has a whopping doubled-size CMOS and the BIOS
vendors don't seem to have used it all yet.

I think it would be worth trying to use it, but, well it is a PC, hmm.

ron

[Dan Cross]

On Tue, Jul 28, 2009 at 2:37 PM, erik quanstrom<quan...@quanstro.net> wrote:
> this change as worked well on my personal system and at coraid
> for the past 6 months.  it just works.  even on hitherto unknown
> controllers like the orion.

Hmm. A few years ago, I ran into a similar problem and added a
variable that could be set in plan9.ini to specify where the nvram
actually is. It works reasonably well....

[erik quanstrom]

> Hmm. A few years ago, I ran into a similar problem and added a
> variable that could be set in plan9.ini to specify where the nvram
> actually is. It works reasonably well....

difficult to maintain in a pretty active environment;
one more reason for boot failure.

- erik

[sqweek]

2009/7/29 erik quanstrom <quan...@quanstro.net>:

Speaking of, I had a disk in my server die recently, and eventually
it affected the nvram partition. So of course, when I booted up it
couldn't read it and prompted me for the auth credentials, then tried
to write back to nvram, got an i/o error and rebooted.
The reboot could have been caused by some other problem shortly after
(the motherboard seems to have given up on me also), but it raised the
question - does an unsuccesful write to nvram halt the boot process?
-sqweek

[erik quanstrom]

> Speaking of, I had a disk in my server die recently, and eventually
> it affected the nvram partition. So of course, when I booted up it
> couldn't read it and prompted me for the auth credentials, then tried
> to write back to nvram, got an i/o error and rebooted.
> The reboot could have been caused by some other problem shortly after
> (the motherboard seems to have given up on me also), but it raised the
> question - does an unsuccesful write to nvram halt the boot process?

no. it happens to me all the time. (when there is no
place to write nvram, as when no disk is partitioned.)

- erik

[sqweek]

2009/7/31 erik quanstrom <quan...@quanstro.net>:

OK, but you won't hit an error in that case either. I was wondering
whether the i/o problem was tripping it up.
-sqweek

[erik quanstrom]

> >
> > no.  it happens to me all the time.  (when there is no
> > place to write nvram, as when no disk is partitioned.)
>
> OK, but you won't hit an error in that case either. I was wondering
> whether the i/o problem was tripping it up.
> -sqweek

factotum handles this case.

- erik

[Steve Simon]

no it doesn't, I had this a few days ago, moving disks about so
nvram couldn't be found. I could still boot the system but I had to enter
the nvram info from the keyboard, it did then try to write the data back
which (of course) fails - perhaps it was this write to a dead disk that
caused the boot process to die.

-Steve

[erik quanstrom]

i hate to disagree. but i think you may have typed your
auth information incorrectly — that does cause a panic. but not having
a plan9.nvr or nvram partition does not. here's a demo i
just ran:

baxley# 9fat:
baxley# rm /n/9fat/plan9.nvr
baxley# echo reboot>/dev/reboot
[...]
2040M memory: 108M kernel data, 1931M user, 2556M swap
sdE0: LBA 3,931,200 sectors
SATADOM H Type rs1.a000 20090504AA0000000013 [newdrive]
readnvram: couldn't find nvram
can't read nvram: unknown device in # filename
authid: bootes
authdom: plan9.quanstro.net
secstore key:
password:
can't write key to nvram: unknown device in # filename
version...time...
nit: starting /bin/rc
baxley#

now if i mistype my auth information, i get

version...authpanic: boot process died: unknown
entication failed (auth_proxy rpc write: : bad key), trying mount anyways
boot: mount /: attach -- unknown user or failed authentication
dumpstack

unfortunately, at this point i'm stuck in a reboot loop and
i can only disconnect the offending media.

- erik