Looking for Grub and Windows bootloader in all partitions.

[please_try_again]

http://www.unixversal.com/linux/openSUSE/findgrub-4.4.1.tgz

[jdmcdaniel3]

Your latest version of findgrub is looking good to me.




Thank You,

[please_try_again]

Hi James,

I think version 4.4 did already work for you because you have Grub2 in MBR. In this case, the core is embedded, and we can read the partition UUID of the next stage from the uncompressed core. See the grubcore test script in post #225.

The bug version 4.4.1 addresses (and I hope fixes, but @arvidjaar will tell us) affects situations where Grub2 1.99 or 2.00 (but not 1.98) is installed on a disk other than the first one but NOT in mbr. In this case, we don't have info about the partition in the boot sector (and the core is not embedded) but only a 1byte value which says if the next stage is on the same disk or on another one. If this value is 128 (0x80), the boot loader is looking for the next stage on the same disk and NOT on the first disk (I guess it was the bug here). If it is 129 (0x81), it will be hd1, etc ... (and then we have to look in device.map if available to find out which disk device that BIOS drive actually matches).

[please_try_again]

The bug version 4.4.1 addresses (and I hope fixes, but @arvidjaar will tell us) affects situations where Grub2 1.99 or 2.00 (but not 1.98) is installed on a disk other than the first one but NOT in mbr.

And this is only possible if /boot is on the same disk, because you can not cross-disk install with Grub2 >= 1.99 (unlike with Legacy Grub):

Example (with OpenSUSE /boot/grub2 in sda9):

# grub2-install --force /dev/sdb12
/usr/sbin/grub2-bios-setup: warning: File system `ext2' doesn't support embedding.
/usr/sbin/grub2-bios-setup: error: embedding is not possible, but this is required for cross-disk install.

[jdmcdaniel3]

Hi James,

I think version 4.4 did already work for you because you have Grub2 in MBR. In this case, the core is embedded, and we can read the partition UUID of the next stage from the uncompressed core. See the grubcore test script in post #225.

The bug version 4.4.1 addresses (and I hope fixes, but @arvidjaar will tell us) affects situations where Grub2 1.99 or 2.00 (but not 1.98) is installed on a disk other than the first one but NOT in mbr. In this case, we don't have info about the partition in the boot sector (and the core is not embedded) but only a 1byte value which says if the next stage is on the same disk or on another one. If this value is 128 (0x80), the boot loader is looking for the next stage on the same disk and NOT on the first disk (I guess it was the bug here). If it is 129 (0x81), it will be hd1, etc ... (and then we have to look in device.map if available to find out which disk device that BIOS drive actually matches).

I have been reading your message exchanges here with great interest and happy you have found someone else willing to help with findgrub. I wonder if you decided anything about the 32 bit verses 64 bit issue with the Grub 2 bootloader? In the several openSUSE 12.2 installs I have made, the installer seems to not install generic boot code in the MBR, at least for me. I have on purpose had to aim the main Grub 2 bootloader into the MBR. If you already have generic boot code there as is the case for most sda drives you are OK, but not for drives that contain no boot code as they have failed to boot for me when Grub 2 is loaded into the root partition. Have you had an opportunity to witness this behavior by chance? Anyway, I love to see and hear the further improvements for findgrub.

Thank You,

[please_try_again]

I wonder if you decided anything about the 32 bit verses 64 bit issue with the Grub 2 bootloader? In the several openSUSE 12.2 installs I have made, the installer seems to not install generic boot code in the MBR, at least for me.

What happens if you install a 32bit version (and accept setup defaults) in a new virtual machine ( = with a totally blank virtual disk)? My guess is that it would "traditionally" write a generic boot code - despite the fact that it makes more sense to put the Grub boot loader there in such a case.

[jdmcdaniel3]

What happens if you install a 32bit version (and accept setup defaults) in a new virtual machine ( = with a totally blank virtual disk)? My guess is that it would "traditionally" write a generic boot code - despite the fact that it makes more sense to put the Grub boot loader there in such a case.

I will give that a try. Why 32 bit as I always use 64?

Thank You,

[please_try_again]

I will give that a try. Why 32 bit as I always use 64?

I don't know. You did mention the 32 bit version:

I wonder if you decided anything about the 32 bit verses 64 bit issue with the Grub 2 bootloader?

I'm not aware of this issue. But generally speaking, why installing a 64bit OS in a virtual machine? The machine instructions are twice as big. Thus - in theory - you would need twice as much memory to achieve the same.

[jdmcdaniel3]

I don't know. You did mention the 32 bit version:



I'm not aware of this issue. But generally speaking, why installing a 64bit OS in a virtual machine? The machine instructions are twice as big. Thus - in theory - you would need twice as much memory to achieve the same.

Well, I have 16 GB of memory and so it is no worry to me due to memory usage. The question about 32/64 & Grub 2 is its boot loader and the ability to deal with 32 or 64 bit OS'. Is there any different between a 32 bit and 64 bit Grub 2 install of Grub 2 and could Grub 2 from a 32 bit install, run a 64 Bit OS that os-prober had found?

Thank You,

[please_try_again]

Is there any different between a 32 bit and 64 bit Grub 2 install of Grub 2 ?

I would say no, at least not from a user point of view.

and could Grub 2 from a 32 bit install, run a 64 Bit OS that os-prober had found?

I would guess so, but I might be wrong because I never tried. Loading a 64bit kernel from a 32bit Grub might indeed not work (but I'm not sure). The other way should be OK, AFAIK. In the worst case, chainloading another Grub should always work.