[gentoo-amd64] Drive asignments for sata drives

[gentoo-amd64] Drive asignments for sata drives

[P.V.Anthony]

Hi again,

Is there a way to fix the drive assignment for sata drives?

Currently in the fstab the boot and root partitions are set and working 
great. Once a new sata drive connected, the drive assignments change. 
Initially the / (root) is /dev/sda2. Once another sata drive is added 
the / (root) becomes say /dev/sdb2.

Is there any way that this can be fixed even when more drives are added 
or removed?

P.V.Anthony
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Drive asignments for sata drives

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

Hi,

On Tue, 2007-13-03 at 00:39 +0800, P.V.Anthony wrote:
> Is there a way to fix the drive assignment for sata drives?
> 
> Currently in the fstab the boot and root partitions are set and working 
> great. Once a new sata drive connected, the drive assignments change. 
> Initially the / (root) is /dev/sda2. Once another sata drive is added 
> the / (root) becomes say /dev/sdb2.

The easy solution is to use labels .. so you'd have "LABEL=myroot / ..."
in your fstab

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] Drive asignments for sata drives

[Bob Sanders]

P.V.Anthony, mused, then expounded:
> 
> Currently in the fstab the boot and root partitions are set and working 
> great. Once a new sata drive connected, the drive assignments change. 
> Initially the / (root) is /dev/sda2. Once another sata drive is added 
> the / (root) becomes say /dev/sdb2.
> 
> Is there any way that this can be fixed even when more drives are added 
> or removed?
>

Typically, on the same controller, the lowest numbered port becomes the
first drive.  The description of the symptom leads me to believe that
your /dev/sda drive is attached to port 2 instead of being attached to
port 1.  Have you tried moving your SATA cable to a different port?

Bob 
-  
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Drive asignments for sata drives

[Marcus D. Hanwell]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

On Monday 12 March 2007 17:00:09 Bob Sanders wrote:
> P.V.Anthony, mused, then expounded:
> > Currently in the fstab the boot and root partitions are set and working
> > great. Once a new sata drive connected, the drive assignments change.
> > Initially the / (root) is /dev/sda2. Once another sata drive is added
> > the / (root) becomes say /dev/sdb2.
> >
> > Is there any way that this can be fixed even when more drives are added
> > or removed?
>
> Typically, on the same controller, the lowest numbered port becomes the
> first drive.  The description of the symptom leads me to believe that
> your /dev/sda drive is attached to port 2 instead of being attached to
> port 1.  Have you tried moving your SATA cable to a different port?
>
I had the same problem and despite my existing drive being connected to what 
was labelled on the motherboard as SATA1 it in fact was not! Trial and error 
gave me the correct one... It would be useful if the nodes were more fixed 
but most systems do not change after initial set up and this situation can be 
fixed quite easily.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] Drive asignments for sata drives

[dustin]

On Mon, Mar 12, 2007 at 05:11:03PM +0000, Marcus D. Hanwell wrote:
> I had the same problem and despite my existing drive being connected to what 
> was labelled on the motherboard as SATA1 it in fact was not! Trial and error 
> gave me the correct one... It would be useful if the nodes were more fixed 
> but most systems do not change after initial set up and this situation can be 
> fixed quite easily.

It's worth noting that the "correct" way to do this is now with fs
labels or UUIDs.  Personally, I use LVM for everything but
boot/root/swap, and that uses UUIDs internally, so I don't have much
issue (it would be sweet if Gentoo could easily boot from LVM, but that
requires an initrd).

Anyway, I'm not too sure how to indicate a UUID to the kernel for its
root fs.  There's a RedHat kernel patch that allows you to specify e.g.,
'root=LABEL=myroot' on the kernel cmdline, but I'm not sure if that's
available in the stock Gentoo kernel, or if it supports UUIDs.

You can use 'LABEL=foo' or UUID='fooo-ooo-ooo..' in /etc/fstab, though.

Dustin
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Drive asignments for sata drives

[Marcus D. Hanwell]

[-- Attachment #1: Type: text/plain, Size: 1842 bytes --]

On Monday 12 March 2007 17:21:57 dustin@v.igoro.us wrote:
> On Mon, Mar 12, 2007 at 05:11:03PM +0000, Marcus D. Hanwell wrote:
> > I had the same problem and despite my existing drive being connected to
> > what was labelled on the motherboard as SATA1 it in fact was not! Trial
> > and error gave me the correct one... It would be useful if the nodes were
> > more fixed but most systems do not change after initial set up and this
> > situation can be fixed quite easily.
>
> It's worth noting that the "correct" way to do this is now with fs
> labels or UUIDs.  Personally, I use LVM for everything but
> boot/root/swap, and that uses UUIDs internally, so I don't have much
> issue (it would be sweet if Gentoo could easily boot from LVM, but that
> requires an initrd).
>
> Anyway, I'm not too sure how to indicate a UUID to the kernel for its
> root fs.  There's a RedHat kernel patch that allows you to specify e.g.,
> 'root=LABEL=myroot' on the kernel cmdline, but I'm not sure if that's
> available in the stock Gentoo kernel, or if it supports UUIDs.
>
> You can use 'LABEL=foo' or UUID='fooo-ooo-ooo..' in /etc/fstab, though.
>
I haven't encountered this before, but I thought the labels must have some 
use! That is certainly useful although I am now using RAID0/1/5 (depending up 
on partition) along with LVM2 and so they take care of most of this.

The main issue I see is the root= line in grub (or whatever you use) as I am 
guessing from other posts this doesn't work. I don't think it matters too 
much for me now as that is a RAID5 partition too.

In this age of SATA drives using labels, uuids etc is probably the way to go 
as my system fell flat on its face when I put a new drive in. Anyone know if 
the Gentoo kernel can boot using a label? Back to work anyway... Busy, busy, 
busy...

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-amd64] Re: Drive asignments for sata drives

[Bernhard Auzinger]

Am Montag 12 März 2007 schrieb Marcus D. Hanwell:
> On Monday 12 March 2007 17:00:09 Bob Sanders wrote:
> > P.V.Anthony, mused, then expounded:
> > > Currently in the fstab the boot and root partitions are set and working
> > > great. Once a new sata drive connected, the drive assignments change.
> > > Initially the / (root) is /dev/sda2. Once another sata drive is added
> > > the / (root) becomes say /dev/sdb2.
> > >
> > > Is there any way that this can be fixed even when more drives are added
> > > or removed?
> >
> > Typically, on the same controller, the lowest numbered port becomes the
> > first drive.  The description of the symptom leads me to believe that
> > your /dev/sda drive is attached to port 2 instead of being attached to
> > port 1.  Have you tried moving your SATA cable to a different port?
>
> I had the same problem and despite my existing drive being connected to
> what was labelled on the motherboard as SATA1 it in fact was not! Trial and
> error gave me the correct one... It would be useful if the nodes were more
> fixed but most systems do not change after initial set up and this
> situation can be fixed quite easily.

Another way would be to use udev and the partitions uuid to mount the 
partition.

With

-> udevinfo --query=all --root --name sdb2 | grep uuid

you get the uuid of the partition (in this case sda1). The output looks like:

-> S: disk/by-uuid/24034503-e89e-4e6d-96b6-5dbc2e9b83cf

Then you can mount the drive by simply typing (with the output that gives you 
the command above on your machine)

-> mount UUID=24034503-e89e-4e6d-96b6-5dbc2e9b83cf /mnt_point

or adding a line like

-> UUID=3f465a84-8eac-4207-aeb6-b9178329af4f /mnt_point your_fs your_opts 0 2

to your fstab

With this solution the drives(partitions) should always be mounted at the same 
mount point, no matter at which controller it is attached physically.

rgds
Bernhard
--
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Drive asignments for sata drives

[P.V.Anthony]

Bernhard Auzinger wrote:
> Am Montag 12 März 2007 schrieb Marcus D. Hanwell:
>> On Monday 12 March 2007 17:00:09 Bob Sanders wrote:
>>> P.V.Anthony, mused, then expounded:
>>>> Currently in the fstab the boot and root partitions are set and working
>>>> great. Once a new sata drive connected, the drive assignments change.
>>>> Initially the / (root) is /dev/sda2. Once another sata drive is added
>>>> the / (root) becomes say /dev/sdb2.
>>>>
>>>> Is there any way that this can be fixed even when more drives are added
>>>> or removed?
>>> Typically, on the same controller, the lowest numbered port becomes the
>>> first drive.  The description of the symptom leads me to believe that
>>> your /dev/sda drive is attached to port 2 instead of being attached to
>>> port 1.  Have you tried moving your SATA cable to a different port?
>> I had the same problem and despite my existing drive being connected to
>> what was labelled on the motherboard as SATA1 it in fact was not! Trial and
>> error gave me the correct one... It would be useful if the nodes were more
>> fixed but most systems do not change after initial set up and this
>> situation can be fixed quite easily.
> 
> Another way would be to use udev and the partitions uuid to mount the 
> partition.
> 
> With
> 
> -> udevinfo --query=all --root --name sdb2 | grep uuid
> 
> you get the uuid of the partition (in this case sda1). The output looks like:
> 
> -> S: disk/by-uuid/24034503-e89e-4e6d-96b6-5dbc2e9b83cf
> 
> Then you can mount the drive by simply typing (with the output that gives you 
> the command above on your machine)
> 
> -> mount UUID=24034503-e89e-4e6d-96b6-5dbc2e9b83cf /mnt_point
> 
> or adding a line like
> 
> -> UUID=3f465a84-8eac-4207-aeb6-b9178329af4f /mnt_point your_fs your_opts 0 2
> 
> to your fstab
> 
> With this solution the drives(partitions) should always be mounted at the same 
> mount point, no matter at which controller it is attached physically.
> 
> rgds
> Bernhard

Thanks to all who have responded to this email. The information sent 
have solved my problems with the sata drives. I am very happy.

For the record, I have used the above solution and it is working great.

I hope one day grub will allow "root=UUID=something" then the problem is 
completely solved.

I am very happy. Thank you all very much for helping.

P.V.Anthony

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Drive asignments for sata drives

[dustin]

On Tue, Mar 13, 2007 at 05:08:02PM +0800, P.V.Anthony wrote:
> I hope one day grub will allow "root=UUID=something" then the problem is completely solved.

Not to be picky, but it's the kernel that parses that command line --
grub just supplies it to the kernel.

Dustin
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Drive asignments for sata drives

[Peter Humphrey]

On Tuesday 13 March 2007 14:06:22 dustin@v.igoro.us wrote:
> On Tue, Mar 13, 2007 at 05:08:02PM +0800, P.V.Anthony wrote:
> > I hope one day grub will allow "root=UUID=something" then the problem
> > is completely solved.
>
> Not to be picky, but it's the kernel that parses that command line --
> grub just supplies it to the kernel.

Are you sure? It seems to me that the "root=" parameter is to grub, to tell 
it where to find the kernel to which to pass the remaining arguments.

-- 
Rgds
Peter Humphrey
Linux Counter 5290, Aug 93
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Drive asignments for sata drives

[dustin]

On Tue, Mar 13, 2007 at 05:31:44PM +0000, Peter Humphrey wrote:
> > Not to be picky, but it's the kernel that parses that command line --
> > grub just supplies it to the kernel.
> 
> Are you sure? It seems to me that the "root=" parameter is to grub, to tell 
> it where to find the kernel to which to pass the remaining arguments.

Yep.

kernel /boot/kernel-2.6.15-gentoo-r7-2006040301 root=/dev/sda2

The first argument, /boot/kernel-2.6.15-gentoo-r7-2006040301, is to
grub, and tells it where to find the kernel.  It then laods the kernel
(and any initrd, etc.) and passes the rest of the stuff along as the
command line -- it's similar to a shell command, where the shell
specially interprets the first component, and the rest is left to the
executable.

You can verify this by messing up your 'root=xxx' line in grub.conf and
rebooting.  The kernel will load to the tune of lots of messages, but
then panic when it looks for its root fs.

FWIW, the same thing applies with the "magic words" used in ISOLINUX:
some of those are flags to the kernel, while others are interpreted by
the rc scripts later (the kernel makes its command line available in
/proc/cmdline).

Dustin
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Drive asignments for sata drives

[Duncan]

Peter Humphrey <prh@gotadsl.co.uk> posted
200703131731.44114.prh@gotadsl.co.uk, excerpted below, on  Tue, 13 Mar
2007 17:31:44 +0000:

> On Tuesday 13 March 2007 14:06:22 dustin@v.igoro.us wrote:
>> On Tue, Mar 13, 2007 at 05:08:02PM +0800, P.V.Anthony wrote:
>> > I hope one day grub will allow "root=UUID=something" then the problem
>> > is completely solved.
>>
>> Not to be picky, but it's the kernel that parses that command line --
>> grub just supplies it to the kernel.
> 
> Are you sure? It seems to me that the "root=" parameter is to grub, to
> tell it where to find the kernel to which to pass the remaining
> arguments.

The "root (hd0,0)" (or whatever) line is for grub.

The "kernel ..." line, including the "root=/dev/whatever", or as we are 
talking here "root=label" parameter, are passed to the kernel.  It uses 
that parameter to find and load its rootfs after the kernel has loaded 
and done the pre-root detection and config stuff, but before the first 
userspace program (normally init) starts and does the userspace boot 
stuff, plus loading any additional kernel modules and doing a bit more 
kernel config (sysctl and the like).

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Drive asignments for sata drives

[ducasse.isidore]

By the way, while trying latest 2.6.20 kernel, my machine couldn't mount my SCSI drive as sda2 anymore... 
I swear I didn't plug/unplug any device in the meanwhile.

Got any clue? Is there a magic option to get in a shell and check with genkernel made kernels for the correct device node? Or a udev initramfs with just a prompt available?

On Tue, 13 Mar 2007 18:45:20 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Peter Humphrey <prh@gotadsl.co.uk> posted
> 200703131731.44114.prh@gotadsl.co.uk, excerpted below, on  Tue, 13 Mar
> 2007 17:31:44 +0000:
> 
> > On Tuesday 13 March 2007 14:06:22 dustin@v.igoro.us wrote:
> >> On Tue, Mar 13, 2007 at 05:08:02PM +0800, P.V.Anthony wrote:
> >> > I hope one day grub will allow "root=UUID=something" then the problem
> >> > is completely solved.
> >>
> >> Not to be picky, but it's the kernel that parses that command line --
> >> grub just supplies it to the kernel.
> > 
> > Are you sure? It seems to me that the "root=" parameter is to grub, to
> > tell it where to find the kernel to which to pass the remaining
> > arguments.
> 
> The "root (hd0,0)" (or whatever) line is for grub.
> 
> The "kernel ..." line, including the "root=/dev/whatever", or as we are 
> talking here "root=label" parameter, are passed to the kernel.  It uses 
> that parameter to find and load its rootfs after the kernel has loaded 
> and done the pre-root detection and config stuff, but before the first 
> userspace program (normally init) starts and does the userspace boot 
> stuff, plus loading any additional kernel modules and doing a bit more 
> kernel config (sysctl and the like).
> 
> -- 
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
> 
> -- 
> gentoo-amd64@gentoo.org mailing list
> 
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Drive asignments for sata drives

[Thomas Rösner]

ducasse.isidore@gmail.com schrieb:
> By the way, while trying latest 2.6.20 kernel, my machine couldn't mount my SCSI drive as sda2 anymore... 
> I swear I didn't plug/unplug any device in the meanwhile.
>
> Got any clue? Is there a magic option to get in a shell and check with genkernel made kernels for the correct device node? Or a udev initramfs with just a prompt available?
>   

The correct device name should fly by when the kernel detects the disk, 
but that won't help you much if it get's scrolled out of view and you're 
not dmesg-reading superman.

If you're using genkernel, shouldn't you have /dev/ram0 as root, anyway?

http://www.gentoo.org/doc/en/genkernel.xml#doc_chap2_sect9

Regards,
    Thomas


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Drive asignments for sata drives

[Florian D.]

ducasse.isidore@gmail.com wrote:
> By the way, while trying latest 2.6.20 kernel, my machine couldn't mount my SCSI drive as sda2
> anymore... I swear I didn't plug/unplug any device in the meanwhile.
> 
> Got any clue? Is there a magic option to get in a shell and check with genkernel made kernels for
> the correct device node? Or a udev initramfs with just a prompt available?
> 
depending on your last kernel, it could be that you're using libata for the first time now, which
could lead to a different ordering. did you try it with a current live CD (knoppix, ...) already?

PS: pls. don't hijack threads. start a new one with your problem.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Drive asignments for sata drives

[ducasse.isidore]

OK sorry for interfering, I thought there was a common clue between preceeding stuff and mine.
2.6.20 works fine now, thanks to all. The issue seemed to be a misconfigure, though I'm almost certain I did use nvidia-SATA module at first. Might be that the hd needed some other tiny option... I couldn't figure out what it was but still, it works!

On Thu, 15 Mar 2007 01:35:54 +0000
"Florian D." <flockmock@gmx.at> wrote:

> ducasse.isidore@gmail.com wrote:
> > By the way, while trying latest 2.6.20 kernel, my machine couldn't mount my SCSI drive as sda2
> > anymore... I swear I didn't plug/unplug any device in the meanwhile.
> > 
> > Got any clue? Is there a magic option to get in a shell and check with genkernel made kernels for
> > the correct device node? Or a udev initramfs with just a prompt available?
> > 
> depending on your last kernel, it could be that you're using libata for the first time now, which
> could lead to a different ordering. did you try it with a current live CD (knoppix, ...) already?
> 
> PS: pls. don't hijack threads. start a new one with your problem.
> -- 
> gentoo-amd64@gentoo.org mailing list
> 
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Drive asignments for sata drives

[ducasse.isidore]

Just to mention, I did activate the SCSI drivers for my hd in the new path in menuconfig manually.

By the way, while trying latest 2.6.20 kernel, my machine couldn't mount my SCSI drive as sda2 anymore... 
I swear I didn't plug/unplug any device in the meanwhile.

Got any clue? Is there a magic option to get in a shell and check with genkernel made kernels for the correct device node? Or a udev initramfs with just a prompt available?
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Drive asignments for sata drives

[dustin]

On Tue, Mar 13, 2007 at 08:53:13PM +0100, ducasse.isidore@gmail.com wrote:
> Just to mention, I did activate the SCSI drivers for my hd in the new path in menuconfig manually.
> 
> By the way, while trying latest 2.6.20 kernel, my machine couldn't mount my SCSI drive as sda2 anymore... 
> I swear I didn't plug/unplug any device in the meanwhile.
> 
> Got any clue? Is there a magic option to get in a shell and check with genkernel made kernels for the correct device node? Or a udev initramfs with just a prompt available?

It's always frustrating to diagnose things like that, without being able
to effectively pause and restart the kernel messages.  Booting with a
serial console is, I think, the preferred solution.

One thing you could do is put in an IDE drive and put a basic root
partition on it -- at least enough to boot into a recovery shell.  Then
you can look around at dmesg, etc.

It's not elegant, but it's an idea.

Dustin
-- 
gentoo-amd64@gentoo.org mailing list

RE: [gentoo-amd64] Re: Drive asignments for sata drives

[David Pyke]

It may be that your SATA drive has moved from sda to hda. Trying changing it
in your fstab and see if it works. (boot using the live CD and mount the
drive, etc.)

-----Original Message-----
From: dustin@v.igoro.us [mailto:dustin@v.igoro.us] 
Sent: Tuesday, March 13, 2007 3:59 PM
To: gentoo-amd64@lists.gentoo.org
Subject: Re: [gentoo-amd64] Re: Drive asignments for sata drives

On Tue, Mar 13, 2007 at 08:53:13PM +0100, ducasse.isidore@gmail.com wrote:
> Just to mention, I did activate the SCSI drivers for my hd in the new path
in menuconfig manually.
> 
> By the way, while trying latest 2.6.20 kernel, my machine couldn't mount
my SCSI drive as sda2 anymore... 
> I swear I didn't plug/unplug any device in the meanwhile.
> 
> Got any clue? Is there a magic option to get in a shell and check with
genkernel made kernels for the correct device node? Or a udev initramfs with
just a prompt available?

It's always frustrating to diagnose things like that, without being able to
effectively pause and restart the kernel messages.  Booting with a serial
console is, I think, the preferred solution.

One thing you could do is put in an IDE drive and put a basic root partition
on it -- at least enough to boot into a recovery shell.  Then you can look
around at dmesg, etc.

It's not elegant, but it's an idea.

Dustin
--
gentoo-amd64@gentoo.org mailing list

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] [OT] Drive asignments for sata drives

[Bob Slawson]

P.V.Anthony wrote:
> Is there a way to fix the drive assignment for sata drives?
>
> Currently in the fstab the boot and root partitions are set and 
> working great. Once a new sata drive connected, the drive assignments 
> change. Initially the / (root) is /dev/sda2. Once another sata drive 
> is added the / (root) becomes say /dev/sdb2.
>
> Is there any way that this can be fixed even when more drives are 
> added or removed?
Use disk labels to symbolically name partitions so that you don't need 
to use explicit special device names.

`tune2fs -L <label name>' adds a disk label to a partition (at least for 
ext2/3 file systems).

Then in /etc/fstab use entries along these lines (assuming you've 
labeled the boot partition 'BOOT' and the root partition 'ROOT'...) :

#------------------- (example) -----------------

LABEL=BOOT        /boot    ext2    defaults    0 2
LABEL=ROOT        /        ext3    defaults    0 1

LABEL=fortknox    /precious_data   ext3   defaults,ro   0 1

# use LABELs for pluggable media since the special devices may change
# MS DOS disk labels must be 11 characters and all upper case
LABEL=Backup            /mnt/Backup             auto    
defaults,users,noauto   0 0

#------------------ (/example) -----------------


I'd guess that there are ways to add labels to non-ext2/3 file systems 
(reiserfs, xfs, ...) but I haven't tried.

As always: read `man tune2fs' and `man mount'.

BobS

PS. This isn't an amd64 issue.


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] [OT] Drive asignments for sata drives

[Bob Sanders]

Bob Slawson, mused, then expounded:
> 
> 
> I'd guess that there are ways to add labels to non-ext2/3 file systems 
> (reiserfs, xfs, ...) but I haven't tried.
>

xfs_admin -L <label>

man xfs_admin

Bob 
-  
-- 
gentoo-amd64@gentoo.org mailing list