You are not logged in.
I have just updated to the new kernel, udev, etc. Doco states something about module loading which I did not really understand, so I did nothing.
Now when I try to run arch, gdm no longer comes up, with error messages about /opt/gnome/sbin/gdm not existing. There is a file there but it will not run by typing in gdm, but it does by typing in sh gdm. Not sure what that means. I can then get into Gnome, but now also my networking is no longer functioning.
I assume this has something to do with modules and the new udev. Can someone explain?
As to the changes to fstab, which I also do not understand, I never had any /dev/discs/blah/blah entries anyhow.
One last question, is this whole issue of udev and device naming going to settle down sometime soon - no one can seem to decide what anything si called these days.
Thanks,
8)
Offline
do you have
MOD_AUTOLOAD="yes" in /etc/rc.conf ?
[My Blog] | [My Repo] | [My AUR Packages]
Offline
i don't know about gdm but i don't think it's udev related at all.
the fstab in announce is mentioned because of older installs that might have the /dev/discs entries if you don't have them just be happy and all works just fine.
Offline
do you have
MOD_AUTOLOAD="yes" in /etc/rc.conf ?
Yes - always been there, and I have not changed it.
I installed 0.71 Noodle, the latest release.
Offline
read the news .... check that there are no ! in MODULES otherwise mods will never load
Mr Green
Offline
Some discoveries.
First off that stuff I wrote about GDM and SH was a lot of drivel.
Actually what has happened is that the pacman update seems to have overwritten the /etc/innitab file, which lost the changes I had made, namely:
id:3:initdefault: -> id:5:initdefault:
x:5:respawn:/usr/bin/xdm -nodaemon -> x:5:respawn:/opt/gnome/sbin/gdm -nodeamon
This explains why GDM and X no longer came up. A quick re-edit and that part is fixed.
Re the loss of networking, I noticed when doing an lsmod list that the e1000 module which drives the Intel ethernet chip on my motherboard was no longer in the list. Fortunately I also have an nforce ethernet port in the chipset which uses the forcedeth driver, which is still loaded. A quick movement of the ethernet cable from one port to another and the internet is up and running.
So the two issue of the update are:
***** Update overwrites /etc/inittab file.
***** The new Udev does not pick up my Intel E1000 chip.
This looks like a job for one of the Arch Linux gurus to sort out.
Happy Guru-ing.
8) 8) 8) 8) 8) 8) 8) 8) 8) 8)
Offline
have you added a !e1000 in rc.conf MODULES=, it's pretty strange that it gets not loaded
Offline
Actually i had a similar experience :
my network card uses 8139too , so i had 8139cp blacklisted.
after updating no eth0 was found, because the 8139too module was not loaded.
I removed 8139cp from blacklist and eth0 worked again, but this time both 8139cp and 8139too were loaded.
I put 8139cp back in blacklist, added 8139too to modules array and everything works fine.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
I experinced the same.
I just rewrote the inittab file, and disabled OSS in modprobe.conf to load audio at startup.
That solved the problem
Offline
Having got networking working (hehe) with the forcedeth driver, I decided to try and get the e1000 working. So I swapped the ethernet cable to the Intel E1000 port, booted up arch (expecting the networking not to work) and then to embark on a series of trial and error config file mods.
Amazingly though, the ethernet now worked despite having made no changes whatsoever. Init conf files are exactly the same as when the ethernet connection failed.
THi seems odd since I did not change eth0 to eth1 (surely I should if the hardware detect finds both devices)!? Apparently the e1000 was eth0 originally, and again now, but when the e1000 was not located, the forcedeth became eth0. This makes sense, but only if the e1000 was not picked up by the hardware detect (which conforms to what I currently believe), but then why is it now being picked up?
I am more confused than ever.
Regarding the previous post from the guy who said disabling his soundcard oss emulation fixed a similar problem - even more surprising that the sound card driver should affect networking - unless I misunderstood what he is saying.
:?:
Offline
I experinced the same.
I just rewrote the inittab file, and disabled OSS in modprobe.conf to load audio at startup.
That solved the problem
Can you show me how you did that? I cannot tell which part of the two lines I have in that file that need to be changed and in what way.
Thanks,
Offline
have you added a !e1000 in rc.conf MODULES=, it's pretty strange that it gets not loaded
Read my other big post and you will see that it just reappeared for no apparent reason. Did'nt have to nominate it in the modules variable - which makes sense since I never di that in the first place.
Very baffled.
Offline
Booted into arch again with the e1000 cable connected and suddenly do network. Was working the last boot. Noticed that e1000 driver was in the lsmod list, so beginning to think it has always been there, but I missed it on the visual search of the list. I should have piped it to an editor and made the software look for it - much more reliable.
Tried switching the cable to the other ethernet port, but still no network.
Next I rebooted with the cabel swicthed - e.g. on the forcedeth driver. This time I got the network, and it is over this connection I am posting right now. Both e1000 and forcedeth drivers show in the list.
This on again off again thing is perplexing. The error looks cyclic. But it does not look any more that it is ethernet driver related. Im beginning to thinks its something to do with device naming - this fits with the fact that all this trouble started after a udev update.
Unless I get a brainstorm soon, I might have to give this distro the flick until a later release. At this point Frugalware is having no similar problems, uses pacman too, is slackware based and seems otherwise ok. Shame - I was really beginning to like Arch.
8) 8)
Offline
The network functions on every other boot. Now it works, now it does'nt, now it works, etc.
No changes made to hardware config or software (conf files, etc).
Just using the Gnome restart function to reboot and the PC toggles automatically between the network not working and working.
This is a doozy!!!!!!!
:shock: :shock: :shock: :shock:
Offline
antiloaded wrote:I experinced the same.
I just rewrote the inittab file, and disabled OSS in modprobe.conf to load audio at startup.
That solved the problem
Can you show me how you did that? I cannot tell which part of the two lines I have in that file that need to be changed and in what way.
Thanks,
Hi,
Just comment them both so they look like this:
# install snd-pcm modprobe -i snd-pcm ; modprobe snd-pcm-oss ; true
# install snd-seq modprobe -i snd-seq ; modprobe snd-seq-oss ; true
Offline
The network functions on every other boot. Now it works, now it does'nt, now it works, etc.
No changes made to hardware config or software (conf files, etc).
Just using the Gnome restart function to reboot and the PC toggles automatically between the network not working and working.
This is a doozy!!!!!!!
:shock: :shock: :shock: :shock:
Can you try writing udev rules please ? see this
I think the name of the interfaces is changing on each startup, i had the same problem my wired and wireless were jumping around
[My Blog] | [My Repo] | [My AUR Packages]
Offline
FWIW, this is a common issue if you have two interfaces and no hardware (MAC) rules added to udev or the interface. If you don't use that onboard NIC, I'd just disable it in BIOS - that should take care of the issue. I have had this problem on many RHEL boxen at work, but adding a HWADDR statement to the interface fixes the problem nicely.
Udev rules are nice, and work very well, but I do have to admit that an "ethX" config with that statement in it is a little more transparent. Especially if you're inheriting the box from someone who thinks not documenting their network == job security.
Unthinking respect for authority is the greatest enemy of truth.
-Albert Einstein
Offline
This issue now well documented and in the wiki.
Relates to the fact that udev loads modules "simultaneously" at boot up, and due to timing variations two modules (e.g. network drivers) may load in a different sequence.
CLOSED
Offline