Description: A KDE Control Module for configuring the GRUB2 bootloader.
Smoothly integrated in KDE System Settings, it is the central place for managing your GRUB2 configuration. Supports many GRUB2 configuration options, most notably:
* Manage default boot entry * Manage boot timeout * Manage boot resolutions * Manage boot menu colors * Manage boot menu theme * Manage linux kernel arguments * Save and update the configuration files of GRUB2
Extra features include:
* Recover GRUB2 * Remove old entries * Create and preview GRUB2 splash images
On OpenSUSE Tumbleweed it works GREAT..!! :)
please working on it, much easier than goofing around myself, crashing my system :)
optional: Maybe add options for theme.txt file
thanks...
I am guessing you are using GNOME instead of KDE, that's why you are confused.
You can always run it with the command 'kcmshell4 kcm_grub2'. If that fails, then it's not installed.
I know just enough to get myself into trouble!
I installed Kde desktop, then tried to reinstall the grub 2 app. No luck getting it to run. What should I try next?
Is there a way to delete extra entries ? I have a data drive formatted NTFS so that Windows and Linux Mint can both access it but grub always shows
Windows (on sda1)
Windows (on sda2)
where sda2 is the data drive ( nothing remotely bootable there...need not even be seen by grub2.).
Any help or have I missed what I am looking for?
No, you can't do much. Even if you deleted the entries, the grub-mkconfig script is responsible for re-generating the entries, which in turn calls os-prober.
I guess there used to be a Windows installation there and some hidden boot files/folders have remained, thus making os-prober create this useless entry. Try reformatting the partition or manually removing these files/folders.
The module offers two ways to set the default: choosing a specific kernel via drop down list or using the last booted system as default.
But where is the option to always use the first entry no matter which kernel it is?
After I'd tested your module with a siduction installation with hidden boot menu, the newest kernel is ignored and always the old one is booted, the one shown in the drop down box (which you cannot avoid as it seems?).
This is so by design. The default entry is specified by name instead of number, it's safer. Imagine having this menu:
Debian
Debian (recovery)
memtest
Windows
and you want Windows to be the default. If you specify the entry by number and another kernel pops in the menu like this:
Debian
Debian (recovery)
Debian old kernel
memtest
Windows
your default will become memtest and you'll all be like "wtf!?". Instead, specifying by name always makes sure the same entry is booted and if you want it changed, you can always do it manually.
Perhaps I should introduce an option "Specify by position in the menu" (next to the list box)?
I don't want to use a specific entry number like second or third, I miss an option to just use the first and always the first entry.
Imagine a distribution where new kernel versions arrive weekly to daily. In that case you need an option to always use the first entry resp. no entry (GRUB_DEFAULT=0 ?) as default.
I really would appreciate such an option to keep grub's default behaviour, otherwise it takes more effort to use your module (after every kernel install!) than to edit the grub configuration by hand (once in a while). Grub behaves like that unless one uses your module once.
I understand your point and will take care of it, but the reason for such a design is that a broken default entry is worse than an outdated one (as explained above). Thanks for your feedback!
zypper install kcm-grub2
Loading repository data...
Reading installed packages...
Resolving package dependencies...
Problem: nothing provides libpackagekit-qt.so.14()(64bit) needed by kcm-grub2-0.5.5-8.1.x86_64
Solution 1: do not install kcm-grub2-0.5.5-8.1.x86_64
Solution 2: break kcm-grub2 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/c] (c):
This is known, but thanks for reporting.
At the time of packaging libpackagekit-qt.so was available, but due to to the rolling-release system of openSUSE Factory, it was removed at some point.
Next version will address this issue.
In short, this issue has been fixed in git, but is not yet released. I present you with a short explanation why this happens and a couple of solutions:
Explanation:
Gentoo hides the GRUB executables (grub-install, grub-mkconfig, grub-probe, grub-set-default) from the user's PATH, so technically we can't discover a GRUB installation.
Solutions:
Either compile from git,
or if you really can't wait for the next release, create symlinks to the above executables visible to the user running the following commands (as root):
Quote:
need repo for fedora 16
grub2 paths in fedora 16
/boot/grub2
/boot/grub2/grub.cfg
/etc/bash_completion.d/grub
/etc/default/grub
/etc/grub.d
/etc/grub.d/00_header
/etc/grub.d/10_linux
/etc/grub.d/20_linux_xen
/etc/grub.d/30_os-prober
/etc/grub.d/40_custom
/etc/grub.d/41_custom
/etc/grub.d/90_persistent
/etc/grub.d/README
/etc/grub2.cfg
/sbin/grub2-install
/sbin/grub2-mkconfig
/sbin/grub2-mkdevicemap
/sbin/grub2-mknetdir
/sbin/grub2-probe
/sbin/grub2-reboot
/sbin/grub2-set-default
/sbin/grub2-setup
/usr/bin/grub2-bin2h
/usr/bin/grub2-editenv
/usr/bin/grub2-fstest
/usr/bin/grub2-kbdcomp
/usr/bin/grub2-menulst2cfg
/usr/bin/grub2-mkfont
/usr/bin/grub2-mkimage
/usr/bin/grub2-mklayout
/usr/bin/grub2-mkpasswd-pbkdf2
/usr/bin/grub2-mkrelpath
/usr/bin/grub2-mkrescue
/usr/bin/grub2-script-check
in fedora you can use su -l -c rather than sudo
and beesu rather than sudo
Yea.In Fedora there is the error /bin/sh: grub-mkconfig: not found. That's probably because in Fedora this command has form: grub2-mkconfig. Need a patch
Also point the application to the right configuration files:
/boot/grub2/grub.cfg instead of /boot/grub/grub.cfg,
/boot/grub2/grubenv instead of /boot/grub/grubenv
The next version will include a fix for this. I am sorry for the inconvenience, but there hasn't been any testing/feedback on Fedora other than yours :)
Ratings & Comments
115 Comments
I can't get it to work on Kubuntu 18.04 LTS =/
9 +
On OpenSUSE Tumbleweed it works GREAT..!! :) please working on it, much easier than goofing around myself, crashing my system :) optional: Maybe add options for theme.txt file thanks...
I used yum to install your app to rewrite grub 2 in Fedora 20. I'm not use to the new fedora, but I can't find any where to open the program.
It should appear under ‘System Settings > Startup and Shutdown > GRUB2 Bootloader’.
Maybe the difference is I used a live version install to hard drive. Still can't find a way to open the program.
I am guessing you are using GNOME instead of KDE, that's why you are confused. You can always run it with the command 'kcmshell4 kcm_grub2'. If that fails, then it's not installed.
I know just enough to get myself into trouble! I installed Kde desktop, then tried to reinstall the grub 2 app. No luck getting it to run. What should I try next?
If the above fail, then you should get some kind of error code/description which explains what went wrong.
Is there a way to delete extra entries ? I have a data drive formatted NTFS so that Windows and Linux Mint can both access it but grub always shows Windows (on sda1) Windows (on sda2) where sda2 is the data drive ( nothing remotely bootable there...need not even be seen by grub2.). Any help or have I missed what I am looking for?
No, you can't do much. Even if you deleted the entries, the grub-mkconfig script is responsible for re-generating the entries, which in turn calls os-prober. I guess there used to be a Windows installation there and some hidden boot files/folders have remained, thus making os-prober create this useless entry. Try reformatting the partition or manually removing these files/folders.
The module offers two ways to set the default: choosing a specific kernel via drop down list or using the last booted system as default. But where is the option to always use the first entry no matter which kernel it is? After I'd tested your module with a siduction installation with hidden boot menu, the newest kernel is ignored and always the old one is booted, the one shown in the drop down box (which you cannot avoid as it seems?).
This is so by design. The default entry is specified by name instead of number, it's safer. Imagine having this menu: Debian Debian (recovery) memtest Windows and you want Windows to be the default. If you specify the entry by number and another kernel pops in the menu like this: Debian Debian (recovery) Debian old kernel memtest Windows your default will become memtest and you'll all be like "wtf!?". Instead, specifying by name always makes sure the same entry is booted and if you want it changed, you can always do it manually. Perhaps I should introduce an option "Specify by position in the menu" (next to the list box)?
I don't want to use a specific entry number like second or third, I miss an option to just use the first and always the first entry. Imagine a distribution where new kernel versions arrive weekly to daily. In that case you need an option to always use the first entry resp. no entry (GRUB_DEFAULT=0 ?) as default. I really would appreciate such an option to keep grub's default behaviour, otherwise it takes more effort to use your module (after every kernel install!) than to edit the grub configuration by hand (once in a while). Grub behaves like that unless one uses your module once.
I understand your point and will take care of it, but the reason for such a design is that a broken default entry is worse than an outdated one (as explained above). Thanks for your feedback!
Thanks. Looking forward to it.
zypper install kcm-grub2 Loading repository data... Reading installed packages... Resolving package dependencies... Problem: nothing provides libpackagekit-qt.so.14()(64bit) needed by kcm-grub2-0.5.5-8.1.x86_64 Solution 1: do not install kcm-grub2-0.5.5-8.1.x86_64 Solution 2: break kcm-grub2 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/c] (c):
This is known, but thanks for reporting. At the time of packaging libpackagekit-qt.so was available, but due to to the rolling-release system of openSUSE Factory, it was removed at some point. Next version will address this issue.
Hi, I am on Funtoo. I get a message No valid GRUB2/BURG installation could be detected. What am i missing?
In short, this issue has been fixed in git, but is not yet released. I present you with a short explanation why this happens and a couple of solutions: Explanation: Gentoo hides the GRUB executables (grub-install, grub-mkconfig, grub-probe, grub-set-default) from the user's PATH, so technically we can't discover a GRUB installation. Solutions:
Either compile from git,
or if you really can't wait for the next release, create symlinks to the above executables visible to the user running the following commands (as root):
Quote:
ln -s /usr/sbin/grub2-install /usr/bin/grub2-install
ln -s /usr/sbin/grub2-mkconfig /usr/bin/grub2-mkconfig
ln -s /usr/sbin/grub2-probe /usr/bin/grub2-probe
ln -s /usr/sbin/grub2-set-default /usr/bin/grub2-set-default
need repo for fedora 16 grub2 paths in fedora 16 /boot/grub2 /boot/grub2/grub.cfg /etc/bash_completion.d/grub /etc/default/grub /etc/grub.d /etc/grub.d/00_header /etc/grub.d/10_linux /etc/grub.d/20_linux_xen /etc/grub.d/30_os-prober /etc/grub.d/40_custom /etc/grub.d/41_custom /etc/grub.d/90_persistent /etc/grub.d/README /etc/grub2.cfg /sbin/grub2-install /sbin/grub2-mkconfig /sbin/grub2-mkdevicemap /sbin/grub2-mknetdir /sbin/grub2-probe /sbin/grub2-reboot /sbin/grub2-set-default /sbin/grub2-setup /usr/bin/grub2-bin2h /usr/bin/grub2-editenv /usr/bin/grub2-fstest /usr/bin/grub2-kbdcomp /usr/bin/grub2-menulst2cfg /usr/bin/grub2-mkfont /usr/bin/grub2-mkimage /usr/bin/grub2-mklayout /usr/bin/grub2-mkpasswd-pbkdf2 /usr/bin/grub2-mkrelpath /usr/bin/grub2-mkrescue /usr/bin/grub2-script-check in fedora you can use su -l -c rather than sudo and beesu rather than sudo
Yea.In Fedora there is the error /bin/sh: grub-mkconfig: not found. That's probably because in Fedora this command has form: grub2-mkconfig. Need a patch
A temporary solution is to soft-link the executables in /usr/bin (not in /sbin!): Quote:
sudo ln -s /sbin/grub2-mkconfig /usr/bin/grub-mkconfig
sudo ln -s /sbin/grub2-set-default /usr/bin/grub-set-default
Also point the application to the right configuration files:
/boot/grub2/grub.cfg instead of /boot/grub/grub.cfg,
/boot/grub2/grubenv instead of /boot/grub/grubenv
The next version will include a fix for this. I am sorry for the inconvenience, but there hasn't been any testing/feedback on Fedora other than yours :)
Quote:I'am sorry for the inconvenience, but there hasn't been any testing/feedback on Fedora other than yours :)
Do not worry about it. Your application is a piece of great work. Thanks for this end tips.
Fix released in git, new version will be out in a couple of weeks max.