Followup to: <[EMAIL PROTECTED]>
By author:David Woodhouse <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> 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 dri
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
> > > mul
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...
> 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 ?
I
[[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 detecte
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 sur
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 devic
[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, t
> > > 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 s
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 a
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 af
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 ass
> > 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 device.
> 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 t
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 i
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
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 m
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
> ftp://icaftp.epfl.
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
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
ftp://icaftp.epfl.ch/pub/people/almesber/booting/bo
[ 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' user
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 instanc
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 utilit
> 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 card
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 curre
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]
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 i
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 mount
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 dri
[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 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 linux-ke
[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 t
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 housekeepi
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
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 for
[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, c
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 yea
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 the
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 qu
** 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
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 o
> 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
> > > linux/drivers/scsi
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 no
> 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
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, 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
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 li
[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
> 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 controller
>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 th
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 n
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 possibl
> 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
A
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 is
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
> initializa
> 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)
[Ve
ot;Venkatesh 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 pos
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.
> [Venk
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
> 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 sett
[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
beha
87 matches
Mail list logo
