Some of the issues here probably won't be addressed in F10, so this is probably a reasonable list for discussion.
Yesterday, I downloaded F10 and installed it on an HP/Compaq EVO D510.
The only non-standard feature on the system is a prism54-based network card. It works with the prism54 driver first incorporated into the kernel, but needs a firmware blob.
The system has a CD drive, not DVD, and since I wanted to install to the system where it will live (needs wireless), I downloaded CD images and installed using those burned to CD. I was downloading and installing at the same time, downloading running a little faster (thank goodness I finally escaped the modem).
Without giving much thought, I chose a text install. On reflection, I think that a good choice.
About disk three there was an error reading the zsh rpm. There were fewer options than I would like, but "eject" is an improvement on last time I had this problem, about RHL 8.0 or a beta of it I think, where I could only retry.
I would like also the options to 1. Skip. I understand it's not always prudent to skip a package, but not all are equally essential and I'd probably do fairly well without zsh. 2. Install from another source.
In this case, ejecting and reloading the CD was effective.
Since I installed in text mode, F10 defaulted to runlevel 3. This highlights the prudence of my choice in doing a text install (besides which, text should be faster in 512 Mbytes RAM).
On first boot, I tried to configure the network - I had copied fhe firmware into place before rebooting after the install), but the text-mode network install doesn't understand wireless.
Note, I've not seen any documentation of how to do this for Fedora, I had some experience with the first release of Ubuntu and this particular wireless card, so I had some ideas of what to do. If there is some documentation on the 'net, it would be especially hard to browse for it as I didn't yet have a working network. For purposes of discussion, we're ignoring the other umpteen computers here, okay?
Once I had the driver in the rignt place and a symlink with the right name, the wireless came up easily enough.
I was quite surprised though to find it's eth0 in F10 (at least some of the time), it used to be eth1 (and is, in the kubuntu 6.10 system I booted off my LAN more recently). The EVO has an on-board NIC, so I fully expected that to be eth0.
I was dismayed to find I had to apply over 600 Mbytes of updates Those, it seemed to me, took longer than the original installation. However, it's done.
I then switched to runlevel 5 and tried to login as root.
The screen displayed some junk, but I did get a login screen of sorts. I tried to login, the login failed but there was no comprehensible message, the fonts were badly distorted. After that, nothing comprehensible displayed and I could not crash X or switch to a text console.
The only way to regain control was the power button (no reset switch on these systems). Remember, no network yet. I need graphics to configure the wireless.
I don't like gdm anyway, never have, so "rpm --erase gdm" and then the bits that require it.
After this, the login screen was less useful, so I tried runlevel 3 and "startx" as root. That got a grey screen with an X cursor and nothing else. I'm pretty sure I had to cycle power again here.
I thought to try tweaking xorg.conf if only to ensure control-alt-backspace and control-alt-F1 etc work, but there is none: (EE) Unable to locate/open config file
The full log is at http://fedora.js.id.au/var/log/Xorg.0.log and its content suggests it's going to take more than five minutes to fix. These don't look good to me: [mi] EQ overflowing. The server is probably stuck in an infinite loop.
Backtrace: 0: /usr/bin/X(xorg_backtrace+0x3b) [0x812bc5b] 1: /usr/bin/X(mieqEnqueue+0x289) [0x810b379] 2: /usr/bin/X(xf86PostMotionEventP+0xc2) [0x80d4262] 3: /usr/bin/X(xf86PostMotionEvent+0x68) [0x80d43c8] 4: /usr/lib/xorg/modules/input//evdev_drv.so [0xa6fa8d] 5: /usr/bin/X [0x80bcdb7] 6: /usr/bin/X [0x80ac91e] 7: [0x130400] 8: [0x130416] 9: /lib/libc.so.6(ioctl+0x19) [0x4f3979] 10: /usr/lib/libdrm.so.2 [0x6f56cf] 11: /usr/lib/libdrm.so.2(drmCommandWrite+0x34) [0x6f5984] 12: /usr/lib/xorg/modules/drivers//intel_drv.so(I830Sync+0x135) [0x711ca5] 13: /usr/lib/xorg/modules/drivers//intel_drv.so [0x73b97a] 14: /usr/lib/xorg/modules//libexa.so(exaWaitSync+0x65) [0x7d4095] 15: /usr/lib/xorg/modules//libexa.so(ExaDoPrepareAccess+0x7e) [0x7d53ae] 16: /usr/lib/xorg/modules//libexa.so [0x7da3b2] 17: /usr/lib/xorg/modules//libexa.so [0x7da905] 18: /usr/lib/xorg/modules//libexa.so(exaDoMigration+0x652) [0x7db0c2] 19: /usr/lib/xorg/modules//libexa.so(exaCopyNtoN+0x3f1) [0x7d7fd1] 20: /usr/lib/xorg/modules//libexa.so(exaComposite+0x90e) [0x7dd4de] 21: /usr/bin/X [0x816f6fa] 22: /usr/bin/X(CompositePicture+0x19a) [0x815818a] 23: /usr/lib/xorg/modules//libexa.so [0x7d8c1d] 24: /usr/lib/xorg/modules//libexa.so(exaGlyphs+0x4e2) [0x7d9672] 25: /usr/bin/X [0x816f9c5] 26: /usr/bin/X(CompositeGlyphs+0xa2) [0x8154612] 27: /usr/bin/X [0x816197e] 28: /usr/bin/X [0x815ad75] 29: /usr/bin/X(Dispatch+0x34f) [0x8085e9f] 30: /usr/bin/X(main+0x47d) [0x806b71d] 31: /lib/libc.so.6(__libc_start_main+0xe5) [0x42e6e5] [mi] mieqEnequeue: out-of-order valuator event; dropping. [mi] EQ overflowing. The server is probably stuck in an infinite loop.
Here is a similar report: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg37058.html In view of this, I tried booting with 'vga=6' but the result is a login screen with a garbage background but visible entry boxes and intelligible text. However, mouseclicks and the keyboard are ignored. With the earlier kernel, I got no garbage (but that might have been luck), but the other symptoms are the same.
I connected over the LAN (It's been relocated). "chvt 1" is ineffective. "telinit 3" has no visible effect. Nothing less than "kill -KILL" got rid of X and that left the display in a parlous state: random junk, frozen X mouse cursor.
This is similar: https://fcp.surfsite.org/modules/newbb/viewtopic.php?viewmode=flat&order...
I have to have this system running, Mrs S requires it. I know this system runs opensuse 11.0, but I plan on trying CentOS5 first. It's not available for testing.
fwiw I have a Kubuntu 6.10 sytem I can boot off the LAN. It boots fine on this system (to a framebuffer console, I don't have X on it), and even loads the firmware for the wireless card (which certainly was not present in the original system I did the install on).
On Wed, Dec 31, 2008 at 4:37 AM, John Summerfield debian@herakles.homelinux.org wrote:
I then switched to runlevel 5 and tried to login as root.
The screen displayed some junk, but I did get a login screen of sorts. I tried to login, the login failed but there was no comprehensible message, the fonts were badly distorted. After that, nothing comprehensible displayed and I could not crash X or switch to a text console.
What graphics card do you have? If it's ATI, try adding "nomodeset" to the kernel boot line in grub ...
MEF
On Wed, Dec 31, 2008 at 12:37:21PM +0900, John Summerfield wrote:
On first boot, I tried to configure the network - I had copied fhe firmware into place before rebooting after the install), but the text-mode network install doesn't understand wireless.
Not entirely true but indeed a default way to do that is through a NetworkManager (a.k.a. NetworkMangler) and that assumes a graphic environment. It is always possible to bring wireless up using iwconfig and/or wpa_supplicant but this is relatively "low level".
Note, I've not seen any documentation of how to do this for Fedora,
'man iwconfig' (with a section "SEE ALSO") and 'man wpa_supplicant'.
I was quite surprised though to find it's eth0 in F10 (at least some of the time), it used to be eth1
Something else already took eth0. Do you have a wired interface on this board? Names and assignments can be changed but they are written "automagically" in udev rules and kept for later. Dig a bit in files in /etc/udev/rules.d/ and you will find that out.
These don't look good to me: [mi] EQ overflowing. The server is probably stuck in an infinite loop.
Aha! Intel graphics, right? Known bug. https://bugzilla.redhat.com/show_bug.cgi?id=469292 For now create a skeleton xorg.conf with a help of 'Xorg -configure' and add an option "NoAccel" to it. Details in the reference bug report (and I was hit by it too). A display slows down but it works.
BTW - some desktop heads are stuck with an idea that forcing gdm on the first console, for some illusory gains but a lot of extra troubles, is a good thing to do. As a result 'chvt 1' "does not work" as you do not have getty running there; but it is not difficult to find a text console with 'chvt 2' or a bit higher.
I have to have this system running, Mrs S requires it.
It will run; even quite well if not perfect but try less emotional approach and search bugzilla for troubles. I do have similar requirements. :-)
... but I plan on trying CentOS5 first.
You are likely to bump into wireless issues.
Michal
Michal Jaegermann wrote:
On Wed, Dec 31, 2008 at 12:37:21PM +0900, John Summerfield wrote:
On first boot, I tried to configure the network - I had copied fhe firmware into place before rebooting after the install), but the text-mode network install doesn't understand wireless.
Not entirely true but indeed a default way to do that is through a NetworkManager (a.k.a. NetworkMangler) and that assumes a graphic environment. It is always possible to bring wireless up using iwconfig and/or wpa_supplicant but this is relatively "low level".
Note, I've not seen any documentation of how to do this for Fedora,
'man iwconfig' (with a section "SEE ALSO") and 'man wpa_supplicant'.
I'm well versed in those, but that's not an acceptable way for general use.
I was quite surprised though to find it's eth0 in F10 (at least some of the time), it used to be eth1
Something else already took eth0. Do you have a wired interface on this board? Names and assignments can be changed but they are written "automagically" in udev rules and kept for later. Dig a bit in files in /etc/udev/rules.d/ and you will find that out.
You misunderstood me. The wireless came up as eth0. Usually, the on-board NIC takes eth0 and the wireless as eth1 or later, or ath0 or something depending on the author's inclination.
These don't look good to me: [mi] EQ overflowing. The server is probably stuck in an infinite loop.
Aha! Intel graphics, right? Known bug.
Yes, I tried to reply to Bob to explain the information's in the log file I posted.
Sadly, I got the URL wrong, so I was going to mention that it's really here: http://fedora.js.id.au/Xorg.0.log
https://bugzilla.redhat.com/show_bug.cgi?id=469292 For now create a skeleton xorg.conf with a help of 'Xorg -configure' and add an option "NoAccel" to it. Details in the reference bug report (and I was hit by it too). A display slows down but it works.
CentOS5 is running (almost) fine, hut a glitch with the wireless, which is behaving very strangely. "ifup eth1" fails, no matter what what magic incantations I utter. These commends work: modprobe -r prism54 ifconfig eth1 # with no operands <shrug> I will incorporate something into the startup.
BTW - some desktop heads are stuck with an idea that forcing gdm on the first console, for some illusory gains but a lot of extra troubles, is a good thing to do. As a result 'chvt 1' "does not work" as you do not have getty running there; but it is not difficult to find a text console with 'chvt 2' or a bit higher.
I have to have this system running, Mrs S requires it.
It will run; even quite well if not perfect but try less emotional approach and search bugzilla for troubles. I do have similar requirements. :-)
The point's "time is of the essence."
In May this year, I will reach the 40th anniversary of my writing my first programs, in fortran and compass. MY time for sorting out the world's computing problems has passed, I want something that works with a minimum of fuss and bother.
... but I plan on trying CentOS5 first.
You are likely to bump into wireless issues.
Not really, as I said before, this card's been supported for quite a while, since 2.6.8 I think. Its chipset was, for quite a while, my recommendation for 11g wireless on Linux. It should work fine in C4.
Note to Bob.
Please prune. For quite a while I couldn't see what you added. When I tried to reply, seamonkey pruned from my sig to the end, and that removed your text that I wanted to respond to. AFAIK the pruning's not configurable in seamonkey (but is in kmail).
On Sat, Jan 03, 2009 at 05:03:24PM +0900, John Summerfield wrote:
Michal Jaegermann wrote:
Not entirely true but indeed a default way to do that is through a NetworkManager (a.k.a. NetworkMangler) and that assumes a graphic environment. It is always possible to bring wireless up using iwconfig and/or wpa_supplicant but this is relatively "low level".
Note, I've not seen any documentation of how to do this for Fedora,
'man iwconfig' (with a section "SEE ALSO") and 'man wpa_supplicant'.
I'm well versed in those, but that's not an acceptable way for general use.
I am not sure what is "an acceptable way" according to your criteria but I thought that you wanted a wireless connection while in a text mode and before fixing other issues. Adding wpa_supplicant.conf entries is not exactly a black magic.
Once you will have X sorted out then NM should be operational.
I was quite surprised though to find it's eth0 in F10 (at least some of the time), it used to be eth1
Something else already took eth0. Do you have a wired interface on this board? Names and assignments can be changed but they are written "automagically" in udev rules and kept for later. Dig a bit in files in /etc/udev/rules.d/ and you will find that out.
You misunderstood me. The wireless came up as eth0.
And? Something enumerated it first. If you dislike it then edit that in /etc/udev/rules.d/70-persistent-net.rules. A comment there says "# You can modify it, as long as you keep each rule on a single line".
... or ath0 or something depending on the author's inclination.
"ath" prefix is used for Atheros driver handled interfaces. These names are really conventional anyway (although I did not experiment to see if NM will not choke on something "unusual"). Check 'man ifrename' even if udev rules really overtook it.
It appears that all your troubles with F10 really boil down to a bug in an X driver for Intel chipsets. Why this was released that way I have no idea; especially that this used to work fine in the past. A significant number of machines already was or will be hit by that.
Michal
Michal Jaegermann wrote:
On Sat, Jan 03, 2009 at 05:03:24PM +0900, John Summerfield wrote:
Michal Jaegermann wrote:
Not entirely true but indeed a default way to do that is through a NetworkManager (a.k.a. NetworkMangler) and that assumes a graphic environment. It is always possible to bring wireless up using iwconfig and/or wpa_supplicant but this is relatively "low level".
Note, I've not seen any documentation of how to do this for Fedora,
'man iwconfig' (with a section "SEE ALSO") and 'man wpa_supplicant'.
I'm well versed in those, but that's not an acceptable way for general use.
I am not sure what is "an acceptable way" according to your criteria but I thought that you wanted a wireless connection while in a text mode and before fixing other issues. Adding wpa_supplicant.conf entries is not exactly a black magic.
A long-term acceptable way to do it has to be no harder than it is on Windows and Linux. No geek required.
Once you will have X sorted out then NM should be operational.
CentOS5 is fine, now I've killed off kudzu.
I was quite surprised though to find it's eth0 in F10 (at least some of the time), it used to be eth1
Something else already took eth0. Do you have a wired interface on this board? Names and assignments can be changed but they are written "automagically" in udev rules and kept for later. Dig a bit in files in /etc/udev/rules.d/ and you will find that out.
You misunderstood me. The wireless came up as eth0.
And? Something enumerated it first. If you dislike it then edit that in /etc/udev/rules.d/70-persistent-net.rules. A comment there says "# You can modify it, as long as you keep each rule on a single line".
"no geek required."
Users get upset when things change for no apparent reason. People objected loudly when 2.6 kernels renamed their ethernet interfaces: suddenly eth0 was connected to a different network, as were eth1 and eth2, with resultant chaos in DHCP server settings, firewalls and so on. It caused grief for me, and for quite a few others.
... or ath0 or something depending on the author's inclination.
"ath" prefix is used for Atheros driver handled interfaces. These names are really conventional anyway (although I did not experiment to see if NM will not choke on something "unusual"). Check 'man ifrename' even if udev rules really overtook it.
I understand that, atheros have been my preferred chips for a while now. I think other writers use other names. It's a bit like having (ATA) drives at hd{a,b,c,d} and then having a few more appearing at disk{0,1,2,3} because some writer thought it cool to use different names for his ATA device driver.
It appears that all your troubles with F10 really boil down to a bug in an X driver for Intel chipsets. Why this was released that way I have no idea; especially that this used to work fine in the past. A significant number of machines already was or will be hit by that.
There's a different bug hits the graphics in my Tosh Satellite 1400 (Trident I think). It hangs when the screensaver kicks in. I gave up on that, Mrs S says it's too slow with F10 anyway.
Michal
My third (and last) F10 is supposed to he hosting virtual test machines. With no xen host support, and KVM not working satisfactorily, I've settled on doing it in Windows.
On Sun, Jan 04, 2009 at 08:56:10PM +0900, John Summerfield wrote:
Michal Jaegermann wrote:
On Sat, Jan 03, 2009 at 05:03:24PM +0900, John Summerfield wrote:
You misunderstood me. The wireless came up as eth0.
And? Something enumerated it first. If you dislike it then edit that in /etc/udev/rules.d/70-persistent-net.rules. A comment there says "# You can modify it, as long as you keep each rule on a single line".
"no geek required."
"No geek needed". Following your criteria only a geek would care what specific names were stuck to network interfaces. Again - why do you care? If you do you are free to adjust things to your taste.
Michal
Michal Jaegermann wrote:
On Sun, Jan 04, 2009 at 08:56:10PM +0900, John Summerfield wrote:
Michal Jaegermann wrote:
On Sat, Jan 03, 2009 at 05:03:24PM +0900, John Summerfield wrote:
You misunderstood me. The wireless came up as eth0.
And? Something enumerated it first. If you dislike it then edit that in /etc/udev/rules.d/70-persistent-net.rules. A comment there says "# You can modify it, as long as you keep each rule on a single line".
"no geek required."
"No geek needed". Following your criteria only a geek would care what specific names were stuck to network interfaces. Again - why do you care? If you do you are free to adjust things to your taste.
Michal
Evidently you haven't had your system mucked up by a kernel upgrade. "no geek required" does not mean "no geek allowed," and I do still need to care about these things. Renaming network interfaces at random can lead to difficulties administering a system remotely.
Whether I care about their names or not, I do care that the cable plugged into _that_ socket goes to my ADSL modem, the next one goes to the staff network and the third to the student network.
If a kernel upgrade changes the first NIC's configuration from "no IP" to "student LAN IP," I have to be on site to sort it out. That's what renaming interfaces can do.
On Mon, Jan 05, 2009 at 02:26:38PM +0900, John Summerfield wrote:
If a kernel upgrade changes the first NIC's configuration from "no IP" to "student LAN IP," I have to be on site to sort it out. That's what renaming interfaces can do.
Sigh! We were talking about an installation and not kernel changes. You clearly did not bother to look into /etc/udev/rules.d/70-persistent-net.rules, for example. Right?
Could you explain how a kernel update can change a network interface name which happens to be tied up to a MAC address of that interface? Or you have on hands network cards with identical MACs? You likely know that you can run into some grief with that no matter what.
Once name interface rules were recorded for the first time it take some work to move those names around. It is possible but for you "too geek". Shrug! One way or another it was like that for a long time.
Michal
Michal Jaegermann wrote:
On Mon, Jan 05, 2009 at 02:26:38PM +0900, John Summerfield wrote:
If a kernel upgrade changes the first NIC's configuration from "no IP" to "student LAN IP," I have to be on site to sort it out. That's what renaming interfaces can do.
Sigh! We were talking about an installation and not kernel changes. You clearly did not bother to look into /etc/udev/rules.d/70-persistent-net.rules, for example. Right?
Could you explain how a kernel update can change a network interface name which happens to be tied up to a MAC address of that interface? Or you have on hands network cards with identical MACs? You likely know that you can run into some grief with that no matter what.
Yesterday, after seeing this, I saw two other emails on two other lists, where people reported their network interfaces changed names.
One on SLED, one on RHEL.
In one case, it was apparently explained by a new driver's failure to claim the usual eth0.
Once name interface rules were recorded for the first time it take some work to move those names around. It is possible but for you "too geek". Shrug! One way or another it was like that for a long time.
On Thu, Jan 08, 2009 at 06:53:12AM +0900, John Summerfield wrote:
Michal Jaegermann wrote:
Could you explain how a kernel update can change a network interface name which happens to be tied up to a MAC address of that interface? Or you have on hands network cards with identical MACs? You likely know that you can run into some grief with that no matter what.
Yesterday, after seeing this, I saw two other emails on two other lists, where people reported their network interfaces changed names.
One on SLED, one on RHEL.
So which one of these two was the current Fedora? None? Oh...
I know that you can change an interface name. It is not so easy to do that if it is tied to a MAC of a interface. Sometimes this is actually a PITA when, for whatever reasons, you do want to change these names and you have to fish out where this connection was recorded.
If you will look closer then in /etc/sysconfig/network-scripts/ifcfg-* files there is HWADDR and it was automatically filled for quite a while now although not from "always". If those configuration files are not used then /etc/udev/rules.d/70-persistent-net.rules are doing a similar thing.
OTOH 'man ifrename' and /etc/iftab were available when needed I do not remember now for how long. The only thing is that once a network interface went up then it is too late for renaming.
Michal
-
John Summerfield -
Mary Ellen Foster -
Michal Jaegermann