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

[John Baldwin]

On Wednesday 14 April 2010 2:04:47 pm Brian A. Seklecki wrote:
> 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.

This is due to the GPART changes in that it is less forgiving about certain 
partition layouts.  You can try bugging marcel at .  FWIW, just doing 'dd 
if=/dev/zero of=/dev/amrd0 count=100' or so should have been enough to wipe 
the partition tables that were confusing sysinstall.

-- 
John Baldwin