On 5/4/10 1:25 PM, Christian Thalinger wrote:
On Tue, 2010-05-04 at 12:13 -0600, Evan Layton wrote:
On 5/4/10 11:09 AM, Christian Thalinger wrote:
On Tue, 2010-05-04 at 11:18 -0500, Shawn Walker wrote:
How are you booting the
system? (rEFIt?)
No, I just installed OpenSolaris.
Ah, only OS then?
Yes.
How was this installed, live CD or AI?
Live CD.
Is the pool mirrored and what is the output from "zpool status"?
No, it's not mirrored.
$ zpool status
pool: rpool
state: ONLINE
status: The pool is formatted using an older on-disk format. The pool can
still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'. Once this is done, the
pool will no longer be accessible on older software versions.
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
c12t0d0s0 ONLINE 0 0 0
errors: No known data errors
...
Only bug I see possibly related is 6929493 (in the sense that changes
for the bug may have triggered this issue possibly).
A few days ago I noticed that the new boot environment is actually there
and can be booted despite the ZFS error. I installed b138 today and it
works, but I get this error on updating.
So, there are some ZFS bugs that seem related, although some of them are
supposedly already fixed and I'm not certain that others relate:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6740164
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6860320
Did you recently attach or import any zpools?
I don't think so. The only thing I did was:
http://mail.opensolaris.org/pipermail/laptop-discuss/2009-November/008131.html
Looking at this link it appears that there was something done to import a pool
so it seems it may be possible that an invalid root pool was imported. (by
invalid I mean one with an EFI labeled disk).
Well, I simply booted a modified Live CD (actually USB, but anyway) and
imported my root pool. So if there is an EFI labeled disk now, it also
was there before.
But I did that around 132 or 133 and at least I did one image-update
after that, which worked.
If you imported a pool with an EFI label, for either of these the image-update
would have failed in exactly the same way as this. This limitation for support
of the bootfs property in a pool with an EFI labeled disk has been around pretty
much forever. Based on that this must have been something that changed on your
system after any successful image-update.
For any pools that were imported were these created on another machine? Were
they created on opensolaris and what build? If not I'm wondering if it's
possible that what we're seeing here is bug 6860320 as Shawn mentioned.
As far as I remember I haven't imported anything on my laptop's system,
just the other way around: imported my laptop's rpool on a Live system
running on the laptop.
Also, when you originally installed the OS, did you completely erase the
drive before installing?
I can't remember, but I guess no.
I don't believe you can install on an EFI labeled partition. The installer will
force the creation of a Solaris2 partition to install onto.
Don't know.
...
set_bootfs: failed to set bootfs property for pool rpool: property
'bootfs' not supported on EFI labeled devices
This message is coming from ZFS and you would see the same basic error if you
tried to set the bootfs property on this pool directly.
for example:
# zpool set bootfs=rpool/ROOT/opensolaris rpool
Right. I tried that.
OK that's what I figure but just wanted to confirm.
-- Christian
Can you try the following and see if it really thinks it's an EFI lable?
# dd if=/dev/dsk/c12t0d0s2 of=x skip=512 bs=1 count=10
# cat x
This may help us determine if this is another instance of bug 6860320
If that's not it then I'm at a loss as to how you ended up with an EFI labeled
disk since neither zpool nor install should allow a boot pool to be with an EFI
labeled partition.
-evan
_______________________________________________
indiana-discuss mailing list
indiana-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
