Description: This Kcm module manages the most common settings of Grub2 . It uses the KAuth authorization system to gain root privilegies and is thus well integrated in system settings, under startup/shutdown.
Grub features supported/general: Default item Timeout Hidden timeout Force menu Countdown Background image Linux quiet and splash parameters Text and background colors
Grub features supported/advanced: Distributor Default commandline Gfx resolution (with video card probe support) Disable recovery Disable memtest Disable uuid Disable gfx Disable OS prober Init tune (with presets)
Grub features supported/security: Enable security Manage users Manage groups Crypt passwords
Grub features supported/tools: Package name Package version Host OS (Re)install grub on device
BUILD INSTRUCTIONS: Grub2 Kcm requires cmake, make, g++, kdelibs-dev, pyqt, pykde and gettext. Starting from version 1.3, python-xlib will be used if available to display the current screen resolution. Move in the build directory and issue the following commands: cmake .. -DCMAKE_INSTALL_PREFIX=/usr make sudo make install
It is available in many languages. Since it is a kde playground project, you should use the kde translation system if you want to help with translations.
Starting from version 1.1, full names will be used instead of numbers when the default boot item is not Linux. This ensures that the default item doesn't change when new Linux kernels (which usually come first) are installed/removed. We still use numbers for Linux entries since you will usually want the latest version to be the default, and not a specific kernel.Last changelog:
v1.3 - 2011/04/04 Translations (thanks to the respective KDE translation teams): * New: Czech, German, Low Saxon, Portuguese, Brazilian Portuguese, Ukrainian, Danish, Spanish, Hungarian * Updated: Lithuanian, Italian, Dutch, Russian Functionality: * Add support for GRUB_INIT_TUNE, including presets * Add support for probing the video card for VBE resolutions (largely based on vbespy/vbetest) * Add support for changing text and background colors * Add tips to explain non-obvious settings Ui: * Rework the General tab Code: * Minor fixes v1.2 - 2011/03/12 Translations: * Add Russian translation (thanks to Yuri Efremov) * Update Italian translation Functionality: * Add full support for Grub security features (users, groups, crypted passwords) * Add support for installing/reinstalling Grub * Add Grub version reporting * Add support for GRUB_DISABLE_OS_PROBER option * Display useful error messages instead of generic ones Fixes: * Gracefully handle wrong grub.cfg permissions Code: * Rework the helper to make it cleaner
v1.1 - 2011/02/03 Translations: * Add French translation (thanks to Bruno Patri) * Add Dutch translation (thanks to Ronald Stroethoff) * Add Lithuanian translation (thanks to Andrius Å tikonas) Fixes: * Fix a bug that prevented the gfx mode and and the distributor from being edited Functionality: * Add support for NetBSD/OpenBSD directory structure * Reload configuration files after applying changes * Use full name instead of number if the default item is not Linux * Add button to restore default values * Disable "Show menu" and "Show countdown" options if timeout is not enabled * Disable memtest option if no memtest has been found * Disable "Graphical mode" input if "disable graphical mode" is enabled * Show the "updating configuration" progress dialog only after the user has entered the password Code: * Use fputs() instead of fprintf() in the backend * Port everything to new-style signals/slots method Other: * Update license to GPLv3
I'm trying to build this package on Fedora 17 and it keeps failing when I run make.
Here is the error that make fails with:
/usr/src/kcmgrub2-1.3/helper/helper.cpp:25:27: error: ‘chdir’ was not declared in this scope
and shows the following 2 errors:
make[2]: *** [helper/CMakeFiles/kcmgrub2helper.dir/helper.o] Error 1
make[1]: *** [helper/CMakeFiles/kcmgrub2helper.dir/all] Error 2
make: *** [all] Error 2
Any help to get this working would be greatly appreciated.
My system is an x86_64 system. I've installed it through apper and fedora repos but when it tries to update it fails with a file conflict between an i686 and x86_64 file conflict!
Please help!
OK, that fixed the build problem, but now when I run it it says the configuration file has the wrong permissions and pops up a couple of error dialogs and finally grays out the window for this addon in system setting.
I was able to build the older version which worked flawlessly on my old system.
So what do I need to do to fix the errors. I really don't know what file it's talking about but I believe it is talking about grub.cfg.
I really liked this app, hope there's a fix for it.
Thanks for your response on how to get it to build.
Just tried Fedora 17 in a virtual machine. The problem is that Fedora now installs grub.cfg under /boot/grub2 instead of /boot/grub, and grub-mkconfig as grub2-mkconfig. I will fix this in the next version, for now you can do (in a terminal as root)
cd /boot/grub
ln -s ../grub2/grub.cfg grub.cfg
cd /usr/sbin
ln -s grub2-mkconfig grub-mkconfig
The first time you will still be prompted about wrong permissions, but after entering your password it will work.
Ah, just noticed that Fedora no more provides update-grub :-(
So you will also need to create /usr/sbin/update-grub with the following contents:
#!/bin/sh
set -e
exec grub-mkconfig -o /boot/grub2/grub.cfg
and set it executable (chmod 0755 /usr/sbin/update-grub)
Ok, the latest git version contains lots of fixes targeted specifically at Fedora 17, plus some other improvements. I tested it quickly in a VM, but the feedback of a day-to-day user would be useful.
Nice effort but I dropped by to let you know that setting permissions for grub.cfg is not that graceful. grub-mkconfig changes its permissions to -r-------- (only owner -root- can read) every time it runs:
Quote:
chmod 400 ${grub_cfg}.new || grub_warn "Could not make ${grub_cfg}.new readable by only root.\
This means that if the generated config contains a password it is readable by everyone"
Plus, system administrators wouldn't really like messing with their file permissions.
Hi, thanks for your constructive comment. I'll try to explain what's behind this decision.
First of all, I think setting grub.cfg to 0400 is useless anyway, since
1) one can simply read the password directly from the scripts in grub.d
2) if you have direct access to the machine, you can easily get the password with a bunch of techniques, it won't be a 400 to stop you (and crypting the disk will be useless in this case, since /boot cannot be crypted).
Second, that's why I added support for sha512 crypted passwords: anyone considering security so important would never use cleartext ones.
Fixperm is designed to avoid to annoy the user with UAC-style messsages, and since you probably won't be running grub-mkconfig manually everyday (probably just when installing a new kernel) I think it does its job.
That said, since kde it's all about giving the user the power to judge and decide, I'm likely going to add an option to disable it in version 1.4 (1.3 is in string freeze now).
Alberto
Well, it's not all about passwords or security, it's about breaking upstream stuff. grub-mkconfig chmods grub.cfg to 0400 for some reason and this is where permissions should change, if need be.
I'm also working on a GRUB2 KCModule, in case you haven't noticed (http://kde-apps.org/content/show.php/GRUB2+Bootloader+KCModule?content=139643) and I encounter the same issues with you. If you want my opinion, go for a separate read-slot in your helper and set it's permissions to "yes" (invoked without asking password). This mechanism is designed like this to allow administrators easily tweak such options and it doesn't break stuff whatsoever.
The automatic read slot seems a really good idea, although it would probably need some checks to avoid potential security risks. It may be good also for the other part of the module requiring root access: vbetest (currently in git). I'll work on it for v1.4.
I have seen your work, that's very good, Linux is all about choice.
Alberto
I have created a package for Slackware/Salix, but when I try to save the settings I receive always the error:
"Unable to authenticate/execute the action." even if I use kdesu or the root user.
I don't understandy why... can someone help me, please?
Many thanks in advance to all!
Hi, could you please execute it with "kcmshell4 kcmgrub2" from the command line, try to save the settings and post the output here? The module shouldn't be executed as root, and that error message usually means that the c++ helper has not been properly installed.
What I see on the kcmgrub2 window is "You are not allowed to save the configuration" above the tabs General and Advanced.
$ kcmshell4 kcmgrub2
true
"Launch helper exited with unknown return code 255"
The word "true" appears when the app starts and the error appears when I click on "Apply" button.
Ok, so the problem is within the helper. Could you check that the following files/directories are correctly installed (Assuming kde is installed in /usr)?
/usr/share/kde4/apps/kcmgrub2/kcmgrub2.py
/usr/share/kde4/apps/kcmgrub2/kcmgrub2.ui
/usr/share/kde4/services/kcmgrub2.desktop
/usr/lib/kde4/libexec/kcmgrub2helper
/etc/dbus-1/system.d/org.kde.kcontrol.kcmgrub2.conf
/usr/share/dbus-1/system-services/org.kde.kcontrol.kcmgrub2.service
/usr/share/polkit-1/actions/org.kde.kcontrol.kcmgrub2.policy
You might also try reloading dbus.
All the files are in the correct path except kcmgrub2.{py,ui} that are on /usr/share/apps instead of /usr/share/kde4/apps.
If I try to move in the second directory I receive an error that the GUI is not present or is for kde3...
Ah, so it seems slackware is using a different directory structure. So most likely one of the other files are in a place which is different from what kde expects them to be. For example, /usr/lib/kde4/libexec/kcmgrub2helper may be /usr/lib/libexec/kcmgrub2helper. To be sure, you could search for the equivalent files in other k control modules: for example a search for all the files that begin with org.kde.kcontrol should give you the correct path for .conf, .service and .policy files.
Nice to see this project progressing nicely. Continue the good work! Booloader configuration was reallly missing a piece in KDE.
On the side note, wouldn't this project gain much more visibility (including more translations) if hosted in KDE infrastructure (e.g., here: https://projects.kde.org/projects/playground/sysadmin)?
Hi Craig
You're right - not everyone knows what Grub2 is, and I surely agree that from a distribution point of view bootloader configuration would sound better (every distribution has only one bootloader, after all). My concern, though, is from a kde point of view: there is already, for example, a module for Grub Legacy, and renaming mine "bootloader configuration" would probably sound like saying "this is official" or something like that.
However, I don't want to impose my view in any way, so I would like to hear other opinions about this and then decide in time for 1.1 (this Thursday).
The app would still be 'kcmgrub2' - just the user visible string in System Settings would change. Which I think is fair enough - why would you want/need more than 1 way to modify grub2?
Ratings & Comments
29 Comments
Hi, I am on Funtoo/Gentoo. I get a message No valid GRUB2/BURG installation could be detected.
"Grub2 Kcm" is different software from "GRUB2 Editor". Since this question refers to "GRUB2 Editor", I have answered it in the appropriate place (http://kde-apps.org/content/show.php?content=139643&forumpage=4).
I'm trying to build this package on Fedora 17 and it keeps failing when I run make. Here is the error that make fails with: /usr/src/kcmgrub2-1.3/helper/helper.cpp:25:27: error: ‘chdir’ was not declared in this scope and shows the following 2 errors: make[2]: *** [helper/CMakeFiles/kcmgrub2helper.dir/helper.o] Error 1 make[1]: *** [helper/CMakeFiles/kcmgrub2helper.dir/all] Error 2 make: *** [all] Error 2 Any help to get this working would be greatly appreciated. My system is an x86_64 system. I've installed it through apper and fedora repos but when it tries to update it fails with a file conflict between an i686 and x86_64 file conflict! Please help!
Hi jakepbg, and sorry for the delay. Does it help if you add #include <unistd.h> at the top of helper.cpp?
OK, that fixed the build problem, but now when I run it it says the configuration file has the wrong permissions and pops up a couple of error dialogs and finally grays out the window for this addon in system setting. I was able to build the older version which worked flawlessly on my old system. So what do I need to do to fix the errors. I really don't know what file it's talking about but I believe it is talking about grub.cfg. I really liked this app, hope there's a fix for it. Thanks for your response on how to get it to build.
Just tried Fedora 17 in a virtual machine. The problem is that Fedora now installs grub.cfg under /boot/grub2 instead of /boot/grub, and grub-mkconfig as grub2-mkconfig. I will fix this in the next version, for now you can do (in a terminal as root) cd /boot/grub ln -s ../grub2/grub.cfg grub.cfg cd /usr/sbin ln -s grub2-mkconfig grub-mkconfig The first time you will still be prompted about wrong permissions, but after entering your password it will work.
Ah, just noticed that Fedora no more provides update-grub :-( So you will also need to create /usr/sbin/update-grub with the following contents: #!/bin/sh set -e exec grub-mkconfig -o /boot/grub2/grub.cfg and set it executable (chmod 0755 /usr/sbin/update-grub)
Ok, the latest git version contains lots of fixes targeted specifically at Fedora 17, plus some other improvements. I tested it quickly in a VM, but the feedback of a day-to-day user would be useful.
Nice effort but I dropped by to let you know that setting permissions for grub.cfg is not that graceful. grub-mkconfig changes its permissions to -r-------- (only owner -root- can read) every time it runs: Quote:chmod 400 ${grub_cfg}.new || grub_warn "Could not make ${grub_cfg}.new readable by only root.\
This means that if the generated config contains a password it is readable by everyone"
Plus, system administrators wouldn't really like messing with their file permissions.
Hi, thanks for your constructive comment. I'll try to explain what's behind this decision. First of all, I think setting grub.cfg to 0400 is useless anyway, since 1) one can simply read the password directly from the scripts in grub.d 2) if you have direct access to the machine, you can easily get the password with a bunch of techniques, it won't be a 400 to stop you (and crypting the disk will be useless in this case, since /boot cannot be crypted). Second, that's why I added support for sha512 crypted passwords: anyone considering security so important would never use cleartext ones. Fixperm is designed to avoid to annoy the user with UAC-style messsages, and since you probably won't be running grub-mkconfig manually everyday (probably just when installing a new kernel) I think it does its job. That said, since kde it's all about giving the user the power to judge and decide, I'm likely going to add an option to disable it in version 1.4 (1.3 is in string freeze now). Alberto
Well, it's not all about passwords or security, it's about breaking upstream stuff. grub-mkconfig chmods grub.cfg to 0400 for some reason and this is where permissions should change, if need be. I'm also working on a GRUB2 KCModule, in case you haven't noticed (http://kde-apps.org/content/show.php/GRUB2+Bootloader+KCModule?content=139643) and I encounter the same issues with you. If you want my opinion, go for a separate read-slot in your helper and set it's permissions to "yes" (invoked without asking password). This mechanism is designed like this to allow administrators easily tweak such options and it doesn't break stuff whatsoever.
The automatic read slot seems a really good idea, although it would probably need some checks to avoid potential security risks. It may be good also for the other part of the module requiring root access: vbetest (currently in git). I'll work on it for v1.4. I have seen your work, that's very good, Linux is all about choice. Alberto
@artemisfowl2007, kbios: You could join in one single project and do something really great for KDE! Thank you both!
Hi, very useful tool! Russian translation: http://ubuntuone.com/p/gZz/
Thanks!
I have created a package for Slackware/Salix, but when I try to save the settings I receive always the error: "Unable to authenticate/execute the action." even if I use kdesu or the root user. I don't understandy why... can someone help me, please? Many thanks in advance to all!
Hi, could you please execute it with "kcmshell4 kcmgrub2" from the command line, try to save the settings and post the output here? The module shouldn't be executed as root, and that error message usually means that the c++ helper has not been properly installed.
What I see on the kcmgrub2 window is "You are not allowed to save the configuration" above the tabs General and Advanced. $ kcmshell4 kcmgrub2 true "Launch helper exited with unknown return code 255" The word "true" appears when the app starts and the error appears when I click on "Apply" button.
Ok, so the problem is within the helper. Could you check that the following files/directories are correctly installed (Assuming kde is installed in /usr)? /usr/share/kde4/apps/kcmgrub2/kcmgrub2.py /usr/share/kde4/apps/kcmgrub2/kcmgrub2.ui /usr/share/kde4/services/kcmgrub2.desktop /usr/lib/kde4/libexec/kcmgrub2helper /etc/dbus-1/system.d/org.kde.kcontrol.kcmgrub2.conf /usr/share/dbus-1/system-services/org.kde.kcontrol.kcmgrub2.service /usr/share/polkit-1/actions/org.kde.kcontrol.kcmgrub2.policy You might also try reloading dbus.
All the files are in the correct path except kcmgrub2.{py,ui} that are on /usr/share/apps instead of /usr/share/kde4/apps. If I try to move in the second directory I receive an error that the GUI is not present or is for kde3...
Ah, so it seems slackware is using a different directory structure. So most likely one of the other files are in a place which is different from what kde expects them to be. For example, /usr/lib/kde4/libexec/kcmgrub2helper may be /usr/lib/libexec/kcmgrub2helper. To be sure, you could search for the equivalent files in other k control modules: for example a search for all the files that begin with org.kde.kcontrol should give you the correct path for .conf, .service and .policy files.
Nice to see this project progressing nicely. Continue the good work! Booloader configuration was reallly missing a piece in KDE. On the side note, wouldn't this project gain much more visibility (including more translations) if hosted in KDE infrastructure (e.g., here: https://projects.kde.org/projects/playground/sysadmin)?
Hi, thanks for the kind words. Yes, I plan doing that as soon as I have some free time, probably in a few weeks.
Hi Craig You're right - not everyone knows what Grub2 is, and I surely agree that from a distribution point of view bootloader configuration would sound better (every distribution has only one bootloader, after all). My concern, though, is from a kde point of view: there is already, for example, a module for Grub Legacy, and renaming mine "bootloader configuration" would probably sound like saying "this is official" or something like that. However, I don't want to impose my view in any way, so I would like to hear other opinions about this and then decide in time for 1.1 (this Thursday).
The app would still be 'kcmgrub2' - just the user visible string in System Settings would change. Which I think is fair enough - why would you want/need more than 1 way to modify grub2?