i thoufgt th accepted way was, (assumping your machine has an IDE interface),
to use an IDE to compact flash adapter and and a CF card, and store the
nvram on this.
this gives you the simple interface of IDE but no rotating disks.
-Steve
That's a much more expensive and involved
method than tacking on a little USB key, to
which you've copied nvram data using `dd'.
ron's method above, with a simple
`dd -if nvram -of /dev/sdU0.0/data' and
three lines in plan9.ini did the trick.
No rotating disks.
The other problem is that my box
sorry, our machines were disconnected for the entire night and I didn't
get mails until now. that's why I didn't reply.
But I see that it's all written in recent mails.
cheers
On Mon, Jul 11, 2011 at 11:28 AM, Akshat Kumar
aku...@mail.nanosouffle.net wrote:
That's a much more expensive and
On 11.07.2011, Steve Simon st...@quintile.net wrote:
i thoufgt th accepted way was, (assumping your machine has an IDE
interface),
to use an IDE to compact flash adapter and and a CF card, and store the
nvram on this.
You can get small IDE DOMs for under ten bucks. No need for CF adapters.
rusty power supply that seems incapable
of handling any IDE devices. Not sure
what's going on at this point, really. But
it does fine as a basic CPU server (more
of an interface to Plan 9 from other OS's).
do yourself a favor. don't run with a dodgy power supply.
there are just too many
I just took all the disks out of my cpu server.
I'm booting from my fileserver. I get the following
prompts (which make the bootup process really
non-automated):
readnvram: couldn't find nvram
can't open nil: unknown device in # filename
authid: bootes
authdom: mydom
secstore:
password:
can't
Some time ago I modified the rtc driver so we could use '#r/nvram'
(oh, gosh, this was almost 10 years ago but ...) so that we could use
the CMOS to store this stuff. Maybe it's time for another look.
ron
On Sun Jul 10 17:56:42 EDT 2011, rminn...@gmail.com wrote:
Some time ago I modified the rtc driver so we could use '#r/nvram'
(oh, gosh, this was almost 10 years ago but ...) so that we could use
the CMOS to store this stuff. Maybe it's time for another look.
vorsicht! there's a lot of magic
Well, I don't have a dedicated AoE for secure keys.
Alternatively, can I store the keys on a little USB
device? Does it require anything more than a change
to the INI (in this case PXE) file?
On Sun, Jul 10, 2011 at 3:04 PM, erik quanstrom
quans...@labs.coraid.com wrote:
On Sun Jul 10 17:56:42
On Sun, Jul 10, 2011 at 3:04 PM, erik quanstrom
quans...@labs.coraid.com wrote:
vorsicht! there's a lot of magic stuff in the rtc. and where the magic
bits are depends on your particular special bios.
Sure. but it's been done. We did it.
ron
yeah, the usb would be a great place to store it! Then you can easily
rewrite the key ...
ron
Sure, but how do mounting and reading and all
that jazz, work on boot?
On Sun, Jul 10, 2011 at 3:13 PM, ron minnich rminn...@gmail.com wrote:
yeah, the usb would be a great place to store it! Then you can easily
rewrite the key ...
ron
write to the raw disk, and use the device name for nvram in plan9.ini
On Mon, Jul 11, 2011 at 12:20 AM, Akshat Kumar
aku...@mail.nanosouffle.net wrote:
Sure, but how do mounting and reading and all
that jazz, work on boot?
On Sun, Jul 10, 2011 at 3:13 PM, ron minnich rminn...@gmail.com wrote:
and of course the other option is to put a file named 'nvram' into the
image and use that. usually the easiest.
ron
it's probablly worth mentioning that if you have nvram
in an emulator, your secstore password is available in the
clear to whomever can read your emulator's emulated disk.
- erik
2009/7/29 erik quanstrom quans...@quanstro.net:
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
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
2009/7/31 erik quanstrom quans...@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
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
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
On Thu Jul 30 14:13:18 EDT 2009, st...@quintile.net wrote:
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
On Tue, Jul 28, 2009 at 2:37 PM, erik quanstromquans...@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
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
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
On Tue Jul 28 14:00:22 EDT 2009, lyn...@orthanc.ca wrote:
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
On Tue, Jul 28, 2009 at 10:58 AM, Lyndon Nerenberglyn...@orthanc.ca wrote:
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.
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
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
On Tue, Jul 28, 2009 at 12:24 PM, erik quanstromquans...@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
29 matches
Mail list logo
