From owner-freebsd-bugs@freebsd.org Sun Dec 29 10:52:45 2019 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 367F01DB241 for ; Sun, 29 Dec 2019 10:52:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 47ly7x0mmBz4MPq for ; Sun, 29 Dec 2019 10:52:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 1A4991DB240; Sun, 29 Dec 2019 10:52:45 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1A0DF1DB23E for ; Sun, 29 Dec 2019 10:52:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47ly7w70ZVz4MPp for ; Sun, 29 Dec 2019 10:52:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id EBBD0186D9 for ; Sun, 29 Dec 2019 10:52:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id xBTAqi0c028156 for ; Sun, 29 Dec 2019 10:52:44 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id xBTAqiMa028154 for bugs@FreeBSD.org; Sun, 29 Dec 2019 10:52:44 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 242954] EBR management continues to remain dysfunctional under FreeBSD Date: Sun, 29 Dec 2019 10:52:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: bourne.identity@hotmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2019 10:52:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D242954 Bug ID: 242954 Summary: EBR management continues to remain dysfunctional under FreeBSD Product: Base System Version: 12.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: bourne.identity@hotmail.com Last year I reported https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D23= 2463 ("EBR slice cannot be added partitions to"), had a long conversation with Andrey V. Elsukov (ae@FreeBSD.org) and finally succeeded in having the issue assigned to geom@FreeBSD.org Come 2019 and Release 12.1, the issue still remains sticking like a sore th= roat with absolutely no action taken. This is no fun. I am a very conventional person who hates new technologies like UEFI and GP= T. GPT in particular bothers me because it won't let me use boot0cfg when I absolutely adore the boot0 manager, which only works with MBR. When partitioning a disk, I always use the MBR schema and then put boot0 to the first block of the disk. I further like to use an EBR slice to hold my secondary partitions because all operating systems can read/write to EBR partitions. My pain lies in the fact that FreeBSD can create the EBR slice, create the EBR schema on that slice and then, lo, will refuse to add/delete partitions in the EBR slice. It has been pointed out to me that I can recompile the kernel without the default EBR_COMPAT option to make EBR functional. This is stupid - this mea= ns that every time I install FreeBSD, I have to recompile the kernel when EBR_COMPAT could so easily be suppressed by default by the makers of FreeBS= D. A few days ago, I installed FreeBSD 12.1 and then, instead of recompiling t= he kernel, I purchased a second disk on which I installed Linux simply to add partitions to the EBR slice. Isn't that funny ? And do the FreeBSD makers intend to let this situation continue ? Please understand that no user in modern times will go through the torture of recompiling the kernel, particularly when the default kernel should be doing the sensible thing in = the first place. It can be argued that I can do without the EBR slice by limiting myself to 4 MBR slices. It's a good argument, but then creates the funny situation that= all secondary DOS/NTFS/Ext2 slices start showing up in the boot0 manager even w= hen they are not bootable. If all the secondary slices were instead EBR partiti= ons, the boot0 manager would simply and rightly refuse to show them, keeping the user well-informed at boot time which slice is bootable. If I were on my deathbed, my last wish would be that the makers of FreeBSD suppress EBR_COMPAT in the default kernel configuration. Thank you - and really looking forward to a resolution this time, Manish Jain --=20 You are receiving this mail because: You are the assignee for the bug.=