Re: Linux not adhering to BIOS Drive boot order?
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
> > > multiple cards on multiple bus types, who knows.
> >
> > 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.
> >
> > Are there any systems where a non-PCI bus is not connected through a
> > PCI-foo bridge?
>
> Yes.
>
> Oh, you propably won't meet them in PC world, but pick
> any UltraSPARC; PCI and SBUS are on parallel "hoses".
> ("hose" is term used at Alpha code for the IO-bus to
>CPU/MEMORY bus interface, sort of "north bridge".)
> Actually those UltraSPARC systems have core-bus called UPA,
> and IO-busses, like PCI and SBUS, are connected there...
>
> Also these "big" systems often do come with multiple "hoses"
> of same type.
>
> If you look carefully at intel things, there is this "FSB"
> which is the real core-bus, and IO-busses hang on it.
>
>
> I have never myself seen big Digital Alpha system where IO-
> busses are anything but PCI, but there exists options to place
> there FutureBus+, PCI, VME, TurboChannel, and several other
> DEC proprietary things. With 43-45 bits of physical address
> space out of the processors, it is trivial to plug in multiple
> 32-bit address space busses.
>
> In coherent view NUMA implementation of Linux, there possibly
> comes even the detail about which NUMA node the busses reside at.
I'm pretty sure the IBM PC-Server 700 (8 MCA-slots and 8 PCI-slots
and a lot of other cool stuff) doesn't have the MCA-bus bridged
onto the PCI-bus. Maybe the other way around. I'd be happy to get one
of these machines to test this, but they seem to be a little hard
to get by for free... :^)
/David
_ _
// David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\
// Project MCA Linux hacker// Dance across the winter sky //
\> http://www.acc.umu.se/~tao/http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 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.
>
> Are there any systems where a non-PCI bus is not connected through a
> PCI-foo bridge?
Yes.
Oh, you propably won't meet them in PC world, but pick
any UltraSPARC; PCI and SBUS are on parallel "hoses".
("hose" is term used at Alpha code for the IO-bus to
CPU/MEMORY bus interface, sort of "north bridge".)
Actually those UltraSPARC systems have core-bus called UPA,
and IO-busses, like PCI and SBUS, are connected there...
Also these "big" systems often do come with multiple "hoses"
of same type.
If you look carefully at intel things, there is this "FSB"
which is the real core-bus, and IO-busses hang on it.
I have never myself seen big Digital Alpha system where IO-
busses are anything but PCI, but there exists options to place
there FutureBus+, PCI, VME, TurboChannel, and several other
DEC proprietary things. With 43-45 bits of physical address
space out of the processors, it is trivial to plug in multiple
32-bit address space busses.
In coherent view NUMA implementation of Linux, there possibly
comes even the detail about which NUMA node the busses reside at.
> -- Ferret
/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
> 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 doesn't nothing can as the way that the pcbios extended partition works as a (linked?) list of partitions so removing one shuffles the rest up. -- Tim Fletcher - Network manager .~. /V\ L I N U X [EMAIL PROTECTED]// \\ >Don't fear the penguin< [EMAIL PROTECTED] /( )\ irc: Night-Shade on quakenet ^^-^^ "While preceding your entrance with a grenade is a good tactic in Quake, it can lead to problems if attempted at work." -- C Hacking - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[[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 transparent to most drivers, so this doesn't necessarily make sense. The thing to do is just decree "drivers will be registered in *this* order..." and then list the busses in some arbitrary order, and specify some sub-scheme for enumerating drivers on each bus. ...Which still doesn't solve the problem of multiple device types on a single bus, for which I think my proposal (passing a meta-address of some sort into scsi_register() and similar, and letting it sort devices as they come in. (Until the end of the bootstrap, of course. Modules all go in at the end.) > Are there any systems where a non-PCI bus is not connected through a > PCI-foo bridge? There are lots of non-PCI systems out there. And quite a few, I suspect, where PCI is bridged off the "native" bus rather than the other way 'round. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 order they are > linked into the kernel, cf. the Makefile. But yes, the problem is > basically the same. > > > Further, for multiple cards of the same type, the detection order is > > up to the individual driver. > > 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 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. Are there any systems where a non-PCI bus is not connected through a PCI-foo bridge? -- Ferret - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 swap partition (sigh) >> - telling your boot loader where to put its boot sector > > 2.4.0 with devfs mounted at boot time into /dev/ > > Only thing missing is that here /dev/scsi/host0/ propably should be > a symlink to something like /dev/bus/pci/BB/II.F ... > Or perhaps /dev/scsi/BUS/BB/II.F/busN/targetT/lunL/partP > but mixing in ISA-bus controllers is somewhat tough.. > >$ mount >/dev/scsi/host0/bus0/target0/lun0/part3 on / type ext2 (rw) >/dev/scsi/host0/bus0/target2/lun0/part2 on /home type ext2 (rw) >/dev/scsi/host0/bus0/target0/lun0/part4 on /usr type ext2 (rw) >/dev/scsi/host0/bus0/target2/lun0/part1 on /usr/src type ext2 (rw) >/dev/scsi/host0/bus0/target0/lun0/part1 on /boot type ext2 (rw) > I do, of course, use mounting with LABEL= > > This new style (which contains, hopefully, physical PCI location) > mount device paths will failry easily handle question about which > is where... And the partitions are PHYSICAL partition numbers, > not some logical ones. That is true with /dev/sdXP case as well > as with /dev/hdXP case. What is the difference between physical and logical partitions ? How does this solve the "I deleted hda5 and now the old hda6 became hda5" problem ? -- David Balazic -- "Be excellent to each other." - Bill & Ted - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
> > 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.
>
> 'would be great to use driver name, e.g. something like
> /dev/scsi/advansys/... (I don't remember devfs naming scheme)
Then you are back to the arguement about should the naming be based on the
function of the device (scsi0,1,2 / eth0,1,2) or based on the hardware
(aic7xxx0,1,2 advansys0,1,2 / tulip0,1,2 eepro0,1,2). *BSD uses this
naming scheme for its ethernet interfaces, not sure about its scsi thou.
I prefer the functional naming scheme (scsi0 / eth0) as I can change the
hardware in a machine and not change anything in the init scripts,
assuming the driver is in kernel or if not I only need to change the line
/etc/modules.conf.
--
Tim Fletcher - Network manager .~.
/V\ L I N U X
[EMAIL PROTECTED]// \\ >Don't fear the penguin<
[EMAIL PROTECTED] /( )\
irc: Night-Shade on quakenet ^^-^^
"I am Homer of Borg. Prepare to Oooh! Doughnuts!"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 will deal with this case, but I'm not sure.
'would be great to use driver name, e.g. something like
/dev/scsi/advansys/... (I don't remember devfs naming scheme)
Xav
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[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 problem is basically the same. > Further, for multiple cards of the same type, the detection order is > up to the individual driver. 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. > One of the ways this could be solved would be to impose bus ordering > on the detection sequence. This would be rather an intrusive change, since it puts the burden on hosts.c to know what devices are where rather than on each driver. A much less intrusive (?) variation: scsi_register() is given the device location in some form. It would then use insertion sort to add the new adapter to the list of known ones. Obviously this behavior should only apply until the end of the boot sequence -- modules always get put on the end of the list. The bus location would be a 32-bit number, perhaps, with the high 8 bits for bus type and the low 24 bits for further enumeration (for PCI: 8 bits each for bus, slot, and fn). Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
> > > 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 really answer the question
>
> What happens if /dev/md0 is /dev/sda and /dev/sdc ( the system also has
> sdb )
> and sda fails or is removed ?
> the old sdb will now be sda and old-sdc will be sdb.
> md0 will look into sda , which is now the non-md disk , and
> sdc , which doesn't exists any more ???
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.
--
Tim Fletcher - Network manager .~.
/V\ L I N U X
[EMAIL PROTECTED]// \\ >Don't fear the penguin<
[EMAIL PROTECTED] /( )\
irc: Night-Shade on quakenet ^^-^^
Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum
immane mittam (For non-latiners: "I have a catapult. Give me all the
money, or I will fling an enormous rock at your head.")
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 I only have > hda and hdc so I can't really answer the question What happens if /dev/md0 is /dev/sda and /dev/sdc ( the system also has sdb ) and sda fails or is removed ? the old sdb will now be sda and old-sdc will be sdb. md0 will look into sda , which is now the non-md disk , and sdc , which doesn't exists any more ??? -- David Balazic -- "Be excellent to each other." - Bill & Ted - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 Balazic has a look at it. > > > > Cool, send it to me ! > > Need to test it a bit first (i.e. at least compile it)... I will just throw a quick look into it , nothing more , as my setup is a mess right now. I no kernel guru either, I just wrote the patch :-) > > > I know a bit about LILO, so I should be able to get the "root=LABEL=" to > > > work there as well. > > > > There were no problems with the original patch with LILO. > > You just must use append="root=x" instead of simply > > root=xxx , because LILO tries to be "smart" at least the > > version I used then did. > > Actually, there are 2 ways to go about this: LILO could do the UUID/LABEL > resolution at the time lilo is run (to store root dev into kernel), and > _also_ append "root=LABEL=X" to kernel options, so that if the kernel > can't resolve the UUID/LABEL (i.e. no support for this option) we can fall > back to the root dev from when LILO was run. > > > > One reason why this may NOT ever make it into the kernel is that I know > > > "kernel poking at devices" is really frowned upon. > > > > This an ugly hack , if you ask me. The identificators ( be it labels , > > UUIDs or whatever ) should be outside the partitions. Otherwise cases with > > swap partitions , unformatted > > partitions etc. can not be handled. > > LVM now has UUID-like identifiers for all "partitions" (Logical Volumes), > although they are not really accessible by any tools right now. The "LABEL" > is actually the LV name, so it is used directly all the time: > > /dev/vgroot/lvroot / ext3defaults1 1 > /dev/vgroot/lvswap noneswapsw,pri=100 0 0 Is /dev/vgroot some kind of pseudo filesystem ? With plain device files you have the same problems as with the "old" partitions , I think. ( they have to be mapped to minors and nodes for them must be created somehow ). I didn't try it yet and with devfs it should work OK. > This obviates most of the reason for the UUID/LABEL support, but not > everyone runs LVM (yet ;-) and ext2 UUID/LABELs are still useful. And LVM is not windows compatible , AFAIK, is it ? -- David Balazic -- "Be excellent to each other." - Bill & Ted - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 assumes the BIOS can boot from /dev/hdc > to start with (i.e. /dev/hda is totally gone). > > 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)? No problem. The /dev/md/0 device is made from partitions on various disks. With the 0.90-style raid all these partitions have a "raid superblock" at the end. The raid superblock isn't part of the filesystem itself. It stores ID information about which array it belongs to. (And where in the array if we are talking raid-0 or raid-5) Having a /dev/md/1 too is fine. It will record its different number in the raid superblock. This lets the kernel autodetect all the raid arrays during boot. This happens in a step after detecting the partitions themselves, before mounting root. This means you don't need any files to find the raid setup, and the root filesystem can be mounted on raid without any initrd crap. Raid devices are just "disks", just like the "real" disks. The raid superblock also means I could move one of my disks to another controller and change its scsi ID at the same time - RAID and RAID-mounted fses would still come up ok. Or I could move the entire raid set to another machine - if it doesn't have a /dev/md/0 set already. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 assumes the BIOS can boot from /dev/hdc to start with (i.e. /dev/hda is totally gone). 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)? No problem. The /dev/md/0 device is made from partitions on various disks. With the 0.90-style raid all these partitions have a "raid superblock" at the end. The raid superblock isn't part of the filesystem itself. It stores ID information about which array it belongs to. (And where in the array if we are talking raid-0 or raid-5) Having a /dev/md/1 too is fine. It will record its different number in the raid superblock. This lets the kernel autodetect all the raid arrays during boot. This happens in a step after detecting the partitions themselves, before mounting root. This means you don't need any files to find the raid setup, and the root filesystem can be mounted on raid without any initrd crap. Raid devices are just "disks", just like the "real" disks. The raid superblock also means I could move one of my disks to another controller and change its scsi ID at the same time - RAID and RAID-mounted fses would still come up ok. Or I could move the entire raid set to another machine - if it doesn't have a /dev/md/0 set already. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 Balazic has a look at it. Cool, send it to me ! Need to test it a bit first (i.e. at least compile it)... I will just throw a quick look into it , nothing more , as my setup is a mess right now. I no kernel guru either, I just wrote the patch :-) I know a bit about LILO, so I should be able to get the "root=LABEL=" to work there as well. There were no problems with the original patch with LILO. You just must use append="root=x" instead of simply root=xxx , because LILO tries to be "smart" at least the version I used then did. Actually, there are 2 ways to go about this: LILO could do the UUID/LABEL resolution at the time lilo is run (to store root dev into kernel), and _also_ append "root=LABEL=X" to kernel options, so that if the kernel can't resolve the UUID/LABEL (i.e. no support for this option) we can fall back to the root dev from when LILO was run. One reason why this may NOT ever make it into the kernel is that I know "kernel poking at devices" is really frowned upon. This an ugly hack , if you ask me. The identificators ( be it labels , UUIDs or whatever ) should be outside the partitions. Otherwise cases with swap partitions , any FS that doesn't support labels/UUIDs unformatted partitions etc. can not be handled. LVM now has UUID-like identifiers for all "partitions" (Logical Volumes), although they are not really accessible by any tools right now. The "LABEL" is actually the LV name, so it is used directly all the time: /dev/vgroot/lvroot / ext3defaults1 1 /dev/vgroot/lvswap noneswapsw,pri=100 0 0 Is /dev/vgroot some kind of pseudo filesystem ? With plain device files you have the same problems as with the "old" partitions , I think. ( they have to be mapped to minors and nodes for them must be created somehow ). I didn't try it yet and with devfs it should work OK. This obviates most of the reason for the UUID/LABEL support, but not everyone runs LVM (yet ;-) and ext2 UUID/LABELs are still useful. And LVM is not windows compatible , AFAIK, is it ? -- David Balazic -- "Be excellent to each other." - Bill Ted - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 I only have hda and hdc so I can't really answer the question What happens if /dev/md0 is /dev/sda and /dev/sdc ( the system also has sdb ) and sda fails or is removed ? the old sdb will now be sda and old-sdc will be sdb. md0 will look into sda , which is now the non-md disk , and sdc , which doesn't exists any more ??? -- David Balazic -- "Be excellent to each other." - Bill Ted - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 really answer the question
What happens if /dev/md0 is /dev/sda and /dev/sdc ( the system also has
sdb )
and sda fails or is removed ?
the old sdb will now be sda and old-sdc will be sdb.
md0 will look into sda , which is now the non-md disk , and
sdc , which doesn't exists any more ???
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.
--
Tim Fletcher - Network manager .~.
/V\ L I N U X
[EMAIL PROTECTED]// \\ Don't fear the penguin
[EMAIL PROTECTED] /( )\
irc: Night-Shade on quakenet ^^-^^
Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum
immane mittam (For non-latiners: "I have a catapult. Give me all the
money, or I will fling an enormous rock at your head.")
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 will deal with this case, but I'm not sure.
'would be great to use driver name, e.g. something like
/dev/scsi/advansys/... (I don't remember devfs naming scheme)
Xav
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[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 problem is basically the same. Further, for multiple cards of the same type, the detection order is up to the individual driver. 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. One of the ways this could be solved would be to impose bus ordering on the detection sequence. This would be rather an intrusive change, since it puts the burden on hosts.c to know what devices are where rather than on each driver. A much less intrusive (?) variation: scsi_register() is given the device location in some form. It would then use insertion sort to add the new adapter to the list of known ones. Obviously this behavior should only apply until the end of the boot sequence -- modules always get put on the end of the list. The bus location would be a 32-bit number, perhaps, with the high 8 bits for bus type and the low 24 bits for further enumeration (for PCI: 8 bits each for bus, slot, and fn). Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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.
'would be great to use driver name, e.g. something like
/dev/scsi/advansys/... (I don't remember devfs naming scheme)
Then you are back to the arguement about should the naming be based on the
function of the device (scsi0,1,2 / eth0,1,2) or based on the hardware
(aic7xxx0,1,2 advansys0,1,2 / tulip0,1,2 eepro0,1,2). *BSD uses this
naming scheme for its ethernet interfaces, not sure about its scsi thou.
I prefer the functional naming scheme (scsi0 / eth0) as I can change the
hardware in a machine and not change anything in the init scripts,
assuming the driver is in kernel or if not I only need to change the line
/etc/modules.conf.
--
Tim Fletcher - Network manager .~.
/V\ L I N U X
[EMAIL PROTECTED]// \\ Don't fear the penguin
[EMAIL PROTECTED] /( )\
irc: Night-Shade on quakenet ^^-^^
"I am Homer of Borg. Prepare to Oooh! Doughnuts!"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 swap partition (sigh) - telling your boot loader where to put its boot sector 2.4.0 with devfs mounted at boot time into /dev/ Only thing missing is that here /dev/scsi/host0/ propably should be a symlink to something like /dev/bus/pci/BB/II.F ... Or perhaps /dev/scsi/BUS/BB/II.F/busN/targetT/lunL/partP but mixing in ISA-bus controllers is somewhat tough.. $ mount /dev/scsi/host0/bus0/target0/lun0/part3 on / type ext2 (rw) /dev/scsi/host0/bus0/target2/lun0/part2 on /home type ext2 (rw) /dev/scsi/host0/bus0/target0/lun0/part4 on /usr type ext2 (rw) /dev/scsi/host0/bus0/target2/lun0/part1 on /usr/src type ext2 (rw) /dev/scsi/host0/bus0/target0/lun0/part1 on /boot type ext2 (rw) I do, of course, use mounting with LABEL= This new style (which contains, hopefully, physical PCI location) mount device paths will failry easily handle question about which is where... And the partitions are PHYSICAL partition numbers, not some logical ones. That is true with /dev/sdXP case as well as with /dev/hdXP case. What is the difference between physical and logical partitions ? How does this solve the "I deleted hda5 and now the old hda6 became hda5" problem ? -- David Balazic -- "Be excellent to each other." - Bill Ted - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 doesn't nothing can as the way that the pcbios extended partition works as a (linked?) list of partitions so removing one shuffles the rest up. -- Tim Fletcher - Network manager .~. /V\ L I N U X [EMAIL PROTECTED]// \\ Don't fear the penguin [EMAIL PROTECTED] /( )\ irc: Night-Shade on quakenet ^^-^^ "While preceding your entrance with a grenade is a good tactic in Quake, it can lead to problems if attempted at work." -- C Hacking - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[[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 transparent to most drivers, so this doesn't necessarily make sense. The thing to do is just decree "drivers will be registered in *this* order..." and then list the busses in some arbitrary order, and specify some sub-scheme for enumerating drivers on each bus. ...Which still doesn't solve the problem of multiple device types on a single bus, for which I think my proposal (passing a meta-address of some sort into scsi_register() and similar, and letting it sort devices as they come in. (Until the end of the bootstrap, of course. Modules all go in at the end.) Are there any systems where a non-PCI bus is not connected through a PCI-foo bridge? There are lots of non-PCI systems out there. And quite a few, I suspect, where PCI is bridged off the "native" bus rather than the other way 'round. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 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.
Are there any systems where a non-PCI bus is not connected through a
PCI-foo bridge?
Yes.
Oh, you propably won't meet them in PC world, but pick
any UltraSPARC; PCI and SBUS are on parallel "hoses".
("hose" is term used at Alpha code for the IO-bus to
CPU/MEMORY bus interface, sort of "north bridge".)
Actually those UltraSPARC systems have core-bus called UPA,
and IO-busses, like PCI and SBUS, are connected there...
Also these "big" systems often do come with multiple "hoses"
of same type.
If you look carefully at intel things, there is this "FSB"
which is the real core-bus, and IO-busses hang on it.
I have never myself seen big Digital Alpha system where IO-
busses are anything but PCI, but there exists options to place
there FutureBus+, PCI, VME, TurboChannel, and several other
DEC proprietary things. With 43-45 bits of physical address
space out of the processors, it is trivial to plug in multiple
32-bit address space busses.
In coherent view NUMA implementation of Linux, there possibly
comes even the detail about which NUMA node the busses reside at.
-- Ferret
/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 order they are linked into the kernel, cf. the Makefile. But yes, the problem is basically the same. Further, for multiple cards of the same type, the detection order is up to the individual driver. 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 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. Are there any systems where a non-PCI bus is not connected through a PCI-foo bridge? -- Ferret - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
> > 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 > > problems and was then booted off with the other disk missing. > > 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 assumes the BIOS can boot from /dev/hdc > to start with (i.e. /dev/hda is totally gone). Hence I have the disks in caddies to make taking them out all together easier, to force the bios to find the /dev/hdc as the boot drive > 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 really answer the question -- Tim Fletcher - Network manager .~. /V\ L I N U X [EMAIL PROTECTED]// \\ >Don't fear the penguin< [EMAIL PROTECTED] /( )\ irc: Night-Shade on quakenet ^^-^^ Never apply a StarTrek solution to a Babylon 5 problem - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 kernel would boot from the first BIOS drive, and > > would search for a UUID or LABEL as the root device. > > 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 > problems and was then booted off with the other disk missing. 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 assumes the BIOS can boot from /dev/hdc to start with (i.e. /dev/hda is totally gone). 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)? Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
> 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 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 kernel would boot from the first BIOS drive, and > would match search for a UUID or LABEL as the root device. I can confirm that this works on RedHat 6.2 + Lilo 0.21 + kernel 2.4.0-test8 and RAID1. 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 problems and was then booted off with the other disk missing. -- Tim Fletcher - Network manager .~. /V\ L I N U X [EMAIL PROTECTED]// \\ >Don't fear the penguin< [EMAIL PROTECTED] /( )\ irc: Night-Shade on quakenet ^^-^^ An NT server can be run by an idiot, and usually is. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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. > > Cool, send it to me ! Need to test it a bit first (i.e. at least compile it)... > > I know a bit about LILO, so I should be able to get the "root=LABEL=" to > > work there as well. > > There were no problems with the original patch with LILO. > You just must use append="root=x" instead of simply > root=xxx , because LILO tries to be "smart" at least the > version I used then did. Actually, there are 2 ways to go about this: LILO could do the UUID/LABEL resolution at the time lilo is run (to store root dev into kernel), and _also_ append "root=LABEL=X" to kernel options, so that if the kernel can't resolve the UUID/LABEL (i.e. no support for this option) we can fall back to the root dev from when LILO was run. > > One reason why this may NOT ever make it into the kernel is that I know > > "kernel poking at devices" is really frowned upon. > > This an ugly hack , if you ask me. The identificators ( be it labels , > UUIDs or whatever ) should be outside the partitions. Otherwise cases with > swap partitions , unformatted > partitions etc. can not be handled. LVM now has UUID-like identifiers for all "partitions" (Logical Volumes), although they are not really accessible by any tools right now. The "LABEL" is actually the LV name, so it is used directly all the time: /dev/vgroot/lvroot / ext3defaults1 1 /dev/vgroot/lvswap noneswapsw,pri=100 0 0 This obviates most of the reason for the UUID/LABEL support, but not everyone runs LVM (yet ;-) and ext2 UUID/LABELs are still useful. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 a RAID1 array, how you do you know whether you mean: 1) An active disk in the array 2) The actual array itself. Hint: With Raid 1, the disks are complete images of each other. You can mount a single disk which is/was part of a raid 1 array and read all data off it. If someone thinks about going down this road, make sure you check the multiple-device arrays BEFORE the physical disks! _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 management, e.g. partitioning or creating file >systems (*) > - adding a swap partition (sigh) > - telling your boot loader where to put its boot sector > > (* in principle, you could even avoid this, if you have some means of >identifying a disk (e.g. via the uuid of a file system). However, >I would consider such a solution to be overly fragile.) That's exactly my point...It doesn't need to be there; there are already ways around it. They just need to be documented, that's all. Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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) > mount device paths will failry easily handle question about which > is where... And the partitions are PHYSICAL partition numbers, Hmm, without PCI locations, you still need to know how the system determines which interface becomes host0. Also, PCI locations probably aren't the most user-friendly way for identifying things ;-) But for the occasional problem case where label or uuid don't work, any such information is, of course, valuable. - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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.ch/pub/people/almesber/booting/bootinglinux-0.ps.gz > for my views on such things. Actually, what is being discussed is not related to your above sections of the paper. AFAICS, the only change needed is to /sbin/lilo to resolve UUID and LABEL tags for "root=LABEL=turbo_root" fields in /etc/lilo.conf. This is not a bloat to the kernel, and doesn't change the boot loader at all, only the user-space block mapping code. 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. 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 kernel would boot from the first BIOS drive, and would match search for a UUID or LABEL as the root device. If /etc/fstab is also handled exclusively with UUID or LABEL (or LVM), then you don't care what the drives are called (excluding swap, hmmm, maybe we can add a signature to swap?). Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 put its boot sector 2.4.0 with devfs mounted at boot time into /dev/ Only thing missing is that here /dev/scsi/host0/ propably should be a symlink to something like /dev/bus/pci/BB/II.F ... Or perhaps /dev/scsi/BUS/BB/II.F/busN/targetT/lunL/partP but mixing in ISA-bus controllers is somewhat tough.. $ mount /dev/scsi/host0/bus0/target0/lun0/part3 on / type ext2 (rw) /dev/scsi/host0/bus0/target2/lun0/part2 on /home type ext2 (rw) /dev/scsi/host0/bus0/target0/lun0/part4 on /usr type ext2 (rw) /dev/scsi/host0/bus0/target2/lun0/part1 on /usr/src type ext2 (rw) /dev/scsi/host0/bus0/target0/lun0/part1 on /boot type ext2 (rw) I do, of course, use mounting with LABEL= This new style (which contains, hopefully, physical PCI location) mount device paths will failry easily handle question about which is where... And the partitions are PHYSICAL partition numbers, not some logical ones. That is true with /dev/sdXP case as well as with /dev/hdXP case. > - Werner /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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/bootinglinux-0.ps.gz for my views on such things. - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[ 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 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 management, e.g. partitioning or creating file systems (*) - adding a swap partition (sigh) - telling your boot loader where to put its boot sector (* in principle, you could even avoid this, if you have some means of identifying a disk (e.g. via the uuid of a file system). However, I would consider such a solution to be overly fragile.) - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 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 housekeeping'. I have seen so many cases (A buys PC, A tries to run > > brand new racing game that does not work, A goes shop and says: don't know > > what's wrong with this PC, look at it and call me when MyCarRacingGame > > works...). > > I also don't want things so complex for the people who need to do complex > things, that they give up in frustration with Linux and use something else like > *BSD, particularly when things are changed from the previous way they were done > in Linux. I agree things should be simple for simple configurations, but that > does not mean we should be throwing boat anchors and couches in the paths of > people who have more complex hardware. > > > 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 docs and > > rebuild a kernel. > > 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 change since at least the fall time frame. There has been some movement on the SCSI subsystem documentation front: http://www.linuxdoc.org/HOWTO/SCSI-2.4-HOWTO/ Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 the > > information. I know people have been complaining about this change > > since at least the fall time frame. > > SCSI host probe order has never been guaranteed, afaik -- this is not > new to 2.4. If you have multiple host adapters, you really need to use > the command line to say which is which, as always. If you don't, you > will be bitten eventually. > > "Eventually" in this case meant 2.2->2.4, perhaps, but that doesn't > make it an item for Documentation/Changes. Or is this not what you > were talking about? What I'm talking about is that whenever you have these flag day(*) type of operations, is weakens the whole Linux movement. Yes, each individual change might mean a few minutes to half an hour of a persons time, but cumulatively it just sends the signal that Linux is just a hackers toy. If people can't easily switch between kernels for instance due to the wrong disk being listed as the boot disk, or they have to replug which ethernet controller gets which cord, it will mean fewer people testing new kernels for instance. * http://www.tuxedo.org/~esr/jargon/html/entry/flag-day.html -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 instance number. This lets you name a device based on the controller instance number, and to possibly move to a different physical slot it if needed. Some examples: Irix /etc/ioconfig.conf: 2 /hw/module/1/slot/io9/fibre_channel/pci/0/scsi_ctlr/0 This says that SCSI controller 2 is really a Fibre Channel controller in slot 9 (on an Origin 2000). Solaris /etc/path_to_inst: "/pci@4,4000/scsi@3" 0 "qla2200" This says that the QLA2200 Fibre Channel controller in slot 3 of PCI bus 4,4000 is controller 0 (zero) for the qla2200 driver. "/pci@4,4000/scsi@3/sd@0,3" 737 "sd" This says that SCSI target 0 will be unit 737 for the sd driver. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 problem is that SCSI targets and LUNs are mapped sequentially to /dev/sd[a-z][a-d] so if you lose a device from the middle the ordering shifts. I think that devfs does a very good job of addressing the latter problem, since you can now use it's naming scheme to find the exact target/lun you were looking for. The former problem is really something that affects all adapter cards in the linux system (you have a similar problem for multiple ethernet cards, etc.) One of the ways this could be solved would be to impose bus ordering on the detection sequence. Since every computer bus (except the ancient ISA) has a way of getting its logical slot numbering (which is not necessarily related to physical slot numbering), you can easily impose this type of ordering on all card detection. Doing this would necessitate some surgery in the way device detection is done, probably major enough to make it a 2.5 feature. The up side would be that, as long as you maintain your cards in the same slot, the SCSI ordering would remain the same (you could even change the card and still have the same order). The compromise over UUID detection is that if you change the slot, all bets are off. If there is sufficient interest in this, I could look at putting together a patch to 2.4.x which would implement the scheme. James Bottomley - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 and such (for > using openssh). .. > Granted I probably have more general knowledge of computers, > (administered and used Data General MV [:-)], DEC, HP, Sun, ...] > than average users, > but then I was totally confused about the > recognition order of SCSI devices under Linux when I > had the second SCSI adaptor in my PC. > As a matter of fact, I hit on a dormant bug/feature > in the SCSI subsystem and was helpless until > I wrote to Kurt Garloff(DC390(tmscsim) maintainer). > Perhaps I missed the word when I said 'play'. I wanted to say somyhing like 'play with apache to setup my web server' or 'play with a command line compiler to do my programs'. Play with soft included in Linux. The normal user you will find around is people that wants to install the OS and start doing things with it. SCSI disks are a 'strange' thing for the average user. They usually see their first SCSI card if buy a SCSI CD toaster or ZIP and have to install a 1502 or 2906 to drive the recorder. So they will never have 8 disks in their machines or worry about SCSI ones because they are expensive. They buy a PC in the store and do not worry about chipsets or brands (well, now the graphics cards are changing that, everybody knows what is a GeForce, even if they don't know the diff between a VIA or a GX). People coming from mac world (myself) are comfortable between scsi ids, terminators and so on. Win people are used to master, slave and that. And in the PC world, SCSI people is the less. So having 3 SCSI cards is a so advanced matter in a PC (god should have erased the mind of the designer of the BIOS hell) that I see no reason to tweak lilo or other soft. -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.0-ac9 #2 SMP Sun Jan 14 01:46:07 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
> 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 hardware failure and i want to get stuff off the drives, i put the disk > containing the /home partition on the failed machine into a working > machine and reboot. What /home gets mounted then? the original /home or > the new one from the dead machine? (and don't say end users wouldn't > possibly do that... if they are adding hardware into their systems this is > by no means beyond their capabilities) > > at least with physical device nodes i can say 'computer, you will mount > this partition on this mountpoint!' and be done with it. > > so tell me then, how would one discern between two partitions with the > same label? On OS/390, the operator gets a message listing the devices with duplicate labels. Unfortunately, the message requests that the operator enter the physical address(es) of the devices to bring offline...not the address(es) of the devices that should be used. Duplicate labels -> human interaction... Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
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 added?. The existing patch for 2.2.xx is quite >> small and it does not bloat the kernel too much either. I think we can port >> it for 2.4.XX with ease.In my words it is worth the effort > >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. Yes, legacy names are supported. It is 100% backward compatible. As far as I know ( I'm the author of the patch ) > >however, this brings up an interesting question: what happens if two disks >(presumably from two different machines) have the same disk label? The first one found will be used. You are dependent on the ordering, only in this special case, while before you were depending on ordering every time. > 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 hardware failure and i want to get stuff off the drives, i put the disk >containing the /home partition on the failed machine into a working >machine and reboot. What /home gets mounted then? the original /home or >the new one from the dead machine? (and don't say end users wouldn't >possibly do that... if they are adding hardware into their systems this is >by no means beyond their capabilities) > at least with physical device nodes i can say 'computer, you will mount >this partition on this mountpoint!' and be done with it. You can still do this, nothing is preventing you from it. If you have /home in your fstab by its label, then you must change this before you insert the other disk. Possibilities : ( to change in /etc/fstab) - use UUID instead of volume-label -> no conflicts ever - temporarily relabel your /home - temporarily use a device node > >so tell me then, how would one discern between two partitions with the >same label? -- David Balazic -- "Be excellent to each other." - Bill & Ted - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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. > > Quite true on this point. Amiga handles it too. > > 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 Control Panel handles this). > > For ATA drives the bios handles this. No it doesn't. Put your root-fs on hda6 ( not unusual in dual boot setups ), delete hda5, watch your linux fail to boot. ( the kernel will be loaded , but it won't find the root-fs , because it looks in hda6 , but the partition has "migrated" to hda5 ) > > > The only way to solve this problem is the DESIGN IT INTO THE OS! Someone needs > > to stand up and say, "This is a problem, and I'm going to fix it." There needs -^ Amen to that ! > > to be a "device mount order database" or some kind, and all the disk drivers > > need to access that database to determine where to put the devices it finds. > > > NO! What needs to happen is: > 1) the person who installs a second scsi card should read the manual BEFORE > installing it so they know how to disable the boot features if they aren't > needed, This won't fix the "kernel doesn't find root-fs" problem. > > or > > 2) install only one bootable scsi card, period. Same ( or similar ) problem as before ... > Anything else is a useless kludge that will come back and bite us in the > ass. Kludges are bad, unfortunately that is all we have currently :-( > > > The only problem is BIOS boot. That information is, I believe, stored in the > > ESCD, but I don't know if it's reliable enough and complete enough to be usable > > by Linux. > > It seems to work well enough. For the "load the kernel" part. Most of the times. > > Matthew D. Pitts > [EMAIL PROTECTED] > -- David Balazic -- "Be excellent to each other." - Bill & Ted - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 > > 2.2 and 2.4 kernels, well volunteered. > > I'm quite interested in this patch, and have taken a good look at it. > Some changes are in order (IMHO) to make it more usable. It should take > parameters that are the same as in /etc/fstab (i.e. LABEL= and UUID= > instead of L: and UUID:). A trivial change... > 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. Cool, send it to me ! > I know a bit about LILO, so I should be able to get the "root=LABEL=" to > work there as well. There were no problems with the original patch with LILO. You just must use append="root=x" instead of simply root=xxx , because LILO tries to be "smart" at least the version I used then did. > I also need to do some work like this in e2fsprogs, so it may make sense > to create a little library that can be updated to handle other kinds of > filesystem/partition LABELs and UUIDs as the need arises. They were > talking about putting a LABEL/UUID into reiserfs recently. This saves > us from having to fix ext2-specific in dozens of utilities (e.g. LILO, > mount, fsck, dump, etc). > > One reason why this may NOT ever make it into the kernel is that I know > "kernel poking at devices" is really frowned upon. This an ugly hack , if you ask me. The identificators ( be it labels , UUIDs or whatever ) should be outside the partitions. Otherwise cases with swap partitions , unformatted partitions etc. can not be handled. -- David Balazic -- "Be excellent to each other." - Bill & Ted - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 of > > things from small embedded devices to large systems, and Linux needs to address > > needs in every area. > > see, thats where you and i disagree...I wouldn't call you an end user > based upon that fact. End users (IMO) are those people who sit back and > buy a PC and expect it to Just Work(tm). Servers, embedded devices, et al > (read: high-end applications) do not equate to end-user applications, > IMNSHO. Besides, *most* (and I say most because I've seen a sharp decline > in the mentality of Linux users as of late) people who are going to manage > a high-scale server are going to know what the hell they are doing in the > first place, so I highly doubt that the end-user argument holds merit > against this. > > Linux, whether you like it or not, is a full-scale UNIX. It takes a good > (read: talented) system administrator to manage any UNIX properly...A good > sysadmin reads documentationSeems clear enough to me. But, then again, > this is coming from an experienced sysadmin so my opinion *must* be > biased. Recently my neighbor ( in no way a high-end user ) called me over, because his Linux setup wouldn't boot anymore. All he did was to add ( or maybe remove, can remember now ) a partition on his IDE disk. Linux assigned different device nodes to the partition as it did before the change, so it couldn't find its root-fs. The same problem exists with _all_ devices that are assigned in the "order I found them today" , like audio devices , network devices etc... BTW, where is the scsihosts= kernel parameter documented ? -- David Balazic -- "Be excellent to each other." - Bill & Ted - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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(8) supports mounting by '-L ' and '-U '. > Most modern mke2fs proggies will assign a UUID to each newly created > filesystem. For /etc/fstab, you can specify LABEL=xxx or UUID=xxx > instead of a device name. > The one thing I don't know is... can the kernel mount the root fs if > only given the uuid? You missed the context. I was referring to the 2.2.5? patch that allowed you to do exactly that - specify a kernel parameter "root=UUID:foo" or "root=LABEL:bar". I've re-worked it and will post after testing a bit. My only hesitation was that kernel probing is frowned upon. When UUID/LABEL support for devfs came up at the Miami Linux Storage Workshop, it was given the thumbs down. If I get a chance I will also fix LILO to allow UUID/LABEL for root as well. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 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. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[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. Doing it by serial number (do SCSI drives have a unique serial number?) would be possible without doing that. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 ' and '-U '. Most modern mke2fs proggies will assign a UUID to each newly created filesystem. For /etc/fstab, you can specify LABEL=xxx or UUID=xxx instead of a device name. The one thing I don't know is... can the kernel mount the root fs if only given the uuid? Jeff -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
"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 docs and > rebuild a kernel. Like Michael Meissner, I have been using Unix-like systems since it first came to Japan around 1981 : the first one was on a VAX at a university computer centre. (Its official English name was spelled with centre.) I came to use Linux after I bought Yggdrasil Fall 1994 disk. I began using it regularly for the last two or three years (after OS/2). 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 and such (for using openssh). And maybe I occasionally produce patches when I notice a few problems in these utilities and send them to the original writers or the current maintainers. (The average users that J.A. Magallon have in mind may not produce patches, but I am not sure.) Granted I probably have more general knowledge of computers, (administered and used Data General MV [:-)], DEC, HP, Sun, ...] than average users, but then I was totally confused about the recognition order of SCSI devices under Linux when I had the second SCSI adaptor in my PC. As a matter of fact, I hit on a dormant bug/feature in the SCSI subsystem and was helpless until I wrote to Kurt Garloff(DC390(tmscsim) maintainer). There was not much documentation to rely on then. Is there enough, today? I wonder. It is true that with 2.4.x kernel: ... - we can control the recognition order of different brand of SCSI cards using scsihosts kernel parameter. (Don't know if this works under non-x86 platforms.) I use loadlin and scsihosts does work. - we can possibly control the recognition order of the same brand of cards either by - the driver (module) parameter if the driver supports it, or - by swapping the bus slots of the drivers (sometimes), - or probably swapping the cable if all the devices are external to the box (if appropriate). ... These might be documented somewhere, but I am not sure. Maybe the config script or rather the short help message that appears might want to mention this somewhere. Then there is the naming scheme: As noted recently, the name of the devices shift if we add, say, a disk in the SCSI chain. By going to `devfs', I am told that the naming becomes consistent, but unfortunately, I have not yet figured out how to write the initializing devfs script for my Debian GNU/Linux system yet. (Yes, I went to R. Gooch home page and started to read the howto doc there, but I am not entire sure of the way initializing script under /etc/rc" ought to be written for my Debian GNU/Linux : rather than risking my system's health, I have given up and hoping that Debian distribution will have devfs as part of standard installation soon.) Anyway, from the viewpoint of Linux (end) users, - there is not much in the way of documentation. I wonder if the SCSI-HOWTO is ever updated these days. - Read the source also doesn't work very well even if the user does read C source code with 15+ years of C programming (from my own experience) SCSI subsystem is rather hard to read. It is a good thing that Alan Cox did the major surgery of re-formatting the code during 2.3.xx development. My point is that SCSI subsystem under Linux is not very user-friendly as of now. I have to wonder then what subsystems of Linux is user-friendlier than SCSI subsystem. I don't know. I have configured network card, Intel EEPRO/100 under linux, and didn't have much trouble, but then I have configured network at the office many many times, and so it helped me, I guess. In comparison, the problem with Linux SCSI subsystem is that I have configured SCSI disks, tape drives, etc. at the office many times, but the experience didn't carry over very well. That is it. I can't pin point what (mis-)features of linux make it difficult for me to share the past SCSI experience: Maybe the devfs thing would help if only it has better introduction documents somewhere. It could be that this is the fate of open source system where the device drivers are written by totally independent groups with various features creeping/implemented at different speeds in different drivers. If this is the case, then there is no intrinsic cure. Anyway, better documentation would help to certain extent certainly. The paragraph between " .." above can be ripped and inserted with more detailed explanation of scsihosts in such a document. Anyway, viewing the (end) users as dumb who just want to play puts me
Re: Linux not adhering to BIOS Drive boot order?
[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-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[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-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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' and '-U UUID'. Most modern mke2fs proggies will assign a UUID to each newly created filesystem. For /etc/fstab, you can specify LABEL=xxx or UUID=xxx instead of a device name. The one thing I don't know is... can the kernel mount the root fs if only given the uuid? Jeff -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[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. Doing it by serial number (do SCSI drives have a unique serial number?) would be possible without doing that. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 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. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 of things from small embedded devices to large systems, and Linux needs to address needs in every area. see, thats where you and i disagree...I wouldn't call you an end user based upon that fact. End users (IMO) are those people who sit back and buy a PC and expect it to Just Work(tm). Servers, embedded devices, et al (read: high-end applications) do not equate to end-user applications, IMNSHO. Besides, *most* (and I say most because I've seen a sharp decline in the mentality of Linux users as of late) people who are going to manage a high-scale server are going to know what the hell they are doing in the first place, so I highly doubt that the end-user argument holds merit against this. Linux, whether you like it or not, is a full-scale UNIX. It takes a good (read: talented) system administrator to manage any UNIX properly...A good sysadmin reads documentationSeems clear enough to me. But, then again, this is coming from an experienced sysadmin so my opinion *must* be biased. Recently my neighbor ( in no way a high-end user ) called me over, because his Linux setup wouldn't boot anymore. All he did was to add ( or maybe remove, can remember now ) a partition on his IDE disk. Linux assigned different device nodes to the partition as it did before the change, so it couldn't find its root-fs. The same problem exists with _all_ devices that are assigned in the "order I found them today" , like audio devices , network devices etc... BTW, where is the scsihosts= kernel parameter documented ? -- David Balazic -- "Be excellent to each other." - Bill Ted - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 2.2 and 2.4 kernels, well volunteered. I'm quite interested in this patch, and have taken a good look at it. Some changes are in order (IMHO) to make it more usable. It should take parameters that are the same as in /etc/fstab (i.e. LABEL= and UUID= instead of L: and UUID:). A trivial change... 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. Cool, send it to me ! I know a bit about LILO, so I should be able to get the "root=LABEL=" to work there as well. There were no problems with the original patch with LILO. You just must use append="root=x" instead of simply root=xxx , because LILO tries to be "smart" at least the version I used then did. I also need to do some work like this in e2fsprogs, so it may make sense to create a little library that can be updated to handle other kinds of filesystem/partition LABELs and UUIDs as the need arises. They were talking about putting a LABEL/UUID into reiserfs recently. This saves us from having to fix ext2-specific in dozens of utilities (e.g. LILO, mount, fsck, dump, etc). One reason why this may NOT ever make it into the kernel is that I know "kernel poking at devices" is really frowned upon. This an ugly hack , if you ask me. The identificators ( be it labels , UUIDs or whatever ) should be outside the partitions. Otherwise cases with swap partitions , any FS that doesn't support labels/UUIDs unformatted partitions etc. can not be handled. -- David Balazic -- "Be excellent to each other." - Bill Ted - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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. Quite true on this point. Amiga handles it too. 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 Control Panel handles this). For ATA drives the bios handles this. No it doesn't. Put your root-fs on hda6 ( not unusual in dual boot setups ), delete hda5, watch your linux fail to boot. ( the kernel will be loaded , but it won't find the root-fs , because it looks in hda6 , but the partition has "migrated" to hda5 ) The only way to solve this problem is the DESIGN IT INTO THE OS! Someone needs to stand up and say, "This is a problem, and I'm going to fix it." There needs -^ Amen to that ! to be a "device mount order database" or some kind, and all the disk drivers need to access that database to determine where to put the devices it finds. NO! What needs to happen is: 1) the person who installs a second scsi card should read the manual BEFORE installing it so they know how to disable the boot features if they aren't needed, This won't fix the "kernel doesn't find root-fs" problem. or 2) install only one bootable scsi card, period. Same ( or similar ) problem as before ... Anything else is a useless kludge that will come back and bite us in the ass. Kludges are bad, unfortunately that is all we have currently :-( The only problem is BIOS boot. That information is, I believe, stored in the ESCD, but I don't know if it's reliable enough and complete enough to be usable by Linux. It seems to work well enough. For the "load the kernel" part. Most of the times. Matthew D. Pitts [EMAIL PROTECTED] -- David Balazic -- "Be excellent to each other." - Bill Ted - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
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 added?. The existing patch for 2.2.xx is quite small and it does not bloat the kernel too much either. I think we can port it for 2.4.XX with ease.In my words it is worth the effort 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. Yes, legacy names are supported. It is 100% backward compatible. As far as I know ( I'm the author of the patch ) however, this brings up an interesting question: what happens if two disks (presumably from two different machines) have the same disk label? The first one found will be used. You are dependent on the ordering, only in this special case, while before you were depending on ordering every time. 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 hardware failure and i want to get stuff off the drives, i put the disk containing the /home partition on the failed machine into a working machine and reboot. What /home gets mounted then? the original /home or the new one from the dead machine? (and don't say end users wouldn't possibly do that... if they are adding hardware into their systems this is by no means beyond their capabilities) at least with physical device nodes i can say 'computer, you will mount this partition on this mountpoint!' and be done with it. You can still do this, nothing is preventing you from it. If you have /home in your fstab by its label, then you must change this before you insert the other disk. Possibilities : ( to change in /etc/fstab) - use UUID instead of volume-label - no conflicts ever - temporarily relabel your /home - temporarily use a device node so tell me then, how would one discern between two partitions with the same label? -- David Balazic -- "Be excellent to each other." - Bill Ted - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 and such (for using openssh). .. Granted I probably have more general knowledge of computers, (administered and used Data General MV [:-)], DEC, HP, Sun, ...] than average users, but then I was totally confused about the recognition order of SCSI devices under Linux when I had the second SCSI adaptor in my PC. As a matter of fact, I hit on a dormant bug/feature in the SCSI subsystem and was helpless until I wrote to Kurt Garloff(DC390(tmscsim) maintainer). Perhaps I missed the word when I said 'play'. I wanted to say somyhing like 'play with apache to setup my web server' or 'play with a command line compiler to do my programs'. Play with soft included in Linux. The normal user you will find around is people that wants to install the OS and start doing things with it. SCSI disks are a 'strange' thing for the average user. They usually see their first SCSI card if buy a SCSI CD toaster or ZIP and have to install a 1502 or 2906 to drive the recorder. So they will never have 8 disks in their machines or worry about SCSI ones because they are expensive. They buy a PC in the store and do not worry about chipsets or brands (well, now the graphics cards are changing that, everybody knows what is a GeForce, even if they don't know the diff between a VIA or a GX). People coming from mac world (myself) are comfortable between scsi ids, terminators and so on. Win people are used to master, slave and that. And in the PC world, SCSI people is the less. So having 3 SCSI cards is a so advanced matter in a PC (god should have erased the mind of the designer of the BIOS hell) that I see no reason to tweak lilo or other soft. -- J.A. Magallon $ cd pub mailto:[EMAIL PROTECTED] $ more beer Linux werewolf 2.4.0-ac9 #2 SMP Sun Jan 14 01:46:07 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 the information. I know people have been complaining about this change since at least the fall time frame. SCSI host probe order has never been guaranteed, afaik -- this is not new to 2.4. If you have multiple host adapters, you really need to use the command line to say which is which, as always. If you don't, you will be bitten eventually. "Eventually" in this case meant 2.2-2.4, perhaps, but that doesn't make it an item for Documentation/Changes. Or is this not what you were talking about? What I'm talking about is that whenever you have these flag day(*) type of operations, is weakens the whole Linux movement. Yes, each individual change might mean a few minutes to half an hour of a persons time, but cumulatively it just sends the signal that Linux is just a hackers toy. If people can't easily switch between kernels for instance due to the wrong disk being listed as the boot disk, or they have to replug which ethernet controller gets which cord, it will mean fewer people testing new kernels for instance. * http://www.tuxedo.org/~esr/jargon/html/entry/flag-day.html -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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/bootinglinux-0.ps.gz for my views on such things. - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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.ch/pub/people/almesber/booting/bootinglinux-0.ps.gz for my views on such things. Actually, what is being discussed is not related to your above sections of the paper. AFAICS, the only change needed is to /sbin/lilo to resolve UUID and LABEL tags for "root=LABEL=turbo_root" fields in /etc/lilo.conf. This is not a bloat to the kernel, and doesn't change the boot loader at all, only the user-space block mapping code. 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. 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 kernel would boot from the first BIOS drive, and would match search for a UUID or LABEL as the root device. If /etc/fstab is also handled exclusively with UUID or LABEL (or LVM), then you don't care what the drives are called (excluding swap, hmmm, maybe we can add a signature to swap?). Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 a RAID1 array, how you do you know whether you mean: 1) An active disk in the array 2) The actual array itself. Hint: With Raid 1, the disks are complete images of each other. You can mount a single disk which is/was part of a raid 1 array and read all data off it. If someone thinks about going down this road, make sure you check the multiple-device arrays BEFORE the physical disks! _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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. Cool, send it to me ! Need to test it a bit first (i.e. at least compile it)... I know a bit about LILO, so I should be able to get the "root=LABEL=" to work there as well. There were no problems with the original patch with LILO. You just must use append="root=x" instead of simply root=xxx , because LILO tries to be "smart" at least the version I used then did. Actually, there are 2 ways to go about this: LILO could do the UUID/LABEL resolution at the time lilo is run (to store root dev into kernel), and _also_ append "root=LABEL=X" to kernel options, so that if the kernel can't resolve the UUID/LABEL (i.e. no support for this option) we can fall back to the root dev from when LILO was run. One reason why this may NOT ever make it into the kernel is that I know "kernel poking at devices" is really frowned upon. This an ugly hack , if you ask me. The identificators ( be it labels , UUIDs or whatever ) should be outside the partitions. Otherwise cases with swap partitions , any FS that doesn't support labels/UUIDs unformatted partitions etc. can not be handled. LVM now has UUID-like identifiers for all "partitions" (Logical Volumes), although they are not really accessible by any tools right now. The "LABEL" is actually the LV name, so it is used directly all the time: /dev/vgroot/lvroot / ext3defaults1 1 /dev/vgroot/lvswap noneswapsw,pri=100 0 0 This obviates most of the reason for the UUID/LABEL support, but not everyone runs LVM (yet ;-) and ext2 UUID/LABELs are still useful. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 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 kernel would boot from the first BIOS drive, and would match search for a UUID or LABEL as the root device. I can confirm that this works on RedHat 6.2 + Lilo 0.21 + kernel 2.4.0-test8 and RAID1. 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 problems and was then booted off with the other disk missing. -- Tim Fletcher - Network manager .~. /V\ L I N U X [EMAIL PROTECTED]// \\ Don't fear the penguin [EMAIL PROTECTED] /( )\ irc: Night-Shade on quakenet ^^-^^ An NT server can be run by an idiot, and usually is. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 kernel would boot from the first BIOS drive, and would search for a UUID or LABEL as the root device. 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 problems and was then booted off with the other disk missing. 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 assumes the BIOS can boot from /dev/hdc to start with (i.e. /dev/hda is totally gone). 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)? Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 problems and was then booted off with the other disk missing. 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 assumes the BIOS can boot from /dev/hdc to start with (i.e. /dev/hda is totally gone). Hence I have the disks in caddies to make taking them out all together easier, to force the bios to find the /dev/hdc as the boot drive 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 really answer the question -- Tim Fletcher - Network manager .~. /V\ L I N U X [EMAIL PROTECTED]// \\ Don't fear the penguin [EMAIL PROTECTED] /( )\ irc: Night-Shade on quakenet ^^-^^ Never apply a StarTrek solution to a Babylon 5 problem - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
"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 docs and rebuild a kernel. Like Michael Meissner, I have been using Unix-like systems since it first came to Japan around 1981 : the first one was on a VAX at a university computer centre. (Its official English name was spelled with centre.) I came to use Linux after I bought Yggdrasil Fall 1994 disk. I began using it regularly for the last two or three years (after OS/2). 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 and such (for using openssh). And maybe I occasionally produce patches when I notice a few problems in these utilities and send them to the original writers or the current maintainers. (The average users that J.A. Magallon have in mind may not produce patches, but I am not sure.) Granted I probably have more general knowledge of computers, (administered and used Data General MV [:-)], DEC, HP, Sun, ...] than average users, but then I was totally confused about the recognition order of SCSI devices under Linux when I had the second SCSI adaptor in my PC. As a matter of fact, I hit on a dormant bug/feature in the SCSI subsystem and was helpless until I wrote to Kurt Garloff(DC390(tmscsim) maintainer). There was not much documentation to rely on then. Is there enough, today? I wonder. It is true that with 2.4.x kernel: ... - we can control the recognition order of different brand of SCSI cards using scsihosts kernel parameter. (Don't know if this works under non-x86 platforms.) I use loadlin and scsihosts does work. - we can possibly control the recognition order of the same brand of cards either by - the driver (module) parameter if the driver supports it, or - by swapping the bus slots of the drivers (sometimes), - or probably swapping the cable if all the devices are external to the box (if appropriate). ... These might be documented somewhere, but I am not sure. Maybe the config script or rather the short help message that appears might want to mention this somewhere. Then there is the naming scheme: As noted recently, the name of the devices shift if we add, say, a disk in the SCSI chain. By going to `devfs', I am told that the naming becomes consistent, but unfortunately, I have not yet figured out how to write the initializing devfs script for my Debian GNU/Linux system yet. (Yes, I went to R. Gooch home page and started to read the howto doc there, but I am not entire sure of the way initializing script under /etc/rc" ought to be written for my Debian GNU/Linux : rather than risking my system's health, I have given up and hoping that Debian distribution will have devfs as part of standard installation soon.) Anyway, from the viewpoint of Linux (end) users, - there is not much in the way of documentation. I wonder if the SCSI-HOWTO is ever updated these days. - Read the source also doesn't work very well even if the user does read C source code with 15+ years of C programming (from my own experience) SCSI subsystem is rather hard to read. It is a good thing that Alan Cox did the major surgery of re-formatting the code during 2.3.xx development. My point is that SCSI subsystem under Linux is not very user-friendly as of now. I have to wonder then what subsystems of Linux is user-friendlier than SCSI subsystem. I don't know. I have configured network card, Intel EEPRO/100 under linux, and didn't have much trouble, but then I have configured network at the office many many times, and so it helped me, I guess. In comparison, the problem with Linux SCSI subsystem is that I have configured SCSI disks, tape drives, etc. at the office many times, but the experience didn't carry over very well. That is it. I can't pin point what (mis-)features of linux make it difficult for me to share the past SCSI experience: Maybe the devfs thing would help if only it has better introduction documents somewhere. It could be that this is the fate of open source system where the device drivers are written by totally independent groups with various features creeping/implemented at different speeds in different drivers. If this is the case, then there is no intrinsic cure. Anyway, better documentation would help to certain extent certainly. The paragraph between " .." above can be ripped and inserted with more detailed explanation of scsihosts in such a document. Anyway, viewing the (end) users as dumb who just want to play puts me in a
Re: Linux not adhering to BIOS Drive boot order?
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 management, e.g. partitioning or creating file systems (*) - adding a swap partition (sigh) - telling your boot loader where to put its boot sector (* in principle, you could even avoid this, if you have some means of identifying a disk (e.g. via the uuid of a file system). However, I would consider such a solution to be overly fragile.) That's exactly my point...It doesn't need to be there; there are already ways around it. They just need to be documented, that's all. Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 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 housekeeping'. I have seen so many cases (A buys PC, A tries to run brand new racing game that does not work, A goes shop and says: don't know what's wrong with this PC, look at it and call me when MyCarRacingGame works...). I also don't want things so complex for the people who need to do complex things, that they give up in frustration with Linux and use something else like *BSD, particularly when things are changed from the previous way they were done in Linux. I agree things should be simple for simple configurations, but that does not mean we should be throwing boat anchors and couches in the paths of people who have more complex hardware. 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 docs and rebuild a kernel. 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 change since at least the fall time frame. There has been some movement on the SCSI subsystem documentation front: http://www.linuxdoc.org/HOWTO/SCSI-2.4-HOWTO/ Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 problem is that SCSI targets and LUNs are mapped sequentially to /dev/sd[a-z][a-d] so if you lose a device from the middle the ordering shifts. I think that devfs does a very good job of addressing the latter problem, since you can now use it's naming scheme to find the exact target/lun you were looking for. The former problem is really something that affects all adapter cards in the linux system (you have a similar problem for multiple ethernet cards, etc.) One of the ways this could be solved would be to impose bus ordering on the detection sequence. Since every computer bus (except the ancient ISA) has a way of getting its logical slot numbering (which is not necessarily related to physical slot numbering), you can easily impose this type of ordering on all card detection. Doing this would necessitate some surgery in the way device detection is done, probably major enough to make it a 2.5 feature. The up side would be that, as long as you maintain your cards in the same slot, the SCSI ordering would remain the same (you could even change the card and still have the same order). The compromise over UUID detection is that if you change the slot, all bets are off. If there is sufficient interest in this, I could look at putting together a patch to 2.4.x which would implement the scheme. James Bottomley - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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) mount device paths will failry easily handle question about which is where... And the partitions are PHYSICAL partition numbers, Hmm, without PCI locations, you still need to know how the system determines which interface becomes host0. Also, PCI locations probably aren't the most user-friendly way for identifying things ;-) But for the occasional problem case where label or uuid don't work, any such information is, of course, valuable. - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
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 hardware failure and i want to get stuff off the drives, i put the disk containing the /home partition on the failed machine into a working machine and reboot. What /home gets mounted then? the original /home or the new one from the dead machine? (and don't say end users wouldn't possibly do that... if they are adding hardware into their systems this is by no means beyond their capabilities) at least with physical device nodes i can say 'computer, you will mount this partition on this mountpoint!' and be done with it. so tell me then, how would one discern between two partitions with the same label? On OS/390, the operator gets a message listing the devices with duplicate labels. Unfortunately, the message requests that the operator enter the physical address(es) of the devices to bring offline...not the address(es) of the devices that should be used. Duplicate labels - human interaction... Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[ 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 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 management, e.g. partitioning or creating file systems (*) - adding a swap partition (sigh) - telling your boot loader where to put its boot sector (* in principle, you could even avoid this, if you have some means of identifying a disk (e.g. via the uuid of a file system). However, I would consider such a solution to be overly fragile.) - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 put its boot sector 2.4.0 with devfs mounted at boot time into /dev/ Only thing missing is that here /dev/scsi/host0/ propably should be a symlink to something like /dev/bus/pci/BB/II.F ... Or perhaps /dev/scsi/BUS/BB/II.F/busN/targetT/lunL/partP but mixing in ISA-bus controllers is somewhat tough.. $ mount /dev/scsi/host0/bus0/target0/lun0/part3 on / type ext2 (rw) /dev/scsi/host0/bus0/target2/lun0/part2 on /home type ext2 (rw) /dev/scsi/host0/bus0/target0/lun0/part4 on /usr type ext2 (rw) /dev/scsi/host0/bus0/target2/lun0/part1 on /usr/src type ext2 (rw) /dev/scsi/host0/bus0/target0/lun0/part1 on /boot type ext2 (rw) I do, of course, use mounting with LABEL= This new style (which contains, hopefully, physical PCI location) mount device paths will failry easily handle question about which is where... And the partitions are PHYSICAL partition numbers, not some logical ones. That is true with /dev/sdXP case as well as with /dev/hdXP case. - Werner /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[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 change > since at least the fall time frame. SCSI host probe order has never been guaranteed, afaik -- this is not new to 2.4. If you have multiple host adapters, you really need to use the command line to say which is which, as always. If you don't, you will be bitten eventually. "Eventually" in this case meant 2.2->2.4, perhaps, but that doesn't make it an item for Documentation/Changes. Or is this not what you were talking about? Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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. 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 housekeeping'. I have seen so many cases (A buys PC, A tries to run > brand new racing game that does not work, A goes shop and says: don't know > what's wrong with this PC, look at it and call me when MyCarRacingGame > works...). I also don't want things so complex for the people who need to do complex things, that they give up in frustration with Linux and use something else like *BSD, particularly when things are changed from the previous way they were done in Linux. I agree things should be simple for simple configurations, but that does not mean we should be throwing boat anchors and couches in the paths of people who have more complex hardware. > 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 docs and > rebuild a kernel. 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 change since at least the fall time frame. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 housekeeping'. I have seen so many cases (A buys PC, A tries to run > brand new racing game that does not work, A goes shop and says: don't know > what's wrong with this PC, look at it and call me when MyCarRacingGame > works...). Yup. Dummies dont need things to be done for them; they need to learn how to do it themselves. That, IMO, is the beauty of UNIX. Nothing is sugar coated, and almost everything gets back down to the K.I.S.S. approach. > 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 docs and > rebuild a kernel. Amen! I couldn't have said it better myself. Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 using lilo. Not everybody does or can use lilo, please > don't assume that the way your system gets booted is the way everybody's does, > particularly those on platforms other than the x86. And I wasn't assuming that. There are several bootloaders for intel alone, eg syslinux and grub, to name a couple. sparc has silo, alpha has something elsewhatever. > I must say, as a 5 year Linux user (and 23 year UNIX user/administrator), I do > get tired of having to hunt down and deal with each of these changes that come > up from time to time with Linux (ie, switching from ipfwadm to ipchains to > netfilter, or in this case reordering how scsi adapters/network adapters are > looked up). I've been a Linux user/administrator for 3 years now. Before that I worked on and administered UNIX machines for about 10 years, including SunOS, HP/UX, and AIX. If you think that Linux is the only operating system to undergo vast changes like that you're wrong: look at the SunOS to Solaris switchBasically the same operating system, no? However, many things were differentOK its off topic but im sure you get the idea. > > besides, how many 'end-users' do you know of that will have multiple scsi > > adapters in one system? how many end-users -period- will have even a > > *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 > > it is. if the user wants to add more than one scsi adapter into his > > system, let him read some documentation on how to do so. (is this even a > > documented feature? if not, i think it should be added to the docs...) > > 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 of > things from small embedded devices to large systems, and Linux needs to address > needs in every area. see, thats where you and i disagree...I wouldn't call you an end user based upon that fact. End users (IMO) are those people who sit back and buy a PC and expect it to Just Work(tm). Servers, embedded devices, et al (read: high-end applications) do not equate to end-user applications, IMNSHO. Besides, *most* (and I say most because I've seen a sharp decline in the mentality of Linux users as of late) people who are going to manage a high-scale server are going to know what the hell they are doing in the first place, so I highly doubt that the end-user argument holds merit against this. Linux, whether you like it or not, is a full-scale UNIX. It takes a good (read: talented) system administrator to manage any UNIX properly...A good sysadmin reads documentationSeems clear enough to me. But, then again, this is coming from an experienced sysadmin so my opinion *must* be biased. Talk to you later, Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 have even a > > *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 > > it is. if the user wants to add more than one scsi adapter into his > > system, let him read some documentation on how to do so. (is this even a > > documented feature? if not, i think it should be added to the docs...) > > 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 of > things from small embedded devices to large systems, and Linux needs to > address > needs in every area. > 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. 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 housekeeping'. I have seen so many cases (A buys PC, A tries to run brand new racing game that does not work, A goes shop and says: don't know what's wrong with this PC, look at it and call me when MyCarRacingGame works...). 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 docs and rebuild a kernel. -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.0-ac9 #2 SMP Sun Jan 14 01:46:07 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
> 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 linux kernel to look into the card to see whether the BIOS for that card has been enabled to make it determine the scsi drive order. If you had followed the earlier threads, the correct way to proceed would be to use labels to make things node independent. I think Andreas is working on patch for 2.2.18 and 2.4.0 kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[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 think > of compiling the drivers, if it is already part of the kernel / > initrd to get his system running. 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? Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[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 will all change with devfs. filesystem labels are to identify the filesystems so you can mount the right ones in the right places. Even if the device names change. -- Cheers John Summerfield http://www2.ami.com.au/ for OS/2 & linux information. Configuration, networking, combined IBM ftpsites index. Note: mail delivered to me is deemed to be intended for me, for my disposition. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[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, combined IBM ftpsites index. Note: mail delivered to me is deemed to be intended for me, for my disposition. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 user (and 23 year UNIX user/administrator), I do > > get tired of having to hunt down and deal with each of these changes that come > > up from time to time with Linux (ie, switching from ipfwadm to ipchains to > > netfilter, or in this case reordering how scsi adapters/network adapters are > > looked up). > > Bad example. > > netfilter does not force you to switch anything. You can just load the ipchains > or even the ipfw module and use your old scripts. Granted I was mainly thinking of the ipfwadm->ipchains conversion, but you have to root around and load the appropriate module. I like to build as much into the kernel as possible, and it took some amount of time to get things so that I could build the ipchains modules, since you are presented with choices that preclude building of the modules. If I had been using make config instead of make xconfig, it would have been worse, since I would have to go through the questions each time to get to the network section. I could also use the various incompatible transforms MD support has had over the years for another example, or the number of times system status monitors break due to changes in the output of /proc files (and yes I grant you many of the changes are due to poor programming in the status programs, but not all of them). Yes, change is one of the things that makes Linux strong. However, change to the way things are done can piss people off to using an alternate system, such as happened to Sun when they changed from the BSD method of system administration to System V many years ago. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 machines dies due > to hardware failure and i want to get stuff off the drives, i put the disk > containing the /home partition on the failed machine into a working > machine and reboot. What /home gets mounted then? the original /home or > the new one from the dead machine? (and don't say end users wouldn't > possibly do that... if they are adding hardware into their systems this is > by no means beyond their capabilities) Don't do that (tm). You may still have that problem (or even all filesystems being mounted wrong) if you add a new drive to a SCSI chain. Likewise if you add an IDE controller, the controllers may be numbered differently... > at least with physical device nodes i can say 'computer, you will mount > this partition on this mountpoint!' and be done with it. If you use a UUID, you will never have conflicts (unless you do drive imaging, which is bad). The label is just a lot more convenient to use than the UUID. > so tell me then, how would one discern between two partitions with the > same label? It will pick the first one found, I guess. However, this still reduces the problem of drive renaming by 99%. It goes from "each time drives are added/moved/removed my system may be broken" to "if I insert two drives with the same label 50% chance my system is broken". I'll take the latter any day. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 interested in this patch, and have taken a good look at it. Some changes are in order (IMHO) to make it more usable. It should take parameters that are the same as in /etc/fstab (i.e. LABEL= and UUID= instead of L: and UUID:). 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. I know a bit about LILO, so I should be able to get the "root=LABEL=" to work there as well. I also need to do some work like this in e2fsprogs, so it may make sense to create a little library that can be updated to handle other kinds of filesystem/partition LABELs and UUIDs as the need arises. They were talking about putting a LABEL/UUID into reiserfs recently. This saves us from having to fix ext2-specific in dozens of utilities (e.g. LILO, mount, fsck, dump, etc). One reason why this may NOT ever make it into the kernel is that I know "kernel poking at devices" is really frowned upon. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
** 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 Control Panel handles this). > > Are you sure about that? According to my documentation on installing linux on a G4 > with scsi disks, you need to specify a device enumeration string like the following > to tell the system where to look for the boot device: > > /pci@f200/pci-bridge@d/ATTO,ExpressPCIProUL2D@4,1/@6:5 > > where the '6' is the SCSI ID of the drive, and the '5' is the partition number of the > boot partition. So if you change SCSI IDs or add a new partition and change the > partition numbering of the drive, your computer can't boot anymore. I was talking about a Mac running Mac OS. I've tried change the SCSI ID of the boot device, but this discussion was about adding devices. On a Mac, I've always been able to add devices, whether they be on an exiting SCSI or IDE bus, or on a new bus, and not worry about the machine not booting. I can't same the same about the PC. Overall, the PC is just much more sensitive to device changes than Macs are. And I think it's because the Mac BIOS and OS are just designed to handle this better. The PC BIOS never had any provision for a third-party boot device to annouce itself. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please direct the reply to the mailing list only. Don't send another copy to me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 having to hunt down and deal with each of these changes that come > up from time to time with Linux (ie, switching from ipfwadm to ipchains to > netfilter, or in this case reordering how scsi adapters/network adapters are > looked up). Bad example. netfilter does not force you to switch anything. You can just load the ipchains or even the ipfw module and use your old scripts. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
> 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 > (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 hardware failure and i want to get stuff off the drives, i put the disk > containing the /home partition on the failed machine into a working > machine and reboot. What /home gets mounted then? the original /home or > the new one from the dead machine? (and don't say end users wouldn't > possibly do that... if they are adding hardware into their systems this is > by no means beyond their capabilities) > > at least with physical device nodes i can say 'computer, you will mount > this partition on this mountpoint!' and be done with it. [Venkatesh Ramamurthy] You are getting my point exactly. This was my argument from the first, we should have a efficient mechanism to mount partitions > so tell me then, how would one discern between two partitions with the > same label? [Venkatesh Ramamurthy] If the OS detects two partitions of the same name , either dont mount both , but display an error (or) mount the first one it finds ( this is not a good idea but) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 > > [Venkatesh Ramamurthy] I think it would be a nice idea if we can > > make this process automatic , with out user typing in the order and > > remembering it. The fact that a kernel developer is not using the machines > > daily to get his work done should be in our minds. If we do this Linux would > > become more user friendly > > 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 using lilo. Not everybody does or can use lilo, please 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 having to hunt down and deal with each of these changes that come up from time to time with Linux (ie, switching from ipfwadm to ipchains to netfilter, or in this case reordering how scsi adapters/network adapters are looked up). > besides, how many 'end-users' do you know of that will have multiple scsi > adapters in one system? how many end-users -period- will have even a > *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 > it is. if the user wants to add more than one scsi adapter into his > system, let him read some documentation on how to do so. (is this even a > documented feature? if not, i think it should be added to the docs...) 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 of things from small embedded devices to large systems, and Linux needs to address needs in every area. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
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 bloat the kernel too much either. I think we can port > it for 2.4.XX with ease.In my words it is worth the effort 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 (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 hardware failure and i want to get stuff off the drives, i put the disk containing the /home partition on the failed machine into a working machine and reboot. What /home gets mounted then? the original /home or the new one from the dead machine? (and don't say end users wouldn't possibly do that... if they are adding hardware into their systems this is by no means beyond their capabilities) at least with physical device nodes i can say 'computer, you will mount this partition on this mountpoint!' and be done with it. so tell me then, how would one discern between two partitions with the same label? just a thought Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
> 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 > adapters in one system? how many end-users -period- will have even a > *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 > it is. if the user wants to add more than one scsi adapter into his > system, let him read some documentation on how to do so. (is this even a > documented feature? if not, i think it should be added to the docs...) [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 bloat the kernel too much either. I think we can port it for 2.4.XX with ease.In my words it is worth the effort - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 > /dev/sda, /dev/sdb, or anything like that). It also remembers the boot device > in its EEPROM (the Startup Disk Control Panel handles this). Are you sure about that? According to my documentation on installing linux on a G4 with scsi disks, you need to specify a device enumeration string like the following to tell the system where to look for the boot device: /pci@f200/pci-bridge@d/ATTO,ExpressPCIProUL2D@4,1/@6:5 where the '6' is the SCSI ID of the drive, and the '5' is the partition number of the boot partition. So if you change SCSI IDs or add a new partition and change the partition numbering of the drive, your computer can't boot anymore. Chris -- Chris Friesen| MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada| email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
