Setting the permissions of 444 is very curious as it only gives ONLY read ability to EVERYBODY. Not sure what you can do to modify the file later, though I can say I have never tried such a combination before. Perhaps that would create the problem that you have? For anyone using Grub 2, I suggest you have a look at my bash script Grub2Cmd you can find here:
I am happy that this procedure works for you, but I could not recommend it to others and it does not get to the heart of your problem as most users are not losing their Grub2 setup after a system update. Not that it could not happen, but it has not happened to me so far on several PC’s.
I set the same permissions as they are orininally.
I can try your script as soon as I some time to play around. The actual problem is that grub2-mkconfig doesn’t see other installed operating systems at all and removes them from boot options. This worked in one update in the mean time but now it is broken again.
If I print out grub2-mkconfig to terminal, there is only opensuse 12.2 what I use as a test environment and my productive linux is still on the other partition.
So I can only say that there is a problem, but I am not sure how your solution is working. The grub 2 script called /etc/grub.d/30_os-prober is supposed to detect other operating system on your PC. The script /etc/grub.d/10_linux detects all of the different kernel versions installed into openSUSE. The Grub 2 menu file is called /boot/grub2/grub.cfg and its permssions are set to 600, thats rw------- meaning that only root can read and write to this file. It can be changed, but when the grub.cfg file is updated by grub 2, it goes back to 600. My grub2cmd bash script asks for root permission before you can view or edit this file. Manual edits will be over written on the next kernel version update. Have a look at Grub2Cmd and perhaps it will help make sense of what you see.
If you want to have static menu entries that are not recreated on grub-mkconfig, add them to either /etc/grub.d/40_custom (you need to re-run grub2-mkconfig) or to /boot/grub2/custom.cfg (included automatically during boot as long as you used grub2-mkconfig to create grub.cfg ).
Did you actually check whether your instructions work? As already mentioned grub.conf does not normally exist.
And I’ve already seen another “grub.conf” somewhere serving another purpose, but I don’t remember on which distro and with which Grub version. It wasn’t the boot menu but a short script with some parameters to install Grub, as far as I remember.
It just appears you have openSUSE mixed up with some other distro. In openSUSE 12.2 and Grub 2, we are using /boot/grub2/grub.cfg for our grub 2 menu, our our script file is called /etc/grub.d/40_custom and nobody in their right mind would set permissions to (r–r–r–) = 444 where not even root can write to the file.
Sorry, but you hare 100% wrong. Look more carefully, and you will notice that os-prober mounts partitions “read only”.
BTW, it doesn’t intend to write to this file, it “reads” this file, provided it exists*. If you had a Fedora installation prior to version 16 and you would run os-prober under openSUSE, linux-boot-prober would run the scripts in /usr/lib/linux-boot-probes/mounted, including 40grub and 40grub2 and look for a Grub menu on the temporarily mounted partition. If there is a Legacy Grub installation on this partition, the menu would be named grub.conf (for Fedora 15 or older), and 40grub will parse this file and add boot entries for this OS in the 30_os-prober section of your /boot/grub2/grub.cfg. That’s all it does, and it has NOTHING to do with your current openSUSE installation or with openSUSE in general…
And you could disable os-prober tests if you don’t need it by using:
This is a stunning omission.
I installed opensuse 12.2 took only the defaults, I always add extras later. This is not stupidity, this is a distribution that simply does not install correctly.
Run the update and grub just hangs. Wow… Did anyone even test this 1 time.
I ran suse from version 5.x to 11.x, now I have to move to RH and I hate it.
If you have a problem to report, perhaps you should start a new message thread. I have loaded the present openSUSE version on many different computers, all were installed successfully. Our developers have decided to allow the kernel video drivers to run unimpeded on first install and only if this does not work is it suggested you use kernel load options such as nomodeset to disable Kernel Mode Setting, thus using a reduced function video driver. You have options to load the very latest driver from nVIDIA or AMD and Intel’s best is most often included in the kernel part anyway. Video companies and really all hardware companies can participate in the Linux kernel if they wish, but many do not and only a few still create a Linux driver. Linux is not Windows and does not get the same support. Any problems you are having likely relate to a hardware problem you are having. openSUSE is the best product you will ever find for free and the only left to make it better is for you to add in your own support. As always, if we can provide you with assistance, we are here to help.