RE: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
** Reply to message from Eddie Williams <[EMAIL PROTECTED]> on Tue, 16 Jan 2001 12:24:49 -0500 > That is not totally true. There are two problems here, one is where you have > different controllers in your system and the other is where you have multiples > of the same controller. What you list 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 - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please direct the reply to the mailing list only. Don't send another copy to me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[EMAIL PROTECTED] said: > [Venkatesh Ramamurthy] Your name is already in the headers of the mail you sent. There's no need to repeat it. > The LILO boot loader and the LILO command line utility should be changed > for this. > Is anybody doing this? - There are patches available for the 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
>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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
On Tue, 16 Jan 2001 16:51:38 GMT, Venkatesh Ramamurthy <[EMAIL PROTECTED]> wrote: > [Venkatesh Ramamurthy] Just think an end-user fuguring out this > Asking him to change PCI slots and trying it out. My point is the end user > should not worry about all this. All he does is plugs a new 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 | [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
David Woodhouse wrote : > [EMAIL PROTECTED] said: > > 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
> > 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
On Tue, 16 Jan 2001, Venkatesh Ramamurthy wrote: > 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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" <[EMAIL PROTECTED]> To: "'David Woodhouse'" <[EMAIL PROTECTED]>; "Venkatesh Ramamurthy" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "'Alan Cox'" <[EMAIL PROTECTED]> Sent: Tuesday, January 16, 2001 5:19 PM Subject: RE: Linux not adhering to BIOS Drive boot order? > > It should be 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 [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[EMAIL PROTECTED] said: > we need some kind of signature being written in the drive, which the > kernel will use for determining the boot drive and later re-order > drives, if required. > Is someone handling this already? It should be possible to read the BIOS setting for this option and behave 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
David Woodhouse wrote : [EMAIL PROTECTED] said: 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
On Tue, 16 Jan 2001 16:51:38 GMT, Venkatesh Ramamurthy [EMAIL PROTECTED] wrote: [Venkatesh Ramamurthy] Just think an end-user fuguring out this Asking him to change PCI slots and trying it out. My point is the end user should not worry about all this. All he does is plugs a new 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 | [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[EMAIL PROTECTED] said: [Venkatesh Ramamurthy] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
** Reply to message from Eddie Williams [EMAIL PROTECTED] on Tue, 16 Jan 2001 12:24:49 -0500 That is not totally true. There are two problems here, one is where you have different controllers in your system and the other is where you have multiples of the same controller. What you list 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 - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please direct the reply to the mailing list only. Don't send another copy to me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
Timur Tabi wrote: And this is a problem that has plagues all PC operating systems, but has never been a problem on the Macintosh. Why? Because the Mac was designed to handle this problem, but the PC never was. The Mac never enumerates its devices like the PC does (no C: D: etc, no /dev/sda, /dev/sdb, or anything like that). It also remembers the boot device in its EEPROM (the Startup Disk Control Panel handles this). Are you sure about that? According to my documentation on installing linux on a G4 with scsi disks, you need to specify a device enumeration string like the following to tell the system where to look for the boot device: /pci@f200/pci-bridge@d/ATTO,ExpressPCIProUL2D@4,1/@6:5 where the '6' is the SCSI ID of the drive, and the '5' is the partition number of the boot partition. So if you change SCSI IDs or add a new partition and change the partition numbering of the drive, your computer can't boot anymore. Chris -- Chris Friesen| MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada| email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
On Tue, Jan 16, 2001 at 03:37:57PM -0500, Michael Meissner wrote: don't assume that the way your system gets booted is the way everybody's does, particularly those on platforms other than the x86. I must say, as a 5 year Linux user (and 23 year UNIX user/administrator), I do get tired of having to hunt down and deal with each of these changes that come up from time to time with Linux (ie, switching from ipfwadm to ipchains to netfilter, or in this case reordering how scsi adapters/network adapters are looked up). Bad example. netfilter does not force you to switch anything. You can just load the ipchains or even the ipfw module and use your old scripts. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
** Reply to message from "Christopher Friesen" [EMAIL PROTECTED] on Tue, 16 Jan 2001 14:54:23 -0500 The Mac never enumerates its devices like the PC does (no C: D: etc, no /dev/sda, /dev/sdb, or anything like that). It also remembers the boot device in its EEPROM (the Startup Disk Control Panel handles this). Are you sure about that? According to my documentation on installing linux on a G4 with scsi disks, you need to specify a device enumeration string like the following to tell the system where to look for the boot device: /pci@f200/pci-bridge@d/ATTO,ExpressPCIProUL2D@4,1/@6:5 where the '6' is the SCSI ID of the drive, and the '5' is the partition number of the boot partition. So if you change SCSI IDs or add a new partition and change the partition numbering of the drive, your computer can't boot anymore. I was talking about a Mac running Mac OS. I've tried change the SCSI ID of the boot device, but this discussion was about adding devices. On a Mac, I've always been able to add devices, whether they be on an exiting SCSI or IDE bus, or on a new bus, and not worry about the machine not booting. I can't same the same about the PC. Overall, the PC is just much more sensitive to device changes than Macs are. And I think it's because the Mac BIOS and OS are just designed to handle this better. The PC BIOS never had any provision for a third-party boot device to annouce itself. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please direct the reply to the mailing list only. Don't send another copy to me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
David Woodhouse writes: There are patches available for the 2.2 kernel which provide the facility to mount by UUID or volume label. It seems that nobody is actively maintaining those at the moment. If you want to update those to the current 2.2 and 2.4 kernels, well volunteered. I'm quite interested in this patch, and have taken a good look at it. Some changes are in order (IMHO) to make it more usable. It should take parameters that are the same as in /etc/fstab (i.e. LABEL= and UUID= instead of L: and UUID:). In the end I re-wrote most of the patch, so that we resolve ROOT_DEV before calling mount_root(), just to be a bit more consistent. I will release a new patch for 2.2.18 and 2.4.0 after David Balazic has a look at it. I know a bit about LILO, so I should be able to get the "root=LABEL=" to work there as well. I also need to do some work like this in e2fsprogs, so it may make sense to create a little library that can be updated to handle other kinds of filesystem/partition LABELs and UUIDs as the need arises. They were talking about putting a LABEL/UUID into reiserfs recently. This saves us from having to fix ext2-specific in dozens of utilities (e.g. LILO, mount, fsck, dump, etc). One reason why this may NOT ever make it into the kernel is that I know "kernel poking at devices" is really frowned upon. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
On Tue, Jan 16, 2001 at 10:01:25PM +0100, Andi Kleen wrote: On Tue, Jan 16, 2001 at 03:37:57PM -0500, Michael Meissner wrote: don't assume that the way your system gets booted is the way everybody's does, particularly those on platforms other than the x86. I must say, as a 5 year Linux user (and 23 year UNIX user/administrator), I do get tired of having to hunt down and deal with each of these changes that come up from time to time with Linux (ie, switching from ipfwadm to ipchains to netfilter, or in this case reordering how scsi adapters/network adapters are looked up). Bad example. netfilter does not force you to switch anything. You can just load the ipchains or even the ipfw module and use your old scripts. Granted I was mainly thinking of the ipfwadm-ipchains conversion, but you have to root around and load the appropriate module. I like to build as much into the kernel as possible, and it took some amount of time to get things so that I could build the ipchains modules, since you are presented with choices that preclude building of the modules. If I had been using make config instead of make xconfig, it would have been worse, since I would have to go through the questions each time to get to the network section. I could also use the various incompatible transforms MD support has had over the years for another example, or the number of times system status monitors break due to changes in the output of /proc files (and yes I grant you many of the changes are due to poor programming in the status programs, but not all of them). Yes, change is one of the things that makes Linux strong. However, change to the way things are done can piss people off to using an alternate system, such as happened to Sun when they changed from the BSD method of system administration to System V many years ago. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[EMAIL PROTECTED] said: Like the ext2 labels? (man e2label) [Venkatesh Ramamurthy] This re-ordering of the scsi drives should be done by SCSI ML , so is incorporating ext2 fs data structure knowledge on the SCSI ML a good idea?. You'd better not care what the drives ae called - it will all change with devfs. filesystem labels are to identify the filesystems so you can mount the right ones in the right places. Even if the device names change. -- Cheers John Summerfield http://www2.ami.com.au/ for OS/2 linux information. Configuration, networking, combined IBM ftpsites index. Note: mail delivered to me is deemed to be intended for me, for my disposition. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[Venkatesh Ramamurthy] [Venkatesh Ramamurthy] I think there should be a better way to handle this , compiling is one of the options, but an end-user should not think of compiling. The end user needs to put an another card and connect drives and get his system up and running. He should not think of compiling the drivers, if it is already part of the kernel / initrd to get his system running. You seem to be full of things that "we" can implement. So I just have to wonder: do you by any chance have some prototype code somewhere to figure out, reliably, which SCSI cards have BIOS extensions enabled, and the order they hook in? Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
You seem to be full of things that "we" can implement. So I just have to wonder: do you by any chance have some prototype code somewhere to figure out, reliably, which SCSI cards have BIOS extensions enabled, and the order they hook in? [Venkat] It would be a very bad idea for the linux kernel to look into the card to see whether the BIOS for that card has been enabled to make it determine the scsi drive order. If you had followed the earlier threads, the correct way to proceed would be to use labels to make things node independent. I think Andreas is working on patch for 2.2.18 and 2.4.0 kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
On Tue, 16 Jan 2001, Michael Meissner wrote: you're forgetting that in /etc/lilo.conf there is a directive called 'append='... all the user has to do is merely add 'append="scsihosts=whatever,whatever"' into their config file and rerun lilo. problem solved That's assuming you are using lilo. Not everybody does or can use lilo, please don't assume that the way your system gets booted is the way everybody's does, particularly those on platforms other than the x86. And I wasn't assuming that. There are several bootloaders for intel alone, eg syslinux and grub, to name a couple. sparc has silo, alpha has something elsewhatever. I must say, as a 5 year Linux user (and 23 year UNIX user/administrator), I do get tired of having to hunt down and deal with each of these changes that come up from time to time with Linux (ie, switching from ipfwadm to ipchains to netfilter, or in this case reordering how scsi adapters/network adapters are looked up). I've been a Linux user/administrator for 3 years now. Before that I worked on and administered UNIX machines for about 10 years, including SunOS, HP/UX, and AIX. If you think that Linux is the only operating system to undergo vast changes like that you're wrong: look at the SunOS to Solaris switchBasically the same operating system, no? However, many things were differentOK its off topic but im sure you get the idea. besides, how many 'end-users' do you know of that will have multiple scsi adapters in one system? how many end-users -period- will have even a *single* scsi adapter in their systems? do we need to bloat the kernel with automatic things like this? no... i think it is handled fine the way it is. if the user wants to add more than one scsi adapter into his system, let him read some documentation on how to do so. (is this even a documented feature? if not, i think it should be added to the docs...) I'm an end-user, and I have 3 scsi-adapters of two different brands in my system. Many of the people using Linux in high end things like servers, etc. will have multiple scsi controlers. People are using Linux in lots of things from small embedded devices to large systems, and Linux needs to address needs in every area. see, thats where you and i disagree...I wouldn't call you an end user based upon that fact. End users (IMO) are those people who sit back and buy a PC and expect it to Just Work(tm). Servers, embedded devices, et al (read: high-end applications) do not equate to end-user applications, IMNSHO. Besides, *most* (and I say most because I've seen a sharp decline in the mentality of Linux users as of late) people who are going to manage a high-scale server are going to know what the hell they are doing in the first place, so I highly doubt that the end-user argument holds merit against this. Linux, whether you like it or not, is a full-scale UNIX. It takes a good (read: talented) system administrator to manage any UNIX properly...A good sysadmin reads documentationSeems clear enough to me. But, then again, this is coming from an experienced sysadmin so my opinion *must* be biased. Talk to you later, Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[Michael Meissner] Ummm, I just reread the 2.4 Changes file once again just to be sure, and it did not cover this issue. So how the *$@% are people supposed to "read some docs" to know about this, if the docs don't mention the information. I know people have been complaining about this change since at least the fall time frame. SCSI host probe order has never been guaranteed, afaik -- this is not new to 2.4. If you have multiple host adapters, you really need to use the command line to say which is which, as always. If you don't, you will be bitten eventually. "Eventually" in this case meant 2.2-2.4, perhaps, but that doesn't make it an item for Documentation/Changes. Or is this not what you were talking about? Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
On Wed, 17 Jan 2001, J . A . Magallon wrote: You want to make things SOOO easy for a 'dummy' user, and that user will never use them. The average user you are targetting says: 'daddy, buy me a PC to run Quake and do my school jobs' or 'please, dear vendor, I want a PC to do my housekeeping'. I have seen so many cases (A buys PC, A tries to run brand new racing game that does not work, A goes shop and says: don't know what's wrong with this PC, look at it and call me when MyCarRacingGame works...). Yup. Dummies dont need things to be done for them; they need to learn how to do it themselves. That, IMO, is the beauty of UNIX. Nothing is sugar coated, and almost everything gets back down to the K.I.S.S. approach. Average users you are targetting with that automagical card detection even do not know there are SCSI and IDE disks. They just want a 30Gb ide disk to install linux and play. If they involve with SCSI and ID numbers and multiple cards and so on they can read some docs and rebuild a kernel. Amen! I couldn't have said it better myself. Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
On Tue, Jan 16, 2001 at 12:01:12PM -0800, Dr. Kelsey Hudson wrote: On Tue, 16 Jan 2001, Venkatesh Ramamurthy wrote: This is due to the fixed ordering of the scsi drivers. You can change the order of the scsi hosts with the "scsihosts" kernel parameter. See linux/drivers/scsi/scsi.c [Venkatesh Ramamurthy] I think it would be a nice idea if we can make this process automatic , with out user typing in the order and remembering it. The fact that a kernel developer is not using the machines daily to get his work done should be in our minds. If we do this Linux would become more user friendly you're forgetting that in /etc/lilo.conf there is a directive called 'append='... all the user has to do is merely add 'append="scsihosts=whatever,whatever"' into their config file and rerun lilo. problem solved That's assuming you are using lilo. Not everybody does or can use lilo, please don't assume that the way your system gets booted is the way everybody's does, particularly those on platforms other than the x86. I must say, as a 5 year Linux user (and 23 year UNIX user/administrator), I do get tired of having to hunt down and deal with each of these changes that come up from time to time with Linux (ie, switching from ipfwadm to ipchains to netfilter, or in this case reordering how scsi adapters/network adapters are looked up). besides, how many 'end-users' do you know of that will have multiple scsi adapters in one system? how many end-users -period- will have even a *single* scsi adapter in their systems? do we need to bloat the kernel with automatic things like this? no... i think it is handled fine the way it is. if the user wants to add more than one scsi adapter into his system, let him read some documentation on how to do so. (is this even a documented feature? if not, i think it should be added to the docs...) I'm an end-user, and I have 3 scsi-adapters of two different brands in my system. Many of the people using Linux in high end things like servers, etc. will have multiple scsi controlers. People are using Linux in lots of things from small embedded devices to large systems, and Linux needs to address needs in every area. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
On Tue, 16 Jan 2001, Venkatesh Ramamurthy wrote: 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 [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
Of course that would be better. The only complaint I have with such a system is that of backwards compatibility...as long as the legacy device names are still supported i would have no problem with it at all. however, this brings up an interesting question: what happens if two disks (presumably from two different machines) have the same disk label? what happens then? for instance, i have several linux machines both at my workplace and my home. if for some reason one of these machines dies due to hardware failure and i want to get stuff off the drives, i put the disk containing the /home partition on the failed machine into a working machine and reboot. What /home gets mounted then? the original /home or the new one from the dead machine? (and don't say end users wouldn't possibly do that... if they are adding hardware into their systems this is by no means beyond their capabilities) at least with physical device nodes i can say 'computer, you will mount this partition on this mountpoint!' and be done with it. [Venkatesh Ramamurthy] You are getting my point exactly. This was my argument from the first, we should have a efficient mechanism to mount partitions so tell me then, how would one discern between two partitions with the same label? [Venkatesh Ramamurthy] If the OS detects two partitions of the same name , either dont mount both , but display an error (or) mount the first one it finds ( this is not a good idea but) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
On Tue, 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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" [EMAIL PROTECTED] To: "'David Woodhouse'" [EMAIL PROTECTED]; "Venkatesh Ramamurthy" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; "'Alan Cox'" [EMAIL PROTECTED] Sent: Tuesday, January 16, 2001 5:19 PM Subject: RE: Linux not adhering to BIOS Drive boot order? It should be 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
On Wed, Jan 17, 2001 at 12:32:05AM +0100, J . A . Magallon wrote: If that is your idea of the average user... You're a system administrator, you can have tons of scsi cards in your system if you want. You want to make things SOOO easy for a 'dummy' user, and that user will never use them. The average user you are targetting says: 'daddy, buy me a PC to run Quake and do my school jobs' or 'please, dear vendor, I want a PC to do my housekeeping'. I have seen so many cases (A buys PC, A tries to run brand new racing game that does not work, A goes shop and says: don't know what's wrong with this PC, look at it and call me when MyCarRacingGame works...). I also don't want things so complex for the people who need to do complex things, that they give up in frustration with Linux and use something else like *BSD, particularly when things are changed from the previous way they were done in Linux. I agree things should be simple for simple configurations, but that does not mean we should be throwing boat anchors and couches in the paths of people who have more complex hardware. Average users you are targetting with that automagical card detection even do not know there are SCSI and IDE disks. They just want a 30Gb ide disk to install linux and play. If they involve with SCSI and ID numbers and multiple cards and so on they can read some docs and rebuild a kernel. Ummm, I just reread the 2.4 Changes file once again just to be sure, and it did not cover this issue. So how the *$@% are people supposed to "read some docs" to know about this, if the docs don't mention the information. I know people have been complaining about this change since at least the fall time frame. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
you're forgetting that in /etc/lilo.conf there is a directive called 'append='... all the user has to do is merely add 'append="scsihosts=whatever,whatever"' into their config file and rerun lilo. problem solved besides, how many 'end-users' do you know of that will have multiple scsi adapters in one system? how many end-users -period- will have even a *single* scsi adapter in their systems? do we need to bloat the kernel with automatic things like this? no... i think it is handled fine the way it is. if the user wants to add more than one scsi adapter into his system, let him read some documentation on how to do so. (is this even a documented feature? if not, i think it should be added to the docs...) [Venkatesh Ramamurthy] Dont you think that mounting and booting based on disk label names is better, then relying on device nodes which can change when a new card is added?. The existing patch for 2.2.xx is quite small and it does not bloat the kernel too much either. I think we can port it for 2.4.XX with ease.In my words it is worth the effort - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[EMAIL PROTECTED] said: [Venkatesh Ramamurthy] If we can truly go for label based mouting and lilo'ing this would solve the problem. Anybody doing this? Red hat Linux 7.0. -- Cheers John Summerfield http://www2.ami.com.au/ for OS/2 linux information. Configuration, networking, combined IBM ftpsites index. Note: mail delivered to me is deemed to be intended for me, for my disposition. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[EMAIL PROTECTED] said: we need some kind of signature being written in the drive, which the kernel will use for determining the boot drive and later re-order drives, if required. Is someone handling this already? It should be possible to read the BIOS setting for this option and behave 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
On Tue, 16 Jan 2001, Venkatesh Ramamurthy wrote: [Venkatesh Ramamurthy] Dont you think that mounting and booting based on disk label names is better, then relying on device nodes which can change when a new card is added?. The existing patch for 2.2.xx is quite small and it does not bloat the kernel too much either. I think we can port it for 2.4.XX with ease.In my words it is worth the effort Of course that would be better. The only complaint I have with such a system is that of backwards compatibility...as long as the legacy device names are still supported i would have no problem with it at all. however, this brings up an interesting question: what happens if two disks (presumably from two different machines) have the same disk label? what happens then? for instance, i have several linux machines both at my workplace and my home. if for some reason one of these machines dies due to hardware failure and i want to get stuff off the drives, i put the disk containing the /home partition on the failed machine into a working machine and reboot. What /home gets mounted then? the original /home or the new one from the dead machine? (and don't say end users wouldn't possibly do that... if they are adding hardware into their systems this is by no means beyond their capabilities) at least with physical device nodes i can say 'computer, you will mount this partition on this mountpoint!' and be done with it. so tell me then, how would one discern between two partitions with the same label? just a thought Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
On 2001.01.16 Michael Meissner wrote: On Tue, Jan 16, 2001 at 12:01:12PM -0800, Dr. Kelsey Hudson wrote: On Tue, 16 Jan 2001, Venkatesh Ramamurthy wrote: .. besides, how many 'end-users' do you know of that will have multiple scsi adapters in one system? how many end-users -period- will have even a *single* scsi adapter in their systems? do we need to bloat the kernel with automatic things like this? no... i think it is handled fine the way it is. if the user wants to add more than one scsi adapter into his system, let him read some documentation on how to do so. (is this even a documented feature? if not, i think it should be added to the docs...) I'm an end-user, and I have 3 scsi-adapters of two different brands in my system. Many of the people using Linux in high end things like servers, etc. will have multiple scsi controlers. People are using Linux in lots of things from small embedded devices to large systems, and Linux needs to address needs in every area. If that is your idea of the average user... You're a system administrator, you can have tons of scsi cards in your system if you want. You want to make things SOOO easy for a 'dummy' user, and that user will never use them. The average user you are targetting says: 'daddy, buy me a PC to run Quake and do my school jobs' or 'please, dear vendor, I want a PC to do my housekeeping'. I have seen so many cases (A buys PC, A tries to run brand new racing game that does not work, A goes shop and says: don't know what's wrong with this PC, look at it and call me when MyCarRacingGame works...). Average users you are targetting with that automagical card detection even do not know there are SCSI and IDE disks. They just want a 30Gb ide disk to install linux and play. If they involve with SCSI and ID numbers and multiple cards and so on they can read some docs and rebuild a kernel. -- J.A. Magallon $ cd pub mailto:[EMAIL PROTECTED] $ more beer Linux werewolf 2.4.0-ac9 #2 SMP Sun Jan 14 01:46:07 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
Kelsey Hudson writes: however, this brings up an interesting question: what happens if two disks (presumably from two different machines) have the same disk label? what happens then? for instance, i have several linux machines both at my workplace and my home. if for some reason one of these machines dies due to hardware failure and i want to get stuff off the drives, i put the disk containing the /home partition on the failed machine into a working machine and reboot. What /home gets mounted then? the original /home or the new one from the dead machine? (and don't say end users wouldn't possibly do that... if they are adding hardware into their systems this is by no means beyond their capabilities) Don't do that (tm). You may still have that problem (or even all filesystems being mounted wrong) if you add a new drive to a SCSI chain. Likewise if you add an IDE controller, the controllers may be numbered differently... at least with physical device nodes i can say 'computer, you will mount this partition on this mountpoint!' and be done with it. If you use a UUID, you will never have conflicts (unless you do drive imaging, which is bad). The label is just a lot more convenient to use than the UUID. so tell me then, how would one discern between two partitions with the same label? It will pick the first one found, I guess. However, this still reduces the problem of drive renaming by 99%. It goes from "each time drives are added/moved/removed my system may be broken" to "if I insert two drives with the same label 50% chance my system is broken". I'll take the latter any day. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
