RE: Linux not adhering to BIOS Drive boot order?

RE: Linux not adhering to BIOS Drive boot order?

[Venkatesh Ramamurthy]

> When the cards are of different make the order is solely dependent on
> the order that the drivers are initialized in the kernel.  If you have
> modules enabled, only build the driver for your root device into the
> kernel image and have the other modular.  This lets you control the
> initialization order to your liking.
	[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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Brian Gerst]

Venkatesh Ramamurthy wrote:
> 
> > When the cards are of different make the order is solely dependent on
> > the order that the drivers are initialized in the kernel.  If you have
> > modules enabled, only build the driver for your root device into the
> > kernel image and have the other modular.  This lets you control the
> > initialization order to your liking.
>         [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.

Why does the end-user have to compile the kernel?  Most distributions
provide a kernel with no SCSI drivers in it, but use an initrd to get
the root SCSI driver in (man mkinitrd on any Redhat box).  Just
distribute all SCSI drivers as modules and you won't have any problems.

--

				Brian Gerst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Eddie Williams]

> Why does the end-user have to compile the kernel?  Most distributions
> provide a kernel with no SCSI drivers in it, but use an initrd to get
> the root SCSI driver in (man mkinitrd on any Redhat box).  Just
> distribute all SCSI drivers as modules and you won't have any problems.
> 

That is not totally true.  There are two problems here, one is where you have 
different controllers in your system and the other is where you have multiples 
of the same controller.  What you list above solves the different controller 
problem.  By loading the drivers in the right order you will get predictable 
results.  However when having multiples of the same controller you are only 
loading one driver so you are at the mercy of the way that driver was 
developed.  Some drivers give you ways to work around this others do not.

For example the aic7xxx.c (current one at least - I have not played with the 
Beta one enough to know what it does) lets you play with the order by turning 
BIOS off on the cards that you don't want to BOOT from.  So the aic7xxx driver 
sorts the controllers with BIOS enabled first.  This solves the problem where 
you have multiple adaptec controllers in the same box to make sure you have 
the "boot" controller first.  This, however, does not solve a third problem 
where you have multiple disks on that controller.  My recommendation is that 
you always install on ID 0 since that will be the "first" one found.  If you 
install on ID 1 and you add ID 0 then you just broke your boot.  If you 
install on ID 1 where there was an ID 0 (so you install to sdb) then if ID 0 
dies, get pulled, etc then you can boot because ID 1 is now ID 0.

So though I do agree that making all drivers modules usually simplifies 
handling this there are still issues and solving these I do agree today is 
beyond the scope for the unexperienced.

Eddie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Timur Tabi]

** Reply to message from Eddie Williams <Eddie.Williams@steeleye.com> on Tue,
16 Jan 2001 12:24:49 -0500


> That is not totally true.  There are two problems here, one is where you have 
> different controllers in your system and the other is where you have multiples 
> of the same controller.  What you list above solves the different controller 
> problem.  By loading the drivers in the right order you will get predictable 
> results.  However when having multiples of the same controller you are only 
> loading one driver so you are at the mercy of the way that driver was 
> developed.  Some drivers give you ways to work around this others do not.
> 
> For example the aic7xxx.c (current one at least - I have not played with the 
> Beta one enough to know what it does) lets you play with the order by turning 
> BIOS off on the cards that you don't want to BOOT from.  So the aic7xxx driver 
> sorts the controllers with BIOS enabled first.  This solves the problem where 
> you have multiple adaptec controllers in the same box to make sure you have 
> the "boot" controller first.  This, however, does not solve a third problem 
> where you have multiple disks on that controller.  My recommendation is that 
> you always install on ID 0 since that will be the "first" one found.  If you 
> install on ID 1 and you add ID 0 then you just broke your boot.  If you 
> install on ID 1 where there was an ID 0 (so you install to sdb) then if ID 0 
> dies, get pulled, etc then you can boot because ID 1 is now ID 0.
> 
> So though I do agree that making all drivers modules usually simplifies 
> handling this there are still issues and solving these I do agree today is 
> beyond the scope for the unexperienced.

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).

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
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.

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.


-- 
Timur Tabi - ttabi@interactivesi.com
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Matthew D. Pitts]

Guys,

> And this is a problem that has plagues all PC operating systems, but has
never
> been a problem on the Macintosh.  Why?  Because the Mac was designed to
handle
> this problem, but the PC never was.

Quite true on this point.

> The Mac never enumerates its devices like the PC does (no C: D: 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.

> 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
> 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,

or

2) install only one bootable scsi card, period.

 Anything else is a useless kludge that will come back and bite us in the
ass.


> 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.

Matthew D. Pitts
mpitts@suite224.net



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Christopher Friesen]

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@f2000000/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: cfriesen@nortelnetworks.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Timur Tabi]

** Reply to message from "Christopher Friesen" <cfriesen@nortelnetworks.com> 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@f2000000/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 - ttabi@interactivesi.com
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Peter Samuelson]

[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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[David Balazic]

Matti Aarnio (matti.aarnio@zmailer.org) 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Tim Fletcher]

> 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
     nightshade@solanum.net        // \\  >Don't fear the penguin<
tim@parrswood.manchester.sch.uk   /(   )\
 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Andries.Brouwer]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[David Balazic]

Tim Fletcher <tim@parrswood.manchester.sch.uk> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Tim Fletcher]

> > > 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
     nightshade@solanum.net        // \\  >Don't fear the penguin<
tim@parrswood.manchester.sch.uk   /(   )\
 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Xavier Bestel]

On 18 Jan 2001 11:35:57 +0000, 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Tim Fletcher]

> > 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
     nightshade@solanum.net        // \\  >Don't fear the penguin<
tim@parrswood.manchester.sch.uk   /(   )\
 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Linux not adhering to BIOS Drive boot order?

[David Balazic]

Dr. Kelsey Hudson (kernel@blackhole.compendium-tech.com) 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[David Balazic]

Matthew D. Pitts (mpitts@suite224.net) 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
> mpitts@suite224.net
>    

-- 
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[David Balazic]

Andreas Dilger <adilger@turbolinux.com> 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=xxxxx" 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Andreas Dilger]

David Balazic writes:
> Andreas Dilger <adilger@turbolinux.com> 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=xxxxx" 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	/	ext3	defaults	1	1
/dev/vgroot/lvswap	none	swap	sw,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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[David Balazic]

Andreas Dilger wrote:
> 
> David Balazic writes:
> > Andreas Dilger <adilger@turbolinux.com> 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=xxxxx" 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      /       ext3    defaults        1       1
> /dev/vgroot/lvswap      none    swap    sw,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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[David Balazic]

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 documentation....Seems 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Boszormenyi Zoltan]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Linux not adhering to BIOS Drive boot order?

[Venkatesh Ramamurthy]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Linux not adhering to BIOS Drive boot order?

[Venkatesh Ramamurthy]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Linux not adhering to BIOS Drive boot order?

[Venkatesh Ramamurthy]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Linux not adhering to BIOS Drive boot order?

[Dr. Kelsey Hudson]

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                                           khudson@ctica.com 
 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Andreas Dilger]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Linux not adhering to BIOS Drive boot order?

[Mike Porter]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[James Bottomley]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Craig Ruff]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Peter Samuelson]

[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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[idalton]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Peter Samuelson]

[idalton@ferret.phonewave.net]
> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Matti Aarnio]

On Thu, Jan 18, 2001 at 09:59:06AM -0800, idalton@ferret.phonewave.net 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[David Weinehall]

On Thu, Jan 18, 2001 at 10:53:16PM +0200, Matti Aarnio wrote:
> On Thu, Jan 18, 2001 at 09:59:06AM -0800, idalton@ferret.phonewave.net 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 <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Linux not adhering to BIOS Drive boot order?

[Venkatesh Ramamurthy]

> From a layering point of view, it makes a lot more sense to
> me for the label (or signature or whatever) for this purpose 
> to be in the partition table than inside the filesystem.  The 
> parts of the system that assign devices their identities already 
> know about that part of the disk.
	[Venkatesh Ramamurthy]  The LILO boot loader and the LILO command
line utility should be changed for this. There are some issues when we have
different set of labels names for file system and partition table. The LILO
command line utility should make use of the disk labels of the file system
and use this for creating the partition disk label name. This is something
like assigning a label for kernel in lilo.conf. Is anybody doing this?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[David Woodhouse]

Venkateshr@ami.com said:
> 	[Venkatesh Ramamurthy]  

Your name is already in the headers of the mail you sent. There's no need to
repeat it.

> The LILO boot loader and the LILO command line utility should be changed
> for this.
> Is anybody doing this? -

There are patches available for the 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.

--
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Andreas Dilger]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[David Woodhouse]

adilger@turbolinux.com 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Jeff Garzik]

David Woodhouse wrote:
> 
> adilger@turbolinux.com 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Andreas Dilger]

Jeff writes:
> David Woodhouse wrote:
> > 
> > adilger@turbolinux.com 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?

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[David Woodhouse]

jgarzik@mandrakesoft.com 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[H. Peter Anvin]

Followup to:  <13466.979725727@redhat.com>
By author:    David Woodhouse <dwmw2@infradead.org>
In newsgroup: linux.dev.kernel
> 
> There are 2.2 patches to do it, which I think are now being dusted off and 
> resurrected. but scanning for UUID involves poking at every partition on 
> every available hard drive.
> 

The kernel does that anyway, so what's the problem, really?

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Andreas Dilger]

David Woodhouse writes:
> adilger@turbolinux.com 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Russell King]

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        rmk@arm.linux.org.uk      --- ---
  | | | | 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Werner Almesberger]

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           Werner.Almesberger@epfl.ch /
/_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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Andreas Dilger]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Tim Fletcher]

> 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
     nightshade@solanum.net        // \\  >Don't fear the penguin<
tim@parrswood.manchester.sch.uk   /(   )\
 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Andreas Dilger]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Tim Fletcher]

> > 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
     nightshade@solanum.net        // \\  >Don't fear the penguin<
tim@parrswood.manchester.sch.uk   /(   )\
 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Helge Hafting]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Linux not adhering to BIOS Drive boot order?

[Bryan Henderson]

>If we can truly go for label based mounting
>and lilo'ing this would solve the problem.

>From a layering point of view, it makes a lot more sense to
me for the label (or signature or whatever) for this purpose 
to be in the partition table than inside the filesystem.  The 
parts of the system that assign devices their identities already 
know about that part of the disk.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[David Balazic]

David Woodhouse wrote :
> Venkateshr@ami.com said:
> > we need some kind of signature being written in the drive, which the 
> > kernel will use for determining the boot drive and later re-order 
> > drives, if required.  
>      
> > Is someone handling this already? 
>     
> It should be possible to read the BIOS setting for this option and
> behave accordingly. Please give full details of how to read and interpret
> the information stored in the CMOS for all versions of AMI BIOS, and I'll
> take a look at this.

To mount the right partitions , refer to the by the volume label or
UUID.
( read the mount and fstab man pages for more info )

This work after the root-fs is already mounted.

Currently ( AFAIK ) the root-fs can be specified only as a major:minor
pair ( and maybe also as a "/dev/hdxx" string )

Once I wrote a patch that allows specifying the root-fs by
UUID or volume label. It is available at
http://linux-patches.rock-projects.com/v2.2-f/uuid.html

It is for 2.2.x kernel , since nobody seems to be interested in it.


As for the "device nodes are assigned to disk devices almost randomly"
problem : I complained about this years ago , but nothing happened.

If someone knows a way to reliably find a certain partition ,
regardless of the (non)existence and position of other partitions
and disks in the system , short of scanning the contents of all
available
partitions , please tell me.


Party on !
-- 
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Linux not adhering to BIOS Drive boot order?

[Venkatesh Ramamurthy]

> Why is this a SCSI ML problem?  The problem is that the OS can't figure
> out 
> where to mount root from.  Sounds like an OS problem.
> I think the file system label is the leading candidate to solve this.  One
> 
> really does not care if the root disk is called /dev/sda or /dev/fred.
> All 
> one cares is that you can boot your system and the right disks are
> mounted.  
> What I have seen so far with the fs label this either does solve this
> today or 
> it can solve this.  I notice today on some systems the entries in
> /etc/fstab 
> already are "deviceless" in that it does not have the disk/partition but 
> simply the disk label.
> 
> Can lilo use a label for the root disk also?  I have not looked into that
> yet. 
>  If it does not can it?  When I noticed the use of the label in /etc/fstab
> my 
> first thought was "alright, someone is solving this problem."  I have not 
> taken the time - not a burning issue with me right now - to see if this is
> all 
> done yet though.
> 
> Keep in mind that the example where /dev/sda is where root lies is that
> "easy" 
> case.  The hard case is what happens if someone installs on /dev/sdg.  Now
> 
> they boot up with a disk array turned off.  Is the mid-layer going to
> figure 
> out that what is now /dev/sda suppose to be /dev/sdg?  Or they install to 
> /dev/sdb and /dev/sda goes bad so they pull it out?
	[Venkatesh Ramamurthy]   If we can truly go for label based mouting
and lilo'ing this would solve the problem. Anybody doing this?



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[John Summerfield]

Venkateshr@ami.com 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Linux not adhering to BIOS Drive boot order?

[Venkatesh Ramamurthy]

> The scsi host numbers will be allocated to the HBAs in 
> the order shown starting at 0. This method does not
> distinguish between the two advansys controllers, luckily
> swapping their positions on the PCI bus does.
	[Venkatesh Ramamurthy]  Just think an end-user fuguring out this!!!!
Asking him to change PCI slots and trying it out. My point is the end user
should not worry about all this. All he does is plugs a new different/ same
type of card, and gets it going. Why should the linux kernel force the user
to change the PCI slots. Will this not make it more user - unfriendly


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Honza Pazdziora]

On Tue, 16 Jan 2001 16:51:38 GMT, Venkatesh Ramamurthy <Venkateshr@ami.com> wrote:
> 	[Venkatesh Ramamurthy]  Just think an end-user fuguring out this!!!!
> Asking him to change PCI slots and trying it out. My point is the end user
> should not worry about all this. All he does is plugs a new different/ same
> type of card, and gets it going. Why should the linux kernel force the user
> to change the PCI slots. Will this not make it more user - unfriendly

And so what you suggest ... is?

If the system allows variable order of initialization and you want
fixed order, they you have to enter some information to fixate it.

Is plugging new SCSI card and "end user task"?

-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton@fi.muni.cz | http://www.fi.muni.cz/~adelton/
   .project: Perl, DBI, Oracle, MySQL, auth. WWW servers, MTB, Spain.
Petition for a Software Patent Free Europe http://petition.eurolinux.org
------------------------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Linux not adhering to BIOS Drive boot order?

[Venkatesh Ramamurthy]

> > Is someone handling this already? 
> 
> "mount by uuid"?
> 
> Amiga's Rigid Disk Block?
	[Venkatesh Ramamurthy]  Something like this is better. The problem
is where do we store this info. Last sector is one of the options. Does
anyone know where NT stores this info?



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Linux not adhering to BIOS Drive boot order?

[Venkatesh Ramamurthy]

> 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

> Yours,
>   Dominik
> -- 
> http://petition.eurolinux.org/index_html - No Software Patents In Europe!
> http://petition.lugs.ch/ (in Switzerland)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Linux not adhering to BIOS Drive boot order?

[Dr. Kelsey Hudson]

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

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...)

just my thoughts on the matter....

 Kelsey Hudson                                           khudson@ctica.com 
 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Michael Meissner]

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:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Andi Kleen]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Michael Meissner]

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:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[J . A . Magallon]

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:jamagallon@able.es                                          $> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Dr. Kelsey Hudson]

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                                           khudson@ctica.com 
 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Michael Meissner]

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:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Peter Samuelson]

[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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Michael Meissner]

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:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Douglas Gilbert]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Ishikawa]

"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 very uncomfortable position.
I guess (hope) I am not that dumb at all, and yet
for heaven's sake, I could not get my two SCSI cards
working for a few weeks (due to a bug), and I had
read the docs many times during the time.

There will be more users like Michael Meissner and me
who have past experience with other systems before
and yet a NEWBIE linux users initially: There will be
more such users since Linux seems to get more management
nods in the future.

And these experienced NEWBIESs probably
can't figure out these SCSI problems under linux either and
I frankly doubt if the old SCSI-HOWTO docs might help.
(I checked a few web pages : was the current
how-to re-written in 1996?)

Something needs to be done here.

PS: I have now about 5 or 6 SCSI host adaptors in
a few PC boxes.
I hate IDE/ATA disks with all the geometry problems.
Also, being able to use external drives help cool down
the PC boxes IMHO.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[J . A . Magallon]

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:jamagallon@able.es                                          $> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Dr. Kelsey Hudson]

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 else....whatever. 

> 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
switch....Basically the same operating system, no? However, many things
were different....OK 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 documentation....Seems 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                                           khudson@ctica.com 
 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Werner Almesberger]

[ 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           Werner.Almesberger@epfl.ch /
/_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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Matti Aarnio]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Werner Almesberger]

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           Werner.Almesberger@epfl.ch /
/_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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Dr. Kelsey Hudson]

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                                           khudson@ctica.com 
 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Linux not adhering to BIOS Drive boot order?

[Venkatesh Ramamurthy]

> In article <1355693A51C0D211B55A00105ACCFE64E9518C@ATL_MS1> you wrote:
> 
> > we need some kind of signature being written in the drive, which the
> kernel
> > will use for determining the boot drive and later re-order drives, if
> > required.
> 
> Like the ext2 labels? (man e2label)
	[Venkatesh 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?. 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Eddie Williams]

Why is this a SCSI ML problem?  The problem is that the OS can't figure out 
where to mount root from.  Sounds like an OS problem.

I think the file system label is the leading candidate to solve this.  One 
really does not care if the root disk is called /dev/sda or /dev/fred.  All 
one cares is that you can boot your system and the right disks are mounted.  
What I have seen so far with the fs label this either does solve this today or 
it can solve this.  I notice today on some systems the entries in /etc/fstab 
already are "deviceless" in that it does not have the disk/partition but 
simply the disk label.

Can lilo use a label for the root disk also?  I have not looked into that yet. 
 If it does not can it?  When I noticed the use of the label in /etc/fstab my 
first thought was "alright, someone is solving this problem."  I have not 
taken the time - not a burning issue with me right now - to see if this is all 
done yet though.

Keep in mind that the example where /dev/sda is where root lies is that "easy" 
case.  The hard case is what happens if someone installs on /dev/sdg.  Now 
they boot up with a disk array turned off.  Is the mid-layer going to figure 
out that what is now /dev/sda suppose to be /dev/sdg?  Or they install to 
/dev/sdb and /dev/sda goes bad so they pull it out?

Eddie 
> > In article <1355693A51C0D211B55A00105ACCFE64E9518C@ATL_MS1> you wrote:
> > 
> > > we need some kind of signature being written in the drive, which the
> > kernel
> > > will use for determining the boot drive and later re-order drives, if
> > > required.
> > 
> > Like the ext2 labels? (man e2label)
> 	[Venkatesh 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?. 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[John Summerfield]

Venkateshr@ami.com 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Linux not adhering to BIOS Drive boot order?

[Venkatesh Ramamurthy]

> It should be possible to read the BIOS setting for this option and
> behave accordingly. Please give full details of how to read and interpret
> the information stored in the CMOS for all versions of AMI BIOS, and I'll
> take a look at this.
	[Venkatesh Ramamurthy]  When i meant BIOS setting option i meant the
SCSI BIOS settings not system BIOS option. The two SCSI controllers are of
different make. This situation is made worse when the system has many cards
of different makes and one of the controller somewhere in the middle of all
the slots is made the boot controller. 



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Florent Cueto]

Florent Cueto
Java developer
Socks via HTTP Homepage : http://www.javawork.net
(A program to tunnel socks requests via HTTP).

----- Original Message -----
From: "Venkatesh Ramamurthy" <Venkateshr@ami.com>
To: "'David Woodhouse'" <dwmw2@infradead.org>; "Venkatesh Ramamurthy"
<Venkateshr@ami.com>
Cc: <linux-scsi@vger.kernel.org>; <linux-kernel@vger.kernel.org>; "'Alan
Cox'" <alan@lxorguk.ukuu.org.uk>
Sent: Tuesday, January 16, 2001 5:19 PM
Subject: RE: Linux not adhering to BIOS Drive boot order?


> > It should be possible to read the BIOS setting for this option and
> > behave accordingly. Please give full details of how to read and
interpret
> > the information stored in the CMOS for all versions of AMI BIOS, and
I'll
> > take a look at this.
> [Venkatesh Ramamurthy]  When i meant BIOS setting option i meant the
> SCSI BIOS settings not system BIOS option. The two SCSI controllers are of
> different make. This situation is made worse when the system has many
cards
> of different makes and one of the controller somewhere in the middle of
all
> the slots is made the boot controller.
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Brian Gerst]

Venkatesh Ramamurthy wrote:
> 
> > It should be possible to read the BIOS setting for this option and
> > behave accordingly. Please give full details of how to read and interpret
> > the information stored in the CMOS for all versions of AMI BIOS, and I'll
> > take a look at this.
>         [Venkatesh Ramamurthy]  When i meant BIOS setting option i meant the
> SCSI BIOS settings not system BIOS option. The two SCSI controllers are of
> different make. This situation is made worse when the system has many cards
> of different makes and one of the controller somewhere in the middle of all
> the slots is made the boot controller.

When the cards are of different make the order is solely dependent on
the order that the drivers are initialized in the kernel.  If you have
modules enabled, only build the driver for your root device into the
kernel image and have the other modular.  This lets you control the
initialization order to your liking.

--

				Brian Gerst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Dominik Kubla]

On Tue, Jan 16, 2001 at 11:19:34AM -0500, Venkatesh Ramamurthy wrote:
> > It should be possible to read the BIOS setting for this option and
> > behave accordingly. Please give full details of how to read and interpret
> > the information stored in the CMOS for all versions of AMI BIOS, and I'll
> > take a look at this.
> 	[Venkatesh Ramamurthy]  When i meant BIOS setting option i meant the
> SCSI BIOS settings not system BIOS option. The two SCSI controllers are of
> different make. This situation is made worse when the system has many cards
> of different makes and one of the controller somewhere in the middle of all
> the slots is made the boot controller. 

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

Yours,
  Dominik
-- 
http://petition.eurolinux.org/index_html - No Software Patents In Europe!
http://petition.lugs.ch/ (in Switzerland)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Linux not adhering to BIOS Drive boot order?

[Venkatesh Ramamurthy]

Hi,
I have one issue which requires fix from the linux kernel. 
Initially i put a SCSI controller and install the OS on the drive connected
to it. After installing the OS (on sda), the customer puts another SCSI
controller. The BIOS for the first controller has BIOS enabled and for the
second controller does not have the BIOS enabled. 

The linux loads the driver for the second controller first and assigns sda
to it first , and the actual boot drive gets some sdX device node. 
>From the lilo prompt we can override it with root=/dev/sdX to boot to the
correct drive and controller, but for a end -user using these cards, this is
no fun.


Can the linux kernel be changed in such a way that kernel will look for the
actual boot drive and re-order the drives so that mounting can go on in the
right order.

we need some kind of signature being written in the drive, which the kernel
will use for determining the boot drive and later re-order drives, if
required.

Is someone handling this already? 

TIA


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[David Woodhouse]

Venkateshr@ami.com said:
>  we need some kind of signature being written in the drive, which the
> kernel will use for determining the boot drive and later re-order
> drives, if required.

> Is someone handling this already? 

It should be possible to read the BIOS setting for this option and
behave accordingly. Please give full details of how to read and interpret
the information stored in the CMOS for all versions of AMI BIOS, and I'll
take a look at this.

--
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Arjan van de Ven]

In article <1355693A51C0D211B55A00105ACCFE64E9518C@ATL_MS1> you wrote:

> we need some kind of signature being written in the drive, which the kernel
> will use for determining the boot drive and later re-order drives, if
> required.

Like the ext2 labels? (man e2label)

Greetings,
   Arjan van de Ven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Matthias Andree]

On Tue, 16 Jan 2001, Venkatesh Ramamurthy wrote:

> we need some kind of signature being written in the drive, which the kernel
> will use for determining the boot drive and later re-order drives, if
> required.
> 
> Is someone handling this already? 

"mount by uuid"?

Amiga's Rigid Disk Block?

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Douglas Gilbert]

Venkatesh Ramamurthy wrote:
> 
> Hi,
> I have one issue which requires fix from the linux kernel.
> Initially i put a SCSI controller and install the OS on the drive connected
> to it. After installing the OS (on sda), the customer puts another SCSI
> controller. The BIOS for the first controller has BIOS enabled and for the
> second controller does not have the BIOS enabled.
> 
> The linux loads the driver for the second controller first and assigns sda
> to it first , and the actual boot drive gets some sdX device node.
> >From the lilo prompt we can override it with root=/dev/sdX to boot to the
> correct drive and controller, but for a end -user using these cards, this is
> no fun.
> 
> Can the linux kernel be changed in such a way that kernel will look for the
> actual boot drive and re-order the drives so that mounting can go on in the
> right order.
> 
> we need some kind of signature being written in the drive, which the kernel
> will use for determining the boot drive and later re-order drives, if
> required.
> 
> Is someone handling this already?

Venkatesh,
It has been partially addressed in the new lk 2.4 series with
the "scsihosts" parameter. Here is a line from /etc/lilo.conf
in my system:
       append="scsihosts=imm:advansys:advansys:aha1542"

The scsi host numbers will be allocated to the HBAs in 
the order shown starting at 0. This method does not
distinguish between the two advansys controllers, luckily
swapping their positions on the PCI bus does.

In my experience, changing the SCSI BIOS settings only
affects which disk's boot track is accessed to find
the kernel image. It is the kernel's initialization that
detects and orders scsi controllers. This is were
"scsihosts" helps.

Doug Gilbert

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux not adhering to BIOS Drive boot order?

[Malahal Rao Naineni]

Venkatesh Ramamurthy wrote:
> 
> Hi,
> I have one issue which requires fix from the linux kernel. 
> Initially i put a SCSI controller and install the OS on the drive connected
> to it. After installing the OS (on sda), the customer puts another SCSI
> controller. The BIOS for the first controller has BIOS enabled and for the
> second controller does not have the BIOS enabled. 
> 
> The linux loads the driver for the second controller first and assigns sda
> to it first , and the actual boot drive gets some sdX device node. 
> >From the lilo prompt we can override it with root=/dev/sdX to boot to the
> correct drive and controller, but for a end -user using these cards, this is
> no fun.
> 
> 
> Can the linux kernel be changed in such a way that kernel will look for the
> actual boot drive and re-order the drives so that mounting can go on in the
> right order.

Name slippage is a horrible thing. That should be fixed first. The O/S
should get the device names right for every boot.

Thanks, Malahal.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/