[opensuse] Grub, where to find?
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. -- Linux User 183145 using LXDE and KDE4 on a Pentium IV , powered by openSUSE 11.4 (i586) Kernel: 3.1.0-rc6-1-desktop LXDE WM & KDE Development Platform: 4.7.1 (4.7.1) 20:51pm up 0:06, 2 users, load average: 3.90, 4.40, 2.26 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 09/16/2011 10:03 AM, Constant 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.
/boot/grub/menu.lst is the file you would generally edit to change grub menus -- Michael S. Dunsavage -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
It would appear that on Sep 16, Michael S. Dunsavage did say:
On 09/16/2011 10:03 AM, Constant 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.
/boot/grub/menu.lst
is the file you would generally edit to change grub menus
Yes, but I think van Nidek is wanting to find which partition the rest of
the particular grub that is "installed" to the MBR of the boot drive, which
depending on his bios settings is likely /dev/sda...
Assuming it's not grub2 (in which case what he would find is a
/boot/grub/grub.cfg.) Though most likely the file he is looking for is, as
you say, /boot/grub/menu.lst on some partition other than /dev/sdb3 or
/dev/sdc5... {though I have a vague recollection of some Linux I used to use
installing the menu list to /boot/grub/grub.conf}
The trick is finding which partition has the files that his initial grub is
using. If it were me, I'd use the grub shell to "find" those files.
Assuming that his "system" on /dev/sdc5 has grub legacy and NOT grub2
he should be able to start the grub shell at a root command prompt with
# grub
which should get him a grub prompt which looks like:
grub>
at which he should type:
find /boot/grub/menu.lst
Since the OP doesn't seem to know about the grub shell's find command, I'm
going to risk insulting him by mentioning that that is menu.lst with a
lower case L (NOT a number one) I know it took me a while to figure that
out way back when...
The above find command will find instances of that file on every partition
with a filesystem that grub can read. (Note: I think some versions of grub
don't do ext4)
It will list those partitions grub style where /dev/sdc5
will most likely be (hd2,4) (grub legacy counts both drives and partitions
starting with 0 so that "2" would be the third drive, and that "4" would be
the 5th partition)
I Note however that I've seen multi-drive setups where between the bios
order and what not different Linux installed to the same PC listed
different drives on the same computer as /dev/sda so it's possible though
the grub shell installed to all of them used (hd0,0) for the first
partition of the same first drive.
If there is any confusion as to which is which, I would insert a temporary
file into the /boot/grub directory of /dev/sdc5 named "ThisIsSdc5" And
perhaps add one named "ThisIsSdb3" into the /boot/grub directory on
/dev/sdb3
Then, at the grub prompt he can:
find /boot/grub/menu.lst
find /boot/grub/grub.conf
find /boot/grub/grub.cfg
making a note of the listed partitions and then do:
find /boot/grub/ThisIsSdc5
find /boot/grub/ThisIsSdb3
And use the partitions those two commands list to ensure he knows which
of the previous are in his currently active Linux filesystems.
(That technique sure helped me figure out grub's partition naming
convention way back when...)
Oh yeah, to exit the grub shell type "quit" ;-)
And finally if he does have grub2, there is some simular functionality in
it. BUT it's sooo different that somebody else would have to explain it
because grub2 still confuses me.
Hope this helps!
--
| ~^~ ~^~
| <*> <*> Joe (theWordy) Philbrook
| ^ J(tWdy)P
| \___/ <
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
participants (4)
-
Brian K. White -
Constant Brouerius van Nidek -
Joe(theWordy)Philbrook -
Michael S. Dunsavage