Idea #8143: Allocate Programming resources towards Grub2 for rapid completion

413

Written by Auzy the 6 May 08 at 05:04. Category: System.
Related to: Nothing/Others. Status: New

Description

It has become obvious that Grub2 needs some extra programming help, as Grub-legacy will no longer be adding new features and the end of Grub2 is nowhere in sight. Canonical should allocate 1 or 2 programmers for a few months to help complete grub2 quickly, so that X86 support might be complete in time for Interpid Ipex.

One could argue that the boot loader is the most important part of the operating system, because if it doesn't work properly (which it hasn't been for some of us), it can prevent every OS from working on the computer. We should treat it with respect, and help them. Despite grubs importance, programmers generally enjoy working on more exciting projects like Gnome or KDE, which is one reason why development is slow.

Grub2 fixes a lot of previous brainstorm ideas including many booting issues (like mine), so completion would close a lot of bugs, whilst also making Ubuntu more user friendly because Grub2 deals with booting issues better.

Voting for this ensures that Canonical allocates some developers to the Grub2 project, which would be a big win for both Ubuntu and linux in general!

Planned Features for Grub 2
* Rescue mode saves unbootable cases. Stage 1.5 was eliminated.
* Dynamic loading of modules in order to extend itself at the run time rather than at the build time.
* Graphical interface.
* Fix design mistakes in GRUB Legacy, which could not be solved for backward-compatibility, such as the way of numbering partitions.
* Scripting support, such as conditionals, loops, variables and functions.
* Cross-platform installation which allows for installing GRUB from a different architecture.
* Internationalization. This includes support for non-ASCII character code, message catalogs like gettext, fonts, graphics console, and so on.
* Portability for various architectures.
* Modular, hierarchical, object-oriented framework for file systems, files, devices, drives, terminals, commands, partition tables and OS loaders.
* Real memory management, to make GNU GRUB more extensible.

Tags: boot grub grub2

Attachments

No attachments.

Duplicates

Idea #7460: Hotplug Boot loader (19 votes)

[Report a duplicate and merge its votes to this idea]

Comments

Auzy wrote on the 6 May 08 at 05:40

I'd also like to point out, that there are CVS commits from a week ago (so the developers are definately working on it).

Just I believe for something this important, I think we definately want it done as soon as possible, so we can get out of this empty void we are living in currently

glotz wrote on the 6 May 08 at 07:37

And while you're at it give us a Free BIOS too! http://www.fsf.org/campaigns/free-bios.html

:D

steve196 wrote on the 6 May 08 at 11:06

Are there many cases, where GRUB1 is not doing its job properly?
I do not see the need for something so much more complex.

Auzy wrote on the 6 May 08 at 11:49

Yes steve, the main issue is that sometimes when you swap harddisks around, grub no longer loads the menu (and this is a big problem). Since in grub2, grub is entirely contained in the MBR apparently, we dont get this problem.

It fixes lots of other issues too, and the ability to load modules at runtime also means that we can easily support new OS's, and such.

Eldmannen wrote on the 6 May 08 at 12:01

Wow, GRUB2 sounds pretty complex...

Auzy wrote on the 6 May 08 at 12:17

Yes complex, but certainly a lot more flexible, and certainly a lot more runtime, rather then compile-time.

Think of what Grub would be like without scripting for instance...

Grub2 may be flexible enough, so that we dont have to configure another grub.lst first again (unless we want to make it manual). Thats a big bonus for newbies. Unless people want things to be hard for themselves this for instance would be a big plus for any user

Auzy wrote on the 6 May 08 at 12:23

wait a sec.. that didn't come out right.. Maybe I shouldn't watch TV while on brainstorm...

Think of what BASH would be like without scripting for instance...

HDave wrote on the 6 May 08 at 21:29

Screenshots samples can be found here:

http://linux.softpedia.com/progScreenshots/GNU-GRUB-Screenshot-1092.html

Auzy wrote on the 7 May 08 at 02:22

actually, if you check the version Hdave, someone at softpedia hasn't got their head screwed on tight ;)

tgape wrote on the 7 May 08 at 17:23

This idea was suggesting devoting more resources to grub2, since grub1 has been closed to new features, yet has bugs.

Unless grub1 has been closed for bug fixes as well, that sounds like a nonsequitur to me. The bugs should still be able to be fixed, so long as you're not talking about fundamental design issues. And fundamental design issues would still need to wait for grub2 even if grub1 wasn't closed to new features.

Auzy wrote on the 11 May 08 at 06:16

Yes tgape, it Grub1 still has bugs that need fixing. However, Grub2 has design changes that fix a lot of issues (like shifting around hdd's) that affect a lot of people too (but can be fixed by shifting them back), amongst other things.

And I'd hate to watch good developers spend dozens of hours of their time fixing bugs for a program, that we will be dumping in the future. Or coding new frontends, or auto-matic configuration tools.

If they spent that time improving grub2, it means its less time wasted in the long run (because Grub2 is a total rewrite, so patches I doubt could even be applied to both of them).

EnigmaticSeraph wrote on the 12 May 08 at 18:54

I agree entirely... I've been watching this poor project since its inception, but haven't had the CFT to help out... :/ I REALLY don't want to see this become vaporware.

Auzy wrote on the 14 May 08 at 11:45

It wont become vaporware, because the developers repository is still busy, stuff is still actively getting committed.

Its just a matter of the speed stuff is getting implemented

probono wrote on the 14 May 08 at 21:32

Perhaps it could even be brought to the point where it would make Ubuntu bootable from USB on Intel Macs (which it currently isn't) as proposed in http://brainstorm.ubuntu.com/idea/2299/

zishmusic wrote on the 15 May 08 at 12:58

I love this idea. I would like to configure my /boot partition in LVM. Ubuntu's initial configuration will allow me to do it, but then forces me into using LiLo as the boot loader.
This would normally not be a big deal, except that LiLo takes a little longer on my system to boot, and I can't use Xen at all (without some weird customizations).

Definitely +1.

Auzy wrote on the 16 May 08 at 03:53

It will support scripting and the likes probono, so I'd imagine it could also add any boot parameters needed to the boot string.

Either way, since stage 1.5 disappears, it fixes my main issue

notyetroot wrote on the 15 Aug 08 at 12:44

This is worth it. This would introduce scripting, look better and be easier to use!

+1

Post your comment