Hello ! since the upgrade, my PC takes up to 5 minutes to start the internet. It used to be very quick. I think, that is a bug. I got some screenshots, which i attach https://abload.de/img/dsc_00000767vujn.jpg https://abload.de/img/dsc_0000078ctuyy.jpg
Hi Bunk Bunk, Thanks for your report. Please reproduce the problem and then attach the following files: * journalctl.txt that is the result of then running, as root: journalctl -b > journalctl.txt * dmesg.txt that is the result of running dmesg > dmesg.txt * lspci.txt that is the result of running lspcidrake -v > lspci.txt
Keywords: (none) => NEEDINFOCC: (none) => marja11
I saw this for the first dozen or so boots after a clean install of MGA6 as well, but it has since calmed down on its own. Reason unknown. The start job's time out is some crazy-long duration like 5 minutes 39 seconds. Usually the job would finish around the 3 minute mark, but other times it wouldn't finish at all. If Bunk Bunk is experiencing this on a laptop, this issue may have something to do with rfkill. In my case (on an HP Pavilion dv7 notebook with Intel 5100 AGN wireless card) I was seeing this behaviour not long -- or immediately after -- the boot message: Starting Load/Save RF Kill Switch Status In fact, rfkill was exhibiting some very strange behavior at first. Sometimes the machine would complete its boot after the 5-or-so-minute time out, but the network interface would be blocked. Each time I would need to go in as root to have rfkill open it up. Other times I would see the message above and the machine would just hang indefinitely. Toggling the wireless hardware switch would cause the above message to echo repeatedly, but it would never complete its startup. My only recourse was to force a shutdown by holding the power button and crossing my fingers that things would be better on the next boot. An odd thing I discovered while searching for my issue online was that the message *should* actually read: Starting Load/Save RF Kill Switch Status of <wireless-device-identifier> But it never did. It seemed as if perhaps rfkill couldn't find the device and was hanging because of that (?). Anyhow, as I said, I experienced this behaviour for the first day or two over the course of perhaps a dozen or so boots. After that it seems to have settled down of its own accord. Very strange, but I haven't seen the problem again for about a week now. The network is usually up within 20 seconds.
CC: (none) => johnltw
(In reply to Marja van Waes from comment #1) > Hi Bunk Bunk, > > Thanks for your report. > > Please reproduce the problem and then attach the following files: > > > * journalctl.txt that is the result of then running, as root: > journalctl -b > journalctl.txt > * dmesg.txt that is the result of running > dmesg > dmesg.txt > * lspci.txt that is the result of running > lspcidrake -v > lspci.txt __ OK, do i need to edit out something in the files for privacy reasons ? My PC took 5 minutes too, but has decreased by 50 % or so.
3 minutes 7
(In reply to Bunk Bunk from comment #3) > (In reply to Marja van Waes from comment #1) > > > > Please reproduce the problem and then attach the following files: > > > > > > * journalctl.txt that is the result of then running, as root: > > journalctl -b > journalctl.txt > > * dmesg.txt that is the result of running > > dmesg > dmesg.txt > > * lspci.txt that is the result of running > > lspcidrake -v > lspci.txt > > __ > > OK, do i need to edit out something in the files for privacy reasons ? > I don't know, they don't contain passwords and I have never deleted lines for privacy reasons from a journalctl log that I uploaded. However, I do remember having seen a list of videos in someone else's log (not in our Bugzilla) and wondering whether he wouldn't have preferred to delete those lines.
Created attachment 9635 [details] dmesg OK, here we go
CC: (none) => soccerhub
Created attachment 9636 [details] lspci +
Created attachment 9637 [details] journ journ
I had hoped the logs would show for which exact networking item "A start job is running", but grepping for that string returns nothing :-( You have two ethernet cards, right? r8169 : Realtek Semiconductor Co., Ltd.|RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller [NETWORK_ETHERNET] (vendor:10ec device:8136 subv:1631 subd:e038) (rev: 01) r8169 : Realtek Semiconductor Co., Ltd.|RTL8169 PCI Gigabit Ethernet Controller [NETWORK_ETHERNET] (vendor:10ec device:8169 subv:1799 subd:5005) (rev: 10) Whichever one is enp1s6 seems to come up fine and fast (unless I miss something), I fail to see that enp4s0 comes up Anyway, after : Aug 26 00:27:29 localhost.localdomain network[1217]: Schnittstelle »ppp0« aktivieren: Cannot find device "ppp0" The following is repeated several times, from 00:28:00 till 00:30:35, so during 155 seconds : network[1217]: LCP: timeout sending Config-Requests network[1217]: Connection terminated. network[1217]: Modem hangup network[1217]: Using interface ppp0 network[1217]: Connect: ppp0 <--> /dev/pts/2 network[1217]: pppoe: Timeout waiting for PADO packets until it ends with Aug 26 00:30:35 localhost.localdomain network[1217]: [FEHLER] (in English: "[FAILED]" That's 3 minutes 6 after network process 1217 started, which closely matches what you said in comment #4 : > 3 minutes 7 Does it help to attach your ppp0 or GPRS/Edge/3G *) device? Or does it help to not attach it, but to remove it with "drakconnect --del" http://doc.mageia.org/mcc/6/en/content/drakconnect--del.html *) There was a bug with GPRS/Edge/3G devices being shown as ppp0, so please try the above for your 3G-or-so device if that's what you used before instead of an analogue modem. https://bugs.mageia.org/show_bug.cgi?id=17827 CC'ing some more knowledgeable people than me in case I overlooked something important in your logs, and also because I don't think that if a device isn't present, that it should be tried to start it.... for the latter I don't know what/whom to assign this report to, though.
CC: (none) => basesystem, kernelSummary: Internet takes minutes to start => Internet takes minutes to start (the delay matches the time wasted on starting a "ppp0" device that's not present)
Jebus. Yes, i run only one ethernetcontroller. I can take it down. I have to read about that stuff and how to add ppp0
Is this bug still valid? If so, is one (which one?) or both of the suggestions in comment #9 a good workaround?
(In reply to Marja Van Waes from comment #11) > Is this bug still valid? > > If so, is one (which one?) or both of the suggestions in comment #9 a good > workaround? Not yet done, marja. May we keep it open for another day ?
We are now well into Mageia 7. Did you crack the problem? Do you still have it (if you are still with us)?
CC: (none) => lewyssmith
(In reply to Bunk Bunk from comment #12) > (In reply to Marja Van Waes from comment #11) > > Is this bug still valid? > > > > If so, is one (which one?) or both of the suggestions in comment #9 a good > > workaround? > > Not yet done, marja. May we keep it open for another day ? (In reply to Lewis Smith from comment #13) > We are now well into Mageia 7. Did you crack the problem? Do you still have > it (if you are still with us)? @ Bunk Bunk "another day" has become over a year and a half and you didn't reply to Lewis. We hope you are well. Also, this report was filed against Mageia 6, which is no longer supported. Therefore closing as OLD
Status: NEW => RESOLVEDResolution: (none) => OLD