GRUB and SATA Entry

Ok I'm feeling really smart right now!

I just got my first sata hd installed and partitioned(250GB seagate 28 partitions) and installed mepis on partition sda5.

My /boot/grub/menu.lst is contained in hdc1's mandriva x64 partition.

I am trying to use a grub entry like this:
title Mepis
root (sda5) <-------what is the proper syntax for this line????I even tried /dev/sda5!
chainloader +1

while trying to boot I keep getting
error 23:error parsing number.

Help with the sata partition syntax in the grub v0.97 would be great.

Thanks

Try (hd0,4)
Grub basically only knows disks - hd? or fd?. Zero based, as is the partition number.
All in the manual.

Try (hd0,4) Grub basically only knows disks - hd? or fd?. Zero based, as is the partition number.

Ahhhh.
hd0 is my burner and I already have an hdb,hdc,and hdd ide drives.

I do have a board that has 8 sata plugins(msi k8n neo4 plat).so maybe I need to plug my 1 sata hd in the #5 plug and we'll call it (hd4) to GRUB.

BTW. I have read the manual many times and the only vague mention of sata is the letter s when the manual spoke of a serial line connection from box to box.

Thanks

Ooops - sorry, missed the reference to hdc1 in the first post.

Yep, you'll need to find where the SATA is - generally all the (E)IDE will come in one block (say hd0-hd3), and the SATA as another (say hd4-hd5). Nothing guarenteed tho' - SATA may be at hd0-hd1.

As I said, Grub couldn't care less that it's SATA - still just hdn.
It will also ignore the burner.

Originally Posted by PipeDreams root (sda5) <-------what is the proper syntax for this line????I even tried /dev/sda5!

check /boot/grub/device.map file that grub created when you installed it.
it might look something like this:

(hd0)  /dev/sda
(fd0)  /dev/fd0

that should show you what drive to point grub to.

then like syg00 said: the partion numbers are zero based. so root for that entry might be:

root (hd0,4)

Originally Posted by PipeDreams I do have a board that has 8 sata plugins(msi k8n neo4 plat).so maybe I need to plug my 1 sata hd in the #5 plug and we'll call it (hd4) to GRUB.

Don't really think it works that way. Most motherboards need sata drives plugged in starting with #0.

This is how I boot from a sata drive.

title Kernel de Peto
root (hd0,1)
kernel /boot/vmlinuz-2.6.16.2 ro root=/dev/sda2 quiet
initrd /boot/initrd-2.6.16.2.img


my sata drive now is /dev/sda2 it used to be /dev/hde2 before I recompiled the kernel. Hope this helps.

regards,

Just to reiterate: grub ignores all non-disk devices when it's enumerating your drives. It also refers to them as hdN whether they're ATA, SATA, SCSI, whatever. When handing out the actual numbers it defers to the BIOS. It wouldn't matter where the actual drives were plugged in only the order the BIOS detected them in. Basically, if you've only got the one drive then it'll be hd0, again regardless of whether it's ATA, SATA, SCSI, whatever. It's starts getting complicated from there which is why I personally tend to prefer single drive arrangements.

Another little tip, you only use chainloader when you want grub to pass boot control over to another bootloader. For instance, the Windows bootloader or FreeBSDs. You shouldn't need it if you're using grub to boot Linux.

Spot on LSD, you're absolutely correct. If I could elaborate just a bit...

GRUB operates at a time when the kernel is not loaded, and the system knows nothing about things like /dev/hda or /dev/sda, etc. In fact, GRUB's job is to locate the second-stage bootloader(s), and to load the kernel, after which the system does know about system devices and the filesystems on them. Until then, all that GRUB has to go on is what is detected by the BIOS, which is very low-level information. The drive marked in the BIOS as the first boot hard drive will be received by GRUB as (hd0). The first partition on that drive will be (hd0,0), the second (hd0,1), etc. If the first boot drive is a SATA drive, it will most probably be detected as /dev/sda after the kernel is loaded.

That's the case on my computer, which has a grub entry for the boot partition as root (hd0,0) (first partition on first boot drive in the BIOS) and an entry for the partition holding the 'root' filesystem as root=/dev/sda6. The first reference (hd0,0) is GRUB's way of interpreting what the BIOS tells it, while the second reference (/dev/sda6) is the kernel's way of describing devices. The boot partition will later be described by /etc/fstab as being /dev/sda1.

The word root is used in menu.lst in different contexts, and they mean quite different things. The first reference (root (hd0,0)) means 'the root of GRUB's filesystem', or 'the reference point of GRUB's operations', not the root filesystem to be mounted by the kernel, which will later have /etc, /home, /var, etc mounted to it. On my computer, GRUB would know that partition as (hd0,5). However, the menu.lst listing can refer to it as /dev/sda6, because GRUB has loaded the kernel, and uses the menu.lst line to pass control of the boot process to the kernel, which knows how to find such a device.

The confusion over use of root in menu.lst can be avoided if you think of the first use as meaning boot, not the root filesystem as most would take the meaning.

Yep, you'll need to find where the SATA is - generally all the (E)IDE will come in one block (say hd0-hd3), and the SATA as another (say hd4-hd5). Nothing guarenteed tho' - SATA may be at hd0-hd1.

You were right.Its just another drive to grub.
root (hd3,4) worked.It is also the fourth hd listed in the bios.

It will be interesting to see if I get another sata drive(plugged into whatever sata socket #),load it with os's chainloaded by grub then switch the sata plugs around.

Will grub know I did this by the bios hd id# and correct it or will it be lost?

Thanks for the help.

Don't know why you'd want to replug. If it's for (self) education that's fine, but you should make some effort to figure it out yourself in that case.

That said, I'd expect grub to be easier to sort out than the affected distros. A few fstab's might need some surgery - even though grub will be the one (to seem) to complain.
Not a recommendation action.

When you don't know where is the partition that contains linux, then you enter the grub command line and type:
find /boot/grub/menu.lst
or
find /grub/menu.lst (This is in case your /boot dir is on a separate partition)

One of these commands should return the partition where your menu.lst is, in grub syntax. On my pc, it returns (hd0,5)

Now, if you have many linuxes with only one grub, on the first drive, then I guess you can type "find /boot/vmlinuz" and it should return all the partitions that contain linux. You may also want to create a new file called "abcd" (or whatever else you like) on the partition that you want to locate and then type "find /abcd" and it should return the partition where the file is, always in grub syntax

Originally Posted by LSD Another little tip, you only use chainloader when you want grub to pass boot control over to another bootloader. For instance, the Windows bootloader or FreeBSDs. You shouldn't need it if you're using grub to boot Linux.

Let me disagree. GRUB can chainload lilo or another instance of itself. This can be very useful in extreme multi-boot situations -- 10 or 28 partitions.

What I do is create a GRUB partition for a "master" copy of GRUB that is installed in the MBR. Its only job is to chain to the native bootloaders each of the OS's installed. In the case of GNU/Linux distros, this "native" bootloader is usually also GRUB. Whenever a new OS is installed, it is told NOT to put its bootloader in the MBR, but rather in its root partition.

Given that many distros want to make a 4 line menu & also show no respect for each other's bootloader menus, this keeps the master menu.lst less cluttered & easier to maintain. Otherwise, you will have to recreate & merge the menu.lst's & possibly reinstall the old kernels w/ each distro added. You also get the benefit of seeing each boot menu exactly as its designers intended.

There is extra work @ the beginning, but I find that somewhere around th 3rd OS I'm glad I took the extra time to set up the master menu.

That's Linux for you - everyone wants to do things their own way.

I don't like to see multiple menus. Annoys the hell out of me. But then I don't need "sexy" bootsplash either. I just want my system up.
Now.

I directly load everything. But like I said, each to their own.

Originally Posted by syg00 That's Linux for you - everyone wants to do things their own way. I don't like to see multiple menus. Annoys the hell out of me. But then I don't need "sexy" bootsplash either. I just want my system up. Now. I directly load everything. But like I said, each to their own.

i think archtoad is setting each system's grub to a 0 timeout (?) so he doesnt see more than one gub menu.
how are you doing it archtoad? surely youre not making a selection from one grub and then booting another grub and making another selection are you?

Yes I am, or was -- I am about to abandon multi-boot in favor of virtual machines.

I not only don't use 0 timeouts, I don't even use short timeouts. Typically I set them from 30 sec. (my idea of short) to 90 sec. (my idea of moderately long). I mitigate this by setting the default stanzas. (Remember, a simple "Enter" aborts the timeout & chooses the default.) That way, I have plenty of time when I need to think about what I am doing (think 3 am), yet I can reboot & walk away to get (or return) a cup of coffee & when I return I should be at a log in prompt.

This is a matter of taste -- syg00 doesn't like multiple menus, I don't like long menus that roll, or threaten to roll, off the screen. Also, for teaching & demonstration purposes I like to see/show exactly the menu the distro designer intended. Remember too, I was talking about extreme ("10 or 28") situations, where if each distro's menu has:

• a 2.6 stanza
• a 2.4 stanza
• a recovery stanza
• a memtest stanza

you could have 40 to 112 lines in the displayed menu. I will trade that complexity for a 2nd layer of menuing any day of the week; in fact, in the extreme case, I might be persuaded to introduce a 3rd layer. It's just like the decision of when to create a new subdirectory in a file system. It's always a trade off, and it's always a matter of personal preference & perception of ease of use.

As I said in my earlier post, I find ongoing maintainance, i.e. adding new distros, much easier this way -- provided the addition can be told to leave the MBR untouched. If a distro won't leave the MBR alone, or worse, erases partitions that don't belong to it, then I don't want anything to do w/ it anyway.

Finally, something we all should be able to agree on:

Originally Posted by syg00 But like I said, each to their own.