Richard Creighton wrote: > Greg Freemyer wrote: >> On 9/30/07, Richard Creighton <[EMAIL PROTECTED]> wrote: >> >>> Carlos E. R. wrote: >>> >> <snip> >> >>>> That's not quite so now. For instance, the limit on the number of >>>> partitions has been decreased from 64 to 16 (less than). That's one of the >>>> consequence of "progress" in the linux field. >>>> >>>> - -- >>>> Cheers, >>>> Carlos E. R. >>>> >>>> >>> Someone made an ill-advised decision to change the naming scheme of IDE >>> drives to be the same as the new SATA drives to be the same as SCSI. >>> In the process, it inherited the limitations of the SCSI drives. I >>> can't think of a reason for having done it, but it appears to have been >>> done in all the distros. I suspect there will be a great gnashing of >>> teeth when the next release hits the streets and some accomodation will >>> be forthcoming. As one of the beta testers for upcoming 10.3 SuSE, it >>> has already proven 'interesting' and caused me personally no end of >>> frustration. Generally though, Linux's progress has kept pace with the >>> newer hardware without losing sight of its historical past. This is one >>> of the few exceptions so far. I bet that there is NO chance that XP, >>> much less Vista will run on a 386 or a 286... I cranked up 10.2 on a >>> 486DX-2 the other day just to see it run...slow, but it ran :) >>> >>> >>> Richard >>> >> The issue is far deeper than naming conventions. >> >> When SATA support was added to the kernel (libata) they leveraged the >> entire SCSI subsystem due to its quality compared to the IDE >> subsystem. >> >> Then libata got to so good that many (most) of the PATA drivers were >> re-implemented (by Alan Cox of Redhat) via libata. And then the new >> implementations got stable enough that the distros decided to move to >> the libata pata drivers by default. (Fedora was the first to move in >> the spring.) >> >> But, for the foreseeable future you should be able to use the old >> drivers/ide implementation and get the old functionality (and naming >> convention). >> >> The long term solution is to have libata implement its own full set of >> infrastructure and no longer fit under the SCSI infrastructure. When >> that happens the partition limits should be restored to the higher >> limits. >> >> Novell has Tejun Heo supporting libata. He has done 2 major upgrades >> to it in the last 18 months (new error handling logic for 10.2, PMP >> support for 10.3, ??? for 11.0). >> >> My hope is that his next big project will be the libata >> infrastructure, but I have not seen anything posted about that yet. >> >> Greg >> > Greg, I usually do a lot of <snipping> but your reply deserves to be > seen in context and completeness. > > What you say is quite probably accurate. The problem is that the > implementation was made in such a way as to cause unexpected problems. > For many people, it probably was uneventful, but a lot of people have > mixed IDE and SATA architectures with motherboards that have both types > of controllers. These motherboards typically offer the IDE drives to > the OS first, then the SATA drives. I had a perfectly good 10.2 > installation on my IDE system drive and added SATA drives to the machine > for testing the 10.3 beta. I did not know of the unadvertised decision > to incorporate IDE into the SATA/SCSI family. Properly and COMPLETELY > done, there would have been no problem. Had there been a warning I > could have taken precautions but from 9.3 through 10.2 when I have > upgraded, I have never needed to worry about such things. Well, the > install went fine, the 10.3 beta installed onto the SATA drive, but the > IDE drive normally called hdb1 on my system was suddenly renamed sda2 > (my cdrom was on the master channel) and the first SATA drive became > sdb1 and when grub was written and the MBR was written, guess where it > was put....yup, it clobbered my IDE drive. Of course, this was totally > unexpected. OBTW, I neglected to tell you, the SATA drives were not > just 1 drive, they were 4 200G drives in a MD Raid configuration which > also confused the issue, but that is no reason to clobber the IDE MBR or > rewrite it's /boot or /boot/grub entries. To this day, if I want to > install any version above 10.3 beta 1, I have to unplug the IDE drive > until the installation is complete. Also, the YaST repair modules are > totally clueless still about the name changes.
I don't understand - you have full control over where the MBR is installed. By default, it goes on the first drive found. If you want to change that, you are free to do so. I don't understand why you have to unplug the IDE. I have the same setup (well, not RAID but a mix of IDE & SATA) and 10.3 actually installed better than 10.2 on this system. Not sure why you would blame the installation program. > So, while the motive to migrate is honorable, the decision to do so > unilaterally and without proper notice and warning about possible side > effects between minor releases I maintain is and was still ill > advised. To do so between version 10 and version 11 would have been For one, 10.3 is still in testing. For another, the drive renaming is mentioned in the Release Notes: http://www.suse.com/relnotes/i386/openSUSE/10.3/RELEASE-NOTES.en.html#08 > much more appropriate, but from .2 to .3, that usually signifies > relatively minor changes and enhancements and bug fixes and not major > changes. Since I can recall, IDE devices have been called HDxx and > drivers and software buried pretty deep has expected this for years. > To suddenly change this invites trouble, and it happened. I would have > simply unplugged the IDE drive if I had expected trouble, but the > stability of SuSE upgrades in the past even in beta has never put drives > not part of the experiment at risk before and I grew complacent ... my > bad, add a bad decision on the development end and a lot of people > are going to wonder what happened. The buglist reports bear that out > already. I still don't get why the drive renaming is a big deal. I have virtually never had to deal with the actual name of the drive and don't see why I care what it is called. -- Jonathan Arnold (mailto:[EMAIL PROTECTED]) Linux Brain Dump - Linux Notes, HOWTOs and Tutorials: http://www.linuxbraindump.org Daemon Dancing in the Dark, an Open OS weblog: http://freebsd.amazingdev.com/blog/ -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
