On 9/16/2011 10:03 AM, Constant Brouerius van Nidek wrote:
Is there an easy method to find where Grub is located? I have working Grub which defaults to a second grub with my actual system. This system is situated on my third drive on /sdc5. The other working opensuse, a pure LXDE is situated on /sdb3 and is booted via the first Grub. Would like to know where the grub hides.
The question doesn't mean anything. A) "grub" is not a single thing that only exists in any single place. It's made up of a few different parts which exist in a few different places. A) Different copies and different versions of Grub may exist in any number of places at the same time. I'm going to assume that you can find the stage2 and related files by looking in /boot easy enough, and that you want to know which of the possibly many different MBR's and grub stage1's are the ones your computer actually uses during boot. No one can know that but you or someone you hire to come look at your machine. There are two ways to figure it out. The surest way is to walk through the boot process the same way the computer does. The easier but less guaranteed way is to look at the various grub config files from your running system, but since you have multile running systems each with their own different grub config files... maybe theyr're all right, maybe only one is right but no way to know which one, maybe no single set are 100% right. When your machine boots up, your motherboard bios and/or one of your add-in cards own bios's selects a drive a tries to boot from it. We can not know what your motherboard bios will do. That is controlled by however the manufacturer programmed the bios to behave, and somewhat adjustable by various settings you may set in the bios. Go into your bios setup. Find the boot device priority list. The MBR on the first device in the list that looks like a hard drive is the first place to look. * Maybe the MBR on that device holds a copy of some version of grub. * Maybe it holds a generic MBR that only knows how to look for a partition marked bootable and jump there. * Maybe it holds nothing * If it holds nothing then most likely the bios abandons that device and tries the next device in the list. * If there was a generic mbr but no partition was marked bootable, the bios abandons that device and tries the next one on the list. * If the bootable partition didn't have a valid bootloader, the bios abandons that device and tries the next device on the list. So, you might have any of the following: * A working copy of some version of grub stage1 loader right in the mbr of the first device in the boot priority list. * A working generic mbr on the first device, and a partition marked bootable, and a working copy of grub stage1 on that partition. No one else can know any of that but you, or someone who looks at your machine directly. The other less certain thing you can do is look at a few files in your running system. What are the contents of /boot/grub/device.map /etc/grub.conf /boot/grub/menu.lst device.map defines "grub devices" ie, it defines what "hd0" and/or hd1 & hd2 etc actually means. grub.conf then uses "hd0" or hd0,1 or hd2,0 etc in any number of possible ways to do two things: 1 - write the stage1 somewhere 2 - tell the stage1 where to find stage2 menu.lst is then read by stage2 during boot, and menu.lst also uses "hd0" not /dev/something to find kernel and initrd and any other files it itself loads like the graphical boot message file or a background pixmap image etc... When you see /dev/something in menu.lst, that is just a meaningless string to grub, grub just passes it to the kernel as commandline arguments, and the kernel understands it. All kinds of weird things are possible. device.map might actually point to one of the other drives that isn't the one you are currently running on, and so none of the contents of the other files matters. Or, device.map may point at the current running drive, but the grub that actually booted may not have been written by _this_ os and so this device.map doesn't mean anything, but the rest of the files might still matter because maybe the other os's device.map points at this drives satge2 and menu.lst files. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org