Apparent regression in extended/logical partition handling

[Doug Barton]

Howdy,

Summary:
FreeBSD 9-current can't "see" logical drives inside an extended 
partition unless all space is assigned to a logical volume, and all 
logical volumes are formatted with a file system. 7.3-RELEASE does not 
have this problem.

Background:
So I got a new HD, and wanted to put Windows, a fat 32 data partition, 2 
FreeBSDs, and Linux on it. After much juggling, cursing, etc. I finally 
hit upon a solution. Windows and FreeBSDs in primary partitions, and 
fat32-data and Linux in an extended partition. Voila!

My first pass at this configuration had the 3 primary partitions first, 
but the linux (ubuntu gnome to be specific) "Disk Utility" tool was 
showing all the freebsd-style partitions (ad[12]s[a-f]) as linux-style 
partitions (sdaN) under the extended dos-style partition, which not only 
looked odd, but other tools on the linux desktop (such as Nautilus) were 
confused by this. So I looked on line and found a how-to that said this 
is caused by having the extended partition last, and the confusion can 
be avoided if I put the extended partition 2nd, and the 2 FreeBSD 
partitions after it. So I did that, and unfortunately it did not help 
Nautilus be any less confused. However, it did lead to what I think is a 
regression in -current.

Specifically what I did was to boot Windows XP, delete all the 
partitions other than the XP partition (first primary dos-style 
partition) and then create a dos-style extended partition, and a logical 
drive inside of it, leaving room for linux in that same extended 
partition. Since I want that data volume to be fat32, and it is too 
large for windows to do it, I next installed FreeBSD 9-current, in a 
dos-style primary partition. I got it installed fine, but when I booted 
into FreeBSD 9 to format the logical volume it could not see it. fdisk 
showed the right information about the extended partition, but in /dev 
instead of seeing no ad0s2 and seeing ad0s5 like I expected instead 
there was no ad0s5 and there were ad0s2 entries that mirrored the ad0s3 
that FreeBSD 9 was installed on. IOW, I had ad0s3 and ad0s3[a-f] as 
expected, but I had the same for ad0s2 even though they were obviously 
not valid.

"Well that's odd" I thought, but undaunted I proceeded to install 
FreeBSD 7.3-RELEASE in the last dos-style primary partition. When I 
booted it I could see the expected set of entries in /dev, and was 
finally able to newfs the fat32 volume. After confirming that Windows 
can see the fat32 volume I proceeded to boot FreeBSD 9 again. Still no 
joy. So then I proceeded with the Linux install (using up the last of 
the space inside the extended partition) and now FreeBSD 9 has the 
expected entries in /dev, and I can mount the fat32 volume. Haven't 
tried mounting the Linux volumes yet, although the right number of 
entries are there in /dev. So this appears to be an actual bug/regression.

FYI, after getting everything installed and working I did not nuke it 
all again to see if moving the extended partition last fixed the issue 
for FreeBSD 9, but I sort of vaguely recall that when I did the install 
the first time (with extended at the end) I couldn't see it in FreeBSD 9 
either; but didn't dwell on it.

One side note, I was taught "back in the day" that dos-style extended 
partitions always had to be at the end of the disk. Before trying the 
configuration I have I searched quite a few places to find a reference 
to that rule and couldn't find one. Perhaps this is something that's 
actually improved in the PC world in the last 25 years? :)


Doug

-- 

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/

	Computers are useless. They can only give you answers.
			-- Pablo Picasso