Re: Linux not adhering to BIOS Drive boot order?
OK, what about a compromise. The fundamental problem that we all agree on is that SCSI devices are detected in the order that the mid-layer hosts.c file calls their detect routines. Further, for multiple cards of the same type, the detection order is up to the individual driver. A different problem is that SCSI targets and LUNs are mapped sequentially to /dev/sd[a-z][a-d] so if you lose a device from the middle the ordering shifts. I think that devfs does a very good job of addressing the latter problem, since you can now use it's naming scheme to find the exact target/lun you were looking for. The former problem is really something that affects all adapter cards in the linux system (you have a similar problem for multiple ethernet cards, etc.) One of the ways this could be solved would be to impose bus ordering on the detection sequence. Since every computer bus (except the ancient ISA) has a way of getting its logical slot numbering (which is not necessarily related to physical slot numbering), you can easily impose this type of ordering on all card detection. Doing this would necessitate some surgery in the way device detection is done, probably major enough to make it a 2.5 feature. The up side would be that, as long as you maintain your cards in the same slot, the SCSI ordering would remain the same (you could even change the card and still have the same order). The compromise over UUID detection is that if you change the slot, all bets are off. If there is sufficient interest in this, I could look at putting together a patch to 2.4.x which would implement the scheme. James Bottomley - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED]
Re: Linux not adhering to BIOS Drive boot order?
"J . A . Magallon" wrote: Average users you are targetting with that automagical card detection even do not know there are SCSI and IDE disks. They just want a 30Gb ide disk to install linux and play. If they involve with SCSI and ID numbers and multiple cards and so on they can read some docs and rebuild a kernel. Like Michael Meissner, I have been using Unix-like systems since it first came to Japan around 1981 : the first one was on a VAX at a university computer centre. (Its official English name was spelled with centre.) I came to use Linux after I bought Yggdrasil Fall 1994 disk. I began using it regularly for the last two or three years (after OS/2). Anyway, I view myself a typical Linux end-user in the framework of linux system hacker, linux tools developer and the rest (user). All I do on my PC is run netscape, read e-mails, post news articles, run editor to edit documents, and compile a few utilities and such (for using openssh). And maybe I occasionally produce patches when I notice a few problems in these utilities and send them to the original writers or the current maintainers. (The average users that J.A. Magallon have in mind may not produce patches, but I am not sure.) Granted I probably have more general knowledge of computers, (administered and used Data General MV [:-)], DEC, HP, Sun, ...] than average users, but then I was totally confused about the recognition order of SCSI devices under Linux when I had the second SCSI adaptor in my PC. As a matter of fact, I hit on a dormant bug/feature in the SCSI subsystem and was helpless until I wrote to Kurt Garloff(DC390(tmscsim) maintainer). There was not much documentation to rely on then. Is there enough, today? I wonder. It is true that with 2.4.x kernel: ... - we can control the recognition order of different brand of SCSI cards using scsihosts kernel parameter. (Don't know if this works under non-x86 platforms.) I use loadlin and scsihosts does work. - we can possibly control the recognition order of the same brand of cards either by - the driver (module) parameter if the driver supports it, or - by swapping the bus slots of the drivers (sometimes), - or probably swapping the cable if all the devices are external to the box (if appropriate). ... These might be documented somewhere, but I am not sure. Maybe the config script or rather the short help message that appears might want to mention this somewhere. Then there is the naming scheme: As noted recently, the name of the devices shift if we add, say, a disk in the SCSI chain. By going to `devfs', I am told that the naming becomes consistent, but unfortunately, I have not yet figured out how to write the initializing devfs script for my Debian GNU/Linux system yet. (Yes, I went to R. Gooch home page and started to read the howto doc there, but I am not entire sure of the way initializing script under /etc/rc" ought to be written for my Debian GNU/Linux : rather than risking my system's health, I have given up and hoping that Debian distribution will have devfs as part of standard installation soon.) Anyway, from the viewpoint of Linux (end) users, - there is not much in the way of documentation. I wonder if the SCSI-HOWTO is ever updated these days. - Read the source also doesn't work very well even if the user does read C source code with 15+ years of C programming (from my own experience) SCSI subsystem is rather hard to read. It is a good thing that Alan Cox did the major surgery of re-formatting the code during 2.3.xx development. My point is that SCSI subsystem under Linux is not very user-friendly as of now. I have to wonder then what subsystems of Linux is user-friendlier than SCSI subsystem. I don't know. I have configured network card, Intel EEPRO/100 under linux, and didn't have much trouble, but then I have configured network at the office many many times, and so it helped me, I guess. In comparison, the problem with Linux SCSI subsystem is that I have configured SCSI disks, tape drives, etc. at the office many times, but the experience didn't carry over very well. That is it. I can't pin point what (mis-)features of linux make it difficult for me to share the past SCSI experience: Maybe the devfs thing would help if only it has better introduction documents somewhere. It could be that this is the fate of open source system where the device drivers are written by totally independent groups with various features creeping/implemented at different speeds in different drivers. If this is the case, then there is no intrinsic cure. Anyway, better documentation would help to certain extent certainly. The paragraph between " .." above can be ripped and inserted with more detailed explanation of scsihosts in such a document. Anyway, viewing the (end) users as dumb who just want to play puts me in a
Re: Linux not adhering to BIOS Drive boot order?
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-scsi" in the body of a message to [EMAIL PROTECTED]
Re: Linux not adhering to BIOS Drive boot order?
On Tue, Jan 16, 2001 at 10:49:05AM -0500, 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. Nothing wrong with this. 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. Are your two SCSI controllers handled by the same driver or through different ones? If they're handled by two separate drivers, simply build that one you need to boot off into the kernel and build the other one as a module. If theay're both handled by *one* driver, you may look at your SCSI driver's sources to see whether or not there is a command line parameter you could use to alter scan/probe order. ...and you may try to put your two SCSI controllers to different PCI slots, of course... MfG, JBG -- Fehler eingestehen, Gre zeigen: Nehmt die Rechtschreibreform zurck!!! /* Jan-Benedict Glaw [EMAIL PROTECTED] -- +49-177-5601720 */ keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB "insmod vi.o and there we go..." (Alexander Viro on linux-kernel) PGP signature
RE: Linux not adhering to BIOS Drive boot order?
Are your two SCSI controllers handled by the same driver or through different ones? If they're handled by two separate drivers, simply build that one you need to boot off into the kernel and build the other one as a module. [Venkatesh Ramamurthy] Different ones with mutiple controllers. Compiling is good option for developers and for end-users i feel it might not be a fun way of doing this. There should be way for the kernel ( SCSI Mid - Layer to check the for the actual boot drive ) and re-order all the SCSI drives. NT does it this way ( using special signature written on the disk) - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED]
Re: Linux not adhering to BIOS Drive boot order?
[EMAIL PROTECTED] said: 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. Using ext2? lable the partitions and use the labels in /etc/fstab. -- 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-scsi" in the body of a message to [EMAIL PROTECTED]
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-scsi" in the body of a message to [EMAIL PROTECTED]
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-scsi" in the body of a message to [EMAIL PROTECTED]
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-scsi" in the body of a message to [EMAIL PROTECTED]
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-scsi" in the body of a message to [EMAIL PROTECTED]
