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

Reply via email to