Hi I am Rupesh from India and I have an old PC which is MBR not UEFI and previously I have installed windows 8 after that I have installed open suse leap 15.0. Today due to some problems I have re installed windows without deleting Linux partitions. I want to re install grub2 bootloader but failed to mount boot partition properly in rescue mode.
I have created an USB installation media in windows using rusfs tool and while creating I have chosen dd mode. After that I have booted into rescue mode and issued the following commands
mount /dev/sda5 /mnt
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /MBT/sys
chroot /mnt
mount -a
After that I have issued the following command
grub2-mkconfig -o /boot/grub2/grub.cfg
after issuing the above command I am getting error as
" unable to access the file /boot/grub2/grub.cfg "
During the previous installation of Linux I have created first partition of hard disk ie., /dev/sda1 to boot partition with ext3 file system type and 5th partition to root ie., / with XFS file system type.
In the rescue mode when I issue the command ls in /boot directory I am able to see only one entry called grub2 and nothing else.
Please suggest how to re install grub2 boot loader properly and make my system to work.
You also have not indicated where grub is installed. If you are booting from the MBR, then you will need to reinstall. If you have a separate “/boot” partition, then maybe it wasn’t mounted. You should see your kernels in “/boot” (after the “chroot”).
It’s a bit hard to tell you what to do next, because we don’t have enough information.
Please post here using code tags (#] above the input window) the content of /etc/fstab, output from ‘ls -l /boot/g*’, output from lsblk, and output from ‘parted -l’.
I disagree with that. The “mount -a” from within the chroot environment should mount other needed partitions. This includes “/boot” if there is a separate partition for that. It includes “/boot/efi” on UEFI systems. And it is the easiest way to mount the “btrfs” subvolumes if using “btrfs”.
Fair enough. That was my guess, and why I asked if it was a typo.
As I already said I have created a separate boot partition and installed grub to boot partition.
Yes. But you also said: “In the rescue mode when I issue the command ls in /boot directory I am able to see only one entry called grub2 and nothing else.” And that suggests something is wrong. The “/boot” directory should have at least one kernel (“vmlinuz*”) and a corresponding “initrd*” file.
Be sure to check that after the “chroot” and after the “mount -a”. Otherwise you might be listing only the “/boot” of the rescue media.
If everything is okay at that point, then easiest might be to just run yast (it will be the command line version) and it should setup the bootloader for you. When in yast bootloader, change something, such as the timeout, so that it knows to rewrite the boot sector. And that should do everything needed. Be sure to do that in the chroot environment and after that “mount -a”.
Thanks for your suggestions and the issue has been resolved.
At first I booted into rescue mode and after that I chroot into root partition and after I have issued the command mount -a.
Finally I ran yast2 from console and after that I have launched bootloader and selected ok.
Yast has created initrd and other necessary file’s to boot properly.
In the bootloader of yast I found two entries they are “boot from mbr” and boot from boot partition. By default the two entries are selected. What is the need of these two entries at the time which are mutually exclusive.
Luckily I have selected open suse which has yast but for others who have selected other Linux os which do not have yast their life may be horrible.
In the bootloader of yast I found two entries they are “boot from mbr” and boot from boot partition. By default the two entries are selected. What is the need of these two entries at the time which are mutually exclusive.
You don’t need both. But I guess they are not mutually exclusive. There can be more than one way to boot a computer, although in practice only one of those will be used.
Luckily I have selected open suse which has yast but for others who have selected other Linux os which do not have yast their life may be horrible.
For other systems, you need something like (in chroot mode):
On some systems, it is “grub” rather that “grub2” in every place there. The “/dev/sda” should be changed to where you want to boot from, and if it is not the MBR, you will also need a “–force” option. And the command to build the “initrd” might not be “mkinitrd”.
With MBR booting you can have the boot code in the MBR and the the boot partition it does no harm but if grub boot is in the MBR then that is the boot method used. If you have generic boot code in MBR then the partition with the boot flag will be the OS that boots and you do need the grub code in the boot partition of that partition. With EFI booting it is simpler since there is only one place for boot code, the EFI boot partition.
It could be added, that “booting from MBR” resulted in problems with certain updates of windoze.
The OP wrote that he had a dual boot with windoze 8.
The Leap 15.0 installer DVD has “booting from MBR” as the default for non-UEFI systems, which in my view isn’t a good choice for private PCs (in contrast to servers) where dual-booting with windoze will be rather common. This default for non-UEFI systems may just lead to the same kind of problems discussed on this forum years ago for similar reasons.
Booting from a partition, or UEFI booting can also have problems with some Windows updates.
On legacy BIOS system, I make sure that the Windows boot partition is the active partition before applying any Windows updates. I can switch it back to openSUSE as active partition afterwards. On a UEFI box, I make sure that Windows in the first in boot order for the UEFI firmware, before updating Windows. And then I put it back to openSUSE as first in boot order after Windows has updated. Without those precautions, some Windows updates fail.
I have had it happen twice with Windows 8.1 (UEFI booting).
I installed the update, and rebooted as Windows requires. And Windows then told me that the update failed, and backed it out. So I switched so that Windows is the first UEFI boot choice for the firmware, reinstalled, and this time it worked.
