Re: Bug#2063: scsi driver sequence unreasonable
> In article <[🔎] 199512271741.LAA01207@router.patch.net> you wrote:
>
> : It doesn't really matter if a 152X gets detected before a high-power
> : whiz-bang SCSI-matic 2010 PCI adapter, because you can still put root
> : on any SCSI controller you like.
>
> You are correct, of course, Jeff, but the problem with having a card like
> a 15[12]X recognized first is that if you have machines like mine, which all
> have one fast controller that's always there and has the root on it, and you
> then stick 1510's in from time to time when you need to temporarily hang
> an external disk chassis on, or put a tape drive on, or something else that
> is transitory, you have to go through contortions to boot because what
> normally would be the 0th SCSI controller isn't any more, though it may be
> again shortly.
Agreed, that's a problem. Moving the probes around doesn't really solve
it: someone switching to Debian from Slackware will find their SCSI
controllers detected in reverse order, for example. It's a no-win
situation.
> This seems unfortunate. The other OS's I've had experience with (and there
> are many on the list) always made it possible to either nail down hard where
> the root disk was going to be, physically, or they sequenced driver discovery
> "correctly" to handle this case. None have been perfect for all cases, but
> all treated my needs better than Linux currently does.
You're onto something here. I wonder how difficult it would be to add
something to the partition tables to nail down drives to devices. Windows
NT, for example, does _something_ when you run it's fdisk program that
lets you re-order drives.
We'd need to extend the kernel for this, and fdisk and cfdisk would need
to be updated. I'm not up for the kernel work required, but since I have
the dubious distinction of fdisk maintainer, I would be willing to work
on that part. :)
Are there any kernel hackers lurking about that might have an idea as
to how difficult a project this would be? Does the Linux RAID stuff
already have provisions for this?
> I'm not going to get upset no matter what Simon decides to do, because I
> suspect I'll be building custom kernels for most of my machines no matter
> what, but I wanted to make sure that the "silliness" of the current approach
> in my eyes got registered someewhere and fed back upstream.
I'm not running Debian kernels either. PPP 2.2.X is still broken, for
example, and I don't want to be forced to use it. 2.1.2d works just fine
in a stock 1.2.13 kernel.
Thanks,
Jeff
Reply to: