Hello, On Fri, 12 Mar 2010, Philipp Thomas wrote:
On Fri, 12 Mar 2010 19:25:57 +0100, you wrote:
fine. The order openSUSE sees the drives (using fdisk -l) on /dev is different than the physical connect order:
Wellcome to the new dynamic world. Device names get assigned dynamically so the drives get names according to the order in which drives are probed or respond to probes and can't be relied on. That's
That depends. If you have just one SATA-Driver in the initrd (e.g. ahci or sata_nv), the devices get reliably enumerated here. I've recently switched motherboards and simultaneously from SATA-IDE-mode to AHCI-mode (i.e. sata_nv -> ahci), but /dev/sda was and is the same disk. And I use that in grub's device.map and /dev/sda3 in fstab. Anyway: I reliably get /dev/sda to be the disk on the first onboard controller. The driver for the second controller is sata_sil and not in the initrd. In fstab, I use labels for the rest of the partitions.
why we (SuSE) create symlinks in /dev/disk/by-id which point to the corresponding device via an udev rule.
That sucks IMHO. Imagine your bootdisk developing defective sectors. So you replace it (how the data is moved is irrelevevant, even how grub is installed on the new disk). But look at the "fun" you'll have fixing your fstab and grub menu.lst (root= kernel-parameter). I simply have /dev/sda3 in fstab and as kernel-parameter and didn't have to change a thing. Just reinstall grub, as usual. /dev/disk/by-label/ might work as root= parameter.
openSUSE is installed on the 6th partition of SATA0 (/dev/sdd6). Grub in openSUSE is set to boot (hd0,5)... which is correct (as I understand Grub) and which boots fine.
The mapping between device names and grub devices is controlled by /boot/grub/device.map or in absence of that by the order the BIOS enumerates them.
And exclusively by grub. And it's only the "view" from the system that grub is installed from that's relevant.
I installed Gentoo on the 7th partition of SATA0 (dev/sdd7)... but fdisk -l from the Gentoo install sees the drives differently than openSUSE... it sees the drives like this:
You have two choices. Either you let one grub instance boot all other Linux installations or you install one grub in the master boot record and the other grubs in the boot sector of their respective partition.
Three! You can have a grub for each distribution (let them install to their bootsectors, unless it's an XFS, in that case you can use the MBR or the extended partition BR and IIRC any BR of a logical partition, which is NOT the first sector of that partition, but the sector containing the partitiontable that chains the logical partitions). And then install _one_ grub in the mbr, copy the entries from the other distros and adjust the grub hdX,N devices (see my other mail). And of course, add chainloder entries for "the other grubs". So it's both of the choices Philipp told of. It's also a nice fallback. Especially if you add chainloder entries to the other grubs as well. I've been juggling 3 distros + grubs that way.
In the former case you have to edit the mast menu.list to contain the boot lines from all other Linux installations, in the latter you have to make chainloader entries in the master menu.lst.
In the third case, you can have those chainloaders in addition / as fallback.
Otherwise let David explain you the intricacies of linux booting :)
*heh* Haven't looked at grub2 yet and the kernel lately, and especially not at udev and stuff (I hate automatisms). And I dislike huge initrds. And loading modules "at boot". But at least up to "get the kernel and running" I can elaborate. When you've recreated a MBR-partitiontable from scratch by only using DOS debug.com, pen and a piece of paper and a pocket calculator for some of the hex/dec conversions and bit-shifting, using data from the still existing filesystems, you tend to lose the awe or fear about the whole boot-process, even if you don't really have an idea how the actual boot-code works (e.g. grub stage1, a random DOS boot- sector etc.), it's enough to know _what_ the code does[0] and that it's replaceable i.e. recreatable with a bunch of tools like any bootmanager install or fixmbr etc. BTW: splash=native is a must! :) Don't ever nobody hide no useful kernel messages from me![1] -dnh [0] DOS: load first sector of active primary partition to mem and execute it Grub/Lilo/$otherBM: read rest of itself from whereever, show menu, load relevant Kernel/Sector and execute it. I wonder if a DOS BS could load a Linux if you put a kernel in just the right place (and have root= parameter compiled in) ;) [1] not sure how that goes in english, you get the gist, I hope ;) -- When the SysAdmin answers the phone politely, say "sorry", hang up and run awaaaaay! Informal advice to users at Karolinska Institutet, 1993-1994 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org