Craig Andersen wrote:
>
> The old naming method of disk devices (like sda, sdb, ...) in
> /boot/grub/menu.lst and /etc/fstab seems to be available if you do a
> mkinitrd after changing the files to sda1, ... Is there anything else to
> be concerned about ?

Yes, the fact that one part of you HD's can still be called hdX instead
of the expected sdX. This means that I now have hdX and sdX for my IDE
drives. St00pid!

houghi
--
Personally, I think most sports fans are a little "gay". They'd
rather watch a bunch of sweaty guys jumping all over eachother,
than, say fashion TV - where hot models walk down the runway.

On Fri, 2007-11-09 at 11:16 -0600, Craig Andersen wrote:
> The old naming method of disk devices (like sda, sdb, ...) in
> /boot/grub/menu.lst and /etc/fstab seems to be available if you do a
> mkinitrd after changing the files to sda1, ... Is there anything else to
> be concerned about ? I am not sure how the
> /etc/udev/rules.d/60-persistent-storage.rules apply ? For now it works
> but hopefully the naming will not change from one boot to the next.

/dev/sd* names can change order based on controllers and LUNs
being added.

The names under /dev/disk/by-id are persistent.

I usually use /dev/sd* for / for booting on the kernel line (not
sure if /dev/disk names work there)... and then use the
/dev/disk names in /etc/fstab for the other mounts.

If you keep your primary boot drive at the first drive (e.g.
/dev/sda), then the rest can float around if you /dev/disk
instead of the volatile names.

Chris Cox wrote:

> On Fri, 2007-11-09 at 11:16 -0600, Craig Andersen wrote:
>> The old naming method of disk devices (like sda, sdb, ...) in
>> /boot/grub/menu.lst and /etc/fstab seems to be available if you do a
>> mkinitrd after changing the files to sda1, ... Is there anything else to
>> be concerned about ? I am not sure how the
>> /etc/udev/rules.d/60-persistent-storage.rules apply ? For now it works
>> but hopefully the naming will not change from one boot to the next.
>
> /dev/sd* names can change order based on controllers and LUNs
> being added.
>
> The names under /dev/disk/by-id are persistent.
>
> I usually use /dev/sd* for / for booting on the kernel line (not
> sure if /dev/disk names work there)... and then use the
> /dev/disk names in /etc/fstab for the other mounts.
>
> If you keep your primary boot drive at the first drive (e.g.
> /dev/sda), then the rest can float around if you /dev/disk
> instead of the volatile names.

The real hassle is that the apparent drive enumeration order is changed when
you originally have a SATA-only system and later install PATA drives. The
dev/disk method gets you into conflicts with BIOS boot algorithms as your
original GRUB blocks are on what appear to the BIOS as secondary channels -
it wants to put the PATA drives first. Practically, this has caused me
more grief with Windows than anything else, but it does open the
possibility of some disastrous fat finger scenarios by mapping drives to
places you don't expect - as described earlier regarding installations.

I've got a load of 100-300G PATA drives laying around so I run up against
these issues frequently.

--
Will Honea

--
Posted via a free Usenet account from http://www.teranews.com

Will Honea wrote:
> Chris Cox wrote:
>
>
>> On Fri, 2007-11-09 at 11:16 -0600, Craig Andersen wrote:
>>
>>> The old naming method of disk devices (like sda, sdb, ...) in
>>> /boot/grub/menu.lst and /etc/fstab seems to be available if you do a
>>> mkinitrd after changing the files to sda1, ... Is there anything else to
>>> be concerned about ? I am not sure how the
>>> /etc/udev/rules.d/60-persistent-storage.rules apply ? For now it works
>>> but hopefully the naming will not change from one boot to the next.
>>>
>> /dev/sd* names can change order based on controllers and LUNs
>> being added.
>>
>> The names under /dev/disk/by-id are persistent.
>>
>> I usually use /dev/sd* for / for booting on the kernel line (not
>> sure if /dev/disk names work there)... and then use the
>> /dev/disk names in /etc/fstab for the other mounts.
>>
>> If you keep your primary boot drive at the first drive (e.g.
>> /dev/sda), then the rest can float around if you /dev/disk
>> instead of the volatile names.
>>
>
> The real hassle is that the apparent drive enumeration order is changed when
> you originally have a SATA-only system and later install PATA drives. The
> dev/disk method gets you into conflicts with BIOS boot algorithms as your
> original GRUB blocks are on what appear to the BIOS as secondary channels -
> it wants to put the PATA drives first. Practically, this has caused me
> more grief with Windows than anything else, but it does open the
> possibility of some disastrous fat finger scenarios by mapping drives to
> places you don't expect - as described earlier regarding installations.
>
> I've got a load of 100-300G PATA drives laying around so I run up against
> these issues frequently.
>
>
What would happen with a ide promise type controller card I wonder?

Jack

Chris Cox wrote:
>On Fri, 2007-11-09 at 11:16 -0600, Craig Andersen wrote:
>> The old naming method of disk devices (like sda, sdb, ...) in
>> /boot/grub/menu.lst and /etc/fstab seems to be available if you do a
>> mkinitrd after changing the files to sda1, ... Is there anything else to
>> be concerned about ? I am not sure how the
>> /etc/udev/rules.d/60-persistent-storage.rules apply ? For now it works
>> but hopefully the naming will not change from one boot to the next.

>/dev/sd* names can change order based on controllers and LUNs
>being added.

>The names under /dev/disk/by-id are persistent.

>I usually use /dev/sd* for / for booting on the kernel line (not
>sure if /dev/disk names work there)... and then use the
>/dev/disk names in /etc/fstab for the other mounts.

>If you keep your primary boot drive at the first drive (e.g.
>/dev/sda), then the rest can float around if you /dev/disk
>instead of the volatile names.

Some of that is not convenient for users. For example
I often have linux on the high part of the main disk
in a dual disk system.

But never mind that. It seems to me that there was
another way to do it.

The problem, IIRC, is that the same device might be named
differently (in the /dev/hda scheme) depending on race
conditions and the addition of other disks, etc.

This is a problem. But the new cure is not friendly
to human beings.

The right way to do it, in my opinion, is for the computer
to maintain a list of device names, true IDs that will not
change. And then on each boot map these to their given
/dev/hdx names.

That way each disk has a simple to use name and there is
no chance of mixing things up.

As it is now, the *human* has to do that bit of mapping,
and computers are far better at it than humans.

--
--- Paul J. Gans

jrchilds wrote:
> What would happen with a ide promise type controller card I wonder?

I have an extra IDE controler.
The hda-hdd become sda-sde and the hde-hdh become hda-hdd.

Sucks!

houghi
--
You can have my keyboard ...
if you can pry it from my dead, cold, stiff fingers

Paul J Gans wrote:
> Some of that is not convenient for users. For example
> I often have linux on the high part of the main disk
> in a dual disk system.
>
> But never mind that. It seems to me that there was
> another way to do it.
>
> The problem, IIRC, is that the same device might be named
> differently (in the /dev/hda scheme) depending on race
> conditions and the addition of other disks, etc.
>
> This is a problem. But the new cure is not friendly
> to human beings.

A problem? I would say rightout dangerous.
I had hde and hdf for my data and backup. hda and hdb are the things I
play with.

So when I installed 10.3, it proposed to re-format hda. I almost agreed
to default. Luckily I wanted to look at the rest when I suddenly saw a
sda drive. That made me look at the sizes and realize that I almost had
formatted my drive with my main data.

houghi
--
You can have my keyboard ...
if you can pry it from my dead, cold, stiff fingers

On Sat, 10 Nov 2007, houghi wrote:-

>jrchilds wrote:
>> What would happen with a ide promise type controller card I wonder?
>
>I have an extra IDE controler.
>The hda-hdd become sda-sde and the hde-hdh become hda-hdd.

Have you opened a bug report about that? AFAIK, all the IDE drives are
now supposed to be accessed using libata, and should all be identified
as various sdx devices.

>Sucks!

In that sort of situation, it does.

I've not yet installed on a system with PATA and SATA, or an additional
IDE controller so don't know what effect it would have. Damn! Now I've
had my curiosity tweaked...


Regards,
David Bolt

--
www.davjam.org/lifetype/ www.distributed.net: OGR@100Mnodes, RC5-72@15Mkeys
| SUSE 10.1 32bit | openSUSE 10.2 32bit | openSUSE 10.3 32bit
SUSE 10.0 64bit | SUSE 10.1 64bit | openSUSE 10.2 64bit |
RISC OS 3.11 | RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC

David Bolt wrote:
> On Sat, 10 Nov 2007, houghi wrote:-
>
>>jrchilds wrote:
>>> What would happen with a ide promise type controller card I wonder?
>>
>>I have an extra IDE controler.
>>The hda-hdd become sda-sde and the hde-hdh become hda-hdd.
>
> Have you opened a bug report about that? AFAIK, all the IDE drives are
> now supposed to be accessed using libata, and should all be identified
> as various sdx devices.

No and I do not realy have time to follow up on it. Perhaps I will when
the Alpha's or Beta's for 11.0 come out.

houghi
--
You can have my keyboard ...
if you can pry it from my dead, cold, stiff fingers

houghi wrote:
>Paul J Gans wrote:

>> This is a problem. But the new cure is not friendly
>> to human beings.

>A problem? I would say rightout dangerous.
>I had hde and hdf for my data and backup. hda and hdb are the things I
>play with.

>So when I installed 10.3, it proposed to re-format hda. I almost agreed
>to default. Luckily I wanted to look at the rest when I suddenly saw a
>sda drive. That made me look at the sizes and realize that I almost had
>formatted my drive with my main data.

What did you think of my proposal to solve the problem?

--
--- Paul J. Gans

Paul J Gans wrote:

> What did you think of my proposal to solve the problem?
>

I wasn't sure about who (BIOS? OS?) kept the map. I would think that a
relatively simple change to Linux to set the mapping (and utilities to
manage it) would be quite workable. The functionality would be transparent
to "ordinary" users while providing a useful control to those of us
with "strange" configuration requirements. I have one machine here with a
builtin PATA and both addon SCSI and SATA boards. I'll bet I can create
some really wierd situations with that.

I doubt that changing BIOS behavior is an option but I would be all for such
a system at the OS level.

--
Will Honea

--
Posted via a free Usenet account from http://www.teranews.com

Will Honea wrote:
>Paul J Gans wrote:

>> What did you think of my proposal to solve the problem?
>>

>I wasn't sure about who (BIOS? OS?) kept the map. I would think that a
>relatively simple change to Linux to set the mapping (and utilities to
>manage it) would be quite workable. The functionality would be transparent
>to "ordinary" users while providing a useful control to those of us
>with "strange" configuration requirements. I have one machine here with a
>builtin PATA and both addon SCSI and SATA boards. I'll bet I can create
>some really wierd situations with that.

>I doubt that changing BIOS behavior is an option but I would be all for such
>a system at the OS level.

As far as I know, linux doesn't pay attention to the BIOS. It
scans for the drives directly.

What I meant was that since linux *now* collects the hardware
long names *and* has a list of the corresponding old /dev/hdx
designators, would it not be better if it presented the
old designators to us, the human beings, and kept the long
names for its own use?

--
--- Paul J. Gans

houghi wrote:
> Craig Andersen wrote:
>> The old naming method of disk devices (like sda, sdb, ...) in
>> /boot/grub/menu.lst and /etc/fstab seems to be available if you do a
>> mkinitrd after changing the files to sda1, ... Is there anything else to
>> be concerned about ?
>
> Yes, the fact that one part of you HD's can still be called hdX instead
> of the expected sdX. This means that I now have hdX and sdX for my IDE
> drives. St00pid!
>
> houghi

I have one machine installed fresh 10.3 on top of 10.2 with the old /home.

On that one I had only IDE drives and they all got to be /dev/sdx.

Then I added one SATA drive and everything is still /dev/sdx.

Another machine with only IDE was done by upgrading to 10.3 on top of 10.0.

Everything is still /dev/hdx

Then there is one that has IDE and SCSI drives.

In 10.0 there were /dev/hdx and /dev/sdx (correct IMO)
Now, as 10.3 there's only /dev/sdx, fresh install.

I wonder...

Vahis
--
"Only wimps use tape backup: _real_ men just upload their important
stuff on ftp, and let the rest of the world mirror it "
Linus Torvalds 1996.

Paul J Gans wrote:

> What I meant was that since linux *now* collects the hardware
> long names *and* has a list of the corresponding old /dev/hdx
> designators, would it not be better if it presented the
> old designators to us, the human beings, and kept the long
> names for its own use?

Agreed! Are we voting?

Between adapters and jumpers, this has been a PITA since DOS days.

--
Will Honea

--
Posted via a free Usenet account from http://www.teranews.com

Paul J Gans wrote:
> houghi wrote:
>>Paul J Gans wrote:
>
>>> This is a problem. But the new cure is not friendly
>>> to human beings.
>
>>A problem? I would say rightout dangerous.
>>I had hde and hdf for my data and backup. hda and hdb are the things I
>>play with.
>
>>So when I installed 10.3, it proposed to re-format hda. I almost agreed
>>to default. Luckily I wanted to look at the rest when I suddenly saw a
>>sda drive. That made me look at the sizes and realize that I almost had
>>formatted my drive with my main data.
>
> What did you think of my proposal to solve the problem?

I am not sure what the reason for the change was, but the best solution
for me would be to change it back like it was. IDE devices are hdX

houghi
--
The blue light suddenly flashed on my horrified face. What a disaster!
Oh, the humanity! I never thought it would happen to me. How terrifying
it is to see for yourself "*The Blue Screen of Death*".

On Sun, 11 Nov 2007 20:52:51 +0100, houghi wrote:

> IDE devices are hdX

SATA disks are IDE devices too.

Mark South wrote:
> On Sun, 11 Nov 2007 20:52:51 +0100, houghi wrote:
>
>> IDE devices are hdX
>
> SATA disks are IDE devices too.

Then they should be hdX too, or whatever it was in 10.2.

houghi
--
You tried, and you failed, so the lesson is, never try. - Homer J. Simpson.

Mark South wrote:
>On Sun, 11 Nov 2007 20:52:51 +0100, houghi wrote:

>> IDE devices are hdX

>SATA disks are IDE devices too.

Yes, but IDE devices are not always SATA devices. In the
good old days IDE drives were /dev/hdx and SATA's were
/dev/sdx. Now both are /dev/sdx, which is confusing at
best and dangerous at worst.

--
--- Paul J. Gans

On Mon, 12 Nov 2007 17:21:28 +0000, Paul J Gans wrote:

> Mark South wrote:
>>On Sun, 11 Nov 2007 20:52:51 +0100, houghi wrote:
>
>>> IDE devices are hdX
>
>>SATA disks are IDE devices too.
>
> Yes, but IDE devices are not always SATA devices.

Indeed. I was pointing out that the thinking was not very precise in a
discussion that relies on clear thinking.

> In the good old days IDE drives were /dev/hdx

And there you fell into it too. *PATA* IDE drives were /dev/hd?, SATA IDE
drives were always handled by the SCSI layer.

> and SATA's were
> /dev/sdx. Now both are /dev/sdx, which is confusing at
> best and dangerous at worst.

The only place that it can make a difference to complain is the lkml, and
there will only be sympathy if someone offers to maintain the PATA
library, since it's old and difficult to maintain and used only for PATA,
whereas everything else can use libata.