I have been using FreeBSD for 20 years. There is one problem in the base system that simply does not go away : when I create an EBR slice with gpart and put the header on it as such (gpart create -s EBR <dev_node>), things work. But the moment I try creating partitions within the EBR slice created as above, I start getting failure : Operation cancelled; Pre-check failed. Can somebody please make sure FreeBSD's EBR implementation works smoothly ? The BSD nesting schema will be of much less significance in the coming days compared to the EBR schema.
To be able modify EBR you need to remove GEOM_PART_EBR_COMPAT option from your kernel.
Hi Andrey, Thanks, but that is quite surprising. Why cannot the default kernel have EBR compatibility switched on, rather than forcing the user recompile the whole kernel for such a small thing ? People do not want to recompile kernels unless there is a significant cause. As it happens, I am writing a book about FreeBSD/Linux/Cygwin. And whereever the book needs EBR work, I have to document it as MBR (gpart create -s MBR). This is really not desired for me, or for any of my readers. Tx MJ
(In reply to bourne.identity@hotmail.com from comment #2) > Hi Andrey, > > Thanks, but that is quite surprising. Why cannot the default kernel have EBR > compatibility switched on, rather than forcing the user recompile the whole > kernel for such a small thing ? People do not want to recompile kernels > unless there is a significant cause. > > As it happens, I am writing a book about FreeBSD/Linux/Cygwin. And whereever > the book needs EBR work, I have to document it as MBR (gpart create -s MBR). > This is really not desired for me, or for any of my readers. This is because without EBR_COMPAT option, EBR partition naming/numbering will be not compatible with old installations.
Hi Andrey, Can I please request EBR_COMPAT to be switched on in future releases shipped by FreeBSD ? It is a real problem that EBR works well under Linux / Windows, and FreeBSD totally craps out needing hacks and kernel recompile. FreeBSD should be compatible with the current environment, not with some legacy installation that has to be respected till kingdom come. Tx MJ
(In reply to bourne.identity@hotmail.com from comment #4) > Hi Andrey, > > Can I please request EBR_COMPAT to be switched on in future releases shipped > by FreeBSD ? It is a real problem that EBR works well under Linux / Windows, > and FreeBSD totally craps out needing hacks and kernel recompile. > FreeBSD should be compatible with the current environment, not with some > legacy installation that has to be respected till kingdom come. EBR works well under FreeBSD. You just can't modify it without kernel recompilation. It is legacy partitioning scheme and I don't think the ability to modify is really needed feature for FreeBSD. GPT has more features and well supported in all systems, and it supports large disks and many partitions out of the box.
a) What do you mean 'works well under FreeBSD' when you cannot add/delete any partitions in the EBR slice ? b) Suggesting GPT because EBR is non-functional under FreeBSD adds an unwanted twist. GPT is not what people need. People usually need MBR (particularly under FreeBSD), which provides multiple benefits: 1) GPT has no limit on number of partitions, and a GPT disk is permitted to be a jungle. The MBR schema on the other hand is 3 primary partitions (each of which can host OS root) + a sub-divisible EBR (which cannot host OS root). 2) MBR permits use of boot0cfg, the tidiest boot manager. Unless a disk really is > 2TB, GPT must not be used.
(In reply to bourne.identity@hotmail.com from comment #6) > a) > What do you mean 'works well under FreeBSD' when you cannot add/delete any > partitions in the EBR slice ? I mean that it can read EBR scheme and use such partitions. And since there is no need in such partitions, by default FreeBSD doesn't support modification of them. FreeBSD supports BSD label and GPT, and can live well without EBR. > b) > Suggesting GPT because EBR is non-functional under FreeBSD adds an unwanted > twist. GPT is not what people need. People usually need MBR (particularly > under FreeBSD), which provides multiple benefits: I have several hundreds of FreeBSD installations and none of them use MBR/EBR. And all works good for me. So, at least I'm and several other people in my company usually don't need MBR. > > 1) GPT has no limit on number of partitions, and a GPT disk is permitted to > be a jungle. The MBR schema on the other hand is 3 primary partitions (each > of which can host OS root) + a sub-divisible EBR (which cannot host OS root). > > 2) MBR permits use of boot0cfg, the tidiest boot manager. > > Unless a disk really is > 2TB, GPT must not be used.
It surprises me that we can have a long conversation and let EBR remain non-functional, when all it needs to fix is for someone to switch on EBR_COMPAT when a FreeBSD release is being prepared. Does anyone lose anything if EBR_COMPAT is switched on by default ? If you use GPT, it does not mean you have to force others to use GPT too.
(In reply to bourne.identity@hotmail.com from comment #8) > It surprises me that we can have a long conversation and let EBR remain > non-functional, when all it needs to fix is for someone to switch on > EBR_COMPAT when a FreeBSD release is being prepared. > > Does anyone lose anything if EBR_COMPAT is switched on by default ? > > If you use GPT, it does not mean you have to force others to use GPT too. EBR_COMPAT is enabled by default, and it is why you don't have the feature that you need. If you remove this option from the DEFAULT kernel config, this can break existing installation. This is FreeBSD POLA violation and this is why this option is still enabled by default. I didn't force you to use GPT, you can just use what you want, but you need to recompile your kernel. And you also can not force the change this options, because it will break system for other people.
Sorry for my misinterpretation. What I meant was since EBR_COMPAT being on by default is such a pain, and switching it off does not cause any worldly harm to users, why cannot it simply be switched off ?
It might even be considered to create a sysctl for EBR_COMPAT. What we do not want is people being forced to recompile the kernel for such a small thing.
Thanks Andrey
*** Bug 242954 has been marked as a duplicate of this bug. ***
I have some WIP in this area. I've taken the more ambitious aim of providing both behaviors, but if that does not work out, it would be quite trivial to make the compatibility knob a boottime tunable rather than a compile knob. (I agree that the compile knob is ugly compared to at least a tunable.)
(Note that the COMPAT behavior dates to at least 2012.)
# sysctl kern.features.geom_part_ebr_compat kern.geom.part.ebr.compat_aliases kern.features.geom_part_ebr_compat: 1 kern.geom.part.ebr.compat_aliases: 1 # mdconfig -a -t swap -s 200 md0 # gpart create -s mbr md0 md0 created # gpart add -t ebr -i 4 md0 md0s4 added # gpart create -s ebr md0s4 md0s4 created # gpart add -t freebsd md0s4 md0s4+00000001 added # ls -l /dev/md0s* crw-r----- 1 root operator 0, 59 May 21 21:39 /dev/md0s4 crw-r----- 1 root operator 0, 60 May 21 21:42 /dev/md0s4+00000001 lrwxr-xr-x 1 root wheel 14 May 21 21:42 /dev/md0s5 -> md0s4+00000001
https://reviews.freebsd.org/D24938 https://reviews.freebsd.org/D24939
Hi Conrad/others, I welcome the idea of a sysctl tunable for EBR, but I think there is a problem with this approach. I might be wrong but if you are going in for a runtime solution, there would be no way to manipulate the EBR slice from within the FreeBSD installer - which would be undesirable. I look forward to your comments on my concern, and thanks for taking up this issue - it is a much needed fix in FreeBSD. Regards, Manish Jain
(In reply to bourne.identity@hotmail.com from comment #19) Hi, Can you elaborate on the concern around manipulating the EBR slice from the installer? The patchset allows manipulating EBR partitions; the installer could create/manipulate them. I don't know what it does in particular, though. (Does it have hardcoded knowledge of MBR/GPT, or does it have some generic interface to gpart(8)?)
Hi Conrad, Usually a sysctl tunable works by the way of the user first installing FreeBSD, then setting the sysctl in the installed system to get the desired behaviour. Am I wrong about that ? If I am right, then how can the user add/delete partitions in the EBR slice at the time of installation itself ? If add/delete EBR partitions is possible at the time of installation, then I think we have the perfect solution. Kindly do let me know if and how the EBR slice can be manipulated during FreeBSD installation. Thanks, Manish Jain
(In reply to bourne.identity@hotmail.com from comment #21) You understand tunables fine. > If I am right, then how can the user add/delete partitions in the EBR slice > at the time of installation itself ? The tunable does not impact whether EBR slices can be added/deleted at all. It only impacts whether the compatibility names (ada0s5 -> ada0s4+000nnn) are created. Also, the default for the tunable is "enabled" — so the installer has the compatible names. I think it will be possible to create EBR partitions at install time. I don't know how specific the installer's knowledge of MBR/GPT is. If the installer is a pretty generic geom_part wrapper, it should just work. If it is tied to MBR/GPT specifically, it may need additional work. But the kernel support for EBR editing would be enabled by these changes. Cheers
Thanks so much. I will have a drink to that : - ) One more question : (Unlikely but) Will 11.4-RELEASE have the EBR fix ?
(In reply to bourne.identity@hotmail.com from comment #23) It will not be fixed in 11.4, as far as I know.
A commit references this bug: Author: cem Date: Wed Jul 1 02:16:38 UTC 2020 New revision: 362823 URL: https://svnweb.freebsd.org/changeset/base/362823 Log: geom(4): Kill GEOM_PART_EBR_COMPAT option Take advantage of Warner's nice new real GEOM aliasing system and use it for aliased partition names that actually work. Our canonical EBR partition name is the weird, not-default-on-x86-prior-to- this-revision "da1p4+00001234." However, if compatibility mode (tunable kern.geom.part.ebr.compat_aliases) is enabled (1, default), we continue to provide the alias names like "da1p5" in addition to the weird canonical names. Naming partition providers was just one aspect of the COMPAT knob; in addition it limited mutability, in part because it did not preserve existing EBR header content aside from that of LBA 0. This change saves the EBR header for LBA 0, as well as for every EBR partition encountered. That way, when we write out the EBR partition table on modification, we can restore any bootloader or other metadata in both LBA0 (the first data-containing EBR may start after 0) as well as every logical EBR we read from the disk, and only update the geometry metadata and linked list pointers that describe the actual partitioning. (This change does not add support for the 'bootcode' verb to EBR.) PR: 232463 Reported by: Manish Jain <bourne.identity AT hotmail.com> Discussed with: ae (no objection) Relnotes: maybe Differential Revision: https://reviews.freebsd.org/D24939 Changes: head/sys/amd64/conf/DEFAULTS head/sys/conf/NOTES head/sys/conf/options head/sys/geom/part/g_part_ebr.c head/sys/i386/conf/DEFAULTS
Thanks Conrad, for your dedicated work on this issue.
No problem!