On Tue, 16 Jan 2001, Venkatesh Ramamurthy wrote:
> > This is due to the fixed ordering of the scsi drivers. You can change the
> > order of the scsi hosts with the "scsihosts" kernel parameter. See
> > linux/drivers/scsi/scsi.c
> [Venkatesh Ramamurthy] I think it would be a nice idea if
Guys,
> And this is a problem that has plagues all PC operating systems, but has
never
> been a problem on the Macintosh. Why? Because the Mac was designed to
handle
> this problem, but the PC never was.
Quite true on this point.
> The Mac never enumerates its devices like the PC does (no C:
** Reply to message from Eddie Williams <[EMAIL PROTECTED]> on Tue,
16 Jan 2001 12:24:49 -0500
> That is not totally true. There are two problems here, one is where you have
> different controllers in your system and the other is where you have multiples
> of the same controller. What you
[EMAIL PROTECTED] said:
> [Venkatesh Ramamurthy]
Your name is already in the headers of the mail you sent. There's no need to
repeat it.
> The LILO boot loader and the LILO command line utility should be changed
> for this.
> Is anybody doing this? -
There are patches available for
> From a layering point of view, it makes a lot more sense to
> me for the label (or signature or whatever) for this purpose
> to be in the partition table than inside the filesystem. The
> parts of the system that assign devices their identities already
> know about that part of the disk.
Venkatesh Ramamurthy wrote:
>
> Hi,
> I have one issue which requires fix from the linux kernel.
> Initially i put a SCSI controller and install the OS on the drive connected
> to it. After installing the OS (on sda), the customer puts another SCSI
> controller. The BIOS for the first
>If we can truly go for label based mounting
>and lilo'ing this would solve the problem.
>From a layering point of view, it makes a lot more sense to
me for the label (or signature or whatever) for this purpose
to be in the partition table than inside the filesystem. The
parts of the system
On Tue, 16 Jan 2001 16:51:38 GMT, Venkatesh Ramamurthy <[EMAIL PROTECTED]> wrote:
> [Venkatesh Ramamurthy] Just think an end-user fuguring out this
> Asking him to change PCI slots and trying it out. My point is the end user
> should not worry about all this. All he does is plugs a new
> Why does the end-user have to compile the kernel? Most distributions
> provide a kernel with no SCSI drivers in it, but use an initrd to get
> the root SCSI driver in (man mkinitrd on any Redhat box). Just
> distribute all SCSI drivers as modules and you won't have any problems.
>
That is
Venkatesh Ramamurthy wrote:
>
> > When the cards are of different make the order is solely dependent on
> > the order that the drivers are initialized in the kernel. If you have
> > modules enabled, only build the driver for your root device into the
> > kernel image and have the other modular.
David Woodhouse wrote :
> [EMAIL PROTECTED] said:
> > we need some kind of signature being written in the drive, which the
> > kernel will use for determining the boot drive and later re-order
> > drives, if required.
>
> > Is someone handling this already?
>
> It should be
> Why is this a SCSI ML problem? The problem is that the OS can't figure
> out
> where to mount root from. Sounds like an OS problem.
> I think the file system label is the leading candidate to solve this. One
>
> really does not care if the root disk is called /dev/sda or /dev/fred.
> All
> The scsi host numbers will be allocated to the HBAs in
> the order shown starting at 0. This method does not
> distinguish between the two advansys controllers, luckily
> swapping their positions on the PCI bus does.
[Venkatesh Ramamurthy] Just think an end-user fuguring out this
Why is this a SCSI ML problem? The problem is that the OS can't figure out
where to mount root from. Sounds like an OS problem.
I think the file system label is the leading candidate to solve this. One
really does not care if the root disk is called /dev/sda or /dev/fred. All
one cares
Venkatesh Ramamurthy wrote:
>
> Hi,
> I have one issue which requires fix from the linux kernel.
> Initially i put a SCSI controller and install the OS on the drive connected
> to it. After installing the OS (on sda), the customer puts another SCSI
> controller. The BIOS for the first controller
> > Is someone handling this already?
>
> "mount by uuid"?
>
> Amiga's Rigid Disk Block?
[Venkatesh Ramamurthy] Something like this is better. The problem
is where do we store this info. Last sector is one of the options. Does
anyone know where NT stores this info?
-
To unsubscribe
> This is due to the fixed ordering of the scsi drivers. You can change the
> order of the scsi hosts with the "scsihosts" kernel parameter. See
> linux/drivers/scsi/scsi.c
[Venkatesh Ramamurthy] I think it would be a nice idea if we can
make this process automatic , with out user typing
On Tue, 16 Jan 2001, Venkatesh Ramamurthy wrote:
> we need some kind of signature being written in the drive, which the kernel
> will use for determining the boot drive and later re-order drives, if
> required.
>
> Is someone handling this already?
"mount by uuid"?
Amiga's Rigid Disk Block?
> When the cards are of different make the order is solely dependent on
> the order that the drivers are initialized in the kernel. If you have
> modules enabled, only build the driver for your root device into the
> kernel image and have the other modular. This lets you control the
>
> In article <1355693A51C0D211B55A00105ACCFE64E9518C@ATL_MS1> you wrote:
>
> > we need some kind of signature being written in the drive, which the
> kernel
> > will use for determining the boot drive and later re-order drives, if
> > required.
>
> Like the ext2 labels? (man e2label)
sh Ramamurthy"
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "'Alan
Cox'" <[EMAIL PROTECTED]>
Sent: Tuesday, January 16, 2001 5:19 PM
Subject: RE: Linux not adhering to BIOS Drive boot order?
> > It should be possible to read the
Venkatesh Ramamurthy wrote:
>
> > It should be possible to read the BIOS setting for this option and
> > behave accordingly. Please give full details of how to read and interpret
> > the information stored in the CMOS for all versions of AMI BIOS, and I'll
> > take a look at this.
>
In article <1355693A51C0D211B55A00105ACCFE64E9518C@ATL_MS1> you wrote:
> we need some kind of signature being written in the drive, which the kernel
> will use for determining the boot drive and later re-order drives, if
> required.
Like the ext2 labels? (man e2label)
Greetings,
Arjan van
> It should be possible to read the BIOS setting for this option and
> behave accordingly. Please give full details of how to read and interpret
> the information stored in the CMOS for all versions of AMI BIOS, and I'll
> take a look at this.
[Venkatesh Ramamurthy] When i meant BIOS
[EMAIL PROTECTED] said:
> we need some kind of signature being written in the drive, which the
> kernel will use for determining the boot drive and later re-order
> drives, if required.
> Is someone handling this already?
It should be possible to read the BIOS setting for this option and
In article 1355693A51C0D211B55A00105ACCFE64E9518C@ATL_MS1 you wrote:
we need some kind of signature being written in the drive, which the kernel
will use for determining the boot drive and later re-order drives, if
required.
Like the ext2 labels? (man e2label)
Greetings,
Arjan van de Ven
David Woodhouse wrote :
[EMAIL PROTECTED] said:
we need some kind of signature being written in the drive, which the
kernel will use for determining the boot drive and later re-order
drives, if required.
Is someone handling this already?
It should be possible to read
On Tue, 16 Jan 2001 16:51:38 GMT, Venkatesh Ramamurthy [EMAIL PROTECTED] wrote:
[Venkatesh Ramamurthy] Just think an end-user fuguring out this
Asking him to change PCI slots and trying it out. My point is the end user
should not worry about all this. All he does is plugs a new
If we can truly go for label based mounting
and lilo'ing this would solve the problem.
From a layering point of view, it makes a lot more sense to
me for the label (or signature or whatever) for this purpose
to be in the partition table than inside the filesystem. The
parts of the system that
From a layering point of view, it makes a lot more sense to
me for the label (or signature or whatever) for this purpose
to be in the partition table than inside the filesystem. The
parts of the system that assign devices their identities already
know about that part of the disk.
[EMAIL PROTECTED] said:
[Venkatesh Ramamurthy]
Your name is already in the headers of the mail you sent. There's no need to
repeat it.
The LILO boot loader and the LILO command line utility should be changed
for this.
Is anybody doing this? -
There are patches available for the
** Reply to message from Eddie Williams [EMAIL PROTECTED] on Tue,
16 Jan 2001 12:24:49 -0500
That is not totally true. There are two problems here, one is where you have
different controllers in your system and the other is where you have multiples
of the same controller. What you list
Guys,
And this is a problem that has plagues all PC operating systems, but has
never
been a problem on the Macintosh. Why? Because the Mac was designed to
handle
this problem, but the PC never was.
Quite true on this point.
The Mac never enumerates its devices like the PC does (no C: D:
Timur Tabi wrote:
And this is a problem that has plagues all PC operating systems, but has never
been a problem on the Macintosh. Why? Because the Mac was designed to handle
this problem, but the PC never was.
The Mac never enumerates its devices like the PC does (no C: D: etc, no
On Tue, Jan 16, 2001 at 03:37:57PM -0500, Michael Meissner wrote:
don't assume that the way your system gets booted is the way everybody's does,
particularly those on platforms other than the x86.
I must say, as a 5 year Linux user (and 23 year UNIX user/administrator), I do
get tired of
** Reply to message from "Christopher Friesen" [EMAIL PROTECTED] on
Tue, 16 Jan 2001 14:54:23 -0500
The Mac never enumerates its devices like the PC does (no C: D: etc, no
/dev/sda, /dev/sdb, or anything like that). It also remembers the boot device
in its EEPROM (the Startup Disk
David Woodhouse writes:
There are patches available for the 2.2 kernel which provide the facility
to mount by UUID or volume label. It seems that nobody is actively
maintaining those at the moment. If you want to update those to the current
2.2 and 2.4 kernels, well volunteered.
I'm quite
On Tue, Jan 16, 2001 at 10:01:25PM +0100, Andi Kleen wrote:
On Tue, Jan 16, 2001 at 03:37:57PM -0500, Michael Meissner wrote:
don't assume that the way your system gets booted is the way everybody's does,
particularly those on platforms other than the x86.
I must say, as a 5 year Linux
[EMAIL PROTECTED] said:
Like the ext2 labels? (man e2label)
[Venkatesh Ramamurthy] This re-ordering of the scsi drives should be
done by SCSI ML , so is incorporating ext2 fs data structure knowledge
on the SCSI ML a good idea?.
You'd better not care what the drives ae called - it
[Venkatesh Ramamurthy]
[Venkatesh Ramamurthy] I think there should be a better way to handle
this , compiling is one of the options, but an end-user should not
think of compiling. The end user needs to put an another card and
connect drives and get his system up and running. He should not
You seem to be full of things that "we" can implement. So I just have
to wonder: do you by any chance have some prototype code somewhere to
figure out, reliably, which SCSI cards have BIOS extensions enabled,
and the order they hook in?
[Venkat] It would be a very bad idea for the
On Tue, 16 Jan 2001, Michael Meissner wrote:
you're forgetting that in /etc/lilo.conf there is a directive called
'append='... all the user has to do is merely add
'append="scsihosts=whatever,whatever"' into their config file and rerun
lilo. problem solved
That's assuming you are
[Michael Meissner]
Ummm, I just reread the 2.4 Changes file once again just to be sure,
and it did not cover this issue. So how the *$@% are people supposed
to "read some docs" to know about this, if the docs don't mention the
information. I know people have been complaining about this
Why is this a SCSI ML problem? The problem is that the OS can't figure
out
where to mount root from. Sounds like an OS problem.
I think the file system label is the leading candidate to solve this. One
really does not care if the root disk is called /dev/sda or /dev/fred.
All
one
Venkatesh Ramamurthy wrote:
When the cards are of different make the order is solely dependent on
the order that the drivers are initialized in the kernel. If you have
modules enabled, only build the driver for your root device into the
kernel image and have the other modular. This
Venkatesh Ramamurthy wrote:
Hi,
I have one issue which requires fix from the linux kernel.
Initially i put a SCSI controller and install the OS on the drive connected
to it. After installing the OS (on sda), the customer puts another SCSI
controller. The BIOS for the first controller has
On Wed, 17 Jan 2001, J . A . Magallon wrote:
You want to make things SOOO easy for a 'dummy' user, and that user will never
use them. The average user you are targetting says: 'daddy, buy me a PC to
run Quake and do my school jobs' or 'please, dear vendor, I want a PC to
do my
On Tue, Jan 16, 2001 at 12:01:12PM -0800, Dr. Kelsey Hudson wrote:
On Tue, 16 Jan 2001, Venkatesh Ramamurthy wrote:
This is due to the fixed ordering of the scsi drivers. You can change the
order of the scsi hosts with the "scsihosts" kernel parameter. See
linux/drivers/scsi/scsi.c
On Tue, 16 Jan 2001, Venkatesh Ramamurthy wrote:
This is due to the fixed ordering of the scsi drivers. You can change the
order of the scsi hosts with the "scsihosts" kernel parameter. See
linux/drivers/scsi/scsi.c
[Venkatesh Ramamurthy] I think it would be a nice idea if we can
Of course that would be better. The only complaint I have with such a
system is that of backwards compatibility...as long as the legacy device
names are still supported i would have no problem with it at all.
however, this brings up an interesting question: what happens if two disks
On Tue, 16 Jan 2001, Venkatesh Ramamurthy wrote:
we need some kind of signature being written in the drive, which the kernel
will use for determining the boot drive and later re-order drives, if
required.
Is someone handling this already?
"mount by uuid"?
Amiga's Rigid Disk Block?
--
It should be possible to read the BIOS setting for this option and
behave accordingly. Please give full details of how to read and interpret
the information stored in the CMOS for all versions of AMI BIOS, and I'll
take a look at this.
[Venkatesh Ramamurthy] When i meant BIOS setting
Venkatesh Ramamurthy wrote:
It should be possible to read the BIOS setting for this option and
behave accordingly. Please give full details of how to read and interpret
the information stored in the CMOS for all versions of AMI BIOS, and I'll
take a look at this.
[Venkatesh
thy"
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; "'Alan
Cox'" [EMAIL PROTECTED]
Sent: Tuesday, January 16, 2001 5:19 PM
Subject: RE: Linux not adhering to BIOS Drive boot order?
It should be possible to read the BIOS setting for this option and
behave accordingly.
On Wed, Jan 17, 2001 at 12:32:05AM +0100, J . A . Magallon wrote:
If that is your idea of the average user... You're a system administrator,
you can have tons of scsi cards in your system if you want.
You want to make things SOOO easy for a 'dummy' user, and that user will never
use them.
In article 1355693A51C0D211B55A00105ACCFE64E9518C@ATL_MS1 you wrote:
we need some kind of signature being written in the drive, which the
kernel
will use for determining the boot drive and later re-order drives, if
required.
Like the ext2 labels? (man e2label)
[Venkatesh
When the cards are of different make the order is solely dependent on
the order that the drivers are initialized in the kernel. If you have
modules enabled, only build the driver for your root device into the
kernel image and have the other modular. This lets you control the
initialization
Why does the end-user have to compile the kernel? Most distributions
provide a kernel with no SCSI drivers in it, but use an initrd to get
the root SCSI driver in (man mkinitrd on any Redhat box). Just
distribute all SCSI drivers as modules and you won't have any problems.
That is not
Venkatesh Ramamurthy wrote:
Hi,
I have one issue which requires fix from the linux kernel.
Initially i put a SCSI controller and install the OS on the drive connected
to it. After installing the OS (on sda), the customer puts another SCSI
controller. The BIOS for the first controller has
you're forgetting that in /etc/lilo.conf there is a directive called
'append='... all the user has to do is merely add
'append="scsihosts=whatever,whatever"' into their config file and rerun
lilo. problem solved
besides, how many 'end-users' do you know of that will have multiple scsi
[EMAIL PROTECTED] said:
[Venkatesh Ramamurthy] If we can truly go for label based mouting
and lilo'ing this would solve the problem. Anybody doing this?
Red hat Linux 7.0.
--
Cheers
John Summerfield
http://www2.ami.com.au/ for OS/2 linux information.
Configuration, networking,
Is someone handling this already?
"mount by uuid"?
Amiga's Rigid Disk Block?
[Venkatesh Ramamurthy] Something like this is better. The problem
is where do we store this info. Last sector is one of the options. Does
anyone know where NT stores this info?
-
To unsubscribe from
This is due to the fixed ordering of the scsi drivers. You can change the
order of the scsi hosts with the "scsihosts" kernel parameter. See
linux/drivers/scsi/scsi.c
[Venkatesh Ramamurthy] I think it would be a nice idea if we can
make this process automatic , with out user typing in
[EMAIL PROTECTED] said:
we need some kind of signature being written in the drive, which the
kernel will use for determining the boot drive and later re-order
drives, if required.
Is someone handling this already?
It should be possible to read the BIOS setting for this option and
behave
Why is this a SCSI ML problem? The problem is that the OS can't figure out
where to mount root from. Sounds like an OS problem.
I think the file system label is the leading candidate to solve this. One
really does not care if the root disk is called /dev/sda or /dev/fred. All
one cares
The scsi host numbers will be allocated to the HBAs in
the order shown starting at 0. This method does not
distinguish between the two advansys controllers, luckily
swapping their positions on the PCI bus does.
[Venkatesh Ramamurthy] Just think an end-user fuguring out this
On Tue, 16 Jan 2001, Venkatesh Ramamurthy wrote:
[Venkatesh Ramamurthy] Dont you think that mounting and booting
based on disk label names is better, then relying on device nodes which can
change when a new card is added?. The existing patch for 2.2.xx is quite
small and it does not
On 2001.01.16 Michael Meissner wrote:
On Tue, Jan 16, 2001 at 12:01:12PM -0800, Dr. Kelsey Hudson wrote:
On Tue, 16 Jan 2001, Venkatesh Ramamurthy wrote:
..
besides, how many 'end-users' do you know of that will have multiple scsi
adapters in one system? how many end-users -period- will
Kelsey Hudson writes:
however, this brings up an interesting question: what happens if two disks
(presumably from two different machines) have the same disk label? what
happens then? for instance, i have several linux machines both at my
workplace and my home. if for some reason one of these
101 - 169 of 169 matches
Mail list logo
