From owner-freebsd-hardware@FreeBSD.ORG Wed Apr 14 18:04:49 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D6CF1065689 for ; Wed, 14 Apr 2010 18:04:49 +0000 (UTC) (envelope-from lavalamp@spiritual-machines.org) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id 1A1B88FC1A for ; Wed, 14 Apr 2010 18:04:48 +0000 (UTC) Received: from [127.0.0.1] ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Wed, 14 Apr 2010 14:15:25 -0400 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::361 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-hardware@freebsd.org X-SMFBL: ZnJlZWJzZC1oYXJkd2FyZUBmcmVlYnNkLm9yZw== Message-ID: <4BC603BF.4070705@spiritual-machines.org> Date: Wed, 14 Apr 2010 14:04:47 -0400 From: "Brian A. Seklecki" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-hardware@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sean McAfee , spolyack@gmail.com Subject: sysinstall butchers amr(4) partitions RELENG_6.3 -> 8.0-R binary upgrade X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 18:04:49 -0000 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