Incomplete /boot/grub directory leading to boot problems
Hi, I have a virtual server that's been running since 13.2, now at 15.1 . At some point I started having boot problems requiring me to log in to the provider's virtual console and manually press enter a couple of times. The first type of problems wa that I only saw error: file `/boot/grub/fonts/unicode.pf2' not found. and the boot process hung (unless I pressed enter a couple of times). So I copied /usr/share/grub2/unicode.pf2 to /boot/grub2/fonts ( the directory did not exist ), regenerated grub.cfg using grub2-mkconfig -o /boot/grub2/grub.cfg and rebooted. I was next greeted by error: file `/boot/grub/i386-pc/all_video.mod' not found. which indeed, did not exist. I checked another virtual server I have running ( 15.2 this time ) and working properly and it has the following additional entries in /boot/grub device.map i386-pc locale I could start copying them over, but I guess I'm missing some sort of fundamental operation that was supposed to happen and also potential updates will not happen. I checked, and these files are installed by packages: $ rpm -qf i386-pc locale device.map file /boot/grub2/i386-pc is not owned by any package file /boot/grub2/locale is not owned by any package file /boot/grub2/device.map is not owned by any package With a recent Leap 15.1 upgrade all the grub2 packages were reinstalled, so these were not brought in by scriptlets. I have no idea where to look next right now. Does anyone have any suggestion about how I can get my /boot/grub directory in working order? Thanks, Robert
On 6/27/21 4:39 PM, Robert Munteanu wrote:
The first type of problems wa that I only saw
error: file `/boot/grub/fonts/unicode.pf2' not found.
and the boot process hung (unless I pressed enter a couple of times).
I will make a wild guess. At some time in the past you were having boot problems, so you used rescue media to "fix" it. But the rescue media appears to have been Debian based (or similar). So you have a mixed up system with some of the boot files coming from openSUSE and some of them coming from Debian. Hint: openSUSE uses "/boot/grub2" while Debian and Ubuntu use "/boot/grub". I suggest using openSUSE media to rescue. The Tumbleweed rescue CD would be fine. Or use the rescue system on your 15.1 install media. If you can use the option to boot a system from disk, that would get you in. And, from there, use Yast bootloader to reinstall booting.
Hi Neil, On Sun, 2021-06-27 at 19:38 -0500, Neil Rickert wrote:
On 6/27/21 4:39 PM, Robert Munteanu wrote:
The first type of problems wa that I only saw
error: file `/boot/grub/fonts/unicode.pf2' not found.
and the boot process hung (unless I pressed enter a couple of times).
I will make a wild guess.
At some time in the past you were having boot problems, so you used rescue media to "fix" it. But the rescue media appears to have been Debian based (or similar). So you have a mixed up system with some of the boot files coming from openSUSE and some of them coming from Debian.
Hint: openSUSE uses "/boot/grub2" while Debian and Ubuntu use "/boot/grub".
That may very well be, the details are hazy since I let this linger for so long (my bad).
I suggest using openSUSE media to rescue. The Tumbleweed rescue CD would be fine. Or use the rescue system on your 15.1 install media. If you can use the option to boot a system from disk, that would get you in. And, from there, use Yast bootloader to reinstall booting.
I can still boot, so I will run `yast bootloader` and reboot in the next window of downtime that I get. Hopefully that will solve it. Thank you, Robert
On 28/06/2021 08.59, Robert Munteanu wrote: ...
I can still boot, so I will run `yast bootloader` and reboot in the next window of downtime that I get. Hopefully that will solve it.
Trick: once in the yast bootloader module, just change the timeout 1 second up or down. This forces yast to write "everything". Maybe also writes those files. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 28/06/2021 22:28, Carlos E. R. wrote:
On 28/06/2021 08.59, Robert Munteanu wrote:
...
I can still boot, so I will run `yast bootloader` and reboot in the next window of downtime that I get. Hopefully that will solve it.
Trick: once in the yast bootloader module, just change the timeout 1 second up or down. This forces yast to write "everything". Maybe also writes those files.
At least in Leap 15.2, I find that simply loading the Yast bootloader module and clicking "OK" is sufficient to trigger such a write. That is, it isn't necessary to change the timeout or whatever. -- Robin K Wellington "Harbour City" New Zealand
On 28/06/2021 13.02, Robin Klitscher wrote:
On 28/06/2021 22:28, Carlos E. R. wrote:
On 28/06/2021 08.59, Robert Munteanu wrote:
...
I can still boot, so I will run `yast bootloader` and reboot in the next window of downtime that I get. Hopefully that will solve it.
Trick: once in the yast bootloader module, just change the timeout 1 second up or down. This forces yast to write "everything". Maybe also writes those files.
At least in Leap 15.2, I find that simply loading the Yast bootloader module and clicking "OK" is sufficient to trigger such a write. That is, it isn't necessary to change the timeout or whatever.
Ah...!? Interesting. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On Mon, 2021-06-28 at 14:44 +0200, Carlos E. R. wrote:
On 28/06/2021 13.02, Robin Klitscher wrote:
On 28/06/2021 22:28, Carlos E. R. wrote:
On 28/06/2021 08.59, Robert Munteanu wrote:
...
I can still boot, so I will run `yast bootloader` and reboot in the next window of downtime that I get. Hopefully that will solve it.
Trick: once in the yast bootloader module, just change the timeout 1 second up or down. This forces yast to write "everything". Maybe also writes those files.
At least in Leap 15.2, I find that simply loading the Yast bootloader module and clicking "OK" is sufficient to trigger such a write. That is, it isn't necessary to change the timeout or whatever.
Ah...!? Interesting.
I ran the yast bootloader module ( prompted me to install kexec-tools, so it was probably never executed before ). However, it still did not add the missing files to /boot/grub2, even with a dummy timeout change. Regarding the /boot/grub → grub2 symlink, I have it on two other VMs running with the same provider, so it's not an artifact of a rescue CD, but probably something specific to the VM images used by the provider (Linode). Thanks, Robert
participants (4)
-
Carlos E. R. -
Neil Rickert -
Robert Munteanu -
Robin Klitscher