Skip site navigation (1)Skip section navigation (2)
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>