Home_greyopenFATE - openSUSE feature tracking > #310856
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

don't remove custom grub entries

Feature state



from https://bugzilla.novell.com/show_bug.cgi?id=648565 (written by Nico Gruber):

Applying a kernel update will delete custom grub entries with this kernel and add a default one

Steps to Reproduce:

  1. duplicate a grub entry and add some parameter to the kernel command line
  2. update kernel, e.g. by doing auto-update with one of the provided kernel updates

Actual Results: the created custom entry in grub which uses the outdated kernel which has now been updated is removed, a default entry is created, e.g. "Desktop -- openSUSE 11.3 -"

Expected Results: all (custom) entries with the updated kernel should be changed in order to boot the new one - without changing either the name of the entry, nor any parameters

Custom entries can be there for various reasons, and I need them on nearly every system I use (see "use cases").

Please change perl-bootloader as described in "Expected Results" above. It should not remove or change any entry in menu.lst, except filename changes of kernel and initrd at a kernel update.

User benefit:

Because custom bootloader entries are used quite often, and it's very annoying if you have to re-add them at every kernel update.


  • Bug report (648565 )


  • Servers with RAID: fallback entry to boot from the second disk
  • abusing ;-) a boot parameter like x11failsave to switch between two xorg.conf files without hacking the initscript


icons/user_comment.png L. M. wrote: (7 years ago)

Why not enableing the currently unlimited multiversion feature in /etc/zypp/zypp.conf ?

Doesn't that already cover the issue?

icons/user_comment.png C. B. wrote: (7 years ago)

No, that's something different. multiversion adds support for different kernels.

However, what I'd like to have is support for/non-destruction of multiple boot menu entries for the same kernel.

icons/user_comment.png R. U. wrote: (7 years ago)

I hope openSUSE-11.4 comes with the new supported grub2. Grub1 is a no more maintained version upstream. Look at Debian or Ubuntu where this feature is implemented via /etc/grub.d/40_custom.

icons/user_comment.png B. C. wrote: (7 years ago)

Hi Folks,
I too would like my grub menu to be left untouched after a kernel update via the automatic updater. I have about 5 OSes on my desktop PC, so I make a grub menu that is very clean, otherwise things look untidy and can get lost.
For suse, I would just like to see "openSUSE 11.3" in the menu as the title of my suse installation. For me, the kernel version is unnecessary information. However, for others I am sure it is useful (those you use different kernels in the same installation, such as kernel developers or musicians who use the RT kernel). Thus I suggest that this feature be introduced as an option, configurable in /etc/sysconfig Editor in YaST under System | Kernel.
Perhaps the default behaviour should be to get Grub to point to a link which then points to the required kernel with the title in the Grub menu being invarient (good for general desktop use). Those wanting version numbers, kernel types etc. can select for a direct link from the Grub menu in /etc/sysconfig Editor (good for specialists).
In addition to this, I'd love it if Suse were smarter in detecting non-linux OSes. For example, if it could add Windows XP Pro to the Grub menu on installation as "Windows XP Pro" rather then just "Windows", I would like that. This may be achievable by reading the volume label of the windows partition (if it were named after the version of windows installed), or by looking for certain files particular to windows versions (if possible). Also, I now keep a separate partition that acts as a swap partition for windows. It is given the drive letter E: and just contains the file "pagefile.sys". However, suse identifies this as a second windows installation (when it is not) and also adds it to the Grub menu on installation.
Finally, on disks which have lots of partitions, is there any reason why the installer should write the Grub code to the extended partition that contains all the logical partitions? I sometimes see this selected but I always change the destination to MBR. Once I left it selected to install the Grub code on the extended partition during an installation and it messed things up good and proper.

Thanks for your time,

icons/user_comment.png C. B. wrote: (7 years ago)

Not changing the bootloader config should be possible with LOADER_TYPE="none" in /etc/sysconfig/bootloader. You can then use the /boot/vmlinuz and /boot/initrd symlinks in your grub configuration.

Regarding the other things you mentioned: You have lots of good ideas, but mixing them up in this feature request makes it nearly impossible to handle them. Please open separate feature requests - one per feature.

Last change: 7 years ago
Loading tags...
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint