I have to add some details:
0.
I ludelete-d nv91
# lustatus
Boot Environment Is Active Active Can Copy Name
Complete Now On Reboot Delete Status
-------------------------- -------- ------ --------- ------ ----------
nv81 yes yes yes no - #
Gone.
Gone?
1. After booting to failsafe, the described proposal to upgrade an out of sync
boot archive on /dev/dsk/c2d0s4 came up again, I rejected the proposal. A shell
came up, I entered 'format', and now two (!?) BEs were on offer:
1 /dev/dsk/c2d0s0 ... snv_81
2 /dev/dsk/c2d0s4 ... snv_91
Makes me wonder how successful the ludelete was!?
And I also got further with the strange allocation of disks:
'format' in failsafe offered
c0t0d0: the USB-drive with 3 ext3-partitions only
c2d0: the SATA drive
In nv81 both show as
AVAILABLE DISK SELECTIONS:
0. c1d0 <DEFAULT cyl 9725 alt 2 hd 255 sec 63>
/pci at 0,0/pci-ide at 9/ide at 0/cmdk at 0,0
1. c2t0d0 <Maxtor-OneTouch-0200 cyl 38911 alt 2 hd 255 sec 63>
/pci at 0,0/pci1565,3409 at 2,1/storage at 2/disk at 0,0
though. Yes, they are just swapped.
Next, I followed skg's advice to turn off the USB-drive. Reboot, and now the
out of sync boot archive is on /dev/dsk/c1d0s4! And the 2 boot archives are
still there, now on c1d0:
1 /dev/dsk/c1d0s0 ... snv_81
2 /dev/dsk/c1d0s4 ... snv_91
To me, personally, this is quite a mess. How can a SATA controller make it to
c0, c1 or c2 just according to the liking of the system (reproduceable, though)?
Should we not expect some consistency here?
(I personally expect c0 to be the single IDE-controller, c1 to identify the
SATA-controller, and c2 to be the USB-controller, for example)
And should we not expect a ludelete to delete a boot environment?
Uwe
This message posted from opensolaris.org
