zfs discuss - May 2010 - [indiana-discuss] image-update doesn''t work anymore (bootfs not supported on EFI)

On 5/5/10 1:44 AM, Christian Thalinger wrote:
> On Tue, 2010-05-04 at 16:19 -0600, Evan Layton wrote:
>> 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
>
> # dd if=/dev/dsk/c12t0d0s2 of=x skip=512 bs=1 count=10
> 10+0 records in
> 10+0 records out
> 10 bytes (10 B) copied, 0.0259365 s, 0.4 kB/s
> # cat x
> # od x
> 0000000 000000 000000 000000 000000 000000
> 0000012
> #
>
> Doesn''t look like an EFI label.
>
No that doesn''t appear like an EFI label. So it appears that ZFS
is seeing something there that it''s interpreting as an EFI label.
Then the command to set the bootfs property is failing due to that.

To restate the problem the BE can''t be activated because we
can''t set
the bootfs property of the root pool and even the ZFS command to set
it fails with "property ''bootfs'' not supported on EFI
labeled devices"

for example the following command:
# zfs set bootfs=rpool/ROOT/opensolaris rpool

fails with that same error message.

Do you have any of the older BEs like build 134 that you can boot back
to and see if those will allow you to set the bootfs property on the
root pool? It''s just really strange that out of nowhere it started
thinking that the device is EFI labeled.

I''m including zfs-discuss to get the ZFS folks thoughts on the issue.

-evan


More info from original thread:

 > On 05/ 4/10 10:45 AM, Christian Thalinger wrote:
 >> On Tue, 2010-05-04 at 10:36 -0500, Shawn Walker wrote:
 >>>> What confuses me is that the update from b133 to b134
obviously worked
 >>>> before--because I have a b134 image--but it doesn''t
now.
 >>>
 >>> I''m on b135 myself and haven''t seen this issue
yet.
 >>>
 >>>> I can''t think of anything I did that changed anything
on the disk or
 >>>> the
 >>>> partition table, whatever that could be. Or is this because I
tried to
 >>>> install b137 and that changed something?
 >>>
 >>> What does your partition layout look like?
 >>
 >> Not sure how I can print the partition to show what you want to see.
 >> Maybe this:
 >>
 >> format> current
 >> Current Disk = c12t0d0
 >> <DEFAULT cyl 38910 alt 2 hd 255 sec 63>
 >> /pci at 0,0/pci10de,cb79 at b/disk at 0,0
 >>
 >> format> verify
 >>
 >> Primary label contents:
 >>
 >> Volume name =< >
 >> ascii name =<DEFAULT cyl 38910 alt 2 hd 255 sec 63>
 >> pcyl = 38912
 >> ncyl = 38910
 >> acyl = 2
 >> bcyl = 0
 >> nhead = 255
 >> nsect = 63
 >> Part Tag Flag Cylinders Size Blocks
 >> 0 root wm 1 - 38909 298.06GB (38909/0/0) 625073085
 >> 1 unassigned wm 0 0 (0/0/0) 0
 >> 2 backup wu 0 - 38909 298.07GB (38910/0/0) 625089150
 >> 3 unassigned wm 0 0 (0/0/0) 0
 >> 4 unassigned wm 0 0 (0/0/0) 0
 >> 5 unassigned wm 0 0 (0/0/0) 0
 >> 6 unassigned wm 0 0 (0/0/0) 0
 >> 7 unassigned wm 0 0 (0/0/0) 0
 >> 8 boot wu 0 - 0 7.84MB (1/0/0) 16065
 >> 9 unassigned wm 0 0 (0/0/0) 0
 >>
 >> format>
 >>
 >>> How are you booting the
 >>> system? (rEFIt?)
 >>
 >> No, I just installed OpenSolaris.
 >
 > Ah, only OS then?
 >
 > ...
 >>> 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?
 >
 > Also, when you originally installed the OS, did you completely erase the
 > drive before installing?
 >
 > 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
 > ...
 > set_bootfs: failed to set bootfs property for pool rpool: property
 > ''bootfs'' not supported on EFI labeled devices
 > be_activate: failed to set bootfs pool property for
 > rpool/ROOT/opensolaris-135

On Wed, 2010-05-05 at 09:45 -0600, Evan Layton wrote:
> No that doesn''t appear like an EFI label. So it appears that ZFS
> is seeing something there that it''s interpreting as an EFI label.
> Then the command to set the bootfs property is failing due to that.
> 
> To restate the problem the BE can''t be activated because we
can''t set
> the bootfs property of the root pool and even the ZFS command to set
> it fails with "property ''bootfs'' not supported on
EFI labeled devices"
> 
> for example the following command:
> # zfs set bootfs=rpool/ROOT/opensolaris rpool
> 
> fails with that same error message.
I guess you mean zpool, but yes:

# zpool set bootfs=rpool/ROOT/opensolaris-138 rpool
cannot set property for ''rpool'': property
''bootfs'' not supported on EFI labeled devices
> 
> Do you have any of the older BEs like build 134 that you can boot back
> to and see if those will allow you to set the bootfs property on the
> root pool? It''s just really strange that out of nowhere it started
> thinking that the device is EFI labeled.
I have a couple of BEs I could boot to:

$ beadm list
BE              Active Mountpoint Space   Policy Created          
--              ------ ---------- -----   ------ -------          
opensolaris     -      -          1.00G   static 2009-10-01 08:00 
opensolaris-124 -      -          20.95M  static 2009-10-03 13:30 
opensolaris-125 -      -          30.00M  static 2009-10-17 15:18 
opensolaris-126 -      -          25.33M  static 2009-10-29 20:18 
opensolaris-127 -      -          1.37G   static 2009-11-14 13:20 
opensolaris-128 -      -          1.91G   static 2009-12-04 14:28 
opensolaris-129 -      -          22.49M  static 2009-12-12 11:31 
opensolaris-130 -      -          21.64M  static 2009-12-26 19:46 
opensolaris-131 -      -          24.72M  static 2010-01-22 22:51 
opensolaris-132 -      -          57.32M  static 2010-02-09 23:05 
opensolaris-133 -      -          1.07G   static 2010-02-20 12:55 
opensolaris-134 N      /          43.17G  static 2010-03-08 21:58 
opensolaris-138 R      -          1.81G   static 2010-05-04 12:03 

I will try on 132 or 133.  Get back to you later.

-- Christian

On 5/5/10 10:22 AM, Christian Thalinger wrote:
> On Wed, 2010-05-05 at 09:45 -0600, Evan Layton wrote:
>> No that doesn''t appear like an EFI label. So it appears that
ZFS
>> is seeing something there that it''s interpreting as an EFI
label.
>> Then the command to set the bootfs property is failing due to that.
>>
>> To restate the problem the BE can''t be activated because we
can''t set
>> the bootfs property of the root pool and even the ZFS command to set
>> it fails with "property ''bootfs'' not supported
on EFI labeled devices"
>>
>> for example the following command:
>> # zfs set bootfs=rpool/ROOT/opensolaris rpool
>>
>> fails with that same error message.
>
> I guess you mean zpool, but yes:
Yes that''s what I meant (I hate when my fingers betray me like that)
;-)
>
> # zpool set bootfs=rpool/ROOT/opensolaris-138 rpool
> cannot set property for ''rpool'': property
''bootfs'' not supported on EFI labeled devices
>
>>
>> Do you have any of the older BEs like build 134 that you can boot back
>> to and see if those will allow you to set the bootfs property on the
>> root pool? It''s just really strange that out of nowhere it
started
>> thinking that the device is EFI labeled.
>
> I have a couple of BEs I could boot to:
>
> $ beadm list
> BE              Active Mountpoint Space   Policy Created
> --              ------ ---------- -----   ------ -------
> opensolaris     -      -          1.00G   static 2009-10-01 08:00
> opensolaris-124 -      -          20.95M  static 2009-10-03 13:30
> opensolaris-125 -      -          30.00M  static 2009-10-17 15:18
> opensolaris-126 -      -          25.33M  static 2009-10-29 20:18
> opensolaris-127 -      -          1.37G   static 2009-11-14 13:20
> opensolaris-128 -      -          1.91G   static 2009-12-04 14:28
> opensolaris-129 -      -          22.49M  static 2009-12-12 11:31
> opensolaris-130 -      -          21.64M  static 2009-12-26 19:46
> opensolaris-131 -      -          24.72M  static 2010-01-22 22:51
> opensolaris-132 -      -          57.32M  static 2010-02-09 23:05
> opensolaris-133 -      -          1.07G   static 2010-02-20 12:55
> opensolaris-134 N      /          43.17G  static 2010-03-08 21:58
> opensolaris-138 R      -          1.81G   static 2010-05-04 12:03
>
> I will try on 132 or 133.  Get back to you later.
Thanks!

On Wed, 2010-05-05 at 10:35 -0600, Evan Layton wrote:
> >> Do you have any of the older BEs like build 134 that you can boot
back
> >> to and see if those will allow you to set the bootfs property on
the
> >> root pool? It''s just really strange that out of nowhere
it started
> >> thinking that the device is EFI labeled.
> >
> > I have a couple of BEs I could boot to:
> >
> > $ beadm list
> > BE              Active Mountpoint Space   Policy Created
> > --              ------ ---------- -----   ------ -------
> > opensolaris     -      -          1.00G   static 2009-10-01 08:00
> > opensolaris-124 -      -          20.95M  static 2009-10-03 13:30
> > opensolaris-125 -      -          30.00M  static 2009-10-17 15:18
> > opensolaris-126 -      -          25.33M  static 2009-10-29 20:18
> > opensolaris-127 -      -          1.37G   static 2009-11-14 13:20
> > opensolaris-128 -      -          1.91G   static 2009-12-04 14:28
> > opensolaris-129 -      -          22.49M  static 2009-12-12 11:31
> > opensolaris-130 -      -          21.64M  static 2009-12-26 19:46
> > opensolaris-131 -      -          24.72M  static 2010-01-22 22:51
> > opensolaris-132 -      -          57.32M  static 2010-02-09 23:05
> > opensolaris-133 -      -          1.07G   static 2010-02-20 12:55
> > opensolaris-134 N      /          43.17G  static 2010-03-08 21:58
> > opensolaris-138 R      -          1.81G   static 2010-05-04 12:03
> >
> > I will try on 132 or 133.  Get back to you later.
> 
> Thanks!
Sorry, I kind of forgot :-)

root at macbook:~# uname -a
SunOS macbook 5.11 snv_132 i86pc i386 i86pc Solaris
root at macbook:~# zpool set bootfs=rpool/ROOT/opensolaris-132 rpool
cannot set property for ''rpool'': property
''bootfs'' not supported on EFI labeled devices

-- Christian