Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL (recap)

Hi to all;

Recently I've upgraded my home box from FreeBSD 7.2-stable i386 to 8-CURRENT 
amd64 (specifically 200906 snapshot)because of a major CPU-BOARD-MEMORY 
(Phenon 955-AOD790GX/128M-8G RAM)overhaul. 7.2 stable amd64 wouldn't install 
on it (/dev/cd0 disapeared right after sysinstall screen, so no CD/DVD to 
install from. Same with all attempts with any previous amd64 revision). So I 
figured, what the heck, lets do it! 8-CURRENT intalled fine.

My box is pretty full of stuff. A lot of the files I have here have been 
migrating from version to version of all these OSses along the years, without 
any problem. Please, just try to bear with the fact that I do need to have all 
this, leaving the "why" out of scope and knowing that I DO have backups for 
almost all of it.

I use this box from pro audio productions (winedows) to devel (winedows 
(VBox),BSD, & linux (Vbox), to network environment emulation (Vbox), and in-
betweens. 

2 500G SATA drives and 1 20G ide for XP64 "fun". 

On those sata drives I have: 

SATA1:1 primary FAT32 part, 
      1 primary BSD /
      1 EXT -> 3 FAT32, 1 NTFS
      1 primary ext2fs
SATA2:1 primary BSD (5 slices /usr, /apps, /var, /tmp and swap)
      1 EXT -> 3 FAT32, 1 NTFS  

By now you should have a clue as to why I brought this subject back.

On the first boot, first question: Where were those nice GEOM devices that so 
nicely showed up and held ALL of the above on my previous 7.2-STABLE?  

At first, I found out that sysinstall (label or fdisk, I don't know) did 
something to my part table that made everything disappear. I went to the IDE 
drive and restored everything with testdisk (nice program !).

booted BSD. result:
2 GEOM label mismatch errors (1 for /, 1 for the other SATA2 BSD part)
only 2 FAT32 and 1 NTFS from SATA1
only 1 FAT32 SATA2

Well, back and forth from my XP64 part, googling started (no X yet on 8).

I tried to manually mount the devices that didn't show up on 
/dev/msdosfs,ntsf,ext2fs. Errors. Tried by taking GEOM_PART out of the picture 
and kernel recompile. Didn't even boot. Livecd and loaded geom_part as 
modules. Booted back but still no EXT parts.

After a good while, I picked up this subject, which gave me a clue to what to 
do: 
1)I tried to put "options GEOM_MBR, _BSD & _LABEL" into the kernel. It 
wouldn't config.

2)I noticed that the modules geom_mbr,geom_bsd and geom_label were present in 
/boot, so I kept the GEOMles kernel and loaded those from loader.conf. crossed 
my fingers and rebooted.

BANG !! I could not believe my eyes ! EVERY SINGLE PARTITION showed up on my 
face, as neatly arranged devices, asking "what are you waiting for?"

This is just a rough outline of many days of pain and agony.

Right now, I am typing this e-mail from a fully functional 8-CURRENT/X/KDE 
4.3.1 desktop (yes, BSD IS my desktop), accessing ALL my drives, thanks to 
good old GEOM_XXX.

On one of the subject's thread, I quote Marcel Moolenaar:

>> 1. What's getting removed and why? 
> GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL They're so yesterday. 
>> 2. What's it being replaced with? 
> GEOM_PART_BSD, GEOM_PART_MBR, GEOM_PART_PC98 and GEOM_PART_VTOC8 
>> 3. How do I migrate from the old system to the new one? 
> No migration is needed. You already use the new kernel options. All I'm 
> doing is remove the old not-to-be-used options. FYI, -- Marcel Moolenaar"

Well, # 3 DIDN'T work for me, no matter how hard I tried. GEOM_PART did not 
"understand" what I had, while GEOM_ did, on the first attempt !

Then I quote John Baldwin, a few e-mails ahead on the thread:

"I think it is less painful for folks upgrading from 7 to just use the old 
names. It is also a lot easier on the eyes. I'm also not sure people are going 
to be changing their partition layout once it is done so having the names 
'change' would not seem to be something that would happen very often at all in 
practice. -- John Baldwin"

This is my EXACT experience with GEOM, so this e-mail is and absolute plea to 
the developers:

Please don't take GEOM_XXX away. Folks on the same situation as mine won't be 
able to work if, after one fine csup src and make buildworld/kernel day, those 
geom_xxx.kos are not there !.

A put myself and my box at your disposal in trying to find out what went 
wrong. Meanwhile, please keep them in the source tree.

My apologies for such a long e-mail, but believe me, I made it as short as I 
could.

Best regards to all,
-- 
Mario Lobo
http://www.mallavoodoo.com.br
FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!] (99,7% winedows FREE)