Description
Solaris 10 Live Upgrade patches 121430-66 through 121430-71 (SPARC) and 121431-67 through 121431-72 (x86) may cause ludelete(1M) to erroneously delete unmounted non-OS zfs(1M) datasets from the Primary Boot Environment(PBE). The lost data from those datasets cannot be retrieved later.
This erroneous deletion only occurs if an Alternate Boot Environment (ABE1) is successfully created with shared datasets followed by the unmounting of shared datasets.
Occurrence
This issue can occur in the following releases:
SPARC Platform
•Solaris 10 with patch 121430-66 through 121430-71 and without patch 121430-72
x86 Platform
•Solaris 10 with patch 121431-67 through 121431-72 and without patch 121431-73
Notes:
1. Solaris 8, Solaris 9 and Solaris 11 are not impacted by this issue.
2. Solaris 10 UFS root file systems with user created UFS file systems are not affected by this issue.
3. This issue only affects systems with non-OS zfs(1M) 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 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
...
...
3. Get the list of non-OS shared zfs(1M) 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 non-OS 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 non-OS zfs (1M) 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 can not be retrieved.
This issue is addressed in the following releases:
SPARC Platform
•Solaris 10 with patch 121430-72 or later
x86 Platform
•Solaris 10 with patch 121431-73 or later
Solaris 10 Live Upgrade patches 121430-66 through 121430-71 (SPARC) and 121431-67 through 121431-72 (x86) may cause ludelete(1M) to erroneously delete unmounted non-OS zfs(1M) datasets from the Primary Boot Environment(PBE). The lost data from those datasets cannot be retrieved later.
This erroneous deletion only occurs if an Alternate Boot Environment (ABE1) is successfully created with shared datasets followed by the unmounting of shared datasets.
Occurrence
This issue can occur in the following releases:
SPARC Platform
•Solaris 10 with patch 121430-66 through 121430-71 and without patch 121430-72
x86 Platform
•Solaris 10 with patch 121431-67 through 121431-72 and without patch 121431-73
Notes:
1. Solaris 8, Solaris 9 and Solaris 11 are not impacted by this issue.
2. Solaris 10 UFS root file systems with user created UFS file systems are not affected by this issue.
3. This issue only affects systems with non-OS zfs(1M) 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 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
...
...
3. Get the list of non-OS shared zfs(1M) 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 non-OS 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 non-OS zfs (1M) 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 can not be retrieved.
This issue is addressed in the following releases:
SPARC Platform
•Solaris 10 with patch 121430-72 or later
x86 Platform
•Solaris 10 with patch 121431-73 or later
No comments:
Post a Comment