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> /[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],0 1. c2t0d0 <Maxtor-OneTouch-0200 cyl 38911 alt 2 hd 255 sec 63> /[EMAIL PROTECTED],0/pci1565,[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],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 _______________________________________________ opensolaris-help mailing list opensolaris-help@opensolaris.org