Mailinglist Archive: opensuse (1523 mails)

< Previous Next >
Re: [opensuse] Confused by hard drive naming/position /dev/sda vs hd0 etc,
  • From: David Haller <dnh@xxxxxxxxxxxx>
  • Date: Sat, 13 Mar 2010 00:48:36 +0100
  • Message-id: <20100312234836.GA4241@xxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups
References