Date: Mon, 23 Jan 2012 10:32:59 -0800 From: Garrett Cooper <yanegomi@gmail.com> To: Ian Lepore <freebsd@damnhippie.dyndns.org> 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: <CAGH67wSEbWkLg_kPPhx3x6KKXrr7LZKdTD7CPp2WP4XGpPpLBg@mail.gmail.com> In-Reply-To: <1327343079.69022.87.camel@revolution.hippie.lan> References: <009501ccd9f9$cad088d0$60719a70$@fisglobal.com> <CAGH67wRhT30j2Ask-9pQOQcTihFD5AsOdGXbwPTW6DbPrGc4zw@mail.gmail.com> <1327343079.69022.87.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 23, 2012 at 10:24 AM, Ian Lepore
<freebsd@damnhippie.dyndns.org> wrote:
> 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 jus=
t
>> > swimmingly.
>> >
>> > However, in RELENG_9 I notice something different. My once "ad0" is no=
w showing
>> > up as "ada0". However, something even stranger is that devfs is provid=
ing both
>> > ad0 family devices AND ada0 family devices.
>> >
>> > What's worse is that I can't seem to partition the disk with MBR+diskl=
abel
>> > 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 ada0=
p3
>> > 6. Wipe partition table by executing: dd if=3D/dev/zero of=3D/dev/ada0=
bs=3D512k
>> > count=3D256
>> > 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.
>>
>> =A0 =A0 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).
>
> 'gpart destroy -F <geom>' should do it in one step.
It's better to be methodical and delete all of the partitions and
create the table from scratch. I've run into reproducible cases in the
past where just doing gpart destroy -F for instance [on 9.0-BETA1+
media] didn't work because geom retasted the partition tables and
slices.
Thanks,
-Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGH67wSEbWkLg_kPPhx3x6KKXrr7LZKdTD7CPp2WP4XGpPpLBg>