Project

General

Profile

Actions
Copy link

Bug #13367

closed

beadm activate -t should not promote new BE datasets

Added by Andy Fiddaman 10 months ago. Updated 10 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Andy Fiddaman
Category:
cmd - userland programs
Start date:
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
1104

Description

At present, temporary BE activation via beadm activate -t promotes the boot environment datasets of the new temporary boot environment, leaving the system in arguably the wrong state when returning to the original BE. This is also different to what happens when temporarily selecting an alternate BE from the loader menu.

For example, here I have selected the objset-onu boot environment from the loader menu:

BE           Active Mountpoint Space   Policy Created
20201206     R      -          119.97G static 2020-12-06 08:47
objset-onu   N      /          538.46M static 2020-12-14 03:50

From the sizes, it's apparent that the original activated BE (with the R against it) is still the primary dataset for the set of ZFS clones.
This is the same for a non-global zone on the system:

root@pkgsrc:~# beadm list
BE    Active Mountpoint Space   Policy Created
zbe   xb     -          244.27M static 2020-12-10 03:01
zbe-1 NR     /          43.81M  static 2020-12-14 03:50

(although note that the NGZ BE is not able to determine the proper R flag location in this case, which is expected)

In contrast, here's what happens after a beadm activate -t objset-onu; init 6 from the 20201206 BE:

BE    Active Mountpoint Space   Policy Created
20201206     R      -          15.11M  static 2020-12-06 08:47
objset-onu   N      /          120.42G static 2020-12-14 03:50

In this case the root dataset for objset-onu has been promoted.
After rebooting back into the original BE, the datasets are still inverted:

BE    Active Mountpoint Space   Policy Created
20201206     NR     /          21.48M  static 2020-12-06 16:47
objset-onu   -      -          120.44G static 2020-12-14 11:50

Another activation of the current BE fixes that:

% pfexec beadm activate 20201206
Activated successfully

% beadm list
BE           Active Mountpoint Space   Policy Created
20201206     NR     /          119.94G static 2020-12-06 16:47
objset-onu   -      -          535.90M static 2020-12-14 11:50

The problem is that this should not be necessary. The expected behaviour on reverting from a temporarily activated BE (via reboot or crash) should be to get back to the system as it was.

Actions
Copy link
 #1

Updated by Andy Fiddaman 10 months ago

Test that temporary activation does not promote the dataset and that upon reboot back into the original BE the primary dataset is correct:

bloody% beadm list
BE           Active Mountpoint Space   Policy Created
20201203     -      -          28.28M  static 2020-12-03 21:08
20201206     NR     /          119.97G static 2020-12-06 16:47
objset-onu   -      -          599.95M static 2020-12-14 11:50
bloody% pfexec beadm activate -t objset-onu
Activated successfully
bloody% beadm list
BE           Active Mountpoint Space   Policy Created
20201203     -      -          28.28M  static 2020-12-03 21:08
20201206     NR     /          119.97G static 2020-12-06 16:47
objset-onu   T      -          599.84M static 2020-12-14 11:50
bloody% pfexec init 6
Shared connection to bloody closed.
build% ssh bloody
The illumos Project     gate-ig_13358_objset-39aa772e10 Dec. 14, 2020
illumos development build: af 2020-Dec-14 [illumos]
bloody% beadm list
BE           Active Mountpoint Space   Policy Created
20201203     -      -          28.28M  static 2020-12-03 13:08
20201206     R      -          119.97G static 2020-12-06 08:47
objset-onu   N      /          599.90M static 2020-12-14 03:50
bloody% pfexec zlogin pkgsrc beadm list
BE    Active Mountpoint Space   Policy Created
zbe   xb     -          247.98M static 2020-12-10 03:01
zbe-1 NR     /          46.15M  static 2020-12-14 03:50
bloody% pfexec init 6
Shared connection to bloody closed.
build% ssh bloody
Last login: Tue Dec 15 14:09:23 2020 from 172.27.10.254
OmniOS r151037  omnios-master-0d048edc02        December 2020
bloody% beadm list
BE           Active Mountpoint Space   Policy Created
20201203     -      -          28.28M  static 2020-12-03 21:08
20201206     NR     /          119.98G static 2020-12-06 16:47
objset-onu   -      -          599.87M static 2020-12-14 11:50

Test that activating the booted BE once booted promotes the datasets properly.

build% ssh bloody
Last login: Tue Dec 15 14:39:41 2020 from 172.27.10.254
OmniOS r151037  omnios-master-0d048edc02        December 2020
bloody% pfexec beadm activate -t objset-onu
Activated successfully
bloody% pfexec init 6
Shared connection to bloody closed.
build% ssh bloody
The illumos Project     gate-ig_13358_objset-39aa772e10 Dec. 14, 2020
illumos development build: af 2020-Dec-14 [illumos]
bloody% beadm list
BE           Active Mountpoint Space   Policy Created
20201203     -      -          28.28M  static 2020-12-03 13:08
20201206     R      -          119.98G static 2020-12-06 08:47
objset-onu   N      /          599.97M static 2020-12-14 03:50

bloody% pfexec beadm activate objset-onu
Activated successfully
bloody% beadm list
BE           Active Mountpoint Space   Policy Created
20201203     -      -          28.28M  static 2020-12-03 13:08
20201206     -      -          58.84M  static 2020-12-06 08:47
objset-onu   NR     /          120.51G static 2020-12-14 03:50
bloody% pfexec zlogin pkgsrc beadm list
BE    Active Mountpoint Space   Policy Created
zbe   xb     -          249.77M static 2020-12-10 03:01
zbe-1 NR     /          46.23M  static 2020-12-14 03:50

Test that a non-temporary activation continues to work as expected:

bloody% beadm list
BE           Active Mountpoint Space   Policy Created
20201203     -      -          28.28M  static 2020-12-03 21:08
20201206     NR     /          119.98G static 2020-12-06 16:47
objset-onu   -      -          599.95M static 2020-12-14 11:50
bloody% pfexec beadm activate objset-onu
Activated successfully
bloody% beadm list
BE           Active Mountpoint Space   Policy Created
20201203     -      -          28.28M  static 2020-12-03 21:08
20201206     N      /          58.90M  static 2020-12-06 16:47
objset-onu   R      -          120.51G static 2020-12-14 11:50
Actions
Copy link
 #2

Updated by Andy Fiddaman 10 months ago

There's also another bug here which this patch fixes. Dataset promotion currently even occurs even when removing a temporary activation:

objset-onu   T      -          602.55M static 2020-12-14 11:50
20201216     NR     /          122.71G static 2020-12-16 13:51
bloody:illumos:master% pfexec beadm activate -T objset-onu
Temporary activation removed
bloody:illumos:master% beadm list
BE           Active Mountpoint Space   Policy Created
objset-onu   -      -          120.51G static 2020-12-14 11:50
20201216     NR     /          2.79G   static 2020-12-16 13:51

I've verified that this no longer happens with the patch applied.

Actions
Copy link
 #3

Updated by Electric Monk 10 months ago

  • Gerrit CR set to 1104
Actions
Copy link
 #4

Updated by Electric Monk 10 months ago

  • % Done changed from 0 to 100
  • Status changed from In Progress to Closed

git commit 8b1df8bf71b7b62e7e4d46fe6b457d4d6447b2b8

commit  8b1df8bf71b7b62e7e4d46fe6b457d4d6447b2b8
Author: Andy Fiddaman <omnios@citrus-it.co.uk>
Date:   2020-12-18T21:15:22.000Z

    13367 beadm activate -t should not promote new BE datasets
    Reviewed by: Toomas Soome <tsoome@me.com>
    Reviewed by: Alexander Eremin <aeremin@tintri.com>
    Approved by: Dan McDonald <danmcd@joyent.com>

Actions
Copy link

Also available in: Atom PDF