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.)
Yes it sucks. But much of the sucking didn't originate with Linux. And newer hardware mostly rendered the old heuristics unusable. The PC architecture could have been so much better in so many ways. But it isn't. I do agree, though, that it would be better if the software recognised when it was making potentially unwarranted assumptions (eg, disks on multiple controllers: something which is found out in the discovery process), and flagged it as "an advanced install, please check the auto-detection results". (I'd ask for preferring common "onboard" SATA chipsets, except that the SATA chipsets are used basically interchangably onboard and on PCI cards.)
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 there is a disk on a disk controller in the same PCI device as ISA bridge, seems like as good a default as any. It might even be the disk the system is supposed to boot off.
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.
It is indeed sad that the old method worked more predictably in the "more than one disk, but boot disk is on onboard IDE controller" situation, and the "modern Linux" method (not just Squeeze, but pretty much anything using Linux kernels released in the last 2-3 years -- Lenny was one of the last not to do it this way) forces more people with multiple disk controllers into knowing intricate hardware details ("how did you jumper your ISA card" :-) ). They have largely given up on predictable device naming (sda, sdb, etc can refer to anything), and suggested more unique identifiers for mounting partitions (eg, label, or file system ID -- IIRC Debian defaults to file system ID) which works after you've booted. But the booting problem seems to have been surrendered as "too hard" to deal with any non-trivial case automatically. (And it makes me sad that it doesn't even warn that a given case is non-trivial.)
FYI, I'm sorry you had such an icky experience with what should have been a relatively small Linux upgrade. There was a bit too much pretence that it could automagically do the right thing, and insufficient automagic to actually do so. Sadly the level of "regression in user experience" in Linux seems much higher than was tolerated in the 1990s.
Re grub2, they changed the device naming inside grub from what was used in grub1 (sigh), such that (hd0,0) in grub1 is the first disk, and (hd1,0) is the first disk in grub2 (and there is no (hd0,0) in grub2). This bit me a while ago. As a result you might think it did the right thing, but actually it might not have. (There's also an "auto discovered" -- but editable -- map of Linux devices to BIOS devices used by grub which affects this. "grub-install" tries to automagically do the right thing, which often works, but not always. Sigh.) It's probably possible to make grub2 do the right thing on your hardware (I did eventually succeed on a variety of systems), but I can completely empathise with wanting to put off that battle some more. (I stuck with lilo for years on some of my multi-disk-controller systems, just because I had beaten it into shape already.)
Ewen
PS: Lenny was released early 2009, and there's a school of thought that Debian stable releases are "out of date" before they are released, so it's barely a "modern" Linux for many discussion purposes.
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.)
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.)
Yes it sucks. But much of the sucking didn't originate with Linux. And newer hardware mostly rendered the old heuristics unusable. The PC architecture could have been so much better in so many ways. But it isn't. I do agree, though, that it would be better if the software recognised when it was making potentially unwarranted assumptions (eg, disks on multiple controllers: something which is found out in the discovery process), and flagged it as "an advanced install, please check the auto-detection results". (I'd ask for preferring common "onboard" SATA chipsets, except that the SATA chipsets are used basically interchangably onboard and on PCI cards.)
Ewen
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 there is a disk on a disk controller in the same PCI device as ISA bridge, seems like as good a default as any. It might even be the disk the system is supposed to boot off.
Ewen
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
It is indeed sad that the old method worked more predictably in the "more than one disk, but boot disk is on onboard IDE controller" situation, and the "modern Linux" method (not just Squeeze, but pretty much anything using Linux kernels released in the last 2-3 years -- Lenny was one of the last not to do it this way) forces more people with multiple disk controllers into knowing intricate hardware details ("how did you jumper your ISA card" :-) ). They have largely given up on predictable device naming (sda, sdb, etc can refer to anything), and suggested more unique identifiers for mounting partitions (eg, label, or file system ID -- IIRC Debian defaults to file system ID) which works after you've booted. But the booting problem seems to have been surrendered as "too hard" to deal with any non-trivial case automatically. (And it makes me sad that it doesn't even warn that a given case is non-trivial.)
FYI, I'm sorry you had such an icky experience with what should have been a relatively small Linux upgrade. There was a bit too much pretence that it could automagically do the right thing, and insufficient automagic to actually do so. Sadly the level of "regression in user experience" in Linux seems much higher than was tolerated in the 1990s.
Re grub2, they changed the device naming inside grub from what was used in grub1 (sigh), such that (hd0,0) in grub1 is the first disk, and (hd1,0) is the first disk in grub2 (and there is no (hd0,0) in grub2). This bit me a while ago. As a result you might think it did the right thing, but actually it might not have. (There's also an "auto discovered" -- but editable -- map of Linux devices to BIOS devices used by grub which affects this. "grub-install" tries to automagically do the right thing, which often works, but not always. Sigh.) It's probably possible to make grub2 do the right thing on your hardware (I did eventually succeed on a variety of systems), but I can completely empathise with wanting to put off that battle some more. (I stuck with lilo for years on some of my multi-disk-controller systems, just because I had beaten it into shape already.)
Ewen
PS: Lenny was released early 2009, and there's a school of thought that Debian stable releases are "out of date" before they are released, so it's barely a "modern" Linux for many discussion purposes.
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