Date: Fri, 28 May 2010 17:20:07 GMT From: Garrett Cooper <yanefbsd@gmail.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/141235: 8.0 no longer provides /dev entries for all disk slices [regression] Message-ID: <201005281720.o4SHK7GG026112@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/141235; it has been noted by GNATS. From: Garrett Cooper <yanefbsd@gmail.com> To: dieterbsd@engineer.com Cc: bug-followup@freebsd.org, jh@freebsd.org, freebsd@sopwith.solgatos.com, freebsd-bugs@freebsd.org Subject: Re: kern/141235: 8.0 no longer provides /dev entries for all disk slices [regression] Date: Fri, 28 May 2010 10:18:50 -0700 On Fri, May 28, 2010 at 10:07 AM, Garrett Cooper <yanefbsd@gmail.com> wrote= : > On Fri, May 28, 2010 at 8:53 AM, =A0<dieterbsd@engineer.com> wrote: >>> You should remove GEOM_PART_* entries. I think that the duplicates you >>> saw are because you had geom_part still enabled. >> >> I thought about that. =A0Having both GEOM_PART_MBR and GEOM_MBR >> seemed suspicious, but GEOM_PART_MBR isn't from the config file: >> >> grep -i geom GENERIC >> options =A0 =A0 =A0 =A0 GEOM_PART_GPT =A0 =A0 =A0 =A0 =A0 # GUID Partiti= on Tables. >> options =A0 =A0 =A0 =A0 GEOM_LABEL =A0 =A0 =A0 =A0 =A0 =A0 =A0# Provides= labelization >> >> and then I added GEOM_MBR and GEOM_BSD as suggested. =A0So I don't >> know where GEOM_PART_MBR comes from or how to get rid of it. >> I am assuming that "make buildkernel" calls config(8) and config >> builds opt_geom.h based on the config file, but it must have some >> other input that I haven't found. >> >> It isn't clear to me what the difference between GEOM_PART_MBR and >> GEOM_MBR is supposed to be (same for GEOM_PART_BSD and GEOM_BSD). >> conf/NOTES doesn't list a GEOM_GPT, only GEOM_PART_GPT. =A0I assume >> that removing GEOM_PART_GPT would break disks using GUID partition >> tables. > > GEOM_MBR is the legacy way to specify GEOM_PART_MBR IIRC (from .../UPDATI= NG): > > 20090320: > =A0 =A0 =A0 =A0GEOM_PART has become the default partition slicer for stor= age devices, > =A0 =A0 =A0 =A0replacing GEOM_MBR, GEOM_BSD, GEOM_PC98 and GEOM_GPT slice= rs. It > =A0 =A0 =A0 =A0introduces some changes: > > =A0 =A0 =A0 =A0MSDOS/EBR: the devices created from MSDOS extended partiti= on entries > =A0 =A0 =A0 =A0(EBR) can be named differently than with GEOM_MBR and are = now symlinks > =A0 =A0 =A0 =A0to devices with offset-based names. fstabs may need to be = modified. > > =A0 =A0 =A0 =A0BSD: the "geometry does not match label" warning is harmle= ss in most > =A0 =A0 =A0 =A0cases but it points to problems in file system misalignmen= t with > =A0 =A0 =A0 =A0disk geometry. The "c" partition is now implicit, covers t= he whole > =A0 =A0 =A0 =A0top-level drive and cannot be (mis)used by users. > > =A0 =A0 =A0 =A0General: Kernel dumps are now not allowed to be written to= devices > =A0 =A0 =A0 =A0whose partition types indicate they are meant to be used f= or file > =A0 =A0 =A0 =A0systems (or, in case of MSDOS partitions, as something els= e than > =A0 =A0 =A0 =A0the "386BSD" type). > > =A0 =A0 =A0 =A0Most of these changes date approximately from 200812. I did a bit more digging and what I discovered wasn't entirely true in my first statement; yes, GEOM_MBR is the legacy system from first glance compared to GEOM_PART_MBR, but that doesn't tell the entire story. The two items (GEOM_PART_MBR and GEOM_MBR) also grossly differ with one another. I'm going to take a look at the code in the meantime and try to better digest what's going on (because it would help with work), but just for future reference the files that get used [up through 9-CURRENT] are located at: /sys/geom/geom_mbr.c /sys/geom/part/g_part_mbr.c You can of course determine this info from /sys/conf/files. HTH, -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201005281720.o4SHK7GG026112>