Bug 232463 - EBR slice cannot be added partitions to
Summary: EBR slice cannot be added partitions to
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: Conrad Meyer
URL:
Keywords:
: 242954 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-10-19 22:38 UTC by bourne.identity@hotmail.com
Modified: 2020-07-01 14:48 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bourne.identity@hotmail.com 2018-10-19 22:38:10 UTC
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.
Comment 1 Andrey V. Elsukov freebsd_committer 2018-10-20 06:43:34 UTC
To be able modify EBR you need to remove GEOM_PART_EBR_COMPAT option from your kernel.
Comment 2 bourne.identity@hotmail.com 2018-10-20 10:01:46 UTC
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
Comment 3 Andrey V. Elsukov freebsd_committer 2018-10-20 10:49:51 UTC
(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.
Comment 4 bourne.identity@hotmail.com 2018-10-20 11:02:59 UTC
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
Comment 5 Andrey V. Elsukov freebsd_committer 2018-10-20 11:11:35 UTC
(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.
Comment 6 bourne.identity@hotmail.com 2018-10-20 11:24:03 UTC
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.
Comment 7 Andrey V. Elsukov freebsd_committer 2018-10-20 11:39:47 UTC
(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.
Comment 8 bourne.identity@hotmail.com 2018-10-20 11:45:10 UTC
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.
Comment 9 Andrey V. Elsukov freebsd_committer 2018-10-20 11:50:47 UTC
(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.
Comment 10 bourne.identity@hotmail.com 2018-10-20 11:55:02 UTC
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 ?
Comment 11 bourne.identity@hotmail.com 2018-10-20 11:55:57 UTC
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 ?
Comment 12 bourne.identity@hotmail.com 2018-10-20 12:00:30 UTC
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.
Comment 13 bourne.identity@hotmail.com 2018-10-20 14:38:59 UTC
Thanks Andrey
Comment 14 Conrad Meyer freebsd_committer 2019-12-31 02:22:53 UTC
*** Bug 242954 has been marked as a duplicate of this bug. ***
Comment 15 Conrad Meyer freebsd_committer 2020-05-21 13:51:25 UTC
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.)
Comment 16 Conrad Meyer freebsd_committer 2020-05-21 13:52:19 UTC
(Note that the COMPAT behavior dates to at least 2012.)
Comment 17 Conrad Meyer freebsd_committer 2020-05-22 04:46:49 UTC
# 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
Comment 19 bourne.identity@hotmail.com 2020-05-22 09:28:59 UTC
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
Comment 20 Conrad Meyer freebsd_committer 2020-05-22 15:19:49 UTC
(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)?)
Comment 21 bourne.identity@hotmail.com 2020-05-22 17:58:22 UTC
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
Comment 22 Conrad Meyer freebsd_committer 2020-05-22 18:15:37 UTC
(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
Comment 23 bourne.identity@hotmail.com 2020-05-23 05:49:51 UTC
Thanks so much. I will have a drink to that  : - )

One more question : (Unlikely but) Will 11.4-RELEASE have the EBR fix ?
Comment 24 Conrad Meyer freebsd_committer 2020-05-23 05:57:02 UTC
(In reply to bourne.identity@hotmail.com from comment #23)
It will not be fixed in 11.4, as far as I know.
Comment 25 commit-hook freebsd_committer 2020-07-01 02:16:42 UTC
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
Comment 26 bourne.identity@hotmail.com 2020-07-01 12:28:04 UTC
Thanks Conrad, for your dedicated work on this issue.
Comment 27 Conrad Meyer freebsd_committer 2020-07-01 14:48:39 UTC
No problem!