libata inconsistency through kernel updates

Bug #119659 reported by Radu Cristian Fotescu
4
Affects Status Importance Assigned to Milestone
linux-source-2.6.20 (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: kernel-image-2.6.20-16-386-di

With Ubuntu Feisty, each and every kernel update switches the forcefully use of libata for PATA drives from ON to OFF to ON to OFF...

Here's what I've experienced with Kubuntu 7.04:
* kernel 2.6.20-12: IDE (PATA) /dev/hda goes into /dev/sda
* kernel 2.6.20-13: IDE (PATA) goes back to /dev/hda
* kernel 2.6.20-14: IDE (PATA) /dev/hda goes again /dev/sda
* kernel 2.6.20-15: IDE (PATA) goes back to /dev/hda
* kernel 2.6.20-16: IDE (PATA) /dev/hda goes again /dev/sda

Is this project (Ubuntu/Kubuntu) really having a management? (Sorry, I had to say that. The aforementioned inconsistency is outrageous.)

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

(Bug #116996 and so long as there isn't a performance loss the renaming is a side issue if you use UUIDs - https://wiki.ubuntu.com/UsingUUID )

Revision history for this message
Radu Cristian Fotescu (beranger) wrote :

If 2.6.20 is about forcing users to have PATA disks treated bu the SATA driver, then let's do it CONSISTENTLY!

Nobody has the moral right to force Linux users to use UUIDs or labels when using device names is still possible in /etc/fstab and in other places! One might depend on backup software that needs the device names not changing during subsequent kernel updates!

Once the kernel has switched to libata (which I don't like, but it's Linus' decision after all), let's just f--king stick with it!

What is the reason to have it turned ON and OFF and ON and OFF and ON again, with every kernel update?!

Have you ever read a book on software project management?

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Radu:
Was that abuse aimed at me? It's true I am a programmer and yup I've read books on project management. I don't maintain the kernels in Ubuntu - I'm just another user. I don't even have hardware affected by this. I don't see that anyone is morally forcing you to use UUIDs/labels - you can avoid them and perhaps stuff will break. If your backup software is depending on device names then perhaps your backup software will break too? Maybe that's a bug in the backup software? Who knows?! If you really want to keep the old naming scheme you can always create udev rules to do the renaming for you...

Three of the kernels you mention were beta kernels (-12 to -14). I guess these sorts of changes happen during the testing phases as people try to work out what causes the least problems. The -16 revert is discussed in Bug #117314 .

Eventually I suspect most things will settle on libata (I believe it's Alan Cox/Jeff Garzik's decision and reasons for the move are given on http://lwn.net/Articles/198344/ ) but while some unknown subset of people are reporting issues with the libata drivers and some other set with similar hardware are reporting issue with the IDE drivers you are going to struggle to move people all at once or know who to move and who not to move.

Revision history for this message
Radu Cristian Fotescu (beranger) wrote : Re: [Bug 119659] Re: libata inconsistency through kernel updates

I am trying to get a life (I am getting older and I don't want to switch
distros like a mad man just because they're buggier than all the other
operating systems), and I am pissed off by the inability of the (K)Ubuntu
team to understand what QA is -- because only Mandriva is buggier than
(K)Ubuntu!

> I don't even have hardware affected by this.

I do have. Having
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/66637, i.e. the
swap's UUID permanently changing, I *had* to add the swap in fstab as
/dev/sdb3, then as /dev/hdb3, then as /dev/sdb3, then as /dev/hdb3, etc.

Then, my CD-RW permanently changes from /dev/hdd to /dev/sdb, then back to
/dev/hdd, then again /dev/sdb, etc.

HOW IS IT SO HARD TO UNDERSTAND THAT DURING THE LIFETIME OF A POINT RELEASE
(7.04), THE F--ING DEVICE NAMES SHOULD NOT F--ING CHANGE TWICE A WEEK,
DEPENDING ON THE LATEST KERNEL UPDATE?

> If you really want to keep the old naming scheme you can
> always create udev rules to do the renaming for you...

Or I can fucking stop using this f-- buggy and unstable and undermanaged
distro!

> Eventually I suspect most things will settle on libata (I believe it's
> Alan Cox/Jeff Garzik's decision and reasons for the move are given on
> http://lwn.net/Articles/198344/ ) but while some unknown subset of
> people are reporting issues with the libata drivers and some other set
> with similar hardware are reporting issue with the IDE drivers you are
> going to struggle to move people all at once or know who to move and who
> not to move.

If Ubuntu and Fedora have adopted buggy kernels, it is their decision, and
they have to assume it, not to switch back and forth all the time!

No, this is not project management.

      Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Radu:
OK my bad. My comments aren't helping (apologies for the udev reference) and I'll stop posting on libata bugs now.

Revision history for this message
Rich Johnson (nixternal) wrote :

1. This has been reported
2. Poisonous people and abuse will get you nowhere

Sitsofe, I appreciate you trying to help and offer assistance, I am sorry you had to put up with the abuse.

Radu, I think it would be in your best judgement to control how you criticize if you expect results. There was no reason whatsoever to take the numerous, unorganized, pot shots you did not only at (K)Ubuntu, but also a person offering some explanation.

Changed in linux-source-2.6.20:
status: Unconfirmed → Rejected
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.