SPEC: http://netbsd.sk/~lkundrak/SPECS/grub2.spec SRPM: http://netbsd.sk/~lkundrak/SRPMS/grub2-1.98-0.1.20080807svn.el5.src.rpm Description: This is the second version of the GRUB (Grand Unified Bootloader), a highly configurable and customizable bootloader with modular architecture. It support rich scale of kernel formats, file systems, computer architectures and hardware devices.
*** Bug 228255 has been marked as a duplicate of this bug. ***
Maybe you need trigger-scriptlets with kernel-PAE, too. Also I guess you need Requires(post): mkinitrd Requires(preun): mkinitrd because you use grubby in preun and post.
Thanks, Till, your suggestions have been integrated in the new revision. Marek, this now builds on x86_64. SPEC: http://netbsd.sk/~lkundrak/SPECS/grub2.spec SRPM: http://netbsd.sk/~lkundrak/mock-results/grub2-1.98-0.2.20080807svn.el5.x86_64/grub2-1.98-0.2.20080807svn.el5.src.rpm mock build with build logs: http://netbsd.sk/~lkundrak/mock-results/grub2-1.98-0.2.20080807svn.el5.x86_64/
I just read on Fedoras Planet, that there will a kernel-vanilla package soon, maybe you keep this in mind for the next update of your spec.
Till, right, there's also memtest, and probably some more packages, that make sense to be loaded by GRUB. Maybe it would make sense to adjust grubby for grub2's grub.cfg, and not use update-grub at all. But yes, I think I'll just add those triggers for now, not to deviate from upstream at this point.
Please remember to set the review flag to '?' when you're reviewing.
Dare I suggest that we really don't need more bootloaders? Particularly when they have such a high maintenance cost in the installer, and (in this particular case) it offers no real features over the grub we've got.
Adam: even though at the time GRUB 2 does not have any killer features over GRUB, GRUB 2 has more active code base, that has potential to be shared across distributions (unlike GRUB whose official upstream had been long dead until very recently, and developed into various vendor-specific forks each carrying a load of custom patches, often resulting in regressions). Some of interesting features GRUB 2 has now is native support for UTF-8, support for variety of graphic modes, RAID and LVM support. Note that including GRUB 2 in distribution does not imply any support in the installer. GRUB 2 kernel can be booted from withing GRUB in in the same way as Linux kernel. This package does not intend to replace GRUB (at least until it is feature-complete), but to serve users and developers that are interested in GRUB 2's features.
Afaik grub2 supports booting directly from iso files, which is feature I would like to have very much to boot live cds.
I agree with Till, we have to include this in distribution at least for QA purpose. It may become once the official boot loader and replace dead grub. The final version of package looks sane, Lubomir please include patch comments in the spec file as we agreed on IRC. This package is approved, please include a note about grub2 availability in release notes for Fedora 9. (I'll help with testing once I'm back from my vacation.)
New Package CVS Request ======================= Package Name: grub2 Short Description: Bootloader with support for Linux, Multiboot and more Owners: lkundrak Branches: F-9 EL-5
I think release notes for a bootloader that won't be the default, won't work on some machines that the normal one does, won't be supported by any of the tools... would be rather silly. (Much like including the package, but... eh.)
I'm a bit worried here about user confusion... what happens if someone removes grub and tries to just use grub2? (I would assume it would fail due at least to lack of selinux support). Have you tested how it would fail in that case... many users assume higher versions are better and will update to them even in the absense of any problems with the older version. ;(
(In reply to comment #13) > I'm a bit worried here about user confusion... what happens if someone removes > grub and tries to just use grub2? If anyone removes grub, he should be aware that he needs to install another bootloader (with grub-install). That's also true for lilo, or possibly even newer version of grub. > (I would assume it would fail due at least to > lack of selinux support). Good point; as far as I know, grub2 needs an executable stack, due to use of nested functions. I'll need to eventually verify this and open a ticket against selinux-policy. > Have you tested how it would fail in that case... > > many users assume higher versions are better and will update to them even in > the absense of any problems with the older version. ;( Apart from version number, grub and grub2 also differ in package name, and that's generally enough to distinguish that you are dealing with two different pieces of software. An ordinary desktop user won't even notice the presence of the grub2 package unless he wants to.
Adding the grub maintainer here for comment. ;)
Adding another bootloader for x86 that we're not supporting in grubby and booty is just a mistake.
I'd say it's a mistake to add support for a bootloader that's not packaged into grubby.
ok, so where do we stand here? Shall I process the cvs request? Or do we think this package is not a good idea to add right now?
The consencous is that before grub2 is to go in, support needs to be added for tools (ex grubby). Then it should easily be able to go in. But fedora userspace tools need to support grub2 config files before going into fedora.
(In reply to comment #19) > The consencous is that before grub2 is to go in, support needs to be added for > tools (ex grubby). Then it should easily be able to go in. But fedora userspace > tools need to support grub2 config files before going into fedora. No. It's just your opinion. Please understand that the new grub2 package just adds some optional features. Noone forces you to do so, so if you disagree with the presence of a package, the nice thing about it is that you do not have to install it. In case you feel grubby support is important at this point, you, or anyone, can add it whenever you want to provided your patch is accepted by the grubby maintainer, but please do not use it as argument, unless it is a packaging-comitee approved guideline. I find it highly odd to add support for a nonexistent package, and am not going to do so. In case you question the quality of the review, please point out where does it violate the guidelines. I value comments with valuable opinions, but unsupported assertion presented as "consensus" is of hardly any use. So, to summarize: 1.) grub2 is usable without grubby support - see distribution-agnostic grub2-update 2.) There actually are userspace tools to support grub2 - see grub2-update and $EDITOR 3.) grub2 package does not interfere with anything already in base - none of its provides overlays any existing package, including grub - it does not replace grub2 4.) grub2 was properly reviewed and approved Kevin: given the above explanation, please process the CVS request (unless a package guidelines violation is found, which I believe to be unlikely after a relatively long this request is open)
@Lubomir You have to rembmer I was the first to bring grub2 to fedora last year (as I am a grub2 maintainer .. though not very active as of late ... see bug 228255). While yes you can use grub2 with it's own tools manually, what happens when a new fedora kernel is installed? It doesn't run those tools to update the grub2 config. My point is this issue is integration into the distribution. The grub2 tools are not apart of the distribution process and so this is where the issues are. Making these tools or updating the process to use the tools is what will allow grub2 to go into fedora. You have to stop just thinking about the project, and understand that it is not just a standalone tool. But must be integrated into the processes that fedora uses. Which is why there are comments about grubby & booty support.
(In reply to comment #21) > @Lubomir > > You have to rembmer I was the first to bring grub2 to fedora last year (as I > am a grub2 maintainer .. though not very active as of late ... see bug 228255). Right. Your package did not pass the review. > While yes you can use grub2 with it's own tools manually, what happens when a > new fedora kernel is installed? It doesn't run those tools to update the grub2 > config. Are you sure? > My point is this issue is integration into the distribution. You can not integrate nonexistent parts. > The grub2 tools > are not apart of the distribution process and so this is where the issues are. > Making these tools or updating the process to use the tools is what will allow > grub2 to go into fedora. I'd say we developed the review process to judge which parts do we allow into fedora. > You have to stop just thinking about the project, and understand that it is > not just a standalone tool. It can be. > But must be integrated into the processes that > fedora uses. Which is why there are comments about grubby & booty support. To reiterate: You can not integrate nonexistent parts. The guidelines don't require you to do so. Furthermore, currently it integrates at the level which is sufficient for most use cases, and having the package in distribution encourages more integration. And at last; You obviously haven't even bothered looking at the package or reading the spec file, so I do not consider you a discussion peer here anymore. Please don't put useless and uninformed comments here anymore.
(In reply to comment #21) [...] > My point is this issue is integration into the distribution. The grub2 tools > are not apart of the distribution process and so this is where the issues are. > Making these tools or updating the process to use the tools is what will allow > grub2 to go into fedora.. I don't agree with you, this is not a part of default core system, it's an additional package that will be primary used for hacking and over-time to adjust our tools (which are closed to community commits, btw). I confirm that I'm approving this package.
@Marek Haha. No just just showing where I was coming from. Not to stroke my ego.
ok, cvs done. I still think this could well confuse users, but I don't have any hard objections.
Thanks, imported and built. Description was extended and a README file was added to avoid the confusion as much as possible.