I’ve installed 64-bit OpenSUSE 13.2 RC1 KDE network installation and booted. I made OpenSUSE start with a new session on login. I tried to install Oracle Java. I remember changing some files permission. Then after booting, Grub boots OpenSUSE automatically evertime.
I searched and found https://forums.opensuse.org/showthread.php/486907-How-to-restore-grub-in-OpenSuse-when-another-OS-takes-over. Running this only seems to’ve fixed the problem:
su -
grub2-mkconfig -o /boot/grub2/grub.cfg
During installation, I let it choose partition on the choosen space and used BTRFS.
I hope I hadn’t corrupted anything. How did it happen?
I noticed time is set to GMT+0, after OS loads and changes to correct time once I open Date & Time at Configure Desktop. I suspect there’s a relation, because I face the same issue with Windows 8 Trial, but it was since an another distributions Grub. I didn’t check if it still exists with OpenSUSE 13.2 Grub.
Better use YaST to set date/time and timezone.
But what have you chosen during installation? If that doesn’t stick, it might be a bug in the installer.
OTOH, the LiveCD installation is known to have problems at the moment, so this might be one of them.
I suspect there’s a relation, because I face the same issue with Windows 8 Trial, but it was since an another distributions Grub. I didn’t check if it still exists with OpenSUSE 13.2 Grub.
Grub does not know anything about timezones. And why should it? It’s only a boot loader…
IOW, no, I don’t think that’s related to Grub, neither for Windows nor for openSUSE.
The HW clock set to GMT until a user logs in there is no way to know what time zone they live in. Remember Linux is multi-user thus each user may be in a different timezone.and want to show their local time.
Well, the HW clock doesn’t know anything about time zones either. And even when a user logs in, the HW clock will still be set to what it was set to, i.e. UTC (GMT+0) preferably with Linux.
And the Linux kernel also only uses UTC internally, that’s why it is preferred to use UTC for the HW clock. This makes it easier to switch to all possible time zones: the system time doesn’t have to be changed, you just add the corresponding offset when showing the time to the user.
But the original problem in this thread was that the Grub menu was not shown any more, or am I misunderstanding this?
That GMT+0 “issue” was just mentioned later by the OP as possible explanation.
But again, it doesn’t matter to Grub to what the HW clock is set to. (Although the OP never explicitely mentioned the HW clock. That whole GMT+0 thing was a bit vague to begin with I’d say…)
This cannot be related really.
Did not mean to imply that the HW clock gets changed just the the user configuration changes the time to the local time for the user locally. This does not happen until the user logs in and it is local to each and every user.
There’s the system timezone, which you can set with YaST or in /etc/sysconfig, and there’s the user’s timezone which you can set in the user’s configuration.
The user’s setting is the same as the system’s one by default, but changing it does not influence the system’s timezone in any way.
And again, the kernel keeps all times in UTC (GMT+0), so changing the timezone does not change any time, it only changes the way the time is displayed.
I don’t think I chose wrong time during installation. Yast time was correct.
Grub2 has no write support for btrfs, and therefore cannot reset the boot entry when one is set for one boot.
Remove the file /boot/grub2/grubenv and the menu should reappear.[/QUOTE]
The command in the first post returned the menu (I hope it hadn’t corrupted anything). Should I still delete this file?
/boot/grub2/grubev:
Ok, but did you set the correct time zone during installation?
Maybe KDE didn’t pick it up correctly, i.e. it took the default GMT+0, not the system’s timezone.
I have seen something like this in older versions, about 11.x I think.
Another thing that could be is that the hardware clock was wrong. Entering the date&time config module might have synchronized to some NTP server.
Something like this can also happen if you have multiple operating systems that treat the hw clock’s time differently (UTC vs. local time).
But another time, this is absolutely totally unrelated to the boot menu.
The boot menu doesn’t care about any timezone settings and doesn’t even know about it.
At the time the boot menu is shown, there is no operating system running, and grub2 doesn’t look at any files (except for its own), so any settings in the operating system (be it Windows or Linux) is totally irrelevant.
The command in the first post returned the menu (I hope it hadn’t corrupted anything). Should I still delete this file?
No.
You would only have had to delete it if it was set to boot some predefined entry (it would have prevented to show the boot menu then), as grub2 itself cannot revert it because of missing write support for btrfs.
To further clarify: in KDE you can choose to boot some particular entry when clicking on “Restart”. And there’s the command grub2-reboot to do the same (which is used by KDE).
This writes the entry to grubenv, telling grub2 to boot this one. Grub2 sees that, and immediately boots this entry then without showing the menu.
It would reset this to the default so that on next boot you would see the menu again, but on btrfs this fails and the menu stays hidden.