Hi,
this is not as easy as it may look.
I would be very grateful for help.
Brief (not really) explanation:
I have been using openSUSE 13.2 for about… well, for long. There are also Windows XP and other Linux systems on my laptop.
I’ve also been using custom grub2 which I have tuned and compiled and installed to my disk experiencing bad ache in my butt.
To be more particular my grub draws a horizontal menu (while default one draws it vertically). Some more intelligence below.
I have an image storing my first stage bootloader, MBRloader.bin.bkp. I have also backup of my /boot/grub/ directory containing custom compiled modules and cfg. My /boot is /dev/sda9 physically.
After Windows reinstalls I used to restore MBRloader from the image file, like *dd if=MBRloader.bin.bkp of=/dev/sda bs=446 count=1 *and this worked. My own grub would be restored after this action every time.
Okay, yesterday I performed a massive update on my openSUSE 13.2 including, I assume, some kernel and/or grub patches. After reboot there was “wrong” grub, it wasn’t really new, it was just loaded from /dev/sda9/grub2, not /dev/sda9/grub. How could I see it, there was another theme in the grub2 folder, it stayed there since the time I set my custom grub over the basic one.
The first action I took was restoring 1-stage loader image with dd. This won’t work.
Seeing no profit from my previous action I just… er… copied /dev/sda9/grub over /dev/sda9/grub2 (where the updated grub was trying to work from). It crashed to “grub rescue” console with the message “blah blah ‘grub_isprint’ not found” or something.
I swore and booted from an openSUSE Leap 42.1 livecd and did *grub2-install --boot-directory=/dev/sda9 /dev/sda.
*After that it stopped working at all with “no symbol table”. When I press “any key” it says I have no bootable devices.
Well, what can I do?
At least I wan’t to get ***any ***grub working to be able to get ***mine ***one working.
Thank you. I like openSUSE, but that update was a total disaster for my computer. No sarcasm.
Why do you need custom grub for it? Just set your theme in /etc/default/grub and it will be used in all subsequent menu updates.
copied /dev/sda9/grub over /dev/sda9/grub2 (where the updated grub was trying to work from). It crashed to “grub rescue” console with the message “blah blah ‘grub_isprint’ not found” or something.
That is not going to work. GRUB modules must match GRUB first stage loader. You are lucky it bailed out that early and not crashed later due to incompatible structure offsets, variable types or sizes etc.
That is plain wrong. --boot-directory is directory, not device. I am surprised it worked; something must be seriously wrong.
Well, what can I do?
Any reason you cannot use search? … boot from live media, mount your system partition, chroot and run grub-install. Like
mount /dev/your-root /mnt
mount /dev/your-boot /mnt
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /dev /mnt/dev
chroot /mnt
grub2-install /dev/your-MBR
Adjust device names as needed. If you prefer, use your own grub-install instead.
from this information i assume that you run a BIOS based machine (no UEFI or at least an UEFI switched to CSM/Legacy boot) and that your drive “sda” uses a MBR partition scheme (no GPT). If this is correct, then you could try to boot the rescue system from the openSUSE LEAP 42.1 installation DVD chroot to your system on “sdax” and re-install the standard GRUB2.
If you are using UEFI, secureboot, GPT, … some more information on your configuration is needed to advice you any further.
That is not going to work. GRUB modules must match GRUB first stage loader. You are lucky it bailed out that early and not crashed later due to incompatible structure offsets, variable types or sizes etc.
Okay, can you tell me then why it didn’t work when I restored both MBR-stage loader and old files in /boot/grub?
That is plain wrong. --boot-directory is directory, not device. I am surprised it worked; something must be seriously wrong.
Sure - my typing. –boot-directory=/mnt/sda9 of course it was.
Any reason you cannot use search? … boot from live media, mount your system partition, chroot and run grub-install. Like
mount /dev/your-root /mnt
mount /dev/your-boot /mnt
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /dev /mnt/dev
chroot /mnt
grub2-install /dev/your-MBR
Adjust device names as needed. If you prefer, use your own grub-install instead.
Yeah… I don’t get it right… what purpose is in chrooting? Why can’t I just boot from livecd and run grub-install with the right boot-directory and device? What exactly is missed in that case?
chroot is needed because if you boot from a live media that is your system not what is on the HD so you need to chroot to move the focus to the HD partitions rather then the live media partitions.
It is critically important top know if EFI or legacy booting. But the chroot instructions should work for either.
What did you expect to happen to your custom grub when grub got updated. You did keep a copy of the changes right that you can apply to the new grub code?
Okay… I have to read more about this.
How can I know this for sure?
I didn’t expect grub to update, that’s it. It’s nothing special to apply, there is only one variable to be changed… But the whole thing… wasn’t mucheasy for me last time.
Things get updates. What more can I say. You have to expect and plan for it if you leave the beaten path
Well if you don’t believe us then you will find loads of stuff on chroot. It is a very common tool in Linux and Unix
When you boot from aDVD or a USB you are not running from your normal environment on the HD. chroot allows you to change operation to the partition on the HD so Yast or other tools work in the HD environment not the USB/DVD environment.
*Could you point to the patch you are using? Yes, I think default engine does not support this placement.
what purpose is in chrooting? Why can’t I just boot from livecd and run grub-install with the right boot-directory and device? What exactly is missed in that case?
This simplifies instructions. grub-install runs in native environment, so it knows where to find /boot, its files to install and /etc/default/grub; the only variable is install location. Most of this can be set using grub-install command line, but if you know how to do it you probably do not need to ask in the first place. Also at least one parameter taken from /etc/default/grub (GRUB_ENABLE_CRYPTODISK) currently cannot be set on command like atnall.
Then it often makes sense to also run grub-mkconfig to be sure configuration is consistent and this currently does not support off-root usage at all.
Finally I usually recommend to simply use “update-bootloader” which is the tool called by openSUSE every time bootloader update is needed; this tools knows what bootloader and its location was configured in YaST and automatically calls grub-install with the right parameters. It again works in native environment only.
Could you point to the patch you are using? Yes, I think default engine does not support this placement.
There isn’t any patch. I had modyfied the *grub-2.00/grub-core/gfxmenu/**gui_list.c *changing the statement in list_get_minimal_size
int num_items = 3
to
int num_items = 1
There was four similar looking pics in the theme’s directory, containing four OS logos and only one of them colored. The loader menu was set to fit the pic size exactly and show only one entry at a time… It only looked like it was a horizontal menu, still this worked and looked cool and I hadn’t to bother myself with burg that refused to work.
Now I know why my backup attempts did not succeed. I had been restoring stage1 and stage2, but there was also stage1.5 which I had not backuped and restored respectively.
Now I’m not sure which utility should I use and what way to get the particular core.img (stage1.5 image) which I’m sure is old and write it down to the *“sectors between the MBR and the first partition”. *I definitely know not where they are to do this manually and I see that grub-install generates stage1&stage1.5 itself, so probably it won’t accept something like *–core=./core.img. *If only I knew what does it generates these from…
Yup, here it goes.
at installation time, it is generated from diskboot.img and configured to load the stage 2 by its file path.
I’ve restored the right state of my GRUB! copied old core.img (stage 1.5 loader) to my boot sector (that is situated next to first 512 bytes) and it won’t crash my whole disk but restored the right state of my bootloader.
Now I know that storing only first 446 bytes is not enough;)
*There is absolutely no need or reason to do it. GRUB2 can always be reinstalled and this reinstallation will keep boot configuration (which is in grub.cfg which is not touched by grub-install). You make things far more complicated than they are.