sysinstall butchers amr(4) partitions RELENG_6.3 -> 8.0-R binary upgrade

[Brian A. Seklecki]

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