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?
Is the pool mirrored and what is the output from "zpool status"?
...
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).
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.
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.
I've run into problems in the past where fixes or changes have caused
the OS to check partition headers and other areas for signatures that
were leftover by other disk utilities and gave me grief.
So, to be clear, sometime after you updated to b134, you could no longer
update to any other builds because it gave you a message like this?
be_get_uuid: failed to get uuid property from BE root dataset user
This is a known spurious message that has since been fixed.
...
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
be_activate: failed to set bootfs pool property for
rpool/ROOT/opensolaris-135
Exactly.
-- Christian
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
