Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 674364 - sys-boot/grub:0 removal
Summary: sys-boot/grub:0 removal
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Ian Stakenvicius (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 204830 283637 358215 359579 393201 424343 427340 427818 484862 536802 568222 591574 641412
  Show dependency tree
 
Reported: 2019-01-02 18:15 UTC by William Hubbs
Modified: 2019-02-08 15:34 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description William Hubbs gentoo-dev 2019-01-02 18:15:14 UTC
These two packages have multiple open bugs (which I will ist as
dependencies of this one) and are abandonware.

I think it is time to seriously consider removing them.
Comment 1 Jack 2019-01-07 16:48:03 UTC
I only see grub-static masked.  grub:0 is not masked (unless I miss something) and although all grub:2 ebuilds are masked, I don't see any relevant note in .../profiles/package.mask.  

First - is the masking of grub:2 intended or a mistake?  Also, perhaps that package.mask just needs an edit, but from the discussion it sounds like grub:0 also needs masking, it that is the intent.

As has been remarked elsewhere, it still does what it was intended to, so no updates are really needed, but I'll by happy just copying the ebuild to my local overlay.
Comment 2 Thomas Deutschmann gentoo-dev Security 2019-01-07 17:47:51 UTC
grub:2 is _not_ masked.
Comment 3 Jack 2019-01-07 17:53:42 UTC
Apologies - my bad.  I have grub:2 locally masked, and I quickly and stupidly misread the eix output - [m] is not [M].
Comment 4 Larry the Git Cow gentoo-dev 2019-01-13 17:01:28 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=62d479145e5bb4f18d90cbe202824e7eef29390a

commit 62d479145e5bb4f18d90cbe202824e7eef29390a
Author:     William Hubbs <williamh@gentoo.org>
AuthorDate: 2019-01-13 16:35:11 +0000
Commit:     William Hubbs <williamh@gentoo.org>
CommitDate: 2019-01-13 17:00:37 +0000

    profiles: mask grub:0 for removal
    
    Bug: https://bugs.gentoo.org/674364
    Signed-off-by: William Hubbs <williamh@gentoo.org>

 profiles/package.mask | 7 +++++++
 1 file changed, 7 insertions(+)
Comment 5 Larry the Git Cow gentoo-dev 2019-01-13 20:38:10 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=382f3f3baa44fd8dd8a7cf1a02144aa08d2cd0d7

commit 382f3f3baa44fd8dd8a7cf1a02144aa08d2cd0d7
Author:     William Hubbs <williamh@gentoo.org>
AuthorDate: 2019-01-13 20:33:44 +0000
Commit:     William Hubbs <williamh@gentoo.org>
CommitDate: 2019-01-13 20:37:01 +0000

    profiles: mask floppy use flag on memtest86+
    
    This is being done because it requires grub:0 which is being removed.
    
    Bug: https://bugs.gentoo.org/674364
    
    Signed-off-by: William Hubbs <williamh@gentoo.org>

 profiles/default/linux/package.use.mask | 6 ++++++
 1 file changed, 6 insertions(+)
Comment 6 Larry the Git Cow gentoo-dev 2019-01-13 20:47:13 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3ba42a84e372fbacaec8741a4df2d41f54cb14dd

commit 3ba42a84e372fbacaec8741a4df2d41f54cb14dd
Author:     William Hubbs <williamh@gentoo.org>
AuthorDate: 2019-01-13 20:44:43 +0000
Commit:     William Hubbs <williamh@gentoo.org>
CommitDate: 2019-01-13 20:46:27 +0000

    profiles: move the memtest86+[floppy] mask to base
    
    Bug: https://bugs.gentoo.org/674364
    Signed-off-by: William Hubbs <williamh@gentoo.org>

 profiles/base/package.use.mask          | 6 ++++++
 profiles/default/linux/package.use.mask | 6 ------
 2 files changed, 6 insertions(+), 6 deletions(-)
Comment 7 tt_1 2019-01-14 08:19:38 UTC
I agree to mask it due to not being maintained anymore, but do you really have to tree clean it?
Comment 8 Ian Stakenvicius (RETIRED) gentoo-dev 2019-01-14 12:37:09 UTC
(In reply to tt_1 from comment #7)
> I agree to mask it due to not being maintained anymore, but do you really
> have to tree clean it?

There are so few (if any?) cases where grub:0 is a viable option over grub:2 -- given the bugs and bitrot (its been what, a decade now since it's been maintained upstream?) it's time to let it go.

If there are specific use cases for grub:0 that grub:2 can't provide yet, please file a bug and we can use that to block this one until grub:2 handles it.
Comment 9 Matthew Ogilvie 2019-01-20 05:52:44 UTC
Various thoughts, potential user workarounds, and questions:

The main case for grub:0 I can think of is old installs that predate grub:2, and are already working fine.  Why would would someone tackle the difficulty/risk of figuring out how to setup a substantially different bootloader the same way, if they've already got grub:0 working fine?

Of course, new installs should avoid grub:0, especially on newer hardware.  In some cases grub:0 simply wont work no matter what.  I've been using grub:2 on new machines for some years now, but I've still got some older machines (including my "main" personal machine) still using grub:0.

Also note that for most practical purposes, grub:0 and grub:2 are not related at all.  The fact that they are slots rather than separate packages is kind of misleading - they are much more different than that would lead you to believe.

From a quick glance at the "blocks" issues list, most of them look like new feature requests for grub:0, and/or stale bugs that are either odd corner cases, or were problems introduced by newer compilers or something that were later worked around successfully, and the relevant issue just hasn't been closed yet.  It would probably make sense to close most of these with ("WONTFIX" - use grub:2), whether or not grub:0 is treecleaned.

Are any of the issues newly broken in the most "basic" scenario that was previously working?  It doesn't look like it, but if so, that might be a stronger case for treecleaning...  Some comments on bug #427340 suggest users could possibly keep a local copy of the ebuild, but that will only work if newer compilers/etc do not break the ebuild.  Is compiler compatibility currently a problem, or just a potential problem for the future?  Is this why the comment in package.mask seems to imply it will only be given a total of 2 weeks before removal, instead of the more common 30 days?

One workaround?: If grub:0 is already emerged and grub-install'ed onto /boot and the MBR, and the only changes you anticipate needing to make are to tweak /boot/grub/grub.conf (new kernels, etc), then I wonder if it might be safer to unmerge grub:0 but leave it installed in /boot and the MBR, rather than try to maintain a local copy of the ebuild?  Does booting still work if you unmerge grub:0 after grub-install'ing it?  As near as I can tell, it is only grub-install that modifies /boot and MBR, not portage or the ebuild (although
grub-install of course copies stuff from /usr to /boot...) (This obviously wont work if you backup and restore /boot, or similar.)

Another workaround might be to build a working grub:0 with minimal
dependencies (such as USE=-ncurses), and use emerge -b and/or quickpkg to
save a binary-only version that should continue to be re-installable
(grub-install) until/unless one of the remaining dependencies changes
ABI/so-name.
Comment 10 William Hubbs gentoo-dev 2019-01-21 17:15:37 UTC
Hi Matthew,

(In reply to Matthew Ogilvie from comment #9)
> Various thoughts, potential user workarounds, and questions:
> 
> The main case for grub:0 I can think of is old installs that predate grub:2,
> and are already working fine.  Why would would someone tackle the
> difficulty/risk of figuring out how to setup a substantially different
> bootloader the same way, if they've already got grub:0 working fine?

Well, it really isn't difficult at all to migrate to grub:2, I did it years ago and it was flawless. I'm sure grub:2 works even better now than it did when I did the migration. Here's the link to the procedure.

https://wiki.gentoo.org/wiki/GRUB2_Migration

> Of course, new installs should avoid grub:0, especially on newer hardware. 
> In some cases grub:0 simply wont work no matter what.  I've been using
> grub:2 on new machines for some years now, but I've still got some older
> machines (including my "main" personal machine) still using grub:0.
> 
> Also note that for most practical purposes, grub:0 and grub:2 are not
> related at all.  The fact that they are slots rather than separate packages
> is kind of misleading - they are much more different than that would lead
> you to believe.

Grub 2.x is a newer version of grub 0.x. Yes, it is significantly different, but it is still grub. The slotting was a gentoo-ism to allow people to upgrade their systems and migrate successfully to grub 2.x.

Grub 0.x is dead upstream. They don't support it any longer and haven't supported it for many years. It is time for us as a distro to move on. If you want to run it locally you are welcome to copy the ebuild and necessary patches to a local overlay and deal with it yourself; we aren't stopping that.

As said above in this bug, grub 2.x should now handle all use cases grub 0.x does, and more. If you know of a situation where grub 0 works and grub 2.x doesn't, that is a bug that should be fixed.

> From a quick glance at the "blocks" issues list, most of them look like new
> feature requests for grub:0, and/or stale bugs that are either odd corner
> cases, or were problems introduced by newer compilers or something that were
> later worked around successfully, and the relevant issue just hasn't been
> closed yet.  It would probably make sense to close most of these with
> ("WONTFIX" - use grub:2), whether or not grub:0 is treecleaned.
> 
> Are any of the issues newly broken in the most "basic" scenario that was
> previously working?  It doesn't look like it, but if so, that might be a
> stronger case for treecleaning...  Some comments on bug #427340 suggest
> users could possibly keep a local copy of the ebuild, but that will only
> work if newer compilers/etc do not break the ebuild.  Is compiler
> compatibility currently a problem, or just a potential problem for the
> future?  Is this why the comment in package.mask seems to imply it will only
> be given a total of 2 weeks before removal, instead of the more common 30
> days?

Those bugs are build failures, and I'm sure it is worse with more modern versions of the compiler. As you can see, the bugs haven't been touched, all of the grub work nowadays is focused on grub 2.x.

Thirty days in p.mask before removal is not a hard requirement, and yes I set a shorter time because of the combination of the length of time bugs have been open and  because some of the bugs are flat out build failures.

> One workaround?: If grub:0 is already emerged and grub-install'ed onto /boot
> and the MBR, and the only changes you anticipate needing to make are to
> tweak /boot/grub/grub.conf (new kernels, etc), then I wonder if it might be
> safer to unmerge grub:0 but leave it installed in /boot and the MBR, rather
> than try to maintain a local copy of the ebuild?  Does booting still work if
> you unmerge grub:0 after grub-install'ing it?  As near as I can tell, it is
> only grub-install that modifies /boot and MBR, not portage or the ebuild
> (although
> grub-install of course copies stuff from /usr to /boot...) (This obviously
> wont work if you backup and restore /boot, or similar.)
> 
> Another workaround might be to build a working grub:0 with minimal
> dependencies (such as USE=-ncurses), and use emerge -b and/or quickpkg to
> save a binary-only version that should continue to be re-installable
> (grub-install) until/unless one of the remaining dependencies changes
> ABI/so-name.

We haven't tested any of these "workarounds" and don't plan to. Feel free though to test them locally if you would like to.
Comment 11 Ian Stakenvicius (RETIRED) gentoo-dev 2019-01-21 18:58:50 UTC
(In reply to Matthew Ogilvie from comment #9)
> Various thoughts, potential user workarounds, and questions:
> 
> The main case for grub:0 I can think of is old installs that predate grub:2,
> and are already working fine.  Why would would someone tackle the
> difficulty/risk of figuring out how to setup a substantially different
> bootloader the same way, if they've already got grub:0 working fine?

The main reason here is because it's not actually maintainable.  As per the bug list, many of them are compile-time bugs, meaning you can't actually re-emerge the package if you need to.  Sure grub:0 may work to boot the system now, but if you find yourself needing to grub-install it again and you can't, then there wasn't much point in having the package in the gentoo repo anymore.


> Of course, new installs should avoid grub:0, especially on newer hardware. 
> In some cases grub:0 simply wont work no matter what.  I've been using
> grub:2 on new machines for some years now, but I've still got some older
> machines (including my "main" personal machine) still using grub:0.

And choosing to continue to use it, although likely not recommended, is a choice you have to make.  The package doesn't need to be in the gentoo repo though for you to keep it installed.  It also, I believe, doesn't need to be installed in order for you to keep using it to boot your system (since none of the package's files are installed directly to /boot/) as you alluded to below:

> One workaround?: If grub:0 is already emerged and grub-install'ed onto /boot
> and the MBR, and the only changes you anticipate needing to make are to
> tweak /boot/grub/grub.conf (new kernels, etc), then I wonder if it might be
> safer to unmerge grub:0 but leave it installed in /boot and the MBR, rather
> than try to maintain a local copy of the ebuild?  Does booting still work if
> you unmerge grub:0 after grub-install'ing it?  As near as I can tell, it is
> only grub-install that modifies /boot and MBR, not portage or the ebuild

It's not safer than migrating, but as I mentioned above yes in theory this could work, and IMO is yet another reason for supporting grub:0 removal from gentoo repo.  Also, like everything else grub:0, is not a supported configuration (so you're on your own)
Comment 12 Larry the Git Cow gentoo-dev 2019-02-08 15:34:35 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=05f8154821e3661d7c14be9fcc4df49cd31b2104

commit 05f8154821e3661d7c14be9fcc4df49cd31b2104
Author:     Mikle Kolyada <zlogene@gentoo.org>
AuthorDate: 2019-02-08 15:32:57 +0000
Commit:     Mikle Kolyada <zlogene@gentoo.org>
CommitDate: 2019-02-08 15:32:57 +0000

    profiles: sys-boot/grub:0 removal
    
    Closes: https://bugs.gentoo.org/674364
    
    Signed-off-by: Mikle Kolyada <zlogene@gentoo.org>

 profiles/package.mask | 7 -------
 1 file changed, 7 deletions(-)