Date: Mon, 23 Jan 2012 11:24:39 -0700 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: Garrett Cooper <yanegomi@gmail.com> Cc: freebsd-hackers@freebsd.org, Devin Teske <devin.teske@fisglobal.com> Subject: Re: Parallels v4 regression (aka ada(4) oddity) in RELENG_9 Message-ID: <1327343079.69022.87.camel@revolution.hippie.lan> In-Reply-To: <CAGH67wRhT30j2Ask-9pQOQcTihFD5AsOdGXbwPTW6DbPrGc4zw@mail.gmail.com> References: <009501ccd9f9$cad088d0$60719a70$@fisglobal.com> <CAGH67wRhT30j2Ask-9pQOQcTihFD5AsOdGXbwPTW6DbPrGc4zw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2012-01-23 at 10:15 -0800, Garrett Cooper wrote: > On Mon, Jan 23, 2012 at 10:06 AM, Devin Teske <devin.teske@fisglobal.com> wrote: > > 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. > > The 'bug' is in gpart/geom and the 'issue' is present in prior > versions of FreeBSD. The backup partition is now more of a thorn in > everyone's side than previous versions. gpart delete'ing all the > partitions, then doing gpart destroy is probably what you want (there > isn't a simple one-liner that would do this). > Thanks, > -Garrett 'gpart destroy -F <geom>' should do it in one step. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1327343079.69022.87.camel>