[9fans] "Can't read from nvram: /env/nvrof file does not exist"
ron minnich
well I'm a bit closer but ... what is this?
ron
Russ Cox
it really matters a lot when trying to search for them.
i'm guessing that the real message is
can't read nvram: '/env/nvroff' file does not exist
you need to also set nvroff=0 in your plan9.ini,
it appears. that's surely a bug in the readnvram
code, but the easiest fix is to play along.
Dan Cross
> it appears. that's surely a bug in the readnvram
> code, but the easiest fix is to play along.
Hmm, that's strange. I doubt it's a bug in the readnvram code, but
rather, something weird that's causing the read to fail, and when
readnvram() prints out an error message, "%r" is being interpolated
with the last error string (that the nvroff environment variable
doesn't exist). My guess is that the nvram file doesn't exist on the
9fat on the flash device.
- Dan C.
Russ Cox
> rather, something weird that's causing the read to fail, and when
> readnvram() prints out an error message, "%r" is being interpolated
> with the last error string (that the nvroff environment variable
> doesn't exist). My guess is that the nvram file doesn't exist on the
> 9fat on the flash device.
No, it's definitely a bug. In order to use $nvram,
the code requires $nvroff to be set too. Read it,
you'll see.
Russ Cox
if(strstr(v[0], "/9fat") == nil)
safeoff = 0;
the open failed, but the error is lost.
the open might fail because you typed
the wrong value for $nvram, or perhaps
it fails because the open is ORDWR?
i doubt the ide driver is smart
enough to know that flash is only OREAD,
so i don't think this is it.
Dan Cross
>
> if(strstr(v[0], "/9fat") == nil)
> safeoff = 0;
>
> the open failed, but the error is lost.
Yeah. It's an unfortunate side effect of readnvram's error recovery.
If it fails to read nvram, it tries to write it, so error printing is
delayed. As you noted, to use $nvram, $nvoff is not necessary.
> the open might fail because you typed
> the wrong value for $nvram, or perhaps
> it fails because the open is ORDWR?
> i doubt the ide driver is smart
> enough to know that flash is only OREAD,
> so i don't think this is it.
Wha...? What do you mean `flash is only OREAD'? This is a solid state
device that looks like an IDE hard disk, and most likely is writable.
After looking at the code again, I'm pretty sure that plan9.nvr doesn't
exist in the 9fat, or that there's a typo in $nvram such that it points
to a non-existant file.
- Dan C.
ron minnich
> Hmm, that's strange. I doubt it's a bug in the readnvram code, but
> rather, something weird that's causing the read to fail, and when
> readnvram() prints out an error message, "%r" is being interpolated
> with the last error string (that the nvroff environment variable
> doesn't exist). My guess is that the nvram file doesn't exist on the
> 9fat on the flash device.
well, this brings up an issue. I am having a weird IDE problem with plan9
fdisk and prep.
Here are the platforms.
vmware, virtual disk (i.e. a file) on 2nd channel master (sdD0)
vmware, virtual disk (i.e. a file) on 1st channel master (sdC0)
vmware, compact flash physical disk on 2nd channel master (sdD0)
geode (hardware), compact flash on 2nd channel master (sdD0)
If I do this in plan 9 fdisk:
fdisk /dev/sdx0/data
p 1 0 490
w
q
once I exit, no partition is there.
If I do this:
cat > /dev/sdx0/ctl
<some partition info>
the partition is there *until reboot*, then it goes away
If I fdisk the CF in linux, the partition(s) are there.
(in this case I create FAT and Plan 9 partitions in linux fdisk)
Once I fdisk the CF in linux, and use the disk in plan 9, I can:
prep -banw /dev/sdx0/plan9
the plan9 partitions are there -- until reboot.
OK, what am I doing wrong? Seems like the fdisk/prep stuff does not
'take'. But it works fine for install. weird.
ron
ron minnich
> the open might fail because you typed
> the wrong value for $nvram, or perhaps
> it fails because the open is ORDWR?
> i doubt the ide driver is smart
> enough to know that flash is only OREAD,
> so i don't think this is it.
no this is compact flash, and it should work. There is something weird
going on.
I assume plan 9 partitions use:
- sector 0, 0-511 bytes, for MBR
- sector 1, 512-1023 bytes, for plan9 partitioning
is that it?
I may try writing this under linux and see what shakes.
ron
ron minnich
partition if no nvram partition is found, right? what environment variable
could force this behaviour?
ron
Russ Cox
> fdisk /dev/sdx0/data
> p 1 0 490
> w
> q
>
> once I exit, no partition is there.
I assume you actually typed
a p1 0 490
w
q
If you type `p' before writing and quitting, you will notice
that the newly created partition has type `EMPTY'.
You have to set the partition type with the `t' command,
which, I am surprised to say, is undocumented. Sorry.
(Type '?' at a fdisk prompt and it will tell you about `t'.)
> If I do this:
> cat > /dev/sdx0/ctl
> <some partition info>
>
> the partition is there *until reboot*, then it goes away
That's because you edited the kernel's in-memory partition table.
> Once I fdisk the CF in linux, and use the disk in plan 9, I can:
> prep -banw /dev/sdx0/plan9
> the plan9 partitions are there -- until reboot.
If, after reboot, you run
disk/prep -p /dev/sdx0/plan9 >/dev/sdx0/ctl
does that recreate the partitions properly?
This is in the standard termrc:
for(disk in /dev/sd??) {
if(test -f $disk/data && test -f $disk/ctl)
disk/fdisk -p $disk/data >$disk/ctl >[2]/dev/null
for(part in $disk/plan9*)
if(test -f $part)
disk/prep -p $part >$disk/ctl >[2]/dev/null
}
When you need the partitions earlier in the boot process,
it is 9load's job to pass that information to the kernel.
Sounds like this isn't happening, presumably because
9load can't see your compact flash disk.
I think you should try to fix 9load to recognize your CF
disk and then you'll be happier all around. If you diff
/sys/src/boot/pc/sdata.c /sys/src/9/pc/sdata.c
this sticks out as one of the only significant pieces of
code that is missing from the 9load version:
>
> /*
> * Beware the CompactFlash Association feature set.
> * Now, why this value in Iconfig just walks all over the bit
> * definitions used in the other parts of the ATA/ATAPI standards
> * is a mystery and a sign of true stupidity on someone's part.
> * Anyway, the standard says if this value is 0x848A then it's
> * CompactFlash and it's NOT a packet device.
> */
> iconfig = drive->info[Iconfig];
> if(iconfig != 0x848A && (iconfig & 0xC000) == 0x8000){
> if(iconfig & 0x01)
(The other big difference is there is no DMA support in the
9load version, but that's okay.)
Russ
Dan Cross
> partition if no nvram partition is found, right? what environment variable
> could force this behaviour?
I don't think so; why do you say that? The environment variable you
could use to force it would be to set nvram. Eg, nvram=#S/sdD0/9fat
will force it to look for plan9.nvr on the 9fat partition on sdD0. If
you set it to, e.g., #S/sdD0/9fat!foo.nvr, you can use a different
filename.
My guess is that plan9.nvr doesn't exist on the 9fat partition. Did
you `dd -if /dev/zero -of plan9.nvr -count 1'?
- Dan C.
r...@plan9.bell-labs.com
> could use to force it would be to set nvram. Eg, nvram=#S/sdD0/9fat
> will force it to look for plan9.nvr on the 9fat partition on sdD0. If
> you set it to, e.g., #S/sdD0/9fat!foo.nvr, you can use a different
> filename.
>
> My guess is that plan9.nvr doesn't exist on the 9fat partition. Did
> you `dd -if /dev/zero -of plan9.nvr -count 1'?
You could also set up an nvram partition and use #S/sdD0/nvram,
which I thought was what he did.
In any case, none of this is going to work unless 9load finds the
disk, parses the partition tables, and leaves the info for the kernel.
That's the real problem.
ron minnich
> In any case, none of this is going to work unless 9load finds the
> disk, parses the partition tables, and leaves the info for the kernel.
> That's the real problem.
yep. I added that CompactFlash patch but 9load still doesn't see it.
so still looking.
ron
Dan Cross
> > you `dd -if /dev/zero -of plan9.nvr -count 1'?
>
> You could also set up an nvram partition and use #S/sdD0/nvram,
> which I thought was what he did.
True.
> In any case, none of this is going to work unless 9load finds the
> disk, parses the partition tables, and leaves the info for the kernel.
> That's the real problem.
Oh, I thought that was on another machine? Hmm. Okay.
- Dan C.
ron minnich
> disk, parses the partition tables, and leaves the info for the kernel.
It's finding the disk. I *think* it's parsing the tables.
but env variables aren't making it form 9load to kernel. weird.
another thing to figure out, possibly related to 9load running at 0x800000
instead of < 0x100000
ron
Russ Cox
thing it does is relocate itself anyway. 9load
leaves plan9.ini at BOOTARGS (see mem.h and conf.c).
Presumably you haven't changed this, but if you have
you need to change the kernel too.
ron minnich
> leaves plan9.ini at BOOTARGS (see mem.h and conf.c).
well, hmm, now I am confused ... again.
My reading of 9load left me thinking that environment stuff got dropped at
80001200 by addconf() and friends. Is that wrong? Seems like I am off
track and should be leaving the equivalent of plan9.ini at BOOTARGS?
this could explain something.
ron
r...@plan9.bell-labs.com
you're just fine. The ``environment stuff'' *is*
plan9.ini.