Description
Solaris 10 Live Upgrade patches 121430-66 through 121430-88 (SPARC) and 121431-67 through 121431-89 (x86) may cause ludelete(1M) to erroneously delete unmounted zfs(1M) datasets that are shared across all Boot Environments.
All datasets that do not lie in the hierarchy of 'root' file system are termed as shared datasets in Live Upgrade. These datasets are available to be used across all Boot Environments present in the system. These datasets are considered as shared because they do not belong exclusively to a particular Boot Environment.
This erroneous deletion would occur only if an Alternate Boot Environment ('ABE1') is successfully created with shared datasets, followed by the unmounting of shared datasets. Then one more Alternate Boot Environment ('ABE2') is created successfully, followed by the deletion of 'ABE1' resulting in the deletion of shared datasets.
The sequence of events is summarized below:
1.$ zfs create zonepool/test
2.$ lucreate -n ABE1
3.$ zfs umount zonepool/test
4.$ lucreate -n ABE2
Results: ludelete ABE1 'zonepool/test' will get deleted.
Occurrence
This issue can occur in the following releases:
SPARC Platform
•Solaris 10 with patch 121430-66 through 121430-88 and without patch 121430-89
x86 Platform
•Solaris 10 with patch 121431-67 through 121431-89 and without patch 121431-90
Notes:
1. Solaris 8, Solaris 9 and Solaris 11 are not impacted by this issue.
2. Solaris 10 UFS root file system with user created UFS file systems are not affected by this issue.
3. This issue only affects systems with shared datasets. To determine if a system has such a dataset, the following procedure can be used (Output will vary in different configurations):
1. Determine the name of the Primary Boot Environment (PBE) with the lucurr(1M) command:
# lucurr
OLD_BE
2. Get the root pool dataset for that PBE from the '/etc/lutab' file:
# cat /etc/lutab
<output elided>
1:OLD_BE:C:0
1:/:rootPool/ROOT/s10u10:1
1:boot-device:/dev/dsk/c0t0d0s0:2
<output elided>
3. Get the list of shared datasets present on the system using the root pool dataset obtained from the previous step.
# zfs get mounted | grep -v rootPool/ROOT
NAME PROPERTY VALUE SOURCE
rootPool mounted yes -
rootPool/dump mounted - -
rootPool/export mounted yes -
rootPool/export/home mounted yes -
rootPool/swap mounted - -
zonePool mounted yes -
zonePool/test mounted no -
Note that all the datasets outside of the hierarchy of rootPool/ROOT are considered as shared file systems (eg: zonePool/test). The column VALUE above also shows whether these zfs(1M) datasets are currently mounted or not.
In the above example, the dataset zonePool/test would be erroneously deleted from the PBE as a result of running ludelete(1M) if it was unmounted after the creation of the boot environment (ABE1).
Note: Datasets whose mount status is either "yes" or "-" will not be deleted.
Symptoms
There are no warnings or errors issued when this erroneous deletion from the PBE occurs.
Workaround
To avoid this issue, before issuing the ludelete(1M) command, mount the shared datasets that are shared across boot environments. This needs to be done only if those shared datasets were mounted during the creation of the Alternate Boot Environment and were later unmounted. This is the only way to avoid the shared datasets from getting deleted. If the datasets are deleted, they cannot be retrieved.
This issue is addressed in the following releases:
SPARC Platform
•Solaris 10 with patch 121430-89 or later
x86 Platform
•Solaris 10 with patch 121431-90 or later
Patches
SUNPATCH:121430-89
SUNPATCH:121431-90
Solaris 10 Live Upgrade patches 121430-66 through 121430-88 (SPARC) and 121431-67 through 121431-89 (x86) may cause ludelete(1M) to erroneously delete unmounted zfs(1M) datasets that are shared across all Boot Environments.
All datasets that do not lie in the hierarchy of 'root' file system are termed as shared datasets in Live Upgrade. These datasets are available to be used across all Boot Environments present in the system. These datasets are considered as shared because they do not belong exclusively to a particular Boot Environment.
This erroneous deletion would occur only if an Alternate Boot Environment ('ABE1') is successfully created with shared datasets, followed by the unmounting of shared datasets. Then one more Alternate Boot Environment ('ABE2') is created successfully, followed by the deletion of 'ABE1' resulting in the deletion of shared datasets.
The sequence of events is summarized below:
1.$ zfs create zonepool/test
2.$ lucreate -n ABE1
3.$ zfs umount zonepool/test
4.$ lucreate -n ABE2
Results: ludelete ABE1 'zonepool/test' will get deleted.
Occurrence
This issue can occur in the following releases:
SPARC Platform
•Solaris 10 with patch 121430-66 through 121430-88 and without patch 121430-89
x86 Platform
•Solaris 10 with patch 121431-67 through 121431-89 and without patch 121431-90
Notes:
1. Solaris 8, Solaris 9 and Solaris 11 are not impacted by this issue.
2. Solaris 10 UFS root file system with user created UFS file systems are not affected by this issue.
3. This issue only affects systems with shared datasets. To determine if a system has such a dataset, the following procedure can be used (Output will vary in different configurations):
1. Determine the name of the Primary Boot Environment (PBE) with the lucurr(1M) command:
# lucurr
OLD_BE
2. Get the root pool dataset for that PBE from the '/etc/lutab' file:
# cat /etc/lutab
<output elided>
1:OLD_BE:C:0
1:/:rootPool/ROOT/s10u10:1
1:boot-device:/dev/dsk/c0t0d0s0:2
<output elided>
3. Get the list of shared datasets present on the system using the root pool dataset obtained from the previous step.
# zfs get mounted | grep -v rootPool/ROOT
NAME PROPERTY VALUE SOURCE
rootPool mounted yes -
rootPool/dump mounted - -
rootPool/export mounted yes -
rootPool/export/home mounted yes -
rootPool/swap mounted - -
zonePool mounted yes -
zonePool/test mounted no -
Note that all the datasets outside of the hierarchy of rootPool/ROOT are considered as shared file systems (eg: zonePool/test). The column VALUE above also shows whether these zfs(1M) datasets are currently mounted or not.
In the above example, the dataset zonePool/test would be erroneously deleted from the PBE as a result of running ludelete(1M) if it was unmounted after the creation of the boot environment (ABE1).
Note: Datasets whose mount status is either "yes" or "-" will not be deleted.
Symptoms
There are no warnings or errors issued when this erroneous deletion from the PBE occurs.
Workaround
To avoid this issue, before issuing the ludelete(1M) command, mount the shared datasets that are shared across boot environments. This needs to be done only if those shared datasets were mounted during the creation of the Alternate Boot Environment and were later unmounted. This is the only way to avoid the shared datasets from getting deleted. If the datasets are deleted, they cannot be retrieved.
This issue is addressed in the following releases:
SPARC Platform
•Solaris 10 with patch 121430-89 or later
x86 Platform
•Solaris 10 with patch 121431-90 or later
Patches
SUNPATCH:121430-89
SUNPATCH:121431-90
No comments:
Post a Comment