https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232463
Andrey V. Elsukov changed:
What|Removed |Added
Assignee|b...@freebsd.org|g...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232463
--- Comment #12 from bourne.ident...@hotmail.com
---
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.
--
You are receiving this mai
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232463
--- Comment #5 from Andrey V. Elsukov ---
(In reply to bourne.ident...@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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232463
--- Comment #6 from bourne.ident...@hotmail.com
---
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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232463
--- Comment #11 from bourne.ident...@hotmail.com
---
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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232463
--- Comment #10 from bourne.ident...@hotmail.com
---
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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232463
--- Comment #9 from Andrey V. Elsukov ---
(In reply to bourne.ident...@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 switc
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232463
--- Comment #8 from bourne.ident...@hotmail.com
---
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 pre
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232463
--- Comment #7 from Andrey V. Elsukov ---
(In reply to bourne.ident...@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 E
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232463
--- Comment #4 from bourne.ident...@hotmail.com
---
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 c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232463
--- Comment #3 from Andrey V. Elsukov ---
(In reply to bourne.ident...@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 forc
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232463
--- Comment #2 from bourne.ident...@hotmail.com
---
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 smal
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232463
Andrey V. Elsukov changed:
What|Removed |Added
CC||a...@freebsd.org
--- Comment #
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232463
Bug ID: 232463
Summary: EBR slice cannot be added partitions to
Product: Base System
Version: 10.4-RELEASE
Hardware: Any
OS: Any
Status: New
Severit
14 matches
Mail list logo
