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

On 9/27/09, Mario Lobo <mlobo_at_digiart.art.br> wrote:
> 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.

geom_part* is going to be only partitioning interface in future.
So you should really forget about geom_bsd and geom_mbr and try all geom_part*
modules or if that do not work recreate partitioning table with gpart(8)

Older modules are just buggy and provide no additional features.

-- 
Paul