From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 23 18:07:02 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90AD81065677 for ; Mon, 23 Jan 2012 18:07:02 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 522A08FC23 for ; Mon, 23 Jan 2012 18:07:01 +0000 (UTC) Received: from pps.filterd (ltcfislmsgpa06 [127.0.0.1]) by ltcfislmsgpa06.fnfis.com (8.14.4/8.14.4) with SMTP id q0NHSJeo019620 for ; Mon, 23 Jan 2012 12:07:01 -0600 Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa06.fnfis.com with ESMTP id 12hbkf0agg-14 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 23 Jan 2012 12:07:01 -0600 Received: from dtwin (10.14.152.15) by smtp.fisglobal.com (10.132.206.17) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Jan 2012 12:06:51 -0600 From: Devin Teske To: Date: Mon, 23 Jan 2012 10:06:49 -0800 Message-ID: <009501ccd9f9$cad088d0$60719a70$@fisglobal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AczZ9/5+wWQNMkPcRASncZTp61Im5Q== Content-Language: en-us X-Originating-IP: [10.14.152.15] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7361, 1.0.211, 0.0.0000 definitions=2012-01-23_03:2012-01-22, 2012-01-23, 1970-01-01 signatures=0 Subject: Parallels v4 regression (aka ada(4) oddity) in RELENG_9 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 18:07:02 -0000 I have a Parallels virtual machine and it runs FreeBSD 4 through 8 just swimmingly. However, in RELENG_9 I notice something different. My once "ad0" is now showing up as "ada0". However, something even stranger is that devfs is providing both ad0 family devices AND ada0 family devices. What's worse is that I can't seem to partition the disk with MBR+disklabel scheme. My procedure goes something like this: 1. Boot from RELENG_9 LiveCD 2. Execute: sysctl -n kern.disks 3. Notice two items: cd0 ada0 4. Look in /dev 5. Notice several items: ad0 ad0p1 ad0p2 ad0p3 ada0 ada0p1 ada0p2 ada0p3 6. Wipe partition table by executing: dd if=/dev/zero of=/dev/ada0 bs=512k count=256 7. Look in /dev 8. Notice less items now: ad0 ada0 9. Execute: sysctl -n kern.disks 10. Notice nothing changed: cd0 ada0 11. Write out standard "whole disk" MBR "slice" 12. Look in /dev 13. Notice that nothing changed: ad0 ada0 NOTE: Where is ad0s1 or ada0s1? 14. Use fdisk to make sure everything was written successfully 15. Notice everything looks good (slice 1 is of type FreeBSD, slice 2, 3, and 4 are unused) 16. Reboot 17. Boot back into RELENG_9 LiveCD 18. Look in /dev 19. Notice that the old devices are back!: ad0 ad0p1 ad0p2 ad0p3 ada0 ada0p1 ada0p2 ada0p3 20. Use fstab to look at MBR partition table 21. Notice that things look good (with respect to fdisk'ing): slice 1 is FreeBSD, 2, 3, and 4 are still unused 22. Notice /dev still doesn't have ad0s1 or ada0s1 23. Use gpart to look at ada0 24. Notice "GPT [CORRUPT]" ... OK!?!? ... Use same exact RELENG_9 LiveCD on either a physical machine or VMware Virtual machine. SUCCESS!! Go back to Parallels 4 FAILURE!! Go back to RELENG_8 LiveCD with Parallels 4 SUCCESS!! What's going on here? I think ada(4) is my problem. Can someone please provide feedback? Willing to dig further and provide any/all feedback to help fix this regression. -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.