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.
-- Christian
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss