So, today's rawhide should contain fixes for *nearly* all the bugs on the blocker list (http://rdr.to/YH). Emacs should even be working again! Such fun!
If you've got a bug on the blocker list, or if you have a system using software RAID or dmraid (aka BIOS-raid aka fakeraid) *please* try an install/upgrade from rawhide today. Upgrades on FC6 systems using software RAID on IDE drives are especially important.
Furthermore, if you've got iwlwifi (Intel 3945 wireless) hardware, please update your system and let us know how it works.
For more info on installing rawhide, see: http://fedoraproject.org/wiki/Releases/Rawhide and http://fedoraproject.org/wiki/Testing
Thanks!
-w
Intel ICH7 sound still doesn't work for me. But thats not on the list!
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240081
On 5/23/07, Will Woods wwoods@redhat.com wrote:
So, today's rawhide should contain fixes for *nearly* all the bugs on the blocker list (http://rdr.to/YH). Emacs should even be working again! Such fun!
If you've got a bug on the blocker list, or if you have a system using software RAID or dmraid (aka BIOS-raid aka fakeraid) *please* try an install/upgrade from rawhide today. Upgrades on FC6 systems using software RAID on IDE drives are especially important.
Furthermore, if you've got iwlwifi (Intel 3945 wireless) hardware, please update your system and let us know how it works.
For more info on installing rawhide, see: http://fedoraproject.org/wiki/Releases/Rawhide and http://fedoraproject.org/wiki/Testing
Thanks!
-w
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
Will Woods wrote:
If you've got a bug on the blocker list, or if you have a system using software RAID or dmraid (aka BIOS-raid aka fakeraid) *please* try an install/upgrade from rawhide today. Upgrades on FC6 systems using software RAID on IDE drives are especially important.
Software RAID on IDE still has problems. See my comments at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151653
On Wed, 2007-05-23 at 11:43 -0400, Will Woods wrote:
So, today's rawhide should contain fixes for *nearly* all the bugs on the blocker list (http://rdr.to/YH). Emacs should even be working again! Such fun!
If you've got a bug on the blocker list, or if you have a system using software RAID or dmraid (aka BIOS-raid aka fakeraid) *please* try an install/upgrade from rawhide today. Upgrades on FC6 systems using software RAID on IDE drives are especially important.
Furthermore, if you've got iwlwifi (Intel 3945 wireless) hardware, please update your system and let us know how it works.
For more info on installing rawhide, see: http://fedoraproject.org/wiki/Releases/Rawhide and http://fedoraproject.org/wiki/Testing
Just updated my F7 partition to the latest and greatest. As far as I can tell 3945 WiFi works well. It seems to authenticate faster than before where it would sit at stage 2 for a while before going through 3,4 and 5 (if at all). Strength was a bit low (72-75%) give a distance of max 3 feet from the AP. Suspend did not work. It hung at "shutting down consoles" or something like that (black screen, top left, 2nd message). Before trying suspend I did see this warning in /var/log/messages:
May 23 19:26:26 localhost kernel: BUG: warning at kernel/softirq.c:138/local_bh_enable() (Not tainted) May 23 19:26:26 localhost kernel: [<c042b2ef>] local_bh_enable+0x45/0x92 May 23 19:26:26 localhost kernel: [<c06036b7>] cond_resched_softirq+0x2c/0x42 May 23 19:26:26 localhost kernel: [<c059d5d0>] release_sock+0x54/0xa3 May 23 19:26:26 localhost kernel: [<c04373af>] prepare_to_wait+0x24/0x3f May 23 19:26:26 localhost kernel: [<c05e267f>] inet_stream_connect+0x116/0x1ff May 23 19:26:26 localhost kernel: [<c0437265>] autoremove_wake_function+0x0/0x35 May 23 19:26:26 localhost kernel: [<c059c339>] sys_connect+0x82/0xad May 23 19:26:26 localhost kernel: [<c059d58f>] release_sock+0x13/0xa3 May 23 19:26:26 localhost kernel: [<c0604ad5>] _spin_unlock_bh+0x5/0xd May 23 19:26:26 localhost kernel: [<c059e714>] sock_setsockopt+0x4a8/0x4b2 May 23 19:26:26 localhost kernel: [<c059b6b6>] sock_attach_fd+0x70/0xd2 May 23 19:26:26 localhost kernel: [<c04774a0>] get_empty_filp+0xfc/0x170 May 23 19:26:26 localhost kernel: [<c059b54f>] sys_setsockopt+0x9b/0xa7 May 23 19:26:26 localhost kernel: [<c059cb83>] sys_socketcall+0xac/0x261 May 23 19:26:26 localhost kernel: [<c0404f70>] syscall_call+0x7/0xb May 23 19:26:26 localhost kernel: =======================
Linux localhost.localdomain 2.6.21-1.3189.fc7 #1 SMP Tue May 22 17:14:22 EDT 2007 i686 i686 i386 GNU/Linux This is an Acer TM6465, x86_64 with an i386 install.
Hope this helps.
Regards, Patrick
Will Woods wrote:
So, today's rawhide should contain fixes for *nearly* all the bugs on the blocker list (http://rdr.to/YH). Emacs should even be working again! Such fun!
If you've got a bug on the blocker list, or if you have a system using software RAID or dmraid (aka BIOS-raid aka fakeraid) *please* try an install/upgrade from rawhide today. Upgrades on FC6 systems using software RAID on IDE drives are especially important.
Furthermore, if you've got iwlwifi (Intel 3945 wireless) hardware, please update your system and let us know how it works.
For more info on installing rawhide, see: http://fedoraproject.org/wiki/Releases/Rawhide and http://fedoraproject.org/wiki/Testing
Thanks!
-w
With the 3189 kernel I'm still getting the error (less verbose version) that is causing this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235902
Richard
Will Woods wrote:
So, today's rawhide should contain fixes for *nearly* all the bugs on the blocker list (http://rdr.to/YH). Emacs should even be working again! Such fun!
If you've got a bug on the blocker list, or if you have a system using software RAID or dmraid (aka BIOS-raid aka fakeraid) *please* try an install/upgrade from rawhide today. Upgrades on FC6 systems using software RAID on IDE drives are especially important.
<snip>
Pre-exisiting software raid STILL a problem.
Anaconda fails trying to detect existing installations, some of which are on software raid and some on LVs. Added comments to: BZ# 237456 and the anaconda dump file. This is actually a regression over test 4.
BZ# 237456 should be a blocker. If it is a dup of another BZ, please let me know.
On Wed, 2007-05-23 at 23:55 -0400, Clyde E. Kunkel wrote:
Pre-exisiting software raid STILL a problem.
Anaconda fails trying to detect existing installations, some of which are on software raid and some on LVs. Added comments to: BZ# 237456 and the anaconda dump file. This is actually a regression over test 4.
BZ# 237456 should be a blocker. If it is a dup of another BZ, please let me know.
It's (hopefully) a dup of all the other "anaconda should use mdraid instead of raidautorun" bugs, but nonetheless I've added it to the blocker list.
Today's rawhide should have anaconda-11.2.0.64, which contains another fix for mdraid - say a prayer and give it a shot.
-w
Will Woods wrote:
On Wed, 2007-05-23 at 23:55 -0400, Clyde E. Kunkel wrote:
Pre-exisiting software raid STILL a problem.
Anaconda fails trying to detect existing installations, some of which are on software raid and some on LVs. Added comments to: BZ# 237456 and the anaconda dump file. This is actually a regression over test 4.
BZ# 237456 should be a blocker. If it is a dup of another BZ, please let me know.
It's (hopefully) a dup of all the other "anaconda should use mdraid instead of raidautorun" bugs, but nonetheless I've added it to the blocker list.
Today's rawhide should have anaconda-11.2.0.64, which contains another fix for mdraid - say a prayer and give it a shot.
-w
Waiting for an updated rawhide....
Clyde E. Kunkel wrote:
Waiting for an updated rawhide....
Same here. No sign of it on download.fedora.redhat.com at 18:00 CDT. Anyone know of a mirror that's got it?
Will Woods wrote:
On Wed, 2007-05-23 at 23:55 -0400, Clyde E. Kunkel wrote:
Pre-exisiting software raid STILL a problem.
Anaconda fails trying to detect existing installations, some of which are on software raid and some on LVs. Added comments to: BZ# 237456 and the anaconda dump file. This is actually a regression over test 4.
BZ# 237456 should be a blocker. If it is a dup of another BZ, please let me know.
It's (hopefully) a dup of all the other "anaconda should use mdraid instead of raidautorun" bugs, but nonetheless I've added it to the blocker list.
Today's rawhide should have anaconda-11.2.0.64, which contains another fix for mdraid - say a prayer and give it a shot.
-w
Well, I found a mirror that had .64 on it, but couldn't determine if the images included .64. They are all dated 23 May. Anyway, still get a traceback. Tried to find the version of anaconda at console #2 before clicking next, but there doesn't seem to be -v or --version parm. Is there a way to tell the version of anaconda?
I am going to wait for a rawhide update in the development list before I try again and then I will update the BZ.
On 5/23/07, Will Woods wwoods@redhat.com wrote:
Furthermore, if you've got iwlwifi (Intel 3945 wireless) hardware, please update your system and let us know how it works.
If you can see my bug: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240116
I have some really strange wireless behavior!
For me out-of-the-box fedora 7 wireless experience is terrible. I know enough to make it work, but for standard users this is a really serious but and makes their onboard wireless useless when using fedora 7!
Please fix this bug, upstream or locally... I'm willing to help kill this bug :) also to test it and give you feedback.
Thank you.
On Thu, 2007-05-24 at 13:25 +0200, Valent Turkovic wrote:
On 5/23/07, Will Woods wwoods@redhat.com wrote:
Furthermore, if you've got iwlwifi (Intel 3945 wireless) hardware, please update your system and let us know how it works.
If you can see my bug: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240116
I have some really strange wireless behavior!
For me out-of-the-box fedora 7 wireless experience is terrible. I know enough to make it work, but for standard users this is a really serious but and makes their onboard wireless useless when using fedora 7!
Please fix this bug, upstream or locally... I'm willing to help kill this bug :) also to test it and give you feedback.
Yeah, iwl3945 still isn't as stable as we'd like. We're working really hard on it - linville is keeping us as close to upstream as possible and *vigorously* chases all the iwl3945 bugs. Also, they're trying to get the driver into the mainstream kernel now, so it's currently getting a lot of peer review. The upstream maintainers are pretty responsive, but it's their hardware, they've got the specs.. so the driver quality is pretty much up to them.
So - between patient, diligent testers like you, our fearless (and sleep-deprived) kernel maintainers, and the upstream folks - iwlwifi should be shaping up very, very quickly.
Unfortunately, I can't guarantee it'll be 100% stable for everyone by the initial release of Fedora 7. But it works for a lot of people and, if nothing else, it'll get *way* better in post-F7 updates. And the old driver's still available if you need it.
It's not the ideal situation, but it's the best we can get right now.
-w
On Thu, 24 May 2007, Will Woods wrote:
On Thu, 2007-05-24 at 13:25 +0200, Valent Turkovic wrote:
On 5/23/07, Will Woods wwoods@redhat.com wrote:
Furthermore, if you've got iwlwifi (Intel 3945 wireless) hardware, please update your system and let us know how it works.
If you can see my bug: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240116
I have some really strange wireless behavior!
For me out-of-the-box fedora 7 wireless experience is terrible. I know enough to make it work, but for standard users this is a really serious but and makes their onboard wireless useless when using fedora 7!
Please fix this bug, upstream or locally... I'm willing to help kill this bug :) also to test it and give you feedback.
Yeah, iwl3945 still isn't as stable as we'd like. We're working really hard on it - linville is keeping us as close to upstream as possible and *vigorously* chases all the iwl3945 bugs. Also, they're trying to get the driver into the mainstream kernel now, so it's currently getting a lot of peer review. The upstream maintainers are pretty responsive, but it's their hardware, they've got the specs.. so the driver quality is pretty much up to them.
So - between patient, diligent testers like you, our fearless (and sleep-deprived) kernel maintainers, and the upstream folks - iwlwifi should be shaping up very, very quickly.
Unfortunately, I can't guarantee it'll be 100% stable for everyone by the initial release of Fedora 7. But it works for a lot of people and, if nothing else, it'll get *way* better in post-F7 updates. And the old driver's still available if you need it.
It's not the ideal situation, but it's the best we can get right now.
Wireless support for the bcm4603 has gone from bad to worse.
A few weeks ago I got the old bcm43xx driver working. (My chipset does not support the new firmware.) That worked.
The current devel kernel loads the bcm43xx driver, but it does not appear to load the firmware or do much of anything useful other than occupy ram.
I expect if wireless is this skewed and broken when FC7 gets released for real, there are going to be a bunch of frustrated and pissed off users.
On Thu, 24 May 2007, Will Woods wrote:
On Thu, 2007-05-24 at 13:25 +0200, Valent Turkovic wrote:
On 5/23/07, Will Woods wwoods@redhat.com wrote:
Furthermore, if you've got iwlwifi (Intel 3945 wireless) hardware, please update your system and let us know how it works.
If you can see my bug: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240116
I have some really strange wireless behavior!
For me out-of-the-box fedora 7 wireless experience is terrible. I know enough to make it work, but for standard users this is a really serious but and makes their onboard wireless useless when using fedora 7!
Please fix this bug, upstream or locally... I'm willing to help kill this bug :) also to test it and give you feedback.
Yeah, iwl3945 still isn't as stable as we'd like. We're working really hard on it - linville is keeping us as close to upstream as possible and *vigorously* chases all the iwl3945 bugs. Also, they're trying to get the driver into the mainstream kernel now, so it's currently getting a lot of peer review. The upstream maintainers are pretty responsive, but it's their hardware, they've got the specs.. so the driver quality is pretty much up to them.
The 3194 kernel seems to have made a big difference for me - the connection has been running for about three hours now, albeit with some occasional flakiness. That's a massive improvement on what I've had previously (as noted in bugs 236828 and 238603).
Adam
Will Woods wwoods@redhat.com wrote:
So, today's rawhide should contain fixes for *nearly* all the bugs on the blocker list (http://rdr.to/YH). Emacs should even be working again! Such fun!
Yep, emacs works again.
Kernel sort-off does... kernel-2.6.21-1.3189.fc7, i686 (core duo, Toshiba notebook).
- iwl3945 + NetworkManager works on boot now (!), but the network goes south a while after (1 hour or so?). Strangely, when NM reported no network, the network worked for a while again (15 minutes or so). - Booting with wired network (e1000) panics - Shutdown doesn't work. Pressing the power button just makes the screen go dim (no shutdown dialog). Running "poweroff" hangs in bluetooth (no, the machine has no bluetooth)
On Wed, May 23, 2007 at 11:43:18 -0400, Will Woods wwoods@redhat.com wrote:
If you've got a bug on the blocker list, or if you have a system using software RAID or dmraid (aka BIOS-raid aka fakeraid) *please* try an install/upgrade from rawhide today. Upgrades on FC6 systems using software RAID on IDE drives are especially important.
I am upgrading a machine now that has two software raid arrays. The arrays did not get degraded while the install is running. I won't know until the upgrade has finished that there isn't a problem later.
Has the go nogo for decision 5/31 been made yet?
I found that despite the upgrade process being pretty slow, I was able to keep from being bored by using ssh (after remembering the syntax for the ip and route commands) to get to a remote host where I can read email and browse the web (using lynx).
On 5/25/07, Jesse Keating jkeating@redhat.com wrote:
On Friday 25 May 2007 19:29:23 Bruno Wolff III wrote:
Has the go nogo for decision 5/31 been made yet?
Yes it has. We are go for launch.
-- Jesse Keating Release Engineer: Fedora
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
Latest CD doesn't give me a display on my x1400...... again :(
Need a buggy report
The upgrade process is pretty slow. I have been watching an FC5 to F7 upgrade for almost 12 hours now. 1350 packages were being updated. The machine is fairly old (512MB memory, 800MHz P3, 5400rpm disks), but this still seems excessive. It has been in finishing upgrade for about an hour and a half. It looks like it is running some processes (ldconfig and some desktop update stuff) over and over again. It looks like this may be a case of a lot of packages running the same stuff as part of their post install scripts. But I suspect that ldconfig and desktop update could be run once for the whole transaction rather than once for each package that needs it.
On Saturday 26 May 2007 02:18:15 Bruno Wolff III wrote:
But I suspect that ldconfig and desktop update could be run once for the whole transaction rather than once for each package that needs it.
It's not as simple as that though, as some packages need to run themselves in %post and thus need to have their libraries accessable and thus really do need ldconfig ran. Or even more difficult to discover is package B needs to run package A in %post so Package A's libraries must be acessable.
That said, yes, there is a lot to gain for batching these timely operations. Doing so in an intelligent way that doesn't break things is going to be difficult at best.
On Sat, May 26, 2007 at 02:21:06 -0400, Jesse Keating jkeating@redhat.com wrote:
On Saturday 26 May 2007 02:18:15 Bruno Wolff III wrote:
But I suspect that ldconfig and desktop update could be run once for the whole transaction rather than once for each package that needs it.
It's not as simple as that though, as some packages need to run themselves in %post and thus need to have their libraries accessable and thus really do need ldconfig ran. Or even more difficult to discover is package B needs to run package A in %post so Package A's libraries must be acessable.
That said, yes, there is a lot to gain for batching these timely operations. Doing so in an intelligent way that doesn't break things is going to be difficult at best.
Is it work entering an RFE genericly saying something like try to find a way to run common post install stuff once per transaction? Would such a bugzilla be best filed against rpm? (The process spawning these tasks appeared to be anaconda, but it feels like an rpm feature.
Bruno Wolff III (bruno@wolff.to) said:
That said, yes, there is a lot to gain for batching these timely operations. Doing so in an intelligent way that doesn't break things is going to be difficult at best.
Is it work entering an RFE genericly saying something like try to find a way to run common post install stuff once per transaction? Would such a bugzilla be best filed against rpm? (The process spawning these tasks appeared to be anaconda, but it feels like an rpm feature.
It's been discussed. We've done tests with RPM patched to ignore any %post/%postun scripts that were just /sbin/ldconfig - in testing, it didn't make any difference.
Bill
On Sat, May 26, 2007 at 14:02:05 -0400, Bill Nottingham notting@redhat.com wrote:
It's been discussed. We've done tests with RPM patched to ignore any %post/%postun scripts that were just /sbin/ldconfig - in testing, it didn't make any difference.
Maybe you were running on faster hardware. (Perhaps the library files all stayed in teh OS cache during your testing.) On the machine I was updating these processes were running for a few seconds each time something needed them. And there were at least dozens out of the 1350 updates that called them. There is a good argument that they weren't that significant compared to the other stuff going on then. But it would probably cut a couple of minutes off a process that went for over an hour and a half (that's just the finishing upgrade step and I had to go home before it finished so I don' know how much longer it took). Perhaps there is better bang for the buck in other places. There is also no progress bar for this step which makes it hard to tell how far along things are. For a step that runs for over an hour, I don't think this is a good thing.
Running top while the post processing was going on showed anaconda with about %40 of my 512MB and noticiable CPU, but not pegged (typical less than 20%). I could hear the disk drives making noise (I think seeks, but I don't know for sure) during this process that they don't make when things are fairly idle.
Bruno Wolff III (bruno@wolff.to) said:
It's been discussed. We've done tests with RPM patched to ignore any %post/%postun scripts that were just /sbin/ldconfig - in testing, it didn't make any difference.
Maybe you were running on faster hardware. (Perhaps the library files all stayed in teh OS cache during your testing.)
Possibly. It was installing a full desktop installation, so it shouldn't have been that much in cache. I might try a mem=256m test.
Bill
Software raid looks good after upgrading. I'll test with a fresh install later.
I am seeing some annoying stuff which display resolution. I have a TNT2 card that appears to be using the nv driver and a sync master 1100p monitor. After the upgrade it was using a different resolution than before. The name displayed in the display hardware menu didn't match the name in the drop down menu for the same device. When I switched to the name I could pick and rebooted it came up in a mode that wasn't usable (the display had color, but it wasn't in the right places). I tried removing the xorg.conf file and letting it auto detect again and it came up unusable again. So I switched to the backup config file.
I am going to play with this for a little while yet, but don't want to spend the whole day at work as I want to do some F7 installs at home. So if someone suggests trying another driver, I can probably do that.
On Sat, May 26, 2007 at 14:16:28 -0500, Bruno Wolff III bruno@wolff.to wrote:
I am seeing some annoying stuff which display resolution. I have a TNT2 card that appears to be using the nv driver and a sync master 1100p monitor. After the upgrade it was using a different resolution than before. The name displayed in the display hardware menu didn't match the name in the drop down menu for the same device. When I switched to the name I could pick and rebooted it came up in a mode that wasn't usable (the display had color, but it wasn't in the right places). I tried removing the xorg.conf file and letting it auto detect again and it came up unusable again. So I switched to the backup config file.
I looked through the xorg log and it looks like it is picking up reasonable possible modes for the monitor from direct probing. However the modes I would like are being rejected when checked against the video card as either "width too large for virtual size" or "height too large for virtual size".
I remember seeing some discussion about the nv driver recently in regard to rawhide installs, so I'll see if I can find those or just drive to use the other driver.
On Sat, May 26, 2007 at 14:39:51 -0500,
I looked through the xorg log and it looks like it is picking up reasonable possible modes for the monitor from direct probing. However the modes I would like are being rejected when checked against the video card as either "width too large for virtual size" or "height too large for virtual size".
I remember seeing some discussion about the nv driver recently in regard to rawhide installs, so I'll see if I can find those or just drive to use the other driver.
Uninstalling the nouvea driver didn't help.
I found that changing the max colors did help. However the system config menu for doing this has problems. The possible screen resolutions and color depth should interact but don't. So that when in 24bit mode you can't specify a change to both a lower color depth and a higher resolution that won't work with the current color depth. Or perhaps worse, you can choose a higher color depth when at a resolution that won't work with it and then end up having to reboot in level 3 when your login screen is fubar'd.
So I think I can do what I want now, but perhaps I should bugzilla how the config menu works?
On Sat, 2007-05-26 at 15:26 -0500, Bruno Wolff III wrote:
On Sat, May 26, 2007 at 14:39:51 -0500,
I looked through the xorg log and it looks like it is picking up reasonable possible modes for the monitor from direct probing. However the modes I would like are being rejected when checked against the video card as either "width too large for virtual size" or "height too large for virtual size".
I remember seeing some discussion about the nv driver recently in regard to rawhide installs, so I'll see if I can find those or just drive to use the other driver.
Uninstalling the nouvea driver didn't help.
I found that changing the max colors did help. However the system config menu for doing this has problems. The possible screen resolutions and color depth should interact but don't. So that when in 24bit mode you can't specify a change to both a lower color depth and a higher resolution that won't work with the current color depth. Or perhaps worse, you can choose a higher color depth when at a resolution that won't work with it and then end up having to reboot in level 3 when your login screen is fubar'd.
So I think I can do what I want now, but perhaps I should bugzilla how the config menu works?
Don't feel obligated, I know it's bad.
- ajax
On 5/29/07, Adam Jackson ajackson@redhat.com wrote:
On Sat, 2007-05-26 at 15:26 -0500, Bruno Wolff III wrote:
On Sat, May 26, 2007 at 14:39:51 -0500,
I looked through the xorg log and it looks like it is picking up
reasonable
possible modes for the monitor from direct probing. However the modes I would like are being rejected when checked against
the
video card as either "width too large for virtual size" or "height too
large
for virtual size".
I remember seeing some discussion about the nv driver recently in
regard
to rawhide installs, so I'll see if I can find those or just drive to use the other driver.
Uninstalling the nouvea driver didn't help.
I found that changing the max colors did help. However the system config menu for doing this has problems. The possible screen resolutions and color depth should interact but don't. So that when in 24bit mode you can't specify a change to both a lower color depth and a higher
resolution
that won't work with the current color depth. Or perhaps worse, you can choose a higher color depth when at a resolution that won't work with it and then end up having to reboot in level 3 when your login screen is fubar'd.
So I think I can do what I want now, but perhaps I should bugzilla how
the
config menu works?
Don't feel obligated, I know it's bad.
- ajax
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
Is Fedora 7 still shiping on 5/31?
If so, no support for vesa on laptops with ati x1X00 cards still? Maybe desktop cards too, not sure.
"JC" == Justin Conover justin.conover@gmail.com writes:
JC> If so, no support for vesa on laptops with ati x1X00 cards still?
I booted the last installer on my laptop with an x1600 and it had no trouble at all.
There may be a bug with these cards on some machines; I don't know. But it goes a bit far to say there's no support.
- J<
On 29 May 2007 23:04:25 -0500, Jason L Tibbitts III tibbs@math.uh.edu wrote:
"JC" == Justin Conover justin.conover@gmail.com writes:
JC> If so, no support for vesa on laptops with ati x1X00 cards still?
I booted the last installer on my laptop with an x1600 and it had no trouble at all.
There may be a bug with these cards on some machines; I don't know. But it goes a bit far to say there's no support.
- J<
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
I did say not sure about all ati cards, I know that is a stretch but it does appear that there are a lot of x1300 & x1400 cards out there.
On 5/30/07, Justin Conover justin.conover@gmail.com wrote:
On 29 May 2007 23:04:25 -0500, Jason L Tibbitts III tibbs@math.uh.edu wrote:
> "JC" == Justin Conover justin.conover@gmail.com writes:
JC> If so, no support for vesa on laptops with ati x1X00 cards still?
I booted the last installer on my laptop with an x1600 and it had no trouble at all.
There may be a bug with these cards on some machines; I don't know. But it goes a bit far to say there's no support.
- J<
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
I did say not sure about all ati cards, I know that is a stretch but it does appear that there are a lot of x1300 & x1400 cards out there.
To expand on that, I know crap happens, but since I like Fedora and RedHat, I hate to see the news article's with, "Damn it doesn't work on my laptop..." and other stuff like that ;)
On Wednesday 30 May 2007 11:24:34 Justin Conover wrote:
To expand on that, I know crap happens, but since I like Fedora and RedHat, I hate to see the news article's with, "Damn it doesn't work on my laptop..." and other stuff like that ;)
It's always going to fail for somebody's laptop.
On 5/30/07, Jesse Keating jkeating@redhat.com wrote:
On Wednesday 30 May 2007 11:24:34 Justin Conover wrote:
To expand on that, I know crap happens, but since I like Fedora and
RedHat,
I hate to see the news article's with, "Damn it doesn't work on my laptop..." and other stuff like that ;)
It's always going to fail for somebody's laptop.
-- Jesse Keating Release Engineer: Fedora
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
Yeah, just sucks more now that it is mine :P
On 5/30/07, Justin Conover justin.conover@gmail.com wrote:
On 5/30/07, Jesse Keating jkeating@redhat.com wrote:
On Wednesday 30 May 2007 11:24:34 Justin Conover wrote:
To expand on that, I know crap happens, but since I like Fedora and
RedHat,
I hate to see the news article's with, "Damn it doesn't work on my laptop..." and other stuff like that ;)
It's always going to fail for somebody's laptop.
-- Jesse Keating Release Engineer: Fedora
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
Yeah, just sucks more now that it is mine :P
I have found a work around, not sure if it was stated in a bug or not, but anyway.
I booted the livecd(x64) graphics bailed (duh) vi /etc/X11/xorg.conf added Modes "800x600" to the Display section
SubSection "Display" Depth 24 Modes "800x600" EndSubSection
startx
And I'm trying an install now.
On Wed, May 30, 2007 at 11:54:21AM -0400, Jesse Keating wrote:
On Wednesday 30 May 2007 11:24:34 Justin Conover wrote:
To expand on that, I know crap happens, but since I like Fedora and RedHat, I hate to see the news article's with, "Damn it doesn't work on my laptop..." and other stuff like that ;)
It's always going to fail for somebody's laptop.
And the same problems exist in Ubuntu and SUSE.