All:
We have a large number of non-dangerously-dedicated disks that,
given previous discussion, should be easily updated from 6.3->8.
These are 8th gen Dell PE18/2850 systems with MFI/LSI amr(4):
PERC4
Once loaded, sysinstall sees zero partitions in the
curses-based partition editor.
At the emergency shell, /dev/amrd0, /dev/amrd0a -> /dev/amrd0g are
visible.
In the 6.3 OS installed, these are all mapped as /dev/amrd0s1{a->g}
So perhaps amrd(4) volumes don't follow the rules. What makes
this breakage truly exciting
If you create a new set of partitions sysinstall, then
slice them, and commit, the newfs/fdisk step fails
and creates:
/dev/amrd0as1, /dev/armd0as1a -> /dev/armd0as1g
Then it creates:
/dev/amrd0cs1, /dev/armd0cs1a -> /dev/armd0cs1g
Finally it creates:
/dev/amrd0s1, /dev/armd0s1a -> /dev/armd0s1g
None of which are usable.
You can see the result of booting a FixIt image after a failed
sysinstall process:
http://digitalfreaks.org/~lavalamp/fbsd8_amr_sysinstall_butchered_partitions.jpg
So that means its time to DBAN the volume for 30 seconds
and/or re-init the RAID volume in the BIOS menu to nuke the
partition table, hence a force reformat during upgrade.
We wouldn't mind that if we were forcing everyone to use
GPT and ZFS as defaults, but since FreeBSD 8 really changes
nothing substantial this seems broken.
DBAN+++
~BAS
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[email protected]"
