I believe you'll be waiting a long time for them to "get it right". The vast majority of systems (probably about 99% at this point) have only a single disk controller in them. And so that's probably the only regularly tested configuration now. (I hadn't realised both disks were IDE; that just makes it more lucky that it happened to work before.) FWIW, it's not that the limitation is "never use more than one disk controller". It's that "using more than one disk controller is an advanced topic and will require sysadmin intervention". Which has pretty much always been true
( ... )
The vast majority of systems (probably about 99% at this point) have only a single disk controller in them. And so that's probably the only regularly tested configuration now. (I hadn't realised both disks were IDE; that just makes it more lucky that it happened to work before.)
I think you mean "the vast minority (about 10%)". Surely, the majority of systems currently in use would be of the massive socket 775 (P4/Pentium D/Celeron D/Core2Duo/Core2Extreme/Core2Quad) family and the majority of such machines have both IDE and SATA controllers on-board? I have a P4 machine with IDE, SATA and separate RAID controllers on-board and that's not that uncommon. Core i3/i5/i7 machines don't usually have IDE, but frequently have multiple SATA controllers on-board.
There is absolutely nothing "lucky" about it having worked before. Hda (drive c: to windows) is a well-known, well-defined starting point that every PC operating system for the last 20 years has understood until now.
FWIW, it's not that the limitation is "never use more than one
( ... )
Usually in those IDE + SATA on mainboard, only one of them has disks connected. (This is often true even when there is a "RAID" controller.) You're right that lots of motherboards have various legacy controllers on them now, but even having more than a single disk is relatively uncommon these days, let alone connecting it to a different controller type. (Cf 10 years ago when having multiple disks, often on multiple controllers, was the only way to get a sane amount of disk space.)
And FWIW figuring out which disk the BIOS treats as the boot disk is the core of the problem. Ever since ISA/PCI add on cards were able to "adjust" this (so about 20 years back), and then BIOSes started having "boot order" configuration, this became non-trivial. (I've had IDE + SCSI machines where I wanted to boot off SCSI; and others where I wanted to boot of IDE. It depended on why the disks were there. So I've dealt with this pain for a long time.)
All that said, recognising that your hardware situation is non trivial and saying "you have
( ... )
Re: Linux disk discoverykremmenJuly 12 2011, 05:08:58 UTC
Also, we're getting a little off the track here. It's not terrible if Debian decides to call the drives something different. It can call the boot drive /dev/silly42 if it wants to. But, whatever it calls it, installing grub2 in such a way as to create an unbootable system is just pathetic. I remember grub in the past warning of possible conflicts, even when it got things right. This is a major step backwards.
Re: Linux disk discoveryedmJuly 12 2011, 05:19:22 UTC
FWIW, my psychic powers tell me that what happened was that the driver for your PCI controller got loaded before the driver for the onboard disk controller, and so the PCI controller claimed sda, and the onboard one was left with sdb. The BIOS had the other idea (due to the boot order usually preferring onboard by default). Alas, Linux doesn't know what is "onboard" and what is on a PCI card; since it's PCI buses all the way down, and it takes board-specific knowledge to tell them apart (which the BIOS has baked in, but Linux does not, and there is no standard way for Linux to find out from the BIOS -- or even acceptably few "non standard" ways for Linux to find out
( ... )
Re: Linux disk discoverykremmenJuly 12 2011, 06:16:41 UTC
I don't see why you are trying so hard to excuse crap. Firstly, it could check the BIOS. Secondly, it could check the PCI bus intelligently. e.g. if you see a hard drive controller in the same slot as an ISA bridge or SMBus controller or similar, this is the on-board controller. That's a trivial test and would cover the vast majority of cases. More importantly, it would make the decision somewhat deterministic, instead of totally random.
Re: Linux disk discoveryedmJuly 12 2011, 08:14:31 UTC
Mostly because you seem disproportionally surprised that it didn't magically work in your particular corner case. I've been bitten so many times by this sort of thing that I'm usually surprised when it actually works.
As I've tried to explain, there isn't a way to "check the BIOS" (particularly from a protected mode OS). Maybe there should have been, but that ship sailed a couple of decades ago. Secondly the hard drive controller isn't "in the same slot" as the ISA bridge; generally they're all just on the PCI* bus as far as the software can tell. Again maybe there should have been a better hardware description data structure that made this obvious, but that too didn't happen. (If you have some deep cross-vendor insight into how trivial this check is to implement, I'd expect software implementations would be welcomed. But I've seen enough mjg59 rants to believe there is no such check
( ... )
Re: Linux disk discoverykremmenJuly 12 2011, 08:24:09 UTC
I have honestly never seen you spout such rubbish. Every single machine I've checked has obvious CPU components listed on the same slot as the IDE controller, usually the ISA bridge.
e.g. 00:11.0 ISA bridge: VIA Technologies, Inc. VT8233A ISA Bridge 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:11.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 23) 00:11.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 23)
I'm fairly sure I have never seen a single motherboard that uses up a whole PCI "slot" for just an on-board disk controller. If there is such a thing, then it is you that is talking about a corner case.
Re: Linux disk discoveryedmJuly 12 2011, 08:40:59 UTC
Curious. I'm used to looking at things more like this (eg, my home Linux box):
ewen@tv:~$ lspci | egrep 'ISA|IDE' 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3) 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) 00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) ewen@tv:~$
which are multiple PCI devices on the same bus, even though they're all in the same chip.
But prompted by your comment I checked a few (more modern) systems with Intel chipsets (rather than nVidia) and see that they're presenting like your example. As does one of the AMD chipset devices I have access to.
So I'll grant you, that does seem a somewhat useful heuristic for "more likely to be onboard". There'll likely be other "onboard" disk controllers (eg, the "RAID" ones) that aren't in the same package, and those ones might be the ones with the actual disk. But defaulting to the one in the same package as the ISA bridge, if
( ... )
It figures that you'd have one. :) I've never seen a machine with an nVidia chipset for anything other than purely graphics.
It seems to me that the old method was usually correct, while the new Squeeze method has a 1/n chance of being right, where n=number of controllers which have a live drive on them. n could be quite large, especially if that includes USB devices, external HDDs, etc.
However, the other issue is what went wrong at the grub2 installation. It installed onto the correct drive, yet it couldn't boot from it. I've never seen/used grub2 before, so this could be entirely its fault. Too many variables for me to care about, given that Lenny works fine. (And Lenny was still the default stable release until Feb this year, so I think we can still call it a "modern" Linux distro.)
Most of the vendor server hardware (which realistically is what I've mostly been running Linux on for years) also has the disk controller somewhere completely separate from the ISA controller. So I hadn't actually noticed that most of the (modern) PC desktop/laptop chipsets were presenting their "do everything" onboard controller as a single PCI device now
( ... )
Debian install reportedmJuly 12 2011, 08:57:38 UTC
Incidentally I meant to say that Debian has a form for install reports to be submitted into their bug tracking system. And if you felt inclined to do so it'd be worth suggesting at least: - look for a disk on a disk controller that is in the same PCI device as the ISA bus if you can find one, and consider that the default boot disk (even if it wasn't detected as sda -- and alert the user if it wasn't detected as sda); and - consider using 16-bit 1024x768 (rather than 32-bit) for the graphical install to enhance backwards compatibility, or at least try to automatically fall back to a mode requiring less than 4MB of video RAM
(As might be obvious I wasn't aware of one of those heuristics, so possibly others/the software isn't either.)
Reply
Reply
Reply
I think you mean "the vast minority (about 10%)". Surely, the majority of systems currently in use would be of the massive socket 775 (P4/Pentium D/Celeron D/Core2Duo/Core2Extreme/Core2Quad) family and the majority of such machines have both IDE and SATA controllers on-board? I have a P4 machine with IDE, SATA and separate RAID controllers on-board and that's not that uncommon. Core i3/i5/i7 machines don't usually have IDE, but frequently have multiple SATA controllers on-board.
There is absolutely nothing "lucky" about it having worked before. Hda (drive c: to windows) is a well-known, well-defined starting point that every PC operating system for the last 20 years has understood until now.
FWIW, it's not that the limitation is "never use more than one ( ... )
Reply
And FWIW figuring out which disk the BIOS treats as the boot disk is the core of the problem. Ever since ISA/PCI add on cards were able to "adjust" this (so about 20 years back), and then BIOSes started having "boot order" configuration, this became non-trivial. (I've had IDE + SCSI machines where I wanted to boot off SCSI; and others where I wanted to boot of IDE. It depended on why the disks were there. So I've dealt with this pain for a long time.)
All that said, recognising that your hardware situation is non trivial and saying "you have ( ... )
Reply
Reply
Reply
Reply
As I've tried to explain, there isn't a way to "check the BIOS" (particularly from a protected mode OS). Maybe there should have been, but that ship sailed a couple of decades ago. Secondly the hard drive controller isn't "in the same slot" as the ISA bridge; generally they're all just on the PCI* bus as far as the software can tell. Again maybe there should have been a better hardware description data structure that made this obvious, but that too didn't happen. (If you have some deep cross-vendor insight into how trivial this check is to implement, I'd expect software implementations would be welcomed. But I've seen enough mjg59 rants to believe there is no such check ( ... )
Reply
e.g.
00:11.0 ISA bridge: VIA Technologies, Inc. VT8233A ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:11.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 23)
00:11.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 23)
I'm fairly sure I have never seen a single motherboard that uses up a whole PCI "slot" for just an on-board disk controller. If there is such a thing, then it is you that is talking about a corner case.
Reply
ewen@tv:~$ lspci | egrep 'ISA|IDE'
00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2)
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
ewen@tv:~$
which are multiple PCI devices on the same bus, even though they're all in the same chip.
But prompted by your comment I checked a few (more modern) systems with Intel chipsets (rather than nVidia) and see that they're presenting like your example. As does one of the AMD chipset devices I have access to.
So I'll grant you, that does seem a somewhat useful heuristic for "more likely to be onboard". There'll likely be other "onboard" disk controllers (eg, the "RAID" ones) that aren't in the same package, and those ones might be the ones with the actual disk. But defaulting to the one in the same package as the ISA bridge, if ( ... )
Reply
I've never seen a machine with an nVidia chipset for anything other than purely graphics.
It seems to me that the old method was usually correct, while the new Squeeze method has a 1/n chance of being right, where n=number of controllers which have a live drive on them. n could be quite large, especially if that includes USB devices, external HDDs, etc.
However, the other issue is what went wrong at the grub2 installation. It installed onto the correct drive, yet it couldn't boot from it. I've never seen/used grub2 before, so this could be entirely its fault. Too many variables for me to care about, given that Lenny works fine. (And Lenny was still the default stable release until Feb this year, so I think we can still call it a "modern" Linux distro.)
Reply
Reply
- look for a disk on a disk controller that is in the same PCI device as the ISA bus if you can find one, and consider that the default boot disk (even if it wasn't detected as sda -- and alert the user if it wasn't detected as sda); and
- consider using 16-bit 1024x768 (rather than 32-bit) for the graphical install to enhance backwards compatibility, or at least try to automatically fall back to a mode requiring less than 4MB of video RAM
(As might be obvious I wasn't aware of one of those heuristics, so possibly others/the software isn't either.)
Ewen
Reply
Leave a comment