16.03.2012 14:45, Colin Guthrie kirjoitti: > 'Twas brillig, and Anssi Hannula at 16/03/12 03:45 did gyre and gimble: >> Hi all! >> >> So, I've just upgraded my home server to mga2/cauldron. >> >> Something seems fishy in the network.service handling, systemd thinks it >> has failed: >> >> # systemctl status network.service >> network.service - LSB: Bring up/down networking >> Loaded: loaded (/etc/rc.d/init.d/network) >> Active: failed (Result: exit-code) since Fri, 16 Mar 2012 >> 05:25:09 +0200; 11min ago >> CGroup: name=systemd:/system/network.service >> ├ 4679 /sbin/ifplugd -I -b -i eth0 >> ├ 4723 /sbin/ifplugd -I -b -i eth1 >> └ 5372 /sbin/dhclient -q -lf >> /var/lib/dhcp/dhclient-eth0.leases -pf /var/run/dhclient-eth0.pid -cf >> /etc/dhclient-eth0.conf... >> >> Mar 16 05:25:09 delta.onse.fi ifplugd(eth1)[4723]: Using detection mode: >> SIOCETHTOOL >> Mar 16 05:25:09 delta.onse.fi ifplugd(eth1)[4723]: Initialization >> complete, link beat not detected. >> Mar 16 05:25:09 delta.onse.fi network[4397]: [161B blob data] >> Mar 16 05:25:09 delta.onse.fi network[4397]: [14B blob data] >> Mar 16 05:25:13 delta.onse.fi ifplugd(eth0)[4679]: Link beat detected. >> Mar 16 05:25:14 delta.onse.fi ifplugd(eth0)[4679]: Executing >> '/etc/ifplugd/ifplugd.action eth0 up'. >> Mar 16 05:25:15 delta.onse.fi dhclient[5312]: DHCPREQUEST on eth0 to >> 255.255.255.255 port 67 >> Mar 16 05:25:15 delta.onse.fi dhclient[5312]: DHCPACK from 109.204.128.1 >> Mar 16 05:25:15 delta.onse.fi ifplugd(eth0)[4679]: client: Determining >> IP information for eth0... done. >> Mar 16 05:25:15 delta.onse.fi ifplugd(eth0)[4679]: Program executed >> successfully. >> >> >> Trying to restart it I seem to hit other issues: >> >> # systemctl restart network.service >> Job failed. See system journal and 'systemctl status' for details. >> # systemctl status network.service >> network.service - LSB: Bring up/down networking >> Loaded: loaded (/etc/rc.d/init.d/network) >> Active: failed (Result: exit-code) since Fri, 16 Mar 2012 >> 05:36:39 +0200; 3s ago >> Process: 8027 ExecStart=/etc/rc.d/init.d/network start >> (code=exited, status=1/FAILURE) >> CGroup: name=systemd:/system/network.service >> ├ 8195 /sbin/ifplugd -I -b -i eth0 >> └ 8353 /sbin/dhclient -q -lf >> /var/lib/dhcp/dhclient-eth0.leases -pf /var/run/dhclient-eth0.pid -cf >> /etc/dhclient-eth0.conf... >> >> Mar 16 05:36:39 delta.onse.fi network[8027]: RTNETLINK answers: File exists >> Mar 16 05:36:39 delta.onse.fi network[8027]: RTNETLINK answers: File exists >> Mar 16 05:36:39 delta.onse.fi network[8027]: RTNETLINK answers: File exists >> Mar 16 05:36:39 delta.onse.fi network[8027]: RTNETLINK answers: File exists >> Mar 16 05:36:39 delta.onse.fi dhclient[8261]: DHCPREQUEST on eth0 to >> 255.255.255.255 port 67 >> Mar 16 05:36:40 delta.onse.fi dhclient[8261]: DHCPACK from 109.204.128.1 >> Mar 16 05:36:40 delta.onse.fi ifplugd(eth0)[8195]: client: Determining >> IP information for eth0...NETLINK: Error: File exists >> Mar 16 05:36:40 delta.onse.fi ifplugd(eth0)[8195]: client: done. >> Mar 16 05:36:40 delta.onse.fi ifplugd(eth0)[8195]: client: NETLINK: >> Error: File exists >> Mar 16 05:36:40 delta.onse.fi ifplugd(eth0)[8195]: Program executed >> successfully. >> >> Any ideas? If not, I'll investigate this myself later. > > network.service fails here too, but I've not been able to work out > exactly why. It doens't bother me too much tho' as all my devices are > using network manager! > > THat said, it seems that network.service has still started an ifplugd > for my wlan, despite the ifcfg file clearly saying that NM should take > care of that interface... needs some investigating for sure. > > >> On a related note, I also got dropped to emergency console on first >> boot, not sure why was that (it didn't tell me the reason... maybe the >> reason was in another virtual console, but I didn't remember to check >> there at the time). I just exited the console and it continued to boot... > > Interesting. Was it a dracut shell or a systemd one? (sometimes hard to > tell which is which, but the text usually tells you.
I think it was a systemd one (it seemed to be quite late in the boot, when I exited it the next thing it did was build DKMS stuff). > Knowing which should help identify why. Does it happen on subsequent boots? No idea yet, but will reboot the system now. >> I see the following in systemctl --failed: >> >> # systemctl --failed >> UNIT LOAD ACTIVE SUB JOB DESCRIPTION >> bootparamd.service loaded ESC[1;31mfailed failedESC[0m >> SYSV: The bootparamd server allows older Sun workstations to net boot >> from Linux boxes. It (along with rarp) is rarely used anymore; bootp and >> dhcp have mostly replaced both of them. >> fedora-loadmodules.service loaded ESC[1;31mfailed failedESC[0m >> Load legacy module configuration > > dmorgan reported this as well, but it's a really simple script and > really shouldn't fail. > > I think it must be the /etc/rc.modules script that is likely failing > here. Perhaps trying to modprobe a module that no longer exists due to > old configuration? If possible can you debug the fedora-load-modules > service and comment out one half of the script such that only the > rc.modules bit is run and confirm that's where it's bust. Then maybe > work out what in rc.modules is broken. That woudl be useful as it works > fine here. Actually it is because /etc/modprobe.preload contains some non-existing modules (like psmouse), and /etc/modprobe.preload.d/cpufreq (cpufreq_performance). bootparamd failed because I had no /etc/bootparamd. I'm pretty sure I've not installed bootparamd myself, but it was a leaf package now so I simply removed it. >> network.service loaded ESC[1;31mfailed failedESC[0m >> LSB: Bring up/down networking > > Mentioned above. Needs to be debugged. > >> systemd-modules-load.service loaded ESC[1;31mfailed failedESC[0m >> Load Kernel Modules > > Yeah this one fails for me too. Not sure why, but maybe because I've > done something stupid and symlinked stuff into /etc/modules-load.d when > I shouldn't. I'll look into it. I guess this would be for the same reason as fedora-loadmodules.service... BTW, isn't this duplication? Well, I guess not completely, /etc/modules-load.d doesn't contain the stuff from /etc/modprobe.preload.d/, only /etc/modprobe.preload and /etc/modules. > > Incidentally, just answering your private tmp question from IRC... > > This is what Lennart had to say about it: > <mezcalero> coling: the /tmp dir used by PrivateTmp lies beneath /tmp > <mezcalero> coling: hence, if /tmp is cleaned up those private tmps will > be cleaned up too > <mezcalero> coling: since the clean-up is recursive Ah, clever. Though I should've recognized it was just a simple bind-mount... I'll blame my tiredness for this as well :) -- Anssi Hannula