USB are not working. No comment
antonio montagnani wrote:
USB are not working. No comment
Yes, I have the same problem, the memory stick still does not show up on my desktop. Did I miss something, is there something else I need to do to get it working again?
uname -a Linux box6 2.6.22.1-33.fc7 #1 SMP Mon Jul 23 17:33:07 EDT 2007 i686 i686 i386 GNU/Linux
lsusb Bus 005 Device 004: ID 154b:000f <<< The flash memory stick Bus 005 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 003 Device 001: ID 0000:0000 Bus 002 Device 004: ID 046d:0870 Logitech, Inc. QuickCam Express Bus 002 Device 001: ID 0000:0000 Bus 002 Device 003: ID 046d:c408 Logitech, Inc. Marble Mouse (4-button) Bus 001 Device 001: ID 0000:0000
Bob Goodwin
2007/7/27, Bob Goodwin bobgoodwin@wildblue.net:
antonio montagnani wrote:
USB are not working. No comment
Yes, I have the same problem, the memory stick still does not show up on my desktop. Did I miss something, is there something else I need to do to get it working again?
uname -a Linux box6 2.6.22.1-33.fc7 #1 SMP Mon Jul 23 17:33:07 EDT 2007 i686 i686 i386 GNU/Linux
lsusb Bus 005 Device 004: ID 154b:000f <<< The flash memory stick Bus 005 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 003 Device 001: ID 0000:0000 Bus 002 Device 004: ID 046d:0870 Logitech, Inc. QuickCam Express Bus 002 Device 001: ID 0000:0000 Bus 002 Device 003: ID 046d:c408 Logitech, Inc. Marble Mouse (4-button) Bus 001 Device 001: ID 0000:0000
Bob Goodwin
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Bus 005 Device 004: ID 13fe:1a00 Bus 005 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 002 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Bus 002 Device 001: ID 0000:0000 Bus 003 Device 001: ID 0000:0000 Bus 001 Device 004: ID 04b8:010b Seiko Epson Corp. Perfection 1240 Bus 001 Device 001: ID 0000:0000
that's mine. Bob, we didn't miss anything, someone else is missing to complete test before issuing new kernels: I will not update my laptop, as I can't risk to have no USB, no scanner, no Picture reading from my camera, where there is not easy Internet connection on top of the mountains... :-( !!!!
antonio montagnani wrote:
2007/7/27, Bob Goodwin bobgoodwin@wildblue.net:
antonio montagnani wrote:
USB are not working. No comment
Yes, I have the same problem, the memory stick still does not show up on my desktop. Did I miss something, is there something else I need to do to get it working again?
uname -a Linux box6 2.6.22.1-33.fc7 #1 SMP Mon Jul 23 17:33:07 EDT 2007 i686 i686 i386 GNU/Linux
lsusb Bus 005 Device 004: ID 154b:000f <<< The flash memory stick Bus 005 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 003 Device 001: ID 0000:0000 Bus 002 Device 004: ID 046d:0870 Logitech, Inc. QuickCam Express Bus 002 Device 001: ID 0000:0000 Bus 002 Device 003: ID 046d:c408 Logitech, Inc. Marble Mouse (4-button) Bus 001 Device 001: ID 0000:0000
Bob Goodwin
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Bus 005 Device 004: ID 13fe:1a00 Bus 005 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 002 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Bus 002 Device 001: ID 0000:0000 Bus 003 Device 001: ID 0000:0000 Bus 001 Device 004: ID 04b8:010b Seiko Epson Corp. Perfection 1240 Bus 001 Device 001: ID 0000:0000
that's mine. Bob, we didn't miss anything, someone else is missing to complete test before issuing new kernels: I will not update my laptop, as I can't risk to have no USB, no scanner, no Picture reading from my camera, where there is not easy Internet connection on top of the mountains... :-( !!!!
My computer treats the flash drive as /dev/sdc1 so I just added it to ftsab as such which allows me to mount it as /mnt/flash from the command line. Not as nice as having an icon pop up but it works just as well and I generally deal with its contents from the command line anyway.
The alternative is to continue to boot from the earlier [3228] kernel which I still have and that works as expected.
Bob Goodwin
2007/7/27, Bob Goodwin bobgoodwin@wildblue.net:
antonio montagnani wrote:
2007/7/27, Bob Goodwin bobgoodwin@wildblue.net:
antonio montagnani wrote:
USB are not working. No comment
Yes, I have the same problem, the memory stick still does not show up on my desktop. Did I miss something, is there something else I need to do to get it working again?
uname -a Linux box6 2.6.22.1-33.fc7 #1 SMP Mon Jul 23 17:33:07 EDT 2007 i686 i686 i386 GNU/Linux
lsusb Bus 005 Device 004: ID 154b:000f <<< The flash memory stick Bus 005 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 003 Device 001: ID 0000:0000 Bus 002 Device 004: ID 046d:0870 Logitech, Inc. QuickCam Express Bus 002 Device 001: ID 0000:0000 Bus 002 Device 003: ID 046d:c408 Logitech, Inc. Marble Mouse (4-button) Bus 001 Device 001: ID 0000:0000
Bob Goodwin
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Bus 005 Device 004: ID 13fe:1a00 Bus 005 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 002 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Bus 002 Device 001: ID 0000:0000 Bus 003 Device 001: ID 0000:0000 Bus 001 Device 004: ID 04b8:010b Seiko Epson Corp. Perfection 1240 Bus 001 Device 001: ID 0000:0000
that's mine. Bob, we didn't miss anything, someone else is missing to complete test before issuing new kernels: I will not update my laptop, as I can't risk to have no USB, no scanner, no Picture reading from my camera, where there is not easy Internet connection on top of the mountains... :-( !!!!
My computer treats the flash drive as /dev/sdc1 so I just added it to ftsab as such which allows me to mount it as /mnt/flash from the command line. Not as nice as having an icon pop up but it works just as well and I generally deal with its contents from the command line anyway.
The alternative is to continue to boot from the earlier [3228] kernel which I still have and that works as expected.
Bob Goodwin
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
and that didn't work with a scanner as user (only as root): once again, I assume that the tester should at least have a scanner and an USB stick and check them before issuing. Otherwise three jumps ahead and two jumps back!!! and you don't know what is going to be broken: updating means updating, not improving some parts and killing others :-(
On Fri, 2007-07-27 at 13:34 +0200, antonio montagnani wrote:
USB are not working. No comment
I don't notice any USB problems here. USB mouse, keyboard, and a flash drive are all working as I expect them to.
There's a dearth of information in the two recent 2.6.22.1-33.fc7 kernel problem threads from those that have something not working. They'll need to provide more information (/var/log/messages, dmesg, probably some other things, too).
Bob Goodwin wrote:
My computer treats the flash drive as /dev/sdc1 so I just added it to ftsab as such which allows me to mount it as /mnt/flash from the command line. Not as nice as having an icon pop up but it works just as well and I generally deal with its contents from the command line anyway.
The alternative is to continue to boot from the earlier [3228] kernel which I still have and that works as expected.
Bob Goodwin
One thing to be aware of - if there is an entry to mount the device in /etc/fstab, then HAL will not try to mount the device. So when HAL mounting is fixed, you will probably have to remove it before HAL auto-mounting will work for you.
Mikkel
and that didn't work with a scanner as user (only as root): once again, I assume that the tester should at least have a scanner and an USB stick and check them before issuing. Otherwise three jumps ahead and two jumps back!!! and you don't know what is going to be broken: updating means updating, not improving some parts and killing others :-(
For what its worth, its not as simple as you are making out.
For me, the latest kernel actually fixed USB mounting - I now get it automatically whereas before I didn't. I use KDE, maybe thats important ?
Also what makes you think anyone owes it to you to test *your* hardware for you before releasing updates - Fedora isn't RHEL you know, no support guarantees etc. I suggest you take a look at the testing mailing list / repos to see how hard the testers do work. Still bugs will still get through in a bleeding edge distro like Fedora. Either make an effort and do the testing yourself and provide feedback, or use a more stable distro, like a RHEL derived work (centos... etc.)
Chris
2007/7/27, Tim ignored_mailbox@yahoo.com.au:
On Fri, 2007-07-27 at 13:34 +0200, antonio montagnani wrote:
USB are not working. No comment
I don't notice any USB problems here. USB mouse, keyboard, and a flash drive are all working as I expect them to.
There's a dearth of information in the two recent 2.6.22.1-33.fc7 kernel problem threads from those that have something not working. They'll need to provide more information (/var/log/messages, dmesg, probably some other things, too).
-- [tim@bigblack ~]$ uname -ipr 2.6.22.1-33.fc7 i686 i386
Using FC 4, 5, 6 & 7, plus CentOS 5. Today, it's FC7.
Don't send private replies to my address, the mailbox is ignored. I read messages from the public lists.
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
dmesg usb-storage: device found at 7 usb-storage: waiting for device to settle before scanning usb-storage: device scan complete scsi 5:0:0:0: Direct-Access USB DISK 2.0 PMAP PQ: 0 ANSI: 0 CCS sd 5:0:0:0: [sdb] 964608 512-byte hardware sectors (494 MB) sd 5:0:0:0: [sdb] Write Protect is off sd 5:0:0:0: [sdb] Mode Sense: 23 00 00 00 sd 5:0:0:0: [sdb] Assuming drive cache: write through sd 5:0:0:0: [sdb] 964608 512-byte hardware sectors (494 MB) sd 5:0:0:0: [sdb] Write Protect is off sd 5:0:0:0: [sdb] Mode Sense: 23 00 00 00 sd 5:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 sd 5:0:0:0: [sdb] Attached SCSI removable disk sd 5:0:0:0: Attached scsi generic sg3 type 0
var/log/messages Jul 27 16:53:59 Casa kernel: usb 5-5: new high speed USB device using ehci_hcd and address 7 Jul 27 16:54:00 Casa kernel: usb 5-5: configuration #1 chosen from 1 choice Jul 27 16:54:00 Casa kernel: scsi5 : SCSI emulation for USB Mass Storage devices Jul 27 16:54:05 Casa kernel: scsi 5:0:0:0: Direct-Access USB DISK 2.0 PMAP PQ: 0 ANSI: 0 CCS Jul 27 16:54:05 Casa kernel: sd 5:0:0:0: [sdb] 964608 512-byte hardware sectors (494 MB) Jul 27 16:54:05 Casa kernel: sd 5:0:0:0: [sdb] Write Protect is off Jul 27 16:54:05 Casa kernel: sd 5:0:0:0: [sdb] Assuming drive cache: write through Jul 27 16:54:05 Casa kernel: sd 5:0:0:0: [sdb] 964608 512-byte hardware sectors (494 MB) Jul 27 16:54:05 Casa kernel: sd 5:0:0:0: [sdb] Write Protect is off Jul 27 16:54:05 Casa kernel: sd 5:0:0:0: [sdb] Assuming drive cache: write through Jul 27 16:54:05 Casa kernel: sdb: sdb1 Jul 27 16:54:05 Casa kernel: sd 5:0:0:0: [sdb] Attached SCSI removable disk Jul 27 16:54:05 Casa kernel: sd 5:0:0:0: Attached scsi generic sg3 type 0
I still think that new kernel are not working fine, as old kernel 2.6.21-1.3228 was o.k. And I still think that testing was not o.k.
2007/7/27, Chris Jones jonesc@hep.phy.cam.ac.uk:
and that didn't work with a scanner as user (only as root): once again, I assume that the tester should at least have a scanner and an USB stick and check them before issuing. Otherwise three jumps ahead and two jumps back!!! and you don't know what is going to be broken: updating means updating, not improving some parts and killing others :-(
For what its worth, its not as simple as you are making out.
For me, the latest kernel actually fixed USB mounting - I now get it automatically whereas before I didn't. I use KDE, maybe thats important ?
Also what makes you think anyone owes it to you to test *your* hardware for you before releasing updates - Fedora isn't RHEL you know, no support guarantees etc. I suggest you take a look at the testing mailing list / repos to see how hard the testers do work. Still bugs will still get through in a bleeding edge distro like Fedora. Either make an effort and do the testing yourself and provide feedback, or use a more stable distro, like a RHEL derived work (centos... etc.)
Chris
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Chris
I am using Fedora since first release: and if you look back I reported some bugs (the latest are scanner as user not working). If USB is not working any more in latest releases, I assume that something were not tested (I mean something very easy to test, a 10USD stick to connect and disconnect...) And I assume that my early report about USB not working is an early warning that should be appreciated by developers, don't you??
I am using Fedora since first release: and if you look back I reported some bugs (the latest are scanner as user not working). If USB is not working any more in latest releases, I assume that something were not tested (I mean something very easy to test, a 10USD stick to connect and disconnect...) And I assume that my early report about USB not working is an early warning that should be appreciated by developers, don't you??
I think it is very unfair to claim that testing was not done. Any new update, before being released, is put into the testing repo first. At this point the kind souls who choose to run the testing repo get these updates and report the problems back to the fedora testing lists etc. Any problems which are found are usually fixed.
using the testing repo is voluntary and thus it is quite unfair to complain that it is not properly done. It is not true that USB is completely broken with the new kernel, for many people its OK and for me at least it got better. Maybe the problem is somehow specific to your hardware (sounds likely to me), in which case unless some which your hardware was kind enough to try out the test releases, then your problem would not be found until now. Did you bother to try testing yourself ? If not don't complain about those that do.
Chris
Mikkel L. Ellertson wrote:
Bob Goodwin wrote:
My computer treats the flash drive as /dev/sdc1 so I just added it to ftsab as such which allows me to mount it as /mnt/flash from the command line. Not as nice as having an icon pop up but it works just as well and I generally deal with its contents from the command line anyway.
The alternative is to continue to boot from the earlier [3228] kernel which I still have and that works as expected.
Bob Goodwin
One thing to be aware of - if there is an entry to mount the device in /etc/fstab, then HAL will not try to mount the device. So when HAL mounting is fixed, you will probably have to remove it before HAL auto-mounting will work for you.
Mikkel
Thanks, I will try to remember that. I am sure the problem will be fixed, in fact when I saw the new kernel this morning I figured that would take care of the problem but no luck on that one, maybe next time. In the mean time I can manage ...
Bob Goodwin
2007/7/27, Chris Jones jonesc@hep.phy.cam.ac.uk:
I am using Fedora since first release: and if you look back I reported some bugs (the latest are scanner as user not working). If USB is not working any more in latest releases, I assume that something were not tested (I mean something very easy to test, a 10USD stick to connect and disconnect...) And I assume that my early report about USB not working is an early warning that should be appreciated by developers, don't you??
I think it is very unfair to claim that testing was not done. Any new update, before being released, is put into the testing repo first. At this point the kind souls who choose to run the testing repo get these updates and report the problems back to the fedora testing lists etc. Any problems which are found are usually fixed.
using the testing repo is voluntary and thus it is quite unfair to complain that it is not properly done. It is not true that USB is completely broken with the new kernel, for many people its OK and for me at least it got better. Maybe the problem is somehow specific to your hardware (sounds likely to me), in which case unless some which your hardware was kind enough to try out the test releases, then your problem would not be found until now. Did you bother to try testing yourself ? If not don't complain about those that do.
Chris
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Chris,
if I report that something is not working (and it is not connected to my hardware, as it was working fine with previous kernels...) it is a kind of testing: and using Fedora in a real environment (offices...not software houses, but real life, writing, making calculations, and so on.) is very interesting also for developers. If I say that my USB stick was fine on previous kernels and now not any longer I am here to give additional informations according to my skills.And it is the same for scanner (fine in previous kernels, not now): of course if I should have tested only my USB external disks I should have not reported any problem, as they are fine. Stop
Chris Jones wrote:
and that didn't work with a scanner as user (only as root): once again, I assume that the tester should at least have a scanner and an USB stick and check them before issuing. Otherwise three jumps ahead and two jumps back!!! and you don't know what is going to be broken: updating means updating, not improving some parts and killing others :-(
For what its worth, its not as simple as you are making out.
For me, the latest kernel actually fixed USB mounting - I now get it automatically whereas before I didn't. I use KDE, maybe thats important ?
Also what makes you think anyone owes it to you to test *your* hardware for you before releasing updates - Fedora isn't RHEL you know, no support guarantees etc. I suggest you take a look at the testing mailing list / repos to see how hard the testers do work. Still bugs will still get through in a bleeding edge distro like Fedora. Either make an effort and do the testing yourself and provide feedback, or use a more stable distro, like a RHEL derived work (centos... etc.)
Chris
The way I look at it is that the developers only have so much hardware to test things on. If it works with their hardware, then they release it to testing so that users with other hardware can test it. If it works for the testers, then it gets out to the general Fedora users. There it is used on many more hardware combinations. From the reports of things not working, data is gathered to hopefully fix other bugs. The end results are passed on to less bleeding edge distributions so that they do not run into the same problems. Some things that are tested on Fedora will probably never make it into more stable distributions because they were a good idea that didn't work out in practice.
Just my 2 cents... Mikkel
2007/7/27, Mikkel L. Ellertson mikkel@infinity-ltd.com:
Chris Jones wrote:
and that didn't work with a scanner as user (only as root): once again, I assume that the tester should at least have a scanner and an USB stick and check them before issuing. Otherwise three jumps ahead and two jumps back!!! and you don't know what is going to be broken: updating means updating, not improving some parts and killing others :-(
For what its worth, its not as simple as you are making out.
For me, the latest kernel actually fixed USB mounting - I now get it automatically whereas before I didn't. I use KDE, maybe thats important ?
Also what makes you think anyone owes it to you to test *your* hardware for you before releasing updates - Fedora isn't RHEL you know, no support guarantees etc. I suggest you take a look at the testing mailing list / repos to see how hard the testers do work. Still bugs will still get through in a bleeding edge distro like Fedora. Either make an effort and do the testing yourself and provide feedback, or use a more stable distro, like a RHEL derived work (centos... etc.)
Chris
The way I look at it is that the developers only have so much hardware to test things on. If it works with their hardware, then they release it to testing so that users with other hardware can test it. If it works for the testers, then it gets out to the general Fedora users. There it is used on many more hardware combinations. From the reports of things not working, data is gathered to hopefully fix other bugs. The end results are passed on to less bleeding edge distributions so that they do not run into the same problems. Some things that are tested on Fedora will probably never make it into more stable distributions because they were a good idea that didn't work out in practice.
Just my 2 cents... Mikkel --
Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
I fully agree with you: and it is the way that I will stay as a normal Fedora user, my living unfortunately doesn't come out either from software or computer hardware, so it is an extra work for me to report problems. If additional information are required, happy to share them!!!
The way I look at it is that the developers only have so much hardware to test things on. If it works with their hardware, then they release it to testing so that users with other hardware can test it. If it works for the testers, then it gets out to the general Fedora users. There it is used on many more hardware combinations. From the reports of things not working, data is gathered to hopefully fix other bugs. The end results are passed on to less bleeding edge distributions so that they do not run into the same problems. Some things that are tested on Fedora will probably never make it into more stable distributions because they were a good idea that didn't work out in practice.
Just my 2 cents... Mikkel
I totally agree with you.
My point was simply it is not fair or useful to complain that the testers are not doing their job problem simply because an update gets out that causes problems for some users. As you say, the testers are a small sub-set of the total community and thus don't have all the hardware available.
Of course it is correct to report problems back here, in order to help solve such things, but its best to do so with all the complaining or claiming that 'it should never happen', that doesn't go down well with the testers themselves.
Chris
Around 04:02pm on Friday, July 27, 2007 (UK time), antonio montagnani scrawled:
And I assume that my early report about USB not working is an early warning that should be appreciated by developers, don't you??
I imagine that the ammount of appreciation would be related to the format, tone and effort of your "early warning". You did log it in bugizilla, didn't you. Assiming you did, and if you don't come accross as being ungrateful for something that they put a lot of effort into to provide you with free OS and systems, and if you provide all relevent information about your hardware, the nature of the problem, and any messages, then I am sure they will glad you are helping make Fedora better.
Steve
2007/7/27, Steve Searle steve@stevesearle.com:
Around 04:02pm on Friday, July 27, 2007 (UK time), antonio montagnani scrawled:
And I assume that my early report about USB not working is an early warning that should be appreciated by developers, don't you??
I imagine that the ammount of appreciation would be related to the format, tone and effort of your "early warning". You did log it in bugizilla, didn't you. Assiming you did, and if you don't come accross as being ungrateful for something that they put a lot of effort into to provide you with free OS and systems, and if you provide all relevent information about your hardware, the nature of the problem, and any messages, then I am sure they will glad you are helping make Fedora better.
Steve
--
Play Champions - my free football predictions game at: http://www.stevesearle.com/champs/about.html
16:39:32 up 13 days, 16:27, 2 users, load average: 0.03, 0.09, 0.11
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Bugzilla Bug 249282: USB memory can't mount on kernel 2.6.22.1-27.fc7 and other related bugs
I am not alone in the boat, and I am not drunk....
2007/7/27, antonio montagnani antonio.montagnani@gmail.com:
2007/7/27, Steve Searle steve@stevesearle.com:
Around 04:02pm on Friday, July 27, 2007 (UK time), antonio montagnani scrawled:
And I assume that my early report about USB not working is an early warning that should be appreciated by developers, don't you??
I imagine that the ammount of appreciation would be related to the format, tone and effort of your "early warning". You did log it in bugizilla, didn't you. Assiming you did, and if you don't come accross as being ungrateful for something that they put a lot of effort into to provide you with free OS and systems, and if you provide all relevent information about your hardware, the nature of the problem, and any messages, then I am sure they will glad you are helping make Fedora better.
Steve
--
Play Champions - my free football predictions game at: http://www.stevesearle.com/champs/about.html
16:39:32 up 13 days, 16:27, 2 users, load average: 0.03, 0.09, 0.11
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Bugzilla Bug 249282: USB memory can't mount on kernel 2.6.22.1-27.fc7 and other related bugs
I am not alone in the boat, and I am not drunk....
-- Antonio Montagnani Skype : antoniomontag
another clue: I rebooted with latest kernel anf USB stick is seen if connected before booting!!! if I disconnect it and re-connect it no way to see it.Any additional information required???
2007/7/27, Chris Jones jonesc@hep.phy.cam.ac.uk:
I am using Fedora since first release: and if you look back I reported some bugs (the latest are scanner as user not working). If USB is not working any more in latest releases, I assume that something were not tested (I mean something very easy to test, a 10USD stick to connect and disconnect...) And I assume that my early report about USB not working is an early warning that should be appreciated by developers, don't you??
I think it is very unfair to claim that testing was not done. Any new update, before being released, is put into the testing repo first. At this point the kind souls who choose to run the testing repo get these updates and report the problems back to the fedora testing lists etc. Any problems which are found are usually fixed.
using the testing repo is voluntary and thus it is quite unfair to complain that it is not properly done. It is not true that USB is completely broken with the new kernel, for many people its OK and for me at least it got better. Maybe the problem is somehow specific to your hardware (sounds likely to me), in which case unless some which your hardware was kind enough to try out the test releases, then your problem would not be found until now. Did you bother to try testing yourself ? If not don't complain about those that do.
Chris
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
this is my UUID smolt number.....c22ce927-11ea-437b-a76c-20865908b0a1
Chris Jones wrote:
Also what makes you think anyone owes it to you to test *your* hardware for you before releasing updates - Fedora isn't RHEL you know, no support guarantees etc.
I don't agree.
If a developer makes a change which prevents the software working with some hardware it previously worked with, I think the onus is on the developer to warn the user of this.
If the developer doesn't realize that his modification will have this effect, he has made a mistake.
I very much doubt if anyone realized that going from 2.6.22.1-28 to 2.6.22.1-33 could have any adverse effect.
Chris Jones:
Also what makes you think anyone owes it to you to test *your* hardware for you before releasing updates - Fedora isn't RHEL you know, no support guarantees etc.
Timothy Murphy:
I don't agree.
If a developer makes a change which prevents the software working with some hardware it previously worked with, I think the onus is on the developer to warn the user of this.
How would they know that it doesn't work on hardware that they don't have?
Timothy Murphy wrote:
Chris Jones wrote:
Also what makes you think anyone owes it to you to test *your* hardware for you before releasing updates - Fedora isn't RHEL you know, no support guarantees etc.
I don't agree.
If a developer makes a change which prevents the software working with some hardware it previously worked with, I think the onus is on the developer to warn the user of this.
You would have a valid point if you were running RHEL or one of the clones like centos. By definition, some changes in Fedora are going to break things for some people.
If the developer doesn't realize that his modification will have this effect, he has made a mistake.
Considering the sometimes complex interactions between the kernel, udev, HAL, and your desktop manager, it is almost impossible to know how a modification is going to affect all machines. This is why we have testing. You can have a modification that works fine for the developer, works fine for the people that use the testing repos, but will still fail for a small percentage of the final users.
I very much doubt if anyone realized that going from 2.6.22.1-28 to 2.6.22.1-33 could have any adverse effect.
This is why there is a testing process that starts with the developer, progresses to the testing repos, and finely moves to us. Because of the wide range of hardware/software, there is no way the developers can test it all. The testing repos give a wider range, but it still doesn't come close to the Fedora user base. I don't know about you, but part of the reason I am using Fedora is to help get the bugs out.
Mikkel
Tim wrote:
Chris Jones:
Also what makes you think anyone owes it to you to test *your* hardware for you before releasing updates - Fedora isn't RHEL you know, no support guarantees etc.
Timothy Murphy:
I don't agree.
If a developer makes a change which prevents the software working with some hardware it previously worked with, I think the onus is on the developer to warn the user of this.
How would they know that it doesn't work on hardware that they don't have?
1. We are talking about CHANGES in software, not new software,
If someone makes a change in the way software operates, he should consider (in my view) if there is any hardware on which this might not work. It is not actually necessary to have the hardware in order to work this out.
2. The actual question was about a change between Fedora kernels 2.6.22.1-27 and 2.6.22.1-33. In other words, "improvements" to the same Linux kernel.
I very much doubt it was the intention of whoever made these changes to alter the way in which WiFi works. It seems to me far more likely that he made a simple error, probably a typo of some kind.
3. There seems to me to be a delusion of grandeur on the part of Fedora users (and perhaps developers) that they are on the bleeding edge of technological progress.
In my experience, Fedora is very little different to Ubuntu or other distributions in this sense. And Fedora software does not seem to me any more or less likely to work than Redhat software.
Mikkel L. Ellertson wrote:
If a developer makes a change which prevents the software working with some hardware it previously worked with, I think the onus is on the developer to warn the user of this.
You would have a valid point if you were running RHEL or one of the clones like centos. By definition, some changes in Fedora are going to break things for some people.
As far as I can judge from my reading of newsgroups and mailing lists, CentOS is neither more nor less reliable than Fedora.
Very few software errors arise because some developer is trying something daring. 99% of problems occur simply because someone makes a silly blunder, and that is just as likely to happen anywhere.
I find this "Fedora is bleeding edge" excuse rather absurd.
Timothy Murphy wrote on Tuesday 31 July 2007:
If a developer makes a change which prevents the software working with some hardware it previously worked with, I think the onus is on the developer to warn the user of this.
How would they know that it doesn't work on hardware that they don't have?
If someone makes a change in the way software operates, he should consider (in my view) if there is any hardware on which this might not work. It is not actually necessary to have the hardware in order to work this out.
I don't know whether you are involved in software development of any kind but your statement suggests that you are not.
It is beyond any question that a developer SHOULD consider if there is any hardware which might be affected by a change. But we are not living in a perfect world. People make mistakes and the complexity of a software makes it impossible to consider every side effect of a change - at least not at justifiable costs. There are formal methods to prove software correct - but even those are only applicable under very precise conditions.
Even Donald E. Knuth said: "Beware of bugs in the above code; I have only proved it correct, not tried it."
Any test on software can only prove there are some bugs, but not that a software is bug-free under any circumstances.
- The actual question was about a change
between Fedora kernels 2.6.22.1-27 and 2.6.22.1-33. In other words, "improvements" to the same Linux kernel.
I would call it "changes". Not every change is a improvement - obviously. :) That the finest thing about Linux - if you do not like the changes, you can stick to the old kernel.
In my experience, Fedora is very little different to Ubuntu or other distributions in this sense. And Fedora software does not seem to me any more or less likely to work than Redhat software.
I cannot agree. We used RHEL and Fedora - RHEL (and CentOS) for the servers and Fedora for workstations. There are many differences, even if the administration is very simmilar. RHEL comes with older software which has been in use for longer time. And the kernels are rather old. RHEL had kernel 2.4 for a long time, Debian stable even kernel 2.2. At this time kernel 2.6 was already declared stable and had been integrated into Fedora. New kernels have better support for new hardware, but older are better tested. That is what is important for an admin.
Adalbert Prokop wrote:
In my experience, Fedora is very little different to Ubuntu or other distributions in this sense. And Fedora software does not seem to me any more or less likely to work than Redhat software.
I cannot agree. We used RHEL and Fedora - RHEL (and CentOS) for the servers and Fedora for workstations. There are many differences, even if the administration is very simmilar. RHEL comes with older software which has been in use for longer time. And the kernels are rather old. RHEL had kernel 2.4 for a long time, Debian stable even kernel 2.2. At this time kernel 2.6 was already declared stable and had been integrated into Fedora. New kernels have better support for new hardware, but older are better tested. That is what is important for an admin.
Please read what I said. I did not say that there were NO DIFFERENCES between Fedora and RHEL; I said that in my experience you are just as likely to have problems with one as with the other.
The idea that you are less likely to meet problems with linux-2.2 than with linux-2.6 is just nonsense, in my opinion. It's like saying that a 3-year old car is less likely to go wrong than a new car.
I find the use of the word "stable" absurd in this context. It is years since I came across any Linux kernel (or Windows OS, for that matter) that could be described as unstable, in the normal meaning of that term, which I take to mean "subject to failure in an unpredictable way".
Please note too that the discussion was not about some esoteric feature in a vanilla linux kernel - it was about the changes made in the spec files between 2.6.22.1-27 and 2.6.22.1-33, in other words, spec files for the same Linux kernel. I very much doubt if any deliberate change was made to the WiFi module. I imagine something was altered inadvertently, which hopefully will shortly be corrected.
On Wed, 2007-08-01 at 01:49 +0100, Timothy Murphy wrote:
I find the use of the word "stable" absurd in this context.
Stable meaning without significant changes, rather than meaning extremely reliable operation...
Tim wrote:
I find the use of the word "stable" absurd in this context.
Stable meaning without significant changes, rather than meaning extremely reliable operation...
I guess I give a rather mathematical meaning to the word "stable". A ball in a bowl is stable. A ball on top of my head is not.
An unstable kernel is one that fails in an unpredictable way, eg filling the screen with garbage.
If someone makes a change in the way software operates, he should consider (in my view) if there is any hardware on which this might not work. It is not actually necessary to have the hardware in order to work this out.
Thats complete nonsense.
You cannot, just through imagination alone expect to be able to work out, in all cases, if some change you make to some code has a *unexpected* side-effect on some specific hardware. The developers of course do their best but at the end of the day there is no alternative to just trying it out. Seeing as the developers don't all have access to *all hardware*, the best they can do is try it out on what they have, and if it passes that test, push it to testing. There it gets a bigger test and if thats OK, it ultimately makes it out to updates at which Fedora as a whole test it out. And yes, I do mean test. Thats the way things are .
Chris
As far as I can judge from my reading of newsgroups and mailing lists, CentOS is neither more nor less reliable than Fedora.
I run Fedora on my home system, but uses Scientific Linux (RHEL clone) at work, and can tell you for a *fact* Scientific Linux is much more stable than Fedora. It simply doesn't get major package updates. All that are pushed out are important security updates when needed.
Very few software errors arise because some developer is trying something daring. 99% of problems occur simply because someone makes a silly blunder, and that is just as likely to happen anywhere.
Of course. No one instroduces a bug on purpose. But then we are back to the point that unless you only discover bugs which are hardware dependent by running on that hardware. If the developers/testers don't have this hardware, then it falls to the users to find the bug.
I find this "Fedora is bleeding edge" excuse rather absurd.
Fedora is bleeding edge because it gets much more major package updates. For instance, during the lifetime of a Fedora release it is common to get major new versions of packages like KDE, gnome or the kernel. By major I mean things like KDE going from 3.4.6 to 3.5.7 pr the kernel going from 2.6.21 to 2.6.22.
A *stable* distro, like RHEL simply does not do this. You only updates when they are absolutely nessary for security for instance, and even then Rehdat go to the effort of back-porting the patches to the released version instead of updating to the new major.
This is where Fedora differs to some distros, and its this churning around that makes bugs more likely to creep in
Timothy Murphy:
I find the use of the word "stable" absurd in this context.
Tim:
Stable meaning without significant changes, rather than meaning extremely reliable operation...
Timothy Murphy:
I guess I give a rather mathematical meaning to the word "stable". A ball in a bowl is stable. A ball on top of my head is not.
An unstable kernel is one that fails in an unpredictable way, eg filling the screen with garbage.
The context was "Debian Stable" was it not? (Wasn't too clear, but it seemed that way.) Which I took to mean a Debian release that was *not* like a test release. One with a long life that didn't expect to change much over it, which makes it very easy of developers of other software to work with it.
If one was comparing, say CentOS to Fedora using the testing repos, to be extreme in the example, CentOS being stable, Fedora being not.
Chris Jones wrote:
If someone makes a change in the way software operates, he should consider (in my view) if there is any hardware on which this might not work. It is not actually necessary to have the hardware in order to work this out.
Thats complete nonsense.
You cannot, just through imagination alone expect to be able to work out, in all cases, if some change you make to some code has a *unexpected* side-effect on some specific hardware.
We're not talking about re-writing memory management in the kernel. We're talking about the difference between linux-2.6.22.1-27 and linux-2.6.22.1-33.
I'll bet the change that stops WiFi working on my ThinkPad T23 with the latter had nothing at all to do with hardware. and was simply an error in the SPEC file due to a typo or an oversight.
All this stuff about Fedora being bleeding edge is nonsense, IMHO. 99% of the problems with upgrades - and there are very few, in my experience - have absolutely nothing to do with subtle changes of the kind you are talking about. They are simply due to silly errors on the part of the developer, and don't need any extensive testing or indeed testing at all. Once the problem is drawn to the developer's attention it is immediately obvious what the cause was.
Nb I'm not criticizing developers. Making silly errors is part of the human condition. But let's not pretend it is brain surgery.
I'll bet the change that stops WiFi working on my ThinkPad T23 with the latter had nothing at all to do with hardware. and was simply an error in the SPEC file due to a typo or an oversight.
However the error was made, it still does not change the fact that if the error only effects the ThinkPad T23, which is perfectly possible, then unless ever the dev (him/her)self has a ThinkPad T23 available to test on or b), someone has one and also runs the testing repo (and cares about wireless), then unless it is spotted through sheer chance, its not going to get found before releasing to Fedora as a whole. To expect anything seems unreasonable to me.
No one is forcing you to use the new kernel, just boot back to the old one. Alternately, you could spend a little time trying to figure out whats wrong with the new one.
Chris
At 2:57 PM +0100 8/1/07, Chris Jones wrote:
As far as I can judge from my reading of newsgroups and mailing lists, CentOS is neither more nor less reliable than Fedora.
I run Fedora on my home system, but uses Scientific Linux (RHEL clone) at work, and can tell you for a *fact* Scientific Linux is much more stable than Fedora. It simply doesn't get major package updates. All that are pushed out are important security updates when needed.
...
I'm not disagreeing with you about Scientific Linux, which I haven't used, but CentOS 4 recently had a very large major upgrade from 4.4 to 4.5, which I, as a new CentOS user hoping for the non-upgrade kind of stability, found rather upsetting. I was told that CentOS just follows RedHat, which had just done that to RHEL 4. Is Scientific Linux different?
I'm not disagreeing with you about Scientific Linux, which I haven't used, but CentOS 4 recently had a very large major upgrade from 4.4 to 4.5, which I, as a new CentOS user hoping for the non-upgrade kind of stability, found rather upsetting. I was told that CentOS just follows RedHat, which had just done that to RHEL 4. Is Scientific Linux different?
Sure, Scientific Linux has various different majors versions that are currently SL3 and SL4 (SL5 on the way). These are based on EL3 and EL4 and very different beasts. You won't find yourself going from SL3 to SL4 via yum, unless you choose to try and do that.
For sure though SL also has sub-point releases, 3.x and 4.x (currently I am on a 4.5 release), which I think are the equivalents of what you talk about above. These updates I believe can occur through yum. However, I've not aware of any problems in this, its always been pretty flawless. I'm not the sys-admin though, but I never heard him complain (and I suspect I would have) or noticed any problems as a user.
maybe SL is better than centos in this regard ?
Chris
On Wed, 2007-08-01 at 17:17 +0100, Chris Jones wrote:
I'm not disagreeing with you about Scientific Linux, which I haven't used, but CentOS 4 recently had a very large major upgrade from 4.4 to 4.5, which I, as a new CentOS user hoping for the non-upgrade kind of stability, found rather upsetting. I was told that CentOS just follows RedHat, which had just done that to RHEL 4. Is Scientific Linux different?
Sure, Scientific Linux has various different majors versions that are currently SL3 and SL4 (SL5 on the way). These are based on EL3 and EL4 and very different beasts. You won't find yourself going from SL3 to SL4 via yum, unless you choose to try and do that.
For sure though SL also has sub-point releases, 3.x and 4.x (currently I am on a 4.5 release), which I think are the equivalents of what you talk about above. These updates I believe can occur through yum. However, I've not aware of any problems in this, its always been pretty flawless. I'm not the sys-admin though, but I never heard him complain (and I suspect I would have) or noticed any problems as a user.
maybe SL is better than centos in this regard ?
I don't know, but I doubt it. Both distros are intended to track RHEL pretty much exactly. The upgrade to a new point release usually involves just installing a rather large number of bugfix updates to existing packages.
I recall some discussion from Red Hat of possibly retaining old point releases and issuing only security updates for them so that users wouldn't have to do the point release thing if they didn't want to. That is, one could maintain a RHEL 4.2 system and still get security updates even though RHEL 4.5 is current. I don't know where that stands at this point, though.
Chris
Matthew Saltzman wrote:
On Wed, 2007-08-01 at 17:17 +0100, Chris Jones wrote:
I'm not disagreeing with you about Scientific Linux, which I haven't used, but CentOS 4 recently had a very large major upgrade from 4.4 to 4.5, which I, as a new CentOS user hoping for the non-upgrade kind of stability, found rather upsetting. I was told that CentOS just follows RedHat, which had just done that to RHEL 4. Is Scientific Linux different?
Sure, Scientific Linux has various different majors versions that are currently SL3 and SL4 (SL5 on the way). These are based on EL3 and EL4 and very different beasts. You won't find yourself going from SL3 to SL4 via yum, unless you choose to try and do that.
For sure though SL also has sub-point releases, 3.x and 4.x (currently I am on a 4.5 release), which I think are the equivalents of what you talk about above. These updates I believe can occur through yum. However, I've not aware of any problems in this, its always been pretty flawless. I'm not the sys-admin though, but I never heard him complain (and I suspect I would have) or noticed any problems as a user.
maybe SL is better than centos in this regard ?
I don't know, but I doubt it. Both distros are intended to track RHEL pretty much exactly. The upgrade to a new point release usually involves just installing a rather large number of bugfix updates to existing packages.
I recall some discussion from Red Hat of possibly retaining old point releases and issuing only security updates for them so that users wouldn't have to do the point release thing if they didn't want to. That is, one could maintain a RHEL 4.2 system and still get security updates even though RHEL 4.5 is current. I don't know where that stands at this point, though.
Chris
Well stupid me, I forgot I saved the working kernel rpm. I found the rpm and with rpm -i --force I got it installed. It didn't want to install because of the buggy new ones...
So happy again. My USB memory sticks and all are working and so is skype.
Chris Jones wrote:
I'll bet the change that stops WiFi working on my ThinkPad T23 with the latter had nothing at all to do with hardware. and was simply an error in the SPEC file due to a typo or an oversight.
However the error was made, it still does not change the fact that if the error only effects the ThinkPad T23, which is perfectly possible,
It may be "possible", but it is not true, as you would see if you read the postings about kernel-2.6.22.1-33 .
then unless ever the dev (him/her)self has a ThinkPad T23 available to test on or b), someone has one and also runs the testing repo (and cares about wireless), then unless it is spotted through sheer chance, its not going to get found before releasing to Fedora as a whole. To expect anything seems unreasonable to me.
I can't actually think of any way a package could work with a PCMCIA card on all machines except the T23.
In this case, the new kernel 2.6.22.1-41 works perfectly for me. So I'm convinced there was a simple error in the SPEC file.
I don't think the Fedora kernel developers ever try to "improve" something like a WiFi module, anyway.
No one is forcing you to use the new kernel, just boot back to the old one.
I didn't say anyone was forcing me to use the new kernel - I simply stated as a fact that it did not work with my WiFi device. (Many other people said the same thing. I doubt if any of them was using a T23.)
Yes, I learned quite a long time ago that if one kernel does not work you should try another one.
Timothy Murphy wrote:
I don't think the Fedora kernel developers ever try to "improve" something like a WiFi module, anyway.
There has been a hell lot of misinformation in this thread but this one takes it to a whole new level. Fedora/Red Hat developer John Linville (http://people.redhat.com/linville/) is the upstream wireless subsystem maintainer for the Linux kernel.
If you really want to know what changed in between these kernels, take a look at the changelog or the cvs. Hint: it's not a typo.
Rahul
on 8/1/2007 4:17 PM, Timothy Murphy wrote:
Chris Jones wrote:
However the error was made, it still does not change the fact that if the error only effects the ThinkPad T23, which is perfectly possible,
It may be "possible", but it is not true, as you would see if you read the postings about kernel-2.6.22.1-33 .
then unless ever the dev (him/her)self has a ThinkPad T23 available to test on or b), someone has one and also runs the testing repo (and cares about wireless), then unless it is spotted through sheer chance, its not going to get found before releasing to Fedora as a whole. To expect anything seems unreasonable to me.
I can't actually think of any way a package could work with a PCMCIA card on all machines except the T23.
In this case, the new kernel 2.6.22.1-41 works perfectly for me. So I'm convinced there was a simple error in the SPEC file.
I don't think the Fedora kernel developers ever try to "improve" something like a WiFi module, anyway.
No one is forcing you to use the new kernel, just boot back to the old one.
I didn't say anyone was forcing me to use the new kernel - I simply stated as a fact that it did not work with my WiFi device. (Many other people said the same thing. I doubt if any of them was using a T23.)
Yes, I learned quite a long time ago that if one kernel does not work you should try another one.
If you think that this is a bug, and from what you write you do, a Bugzilla report will do more to solve this problem than posting to this Fedora list ever will. The developers follow Bugzilla. most do not have the time to follow 'help me' lists.
If there already is a report you should add a comment with your experiences/hardware.
Rahul Sundaram wrote:
I don't think the Fedora kernel developers ever try to "improve" something like a WiFi module, anyway.
There has been a hell lot of misinformation in this thread but this one takes it to a whole new level. Fedora/Red Hat developer John Linville (http://people.redhat.com/linville/) is the upstream wireless subsystem maintainer for the Linux kernel.
Sorry, but if they do actually try to improve on Linus' team in this area I wish they wouldn't.
I admit I am not a great fan of Fedora kernels - I normally compile my own from the vanilla kernels (I haven't got round to 2.6.22 yet) and I have never found a distribution kernel from Fedora or anyone else which worked any better for me than the standard kernel. (I've found many that worked worse.)
I regard the kernel and the distribution as more or less orthogonal. If I actually had to run a non-standard kernel in order to run Fedora I would probably move to another distribution. Not a common point of view, I'm sure, but mine.
If you really want to know what changed in between these kernels, take a look at the changelog or the cvs. Hint: it's not a typo.
I'm not sure where one finds either of these - presumably with the kernel source? (I looked at the developer's URL you gave, but didn't find anything there.)
I did think of downloading the two kernel sources, and comparing the SPEC files, but decided life was too short.
on 8/1/2007 4:28 PM, Rahul Sundaram wrote:
Timothy Murphy wrote:
I don't think the Fedora kernel developers ever try to "improve" something like a WiFi module, anyway.
There has been a hell lot of misinformation in this thread but this one takes it to a whole new level. Fedora/Red Hat developer John Linville (http://people.redhat.com/linville/) is the upstream wireless subsystem maintainer for the Linux kernel.
If you really want to know what changed in between these kernels, take a look at the changelog or the cvs. Hint: it's not a typo.
Rahul
In *this* thread? Only in *this* thread?
There has been a *lot* of misinformation in many, many other threads here lately.
Timothy Murphy wrote:
Rahul Sundaram wrote:
I don't think the Fedora kernel developers ever try to "improve" something like a WiFi module, anyway.
There has been a hell lot of misinformation in this thread but this one takes it to a whole new level. Fedora/Red Hat developer John Linville (http://people.redhat.com/linville/) is the upstream wireless subsystem maintainer for the Linux kernel.
Sorry, but if they do actually try to improve on Linus' team in this area I wish they wouldn't.
Being the upstream wireless subsystem maintainer means that John Linville is part of what you call "Linus team" (ie) all the wireless patches go through the sub system maintainer.
You should not extrapolate your personal experiences and declare that any specific patches not upstream yet doesn't improve something. The additional work is being done for a reason. Upstream kernel developers have left the distributions to stabilize on the code they provide in the 2.6 branch because of the large number of changes being committed. So shipping the vanilla kernel as it is not even recommended by many of them. Regardless of that it is likely that there will be a vanilla kernel as part of the Fedora repository for testing and feedback. See fedora-kernel list for details.
I'm not sure where one finds either of these - presumably with the kernel source? (I looked at the developer's URL you gave, but didn't find anything there.)
rpm -q --changelog <packagename> http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/F-7/
Next time people, if you want to know something about development of Fedora ask, instead of assuming. I have even starting a whole new column in Fedora weekly news in part to avoid the ridiculous of misinformation being circulated.
Rahul
At 5:17 PM +0100 8/1/07, Chris Jones wrote: ...
For sure though SL also has sub-point releases, 3.x and 4.x (currently I am on a 4.5 release), which I think are the equivalents of what you talk about above. These updates I believe can occur through yum. However, I've not aware of any problems in this, its always been pretty flawless. I'm not the sys-admin though, but I never heard him complain (and I suspect I would have) or noticed any problems as a user.
maybe SL is better than centos in this regard ?
It sounds more like the Sysadmin just sucked it up when that monstrous update to 4.5 came out.
On Thu, 2007-08-02 at 00:50 +0100, Timothy Murphy wrote:
Rahul Sundaram wrote:
I don't think the Fedora kernel developers ever try to "improve" something like a WiFi module, anyway.
There has been a hell lot of misinformation in this thread but this one takes it to a whole new level. Fedora/Red Hat developer John Linville (http://people.redhat.com/linville/) is the upstream wireless subsystem maintainer for the Linux kernel.
Sorry, but if they do actually try to improve on Linus' team in this area I wish they wouldn't.
I admit I am not a great fan of Fedora kernels - I normally compile my own from the vanilla kernels (I haven't got round to 2.6.22 yet) and I have never found a distribution kernel from Fedora or anyone else which worked any better for me than the standard kernel. (I've found many that worked worse.)
I regard the kernel and the distribution as more or less orthogonal. If I actually had to run a non-standard kernel in order to run Fedora I would probably move to another distribution. Not a common point of view, I'm sure, but mine.
If you really want to know what changed in between these kernels, take a look at the changelog or the cvs. Hint: it's not a typo.
I'm not sure where one finds either of these - presumably with the kernel source? (I looked at the developer's URL you gave, but didn't find anything there.)
I did think of downloading the two kernel sources, and comparing the SPEC files, but decided life was too short.
I am sorry if someone (Tim maybe) is offended but the above contains the most amazing statements. To say they kernel is orthogonal to the distribution must be close to the most amazing statement ever made on this list. The kernel is central and is the most important part of the distribution. I used to compile kernels,and boy that was a waste of time unless you really know what you are doing.
To engage in kernel compiling and not know where to find the changelog of the kernels is even more strange.
I hope no one else decides it is useful to tinker with the Fedora kernels because, I guess, they think the people who create Fedora kernels really don't know what they are doing.
This is my rant for the week. -- ======================================================================= If there were a school for, say, sheet metal workers, that after three years left its graduates as unprepared for their careers as does law school, it would be closed down in a minute, and no doubt by lawyers. -- Michael Levin, "The Socratic Method ======================================================================= Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net
Tony Nelson wrote:
At 5:17 PM +0100 8/1/07, Chris Jones wrote: ...
For sure though SL also has sub-point releases, 3.x and 4.x (currently I am on a 4.5 release), which I think are the equivalents of what you talk about above. These updates I believe can occur through yum. However, I've not aware of any problems in this, its always been pretty flawless. I'm not the sys-admin though, but I never heard him complain (and I suspect I would have) or noticed any problems as a user.
maybe SL is better than centos in this regard ?
It sounds more like the Sysadmin just sucked it up when that monstrous update to 4.5 came out.
Out of interest what went wrong for you with this update ?
Chatting to the guy here he didn't recall the 4.5 update being any more or less problematic than any other. It went smoothly.
Chris
Aaron Konstam wrote:
I admit I am not a great fan of Fedora kernels - I normally compile my own from the vanilla kernels (I haven't got round to 2.6.22 yet) and I have never found a distribution kernel from Fedora or anyone else which worked any better for me than the standard kernel. (I've found many that worked worse.)
I regard the kernel and the distribution as more or less orthogonal. If I actually had to run a non-standard kernel in order to run Fedora I would probably move to another distribution. Not a common point of view, I'm sure, but mine.
If you really want to know what changed in between these kernels, take a look at the changelog or the cvs. Hint: it's not a typo.
I'm not sure where one finds either of these - presumably with the kernel source? (I looked at the developer's URL you gave, but didn't find anything there.)
I did think of downloading the two kernel sources, and comparing the SPEC files, but decided life was too short.
I am sorry if someone (Tim maybe) is offended but the above contains the most amazing statements. To say they kernel is orthogonal to the distribution must be close to the most amazing statement ever made on this list. The kernel is central and is the most important part of the distribution. I used to compile kernels,and boy that was a waste of time unless you really know what you are doing.
I suggest you take a moment to consider what I actually said.
As far as I am concerned, any Linux distribution consists of a large number of applications using the Linux kernel. These applications should - and in fact always do - work with any current kernel. I don't know of any Fedora application that only works with a Fedora kernel, or in fact that works better with a Fedora kernel than with the corresponding vanilla kernel (2.6.22.1 against 2.6.22.1-41). Do you?
As I said, if Fedora started shipping applications which only worked with a modified kernel, I would stop using Fedora. I'd also doubt if it should be called "Linux". In my view, a "Linux distribution" is a collection of applications which work with a Linux kernel.
To engage in kernel compiling and not know where to find the changelog of the kernels is even more strange.
Sigh. I know where the changelog for a vanilla kernel is found - with the kernel source. I was asking where one found the changelog describing the difference between the distribution kernel, say 2.6.22.1-41 and the corresponding vanilla kernel, 2.6.22.1, without downloading the distribution kernel source.
This was explained to me by Rahul. (As a matter of interest, did you know where to find this?) Though actually, I found that changelog more or less useless, as it seemed to mix up changes to the vanilla kernel with changes to the distribution kernel.
Since you claim to be such an expert, did you look at it? If so, you'll be able to tell me at once what mistake was made in the 2.6.22.1-33 kernel.
I guessed that it was probably a typo, but Rahul said it was not. 3 or 4 short pieces of code were added in 2.6.22.1-33, and then removed in 2.6.22.1-41, but I couldn't work out which caused the error. Maybe the Fedora kernel developers couldn't work that out either, and just removed whatever they had added?
I hope no one else decides it is useful to tinker with the Fedora kernels because, I guess, they think the people who create Fedora kernels really don't know what they are doing.
They are compiling a kernel which will work on any machine in the world. If you look at it you will see it comes with hundreds of modules, the vast majority of them completely irrelevant to any individual user.
I am compiling a kernel which will work on my machine. I am not "tinkering" with a Fedora kernel. I am compiling the standard Linux kernel.
Have you ever actually compiled a kernel? Have you ever looked at the SPEC file for a distribution kernel? I've never found any case where a distribution kernel worked any better than the corresponding vanilla kernel, and many cases where it worked worse. Unless you have compiled a vanilla kernel, I don't see how you can offer an opinion on the difference.
The reason for this is simple. A distribution kernel has to work on thousands of different machines, and so in many cases has to choose the lowest common denominator. For example, when you compile a kernel you have to specify the CPU type, and there are a couple of dozen choices. The distribution kernel developer has to choose the most generic type. So either Linus Torvalds' team has put in a lot of useless options, or something is lost in using the distribution kernel.
Incidentally, compiling a kernel is not brain surgery, as you seem to believe. You just get the source from www.kernel.org, choose your options and say "make". Then "make modules_install" and "make install".
Admittedly, choosing the options takes some time if you start from scratch; but I always save the options I've used before, and there are usually only a couple of changes needed to the previous set.
I am going to top post just this once because I am too tired to deal with all the accusations in this note. But: 1. I knew Tim would object to what I said. 2. Orthogonal means that two things doe not affect each other. So it would mean that any kernel would work with and programs in the distribution. That is not true. 3. Yes I have compiled kernels. I said that.
It is all irrelevant. Unless you know what you are doing and can make some significant improvement in the operation of the system by compiling the kernel. Doing it can get you in trouble for little benefit. Currently the kernels are distributed compiled for several cpu versions so that is not something that needs to be done by the user.
But anyone who wants to compile their own kernel id welcome to do it. .On Fri, 2007-08-03 at 13:10 +0100, Timothy Murphy wrote:
Aaron Konstam wrote:
I admit I am not a great fan of Fedora kernels - I normally compile my own from the vanilla kernels (I haven't got round to 2.6.22 yet) and I have never found a distribution kernel from Fedora or anyone else which worked any better for me than the standard kernel. (I've found many that worked worse.)
I regard the kernel and the distribution as more or less orthogonal. If I actually had to run a non-standard kernel in order to run Fedora I would probably move to another distribution. Not a common point of view, I'm sure, but mine.
If you really want to know what changed in between these kernels, take a look at the changelog or the cvs. Hint: it's not a typo.
I'm not sure where one finds either of these - presumably with the kernel source? (I looked at the developer's URL you gave, but didn't find anything there.)
I did think of downloading the two kernel sources, and comparing the SPEC files, but decided life was too short.
I am sorry if someone (Tim maybe) is offended but the above contains the most amazing statements. To say they kernel is orthogonal to the distribution must be close to the most amazing statement ever made on this list. The kernel is central and is the most important part of the distribution. I used to compile kernels,and boy that was a waste of time unless you really know what you are doing.
I suggest you take a moment to consider what I actually said.
As far as I am concerned, any Linux distribution consists of a large number of applications using the Linux kernel. These applications should - and in fact always do - work with any current kernel. I don't know of any Fedora application that only works with a Fedora kernel, or in fact that works better with a Fedora kernel than with the corresponding vanilla kernel (2.6.22.1 against 2.6.22.1-41). Do you?
As I said, if Fedora started shipping applications which only worked with a modified kernel, I would stop using Fedora. I'd also doubt if it should be called "Linux". In my view, a "Linux distribution" is a collection of applications which work with a Linux kernel.
To engage in kernel compiling and not know where to find the changelog of the kernels is even more strange.
Sigh. I know where the changelog for a vanilla kernel is found - with the kernel source. I was asking where one found the changelog describing the difference between the distribution kernel, say 2.6.22.1-41 and the corresponding vanilla kernel, 2.6.22.1, without downloading the distribution kernel source.
This was explained to me by Rahul. (As a matter of interest, did you know where to find this?) Though actually, I found that changelog more or less useless, as it seemed to mix up changes to the vanilla kernel with changes to the distribution kernel.
Since you claim to be such an expert, did you look at it? If so, you'll be able to tell me at once what mistake was made in the 2.6.22.1-33 kernel.
I guessed that it was probably a typo, but Rahul said it was not. 3 or 4 short pieces of code were added in 2.6.22.1-33, and then removed in 2.6.22.1-41, but I couldn't work out which caused the error. Maybe the Fedora kernel developers couldn't work that out either, and just removed whatever they had added?
I hope no one else decides it is useful to tinker with the Fedora kernels because, I guess, they think the people who create Fedora kernels really don't know what they are doing.
They are compiling a kernel which will work on any machine in the world. If you look at it you will see it comes with hundreds of modules, the vast majority of them completely irrelevant to any individual user.
I am compiling a kernel which will work on my machine. I am not "tinkering" with a Fedora kernel. I am compiling the standard Linux kernel.
Have you ever actually compiled a kernel? Have you ever looked at the SPEC file for a distribution kernel? I've never found any case where a distribution kernel worked any better than the corresponding vanilla kernel, and many cases where it worked worse. Unless you have compiled a vanilla kernel, I don't see how you can offer an opinion on the difference.
The reason for this is simple. A distribution kernel has to work on thousands of different machines, and so in many cases has to choose the lowest common denominator. For example, when you compile a kernel you have to specify the CPU type, and there are a couple of dozen choices. The distribution kernel developer has to choose the most generic type. So either Linus Torvalds' team has put in a lot of useless options, or something is lost in using the distribution kernel.
Incidentally, compiling a kernel is not brain surgery, as you seem to believe. You just get the source from www.kernel.org, choose your options and say "make". Then "make modules_install" and "make install".
Admittedly, choosing the options takes some time if you start from scratch; but I always save the options I've used before, and there are usually only a couple of changes needed to the previous set.
-- Timothy Murphy e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
-- ======================================================================= As the trials of life continue to take their toll, remember that there is always a future in Computer Maintenance. -- National Lampoon, "Deteriorata" ======================================================================= Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net
Aaron Konstam wrote:
I am going to top post just this once because I am too tired to deal with all the accusations in this note.
That is no excuse for top-posting. Also I didn't make any "accusations".
But:
- I knew Tim would object to what I said.
Because it was wrong.
- Orthogonal means that two things doe not affect each other. So it
would mean that any kernel would work with and programs in the distribution. That is not true.
I don't know of any Fedora application that works with Fedora kernel 2.6.x.y-n that does not work equally well with vanilla kernel 2.6.x.y . That is what I mean by orthogonal.
I asked you for an example of this. You didn't given one, so I assume you cannot find one.
- Yes I have compiled kernels. I said that.
You implied that it was very difficult, which made me wonder. It used to be much more difficult than it is today, because Torvalds and team have cleaned things up and organized them better. In my view the Fedora developers could learn a lesson from this. Fedora is becoming much too spaghetti-like.
It is all irrelevant. Unless you know what you are doing and can make some significant improvement in the operation of the system by compiling the kernel.
For me, the boot is on the other foot. I do not try to improve Linus Torvalds' kernel. That is what the Fedora people do.
Doing it can get you in trouble for little benefit.
How does running a standard kernel "get you in trouble"? You're talking nonsense.
Currently the kernels are distributed compiled for several cpu versions so that is not something that needs to be done by the user.
Not true. None of the distribution kernels I have seen use CPU choices that accurately match any of the machines I have.
What machine do you have? What CPU choice does the distribution kernel make? Does it accurately reflect your CPU?
But anyone who wants to compile their own kernel id welcome to do it.
Exactly. That is precisely what I said, if you look back: "I know it is not the general view, but _I_ prefer to compile my own kernel." [That is a paraphrase of what I said.]
I don't mind what you do, and don't believe in giving advice where it is not asked for.
Timothy Murphy wrote:
I don't know of any Fedora application that works with Fedora kernel 2.6.x.y-n that does not work equally well with vanilla kernel 2.6.x.y . That is what I mean by orthogonal.
There have been some examples in the past seen in bugzilla. These are treated as bugs and fixed.
It used to be much more difficult than it is today, because Torvalds and team have cleaned things up and organized them better. In my view the Fedora developers could learn a lesson from this. Fedora is becoming much too spaghetti-like.
That's amusing since "Torvalds and team" includes Fedora developers. Red Hat is the largest commercial contributor to the Linux kernel. Do you have bug reports on what you consider "sphagetti-like".
Rahul
On Fri, 2007-08-03 at 16:15 +0100, Timothy Murphy wrote:
I don't know of any Fedora application that works with Fedora kernel 2.6.x.y-n that does not work equally well with vanilla kernel 2.6.x.y . That is what I mean by orthogonal.
We just had a case where the installed version of udev did not work with one of the kernel versions on some machines.
I asked you for an example of this. You didn't given one, so I assume you cannot find one.
Currently the kernels are distributed compiled for several cpu
versions
so that is not something that needs to be done by the user.
Not true. None of the distribution kernels I have seen use CPU choices that accurately match any of the machines I have.
What do you make of the fact that the 2.6.22.1-33.fc7 kernel came in two rpms. One called 2.6.22.1-33.fc7.i586 and the other called
2.6.22.1-33.fc7.i686?
-- ======================================================================= There's so much to say but your eyes keep interrupting me. ======================================================================= Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net
on 8/3/2007 1:46 PM, Aaron Konstam wrote:
On Fri, 2007-08-03 at 16:15 +0100, Timothy Murphy wrote:
I don't know of any Fedora application that works with Fedora kernel 2.6.x.y-n that does not work equally well with vanilla kernel 2.6.x.y . That is what I mean by orthogonal.
We just had a case where the installed version of udev did not work with one of the kernel versions on some machines.
I asked you for an example of this. You didn't given one, so I assume you cannot find one.
Currently the kernels are distributed compiled for several cpu
versions
so that is not something that needs to be done by the user.
Not true. None of the distribution kernels I have seen use CPU choices that accurately match any of the machines I have.
What do you make of the fact that the 2.6.22.1-33.fc7 kernel came in two rpms. One called 2.6.22.1-33.fc7.i586 and the other called
2.6.22.1-33.fc7.i686?
He is referring to the kernels in Fedora 8. There are only i686 kernels.
David Boles wrote:
He is referring to the kernels in Fedora 8. There are only i686 kernels.
I believe that kernel does work on i586 and it is called i686 to prevent a update path conflict with RPM. There was some discussions in fedora-devel list about this. Dave Jones (CC'ed) should be able to confirm.
Rahul
on 8/3/2007 2:39 PM, Rahul Sundaram wrote:
David Boles wrote:
He is referring to the kernels in Fedora 8. There are only i686 kernels.
I believe that kernel does work on i586 and it is called i686 to prevent a update path conflict with RPM. There was some discussions in fedora-devel list about this. Dave Jones (CC'ed) should be able to confirm.
I believe that you are correct and that I did not say that correctly. It has been discussed and evidently done that a kernel named i686 would support i586, i686, SMP. All. There are only kernels with i686 in the package name. The kernel-headers have remained named i386.
Aaron Konstam wrote:
I don't know of any Fedora application that works with Fedora kernel 2.6.x.y-n that does not work equally well with vanilla kernel 2.6.x.y . That is what I mean by orthogonal.
We just had a case where the installed version of udev did not work with one of the kernel versions on some machines.
Please note what I asked for: a case where udev worked with 2.6.x.y-n but not with 2.6.x.y .
I've run Fedora with compiled versions of 2.6.m (up to 2.6.22 which I'm running now) and had no problem with udev.
Of course you need an appropriate .config file. I've no doubt it is possible to choose options which confuse udev.
I asked you for an example of this. You didn't given one, so I assume you cannot find one.
Currently the kernels are distributed compiled for several cpu
versions
so that is not something that needs to be done by the user.
Not true. None of the distribution kernels I have seen use CPU choices that accurately match any of the machines I have.
What do you make of the fact that the 2.6.22.1-33.fc7 kernel came in two rpms. One called 2.6.22.1-33.fc7.i586 and the other called
Why don't you do what I suggest, and look at the .config files for these kernels?
I just looked at kernel.i686 2.6.22.1-41.fc7 and the CPU choice was "Generic architecture". There are many other places where "generic" choices are (necessarily) made. If in fact this is just as good as making the choice reflecting one's actual hardware, it is difficult to see why one should be given a choice.
This kernel, incidentally, is almost twice as large as my compiled kernel, while the /lib/modules/ directory is 8 times as large.
Rahul Sundaram wrote:
I don't know of any Fedora application that works with Fedora kernel 2.6.x.y-n that does not work equally well with vanilla kernel 2.6.x.y . That is what I mean by orthogonal.
There have been some examples in the past seen in bugzilla. These are treated as bugs and fixed.
If an application does not work with a current vanilla kernel, then in my view there is a bug in the application, not the kernel.
It used to be much more difficult than it is today, because Torvalds and team have cleaned things up and organized them better. In my view the Fedora developers could learn a lesson from this. Fedora is becoming much too spaghetti-like.
That's amusing since "Torvalds and team" includes Fedora developers. Red Hat is the largest commercial contributor to the Linux kernel.
That does not contradict what I said in any way. It is the organization of Fedora that I am talking about, not individual applications. I repeat: in my view Fedora is becoming too complex, and would benefit greatly from simplification and organization.
Do you have bug reports on what you consider "sphagetti-like".
A "spaghetti-like development" is not a bug. Examples of what I mean would be most audio and video aspects of Fedora-7. Also things like conflicting config generators, as eg system-config-printer contrasted with the web interface to CUPS.
Nb This is not a serious criticism of Fedora, simply a response to those who were arguing that I was wrong in preferring to keep distribution and kernel orthogonal.
Timothy Murphy wrote:
Nb This is not a serious criticism of Fedora, simply a response to those who were arguing that I was wrong in preferring to keep distribution and kernel orthogonal.
And I'd like to see that taken to an extreme, where I'd be able to run a CentOSplus kernel (or your own branded equivalent should you ever choose to provide a stable alternative) yet have current fedora userland apps.
Timothy Murphy wrote:
Rahul Sundaram wrote:
I don't know of any Fedora application that works with Fedora kernel 2.6.x.y-n that does not work equally well with vanilla kernel 2.6.x.y . That is what I mean by orthogonal.
There have been some examples in the past seen in bugzilla. These are treated as bugs and fixed.
If an application does not work with a current vanilla kernel, then in my view there is a bug in the application, not the kernel.
Yep. It is still a bug that needs to be fixed.
That does not contradict what I said in any way. It is the organization of Fedora that I am talking about, not individual applications. I repeat: in my view Fedora is becoming too complex, and would benefit greatly from simplification and organization.
You got to be a lot more specific than that.
A "spaghetti-like development" is not a bug. Examples of what I mean would be most audio and video aspects of Fedora-7. Also things like conflicting config generators, as eg system-config-printer contrasted with the web interface to CUPS.
http://www.redhat.com/magazine/022aug06/features/fc6_print/
Nb This is not a serious criticism of Fedora, simply a response to those who were arguing that I was wrong in preferring to keep distribution and kernel orthogonal.
That is your choice assuming you are aware of the plus and minuses of doing that.
Rahul
-
Aaron Konstam -
Adalbert Prokop -
Antonio M -
Bob Goodwin -
Chris Jones -
David -
Karl Larsen -
Les Mikesell -
Matthew Saltzman -
Mikkel -
Rahul Sundaram -
Steve Searle -
Tim -
Timothy Murphy -
Tony Nelson