On Thu, Jan 18, 2001 at 10:53:16PM +0200, Matti Aarnio wrote:
> On Thu, Jan 18, 2001 at 09:59:06AM -0800, [EMAIL PROTECTED] wrote:
> ...
> > > Yes. PCI-based drivers will most likely use bus order since the kernel
> > > provides facilities to do this easily. For a single driver driving
> > >
On Thu, Jan 18, 2001 at 09:59:06AM -0800, [EMAIL PROTECTED] wrote:
...
> > Yes. PCI-based drivers will most likely use bus order since the kernel
> > provides facilities to do this easily. For a single driver driving
> > multiple cards on multiple bus types, who knows.
>
> Multiple bus
> What is the difference between physical and logical partitions ?
primary (what you call physical) partitions are partitions in their own
right logical partitions are partitions within a special partition
> How does this solve the "I deleted hda5 and now the old hda6 became
> hda5" problem ?
[[EMAIL PROTECTED]]
> Multiple bus types... Compaq server with PCI and EISA, for example?
> IIRC the EISA bus is bridged onto one of the PCI busses. Perhaps a
> breadth-first scan; PCI busses first, then bridged devices on PCI,
> then internal non-PCI busses, then external busses.
No, bridging
On Thu, Jan 18, 2001 at 06:50:12AM -0600, Peter Samuelson wrote:
> [James Bottomley]
> > The fundamental problem that we all agree on is that SCSI devices are
> > detected in the order that the mid-layer hosts.c file calls their
> > detect routines.
>
> That was yesterday. Today they are
Matti Aarnio ([EMAIL PROTECTED]) wrote :
> On Wed, Jan 17, 2001 at 08:22:22PM +0100, Werner Almesberger wrote:
>> The only cases when you really need to know the name of a disk is when
>> - doing disk-level management, e.g. partitioning or creating file
>> systems (*)
>> -
Matti Aarnio writes:
> And the partitions are PHYSICAL partition numbers,
> not some logical ones.
That is very interesting. Can you explain to me what
physical partition numbers are?
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
> > This is when devfs comes into its own, as the disks are refered to by
> > their device/controller id not by the /dev/sd{a,b,c,etc} numbering, hence
> > when one fails the others don't change. Also I think the kernel autodetect
> > code for scsi devices will deal with this case, but I'm not
On 18 Jan 2001 11:35:57 +, Tim Fletcher wrote:
> This is when devfs comes into its own, as the disks are refered to by
> their device/controller id not by the /dev/sd{a,b,c,etc} numbering, hence
> when one fails the others don't change. Also I think the kernel autodetect
> code for scsi
[James Bottomley]
> The fundamental problem that we all agree on is that SCSI devices are
> detected in the order that the mid-layer hosts.c file calls their
> detect routines.
That was yesterday. Today they are detected in the order they are
linked into the kernel, cf. the Makefile. But yes,
> > > How does MD/RAID0 know which array should be /dev/md0? What if you had a
> > > second array on /dev/hdb and /dev/hdd, would that become /dev/md0 (assuming
> > > it had a kernel/boot sector)?
> >
> > /etc/raidtab specifies which drives belong in which array, but I only have
> > hda and hdc
Tim Fletcher <[EMAIL PROTECTED]> wrote :
> > How does MD/RAID0 know which array should be /dev/md0? What if you had a
> > second array on /dev/hdb and /dev/hdd, would that become /dev/md0 (assuming
> > it had a kernel/boot sector)?
>
> /etc/raidtab specifies which drives belong in which
Andreas Dilger wrote:
>
> David Balazic writes:
> > Andreas Dilger <[EMAIL PROTECTED]> wrote :
> > > In the end I re-wrote most of the patch, so
> > > that we resolve ROOT_DEV before calling mount_root(), just to be a bit
> > > more consistent. I will release a new patch for 2.2.18 and 2.4.0
Andreas Dilger wrote:
> Ahh. What I was missing was that by specifying /dev/md0 as the root device,
> not only do you get an identical map for the kernels, but the root device
> remains /dev/md0 no matter which drive fails and LILO/kernel don't need to
> do anything special to find it. This
Andreas Dilger wrote:
Ahh. What I was missing was that by specifying /dev/md0 as the root device,
not only do you get an identical map for the kernels, but the root device
remains /dev/md0 no matter which drive fails and LILO/kernel don't need to
do anything special to find it. This
Andreas Dilger wrote:
David Balazic writes:
Andreas Dilger [EMAIL PROTECTED] wrote :
In the end I re-wrote most of the patch, so
that we resolve ROOT_DEV before calling mount_root(), just to be a bit
more consistent. I will release a new patch for 2.2.18 and 2.4.0 after
David
Tim Fletcher [EMAIL PROTECTED] wrote :
How does MD/RAID0 know which array should be /dev/md0? What if you had a
second array on /dev/hdb and /dev/hdd, would that become /dev/md0 (assuming
it had a kernel/boot sector)?
/etc/raidtab specifies which drives belong in which array, but
How does MD/RAID0 know which array should be /dev/md0? What if you had a
second array on /dev/hdb and /dev/hdd, would that become /dev/md0 (assuming
it had a kernel/boot sector)?
/etc/raidtab specifies which drives belong in which array, but I only have
hda and hdc so I can't
On 18 Jan 2001 11:35:57 +, Tim Fletcher wrote:
This is when devfs comes into its own, as the disks are refered to by
their device/controller id not by the /dev/sd{a,b,c,etc} numbering, hence
when one fails the others don't change. Also I think the kernel autodetect
code for scsi devices
[James Bottomley]
The fundamental problem that we all agree on is that SCSI devices are
detected in the order that the mid-layer hosts.c file calls their
detect routines.
That was yesterday. Today they are detected in the order they are
linked into the kernel, cf. the Makefile. But yes, the
This is when devfs comes into its own, as the disks are refered to by
their device/controller id not by the /dev/sd{a,b,c,etc} numbering, hence
when one fails the others don't change. Also I think the kernel autodetect
code for scsi devices will deal with this case, but I'm not sure.
Matti Aarnio ([EMAIL PROTECTED]) wrote :
On Wed, Jan 17, 2001 at 08:22:22PM +0100, Werner Almesberger wrote:
The only cases when you really need to know the name of a disk is when
- doing disk-level management, e.g. partitioning or creating file
systems (*)
- adding a
What is the difference between physical and logical partitions ?
primary (what you call physical) partitions are partitions in their own
right logical partitions are partitions within a special partition
How does this solve the "I deleted hda5 and now the old hda6 became
hda5" problem ?
It
[[EMAIL PROTECTED]]
Multiple bus types... Compaq server with PCI and EISA, for example?
IIRC the EISA bus is bridged onto one of the PCI busses. Perhaps a
breadth-first scan; PCI busses first, then bridged devices on PCI,
then internal non-PCI busses, then external busses.
No, bridging is
On Thu, Jan 18, 2001 at 09:59:06AM -0800, [EMAIL PROTECTED] wrote:
...
Yes. PCI-based drivers will most likely use bus order since the kernel
provides facilities to do this easily. For a single driver driving
multiple cards on multiple bus types, who knows.
Multiple bus types... Compaq
Matti Aarnio writes:
And the partitions are PHYSICAL partition numbers,
not some logical ones.
That is very interesting. Can you explain to me what
physical partition numbers are?
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Thu, Jan 18, 2001 at 06:50:12AM -0600, Peter Samuelson wrote:
[James Bottomley]
The fundamental problem that we all agree on is that SCSI devices are
detected in the order that the mid-layer hosts.c file calls their
detect routines.
That was yesterday. Today they are detected in the
> > I have a mirrored boot drive in a pair of firewalls / routers and to test
> > before I put them into service I pulled hda and the machine booted fine
> > from hdc and baring winging about the missing disk (all the drives are
> > mirrored) carried on as normal. A fresh disk was put and rebuilt
Tim Fletcher writes:
> You can already do this, just specify /dev/md0 as the device to install
> onto, and lilo does the rest
>
> > This would potentially allow you to boot from the second drive if the
> > first one fails, assuming the kernel does UUID or LABEL resolution for
> > the root
> What _would_ be interesting, and still not affect the boot loader proper,
> is to allow specifying multiple boot devices in /etc/lilo.conf (for e.g.
> RAID 1 setups), and then /sbin/lilo would put a boot sector on each such
> drive.
You can already do this, just specify /dev/md0 as the device
David Balazic writes:
> Andreas Dilger <[EMAIL PROTECTED]> wrote :
> > In the end I re-wrote most of the patch, so
> > that we resolve ROOT_DEV before calling mount_root(), just to be a bit
> > more consistent. I will release a new patch for 2.2.18 and 2.4.0 after
> > David Balazic has a look at
Andreas Dilger writes:
> Same thing, really. You have to poke each drive to get the serial
> number. What if they are IDE or SCSI or FCAL or RAID array? Probably
> reading a block from a disk is safer than trying to find the drive
> serial number.
If you apply the "read block from disk"
On Wed, 17 Jan 2001, Werner Almesberger wrote:
> "no", because you don't have to do it in the kernel. You can mount by
> uuid or label. For the root FS, you do this from an initrd. Problem
> solved.
>
> The only cases when you really need to know the name of a disk is when
> - doing disk-level
Matti Aarnio wrote:
> 2.4.0 with devfs mounted at boot time into /dev/
Or /proc/partitions, which - according to the mount(8) man page - has
been around since 2.1.116. So we're not exactly talking crazy upgrade
paths here.
> This new style (which contains, hopefully, physical PCI location)
Werner, you write:
> Venkatesh Ramamurthy wrote:
> > [Venkatesh Ramamurthy] The LILO boot loader and the LILO command
> > line utility should be changed for this. There are some issues when we have
>
> Grr, I was just waiting for this ...
>
> See sections 2.6 and 3.5 of
>
On Wed, Jan 17, 2001 at 08:22:22PM +0100, Werner Almesberger wrote:
> The only cases when you really need to know the name of a disk is when
> - doing disk-level management, e.g. partitioning or creating file
>systems (*)
> - adding a swap partition (sigh)
> - telling your boot loader
Venkatesh Ramamurthy wrote:
> [Venkatesh Ramamurthy] The LILO boot loader and the LILO command
> line utility should be changed for this. There are some issues when we have
Grr, I was just waiting for this ...
See sections 2.6 and 3.5 of
[ Ccs trimmed ]
Dr. Kelsey Hudson wrote:
> *single* scsi adapter in their systems? do we need to bloat the kernel
> with automatic things like this? no... i think it is handled fine the way
"no", because you don't have to do it in the kernel. You can mount by
uuid or label. For the root FS, you
Michael Meissner wrote:
>
> 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'
On Tue, Jan 16, 2001 at 08:14:01PM -0600, Peter Samuelson wrote:
>
> [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
On Wed, Jan 17, 2001 at 11:16:58AM -0500, James Bottomley wrote:
> One of the ways this could be solved would be to impose bus ordering on the
> detection sequence.
> ...
On Solaris and Irix, there is an auxillary file in /etc that maps
the hardware path to a controller to a controller
OK, what about a compromise.
The fundamental problem that we all agree on is that SCSI devices are detected
in the order that the mid-layer hosts.c file calls their detect routines.
Further, for multiple cards of the same type, the detection order is up to the
individual driver. A different
On 2001.01.17 Ishikawa wrote:
> Anyway, I view myself a typical Linux end-user in
> the framework of linux system hacker, linux
> tools developer and the rest (user).
> All I do on my PC is run netscape, read e-mails,
> post news articles, run editor to edit documents,
> and compile a few
> 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 machines dies due
Dr. Kelsey Hudson ([EMAIL PROTECTED]) wrote :
>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
Matthew D. Pitts ([EMAIL PROTECTED]) wrote :
> 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.
>
Andreas Dilger <[EMAIL PROTECTED]> wrote :
> 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
On Wed, 17 Jan 2001, David Balazic wrote:
> BTW, where is the scsihosts= kernel parameter documented ?
linux/Documentation/filesystems/devfs/README
Regards,
Zoltan Boszormenyi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Dr. Kelsey Hudson wrote :
> On Tue, 16 Jan 2001, Michael Meissner wrote:
> > I'm an end-user, and I have 3 scsi-adapters of two different brands in my
> > system. Many of the people using Linux in high end things like servers,
> > etc. will have multiple scsi controlers. People are using Linux
Jeff writes:
> David Woodhouse wrote:
> >
> > [EMAIL PROTECTED] said:
> > > One reason why this may NOT ever make it into the kernel is that I
> > > know "kernel poking at devices" is really frowned upon.
> >
> > A possible alternative is to specify drives by serial number.
>
> Currently
David Woodhouse writes:
> [EMAIL PROTECTED] said:
> > One reason why this may NOT ever make it into the kernel is that I
> > know "kernel poking at devices" is really frowned upon.
>
> A possible alternative is to specify drives by serial number.
Same thing, really. You have to poke each
[EMAIL PROTECTED] said:
> The one thing I don't know is... can the kernel mount the root fs if
> only given the uuid?
There are 2.2 patches to do it, which I think are now being dusted off and
resurrected. but scanning for UUID involves poking at every partition on
every available hard
David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > One reason why this may NOT ever make it into the kernel is that I
> > know "kernel poking at devices" is really frowned upon.
>
> A possible alternative is to specify drives by serial number.
Currently mount(8) supports mounting by '-L '
"J . A . Magallon" wrote:
>
>
> Average users you are targetting with that automagical
> card detection even do not know there are SCSI and IDE disks. They just
> want a 30Gb ide disk to install linux and play. If they involve with SCSI
> and ID numbers and multiple cards and so on they can read
[EMAIL PROTECTED] said:
> One reason why this may NOT ever make it into the kernel is that I
> know "kernel poking at devices" is really frowned upon.
A possible alternative is to specify drives by serial number.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe
[EMAIL PROTECTED] said:
One reason why this may NOT ever make it into the kernel is that I
know "kernel poking at devices" is really frowned upon.
A possible alternative is to specify drives by serial number.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe
David Woodhouse wrote:
[EMAIL PROTECTED] said:
One reason why this may NOT ever make it into the kernel is that I
know "kernel poking at devices" is really frowned upon.
A possible alternative is to specify drives by serial number.
Currently mount(8) supports mounting by '-L label'
[EMAIL PROTECTED] said:
The one thing I don't know is... can the kernel mount the root fs if
only given the uuid?
There are 2.2 patches to do it, which I think are now being dusted off and
resurrected. but scanning for UUID involves poking at every partition on
every available hard drive.
David Woodhouse writes:
[EMAIL PROTECTED] said:
One reason why this may NOT ever make it into the kernel is that I
know "kernel poking at devices" is really frowned upon.
A possible alternative is to specify drives by serial number.
Same thing, really. You have to poke each drive to
Dr. Kelsey Hudson wrote :
On Tue, 16 Jan 2001, Michael Meissner wrote:
I'm an end-user, and I have 3 scsi-adapters of two different brands in my
system. Many of the people using Linux in high end things like servers,
etc. will have multiple scsi controlers. People are using Linux in lots
On Wed, 17 Jan 2001, David Balazic wrote:
BTW, where is the scsihosts= kernel parameter documented ?
linux/Documentation/filesystems/devfs/README
Regards,
Zoltan Boszormenyi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Andreas Dilger [EMAIL PROTECTED] wrote :
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
Matthew D. Pitts ([EMAIL PROTECTED]) wrote :
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.
Dr. Kelsey Hudson ([EMAIL PROTECTED]) wrote :
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
On 2001.01.17 Ishikawa wrote:
Anyway, I view myself a typical Linux end-user in
the framework of linux system hacker, linux
tools developer and the rest (user).
All I do on my PC is run netscape, read e-mails,
post news articles, run editor to edit documents,
and compile a few utilities
On Tue, Jan 16, 2001 at 08:14:01PM -0600, Peter Samuelson wrote:
[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
Venkatesh Ramamurthy wrote:
[Venkatesh Ramamurthy] The LILO boot loader and the LILO command
line utility should be changed for this. There are some issues when we have
Grr, I was just waiting for this ...
See sections 2.6 and 3.5 of
Werner, you write:
Venkatesh Ramamurthy wrote:
[Venkatesh Ramamurthy] The LILO boot loader and the LILO command
line utility should be changed for this. There are some issues when we have
Grr, I was just waiting for this ...
See sections 2.6 and 3.5 of
Andreas Dilger writes:
Same thing, really. You have to poke each drive to get the serial
number. What if they are IDE or SCSI or FCAL or RAID array? Probably
reading a block from a disk is safer than trying to find the drive
serial number.
If you apply the "read block from disk" method to
David Balazic writes:
Andreas Dilger [EMAIL PROTECTED] wrote :
In the end I re-wrote most of the patch, so
that we resolve ROOT_DEV before calling mount_root(), just to be a bit
more consistent. I will release a new patch for 2.2.18 and 2.4.0 after
David Balazic has a look at it.
What _would_ be interesting, and still not affect the boot loader proper,
is to allow specifying multiple boot devices in /etc/lilo.conf (for e.g.
RAID 1 setups), and then /sbin/lilo would put a boot sector on each such
drive.
You can already do this, just specify /dev/md0 as the device to
Tim Fletcher writes:
You can already do this, just specify /dev/md0 as the device to install
onto, and lilo does the rest
This would potentially allow you to boot from the second drive if the
first one fails, assuming the kernel does UUID or LABEL resolution for
the root device. The
I have a mirrored boot drive in a pair of firewalls / routers and to test
before I put them into service I pulled hda and the machine booted fine
from hdc and baring winging about the missing disk (all the drives are
mirrored) carried on as normal. A fresh disk was put and rebuilt no
"J . A . Magallon" wrote:
Average users you are targetting with that automagical
card detection even do not know there are SCSI and IDE disks. They just
want a 30Gb ide disk to install linux and play. If they involve with SCSI
and ID numbers and multiple cards and so on they can read some
On Wed, 17 Jan 2001, Werner Almesberger wrote:
"no", because you don't have to do it in the kernel. You can mount by
uuid or label. For the root FS, you do this from an initrd. Problem
solved.
The only cases when you really need to know the name of a disk is when
- doing disk-level
Michael Meissner wrote:
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
OK, what about a compromise.
The fundamental problem that we all agree on is that SCSI devices are detected
in the order that the mid-layer hosts.c file calls their detect routines.
Further, for multiple cards of the same type, the detection order is up to the
individual driver. A different
Matti Aarnio wrote:
2.4.0 with devfs mounted at boot time into /dev/
Or /proc/partitions, which - according to the mount(8) man page - has
been around since 2.1.116. So we're not exactly talking crazy upgrade
paths here.
This new style (which contains, hopefully, physical PCI location)
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 machines dies due
to
[ Ccs trimmed ]
Dr. Kelsey Hudson wrote:
*single* scsi adapter in their systems? do we need to bloat the kernel
with automatic things like this? no... i think it is handled fine the way
"no", because you don't have to do it in the kernel. You can mount by
uuid or label. For the root FS, you
On Wed, Jan 17, 2001 at 08:22:22PM +0100, Werner Almesberger wrote:
The only cases when you really need to know the name of a disk is when
- doing disk-level management, e.g. partitioning or creating file
systems (*)
- adding a swap partition (sigh)
- telling your boot loader where to
[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
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
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, 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
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-
> 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
[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
[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 -
[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,
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
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
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
** 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
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 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, 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
> > >
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
> 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
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
1 - 100 of 171 matches
Mail list logo
