GRUB 2 Editor
Off the Beat: Bruce Byfield's Blog
Mostly, I prefer using a command line for system administration. However, I'm willing to rethink this preference in the case of the GRUB 2 Editor for KDE.
Not too long ago, editing the GRUB boot manager was a straightforward task. You edited a text file directly, and, if in the long intervals between changes you forgot the structure of a boot entry, you could usually figure out what to do from existing entries. About the hardest thing to remember if you didn't have an example to crib from was how to boot an unsupported operating system like Windows.
However, in distributions like Ubuntu in which GRUB 2 has replaced Legacy GRUB, editing has become more complicated. Not only has the basic configuration file changed its name from menu.lst to grub.cfg, but you're not supposed to edit it directly. Although you can edit directly if you know what you are doing, the fact that basic concepts have been renamed still complicates everything. Moreover, after making changes or setting up a kernel that isn't packaged, you need to run the command update-grub.
To confuse matters even more, general behavior -- as opposed to menu entries -- is set in the file /etc/default/grub, while any scripts go into one of a half dozen sub-directories in /etc/grub.d. Unless you regularly edit GRUB 2, it's all a bit much to remember. At the very least, you need to research what you're doing instead of plunging right in.
That's where GRUB 2 Editor becomes useful. Developed by Konstantinos Smanis, a Greek undergraduate, GRUB Editor 2 allows you to make the most common changes to the boot manager without needing to remember where everything goes or looking up the details. Currently at version 0.5.5, it is available as source code, or as packages for Arch, Fedora, Mandriva, SUSE, and Ubuntu.
Grub 2 Editor divides the basic options into three tabs. The default General tab starts, logically enough, with the selection of the default kernel to boot from. Beside it is a button that displays older entries when clicked so that you can remove them. Below are options for hiding the menu and for setting the time before the default is booted automatically, and, lower down, some general behavioral options.
On the Appearance tab, you can set some of the options that GRUB 2 adds to the boot process. Here, you can set the resolution for the boot manager display, set the foreground and background colors for selected and unselected text, and add a graphic as wallpaper.
The third tab is for boot options. The interface includes not only kernel options, but also a choice of terminals -- both of which could use some online help to explain to users what exactly the possibilities are. The tab also includes a tool for re-installing or recovering GRUB.
When you are finished setting options, press the Apply button, and login as root or via sudo to apply the changes.
A necessary counter-balance
So far as I can see, GRUB 2 Editor deals entirely with options set in /etc/default/grub. To be a complete, it could use the ability to search for kernels -- just in case you've configured your own -- as well as the ability to deal with scripts. In fact, it might usefully install with a variety of possible scripts for advanced users.
However, for an application still in development, GRUB 2 Editor is not only useful, but sensibly arranged. A few more versions, and I can see it becoming a standard part of the System Settings in Kubuntu, as well as any other distribution that uses both GRUB 2 and KDE.
Part of me remains saddened that a tool like GRUB 2 Editor is necessary at all. While Legacy GRUB obviously needed updating, I can't help feeling that making editing the boot manager unnecessarily more complicated is a step backwards that at least partly negates the improvements. Still, given that's what is happening, I appreciate that GRUB 2 is helping to restore the balance.
GRUB1 is an advance over 2I am not going to go back to Microsoft Windows from my Linux distros., however, to be objective, GRUB"1" is an advance over GRUB2. Did the same people develop Ubuntu "Unity"? Both have slowed me down and degraded my productivity. Therefore I went back to a "lower number" to get my work done. Wait, maybe GRUB2 and Unity were developed by the same team who developed MS- Me and Vista. Same problems, same mentality.
Grub-2I first encountered GRUB-2 when I installed Fedora-16, and immediately baffled by the complexity. it looks to me like a product that was designed by a management committee who were completely unable to decide what they were actually trying to achieve.
After spending several days struggling with it, I simply went back to Fedora-15 and decided to wait for six months or so to see if there would perhaps be a GRUB 2.1 or GRUB 3?
I am going to download and play with the editor if I get the time, however I am unlikely to attempt to implement any GRUB-2 based system in a production-type environment until the product goes beyond its current beta/hack status.
grub2Grub2 is gratuitous complexity gone wild. It is too hard to preserve and manage multiple OS boot options. What you get depends on the last OS installed or upgraded, and any edits made to better identify the choices in the boot menu get lost. I ended up keeping my own template and editing it after every OS update. Thankfully you can now get a bootable Grub CD that can boot to any installed OS. A logical next step would be a slick GUI editor on that same CD which could update the boot files on the hard disk. The Grub2 design is to have configuration files and scripts reside within the last OS installed, a big mistake IMO.
New flaw in an old encryption scheme leaves the experts scrambling to disable SSL 3
Lennart Poettering wants to change the way Linux developers talk to each other.
Enterprise giant frees itself from ink and home PCs (and visa versa).
Mozilla’s product think tank sinks silently into history.
TODO group will focus on open source tools in large-scale environments.
New tool will look like GParted but support a wider range of storage technologies.
New public key pinning feature will help prevent man-in-the-middle attacks.
Carnegie Mellon researchers say 3 million pages could fall down the phishing hole in the next year.
The US government rolls new best-practice rules for protecting SSH.