| Summary: | sys-boot/grub:0 removal | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | William Hubbs <williamh> |
| Component: | Current packages | Assignee: | Ian Stakenvicius (RETIRED) <axs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | base-system, herrtimson, hydrapolic, luke, ostroffjh |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 204830, 283637, 358215, 359579, 393201, 424343, 427340, 427818, 484862, 536802, 568222, 591574, 641412 | ||
|
Description
William Hubbs
2019-01-02 18:15:14 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. grub:2 is _not_ masked. Apologies - my bad. I have grub:2 locally masked, and I quickly and stupidly misread the eix output - [m] is not [M]. 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(+) 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(+) 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(-) I agree to mask it due to not being maintained anymore, but do you really have to tree clean it? (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. 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.
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. (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) 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(-) |