Description of problem: Booting MGA6 on a recent Lenovo B50 (quadcore, 8 Gb memory) takes double the time than an old Acer D620 (single core , 1 Gb memory) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3.
Keywords: (none) => 6dev1
Maybe related to bug 17574 For the slow booting system, please attach journal.txt that is the result of running, as root: journalctl -ab > journal.txt
CC: (none) => marja11
Keywords: (none) => NEEDINFO
Created attachment 7581 [details] journal file
Btw, what is "double" the time? I see there's 5 minutes between mrt 18 10:11:08 mach5.hviaene.thuis sddm-greeter[3025]: Message received from daemon: HostName and mrt 18 10:16:46 mach5.hviaene.thuis sddm-greeter[3025]: Reading from "/usr/share/xsessions/01plasma.desktop" But I suppose that you had walked away from the system, or does it really take 7 minutes from starting the machine till seeing the login screen? Btw, there are 29 messages about a device having the /sda/sda4 sysfs path, but at the same time having /sda/sda7, or /sda/sda6, or /sda/sda5 sysfs path mrt 18 10:09:27 mach5.hviaene.thuis systemd[1]: dev-disk-by\x2dpartlabel-Basic\x5cx20data\x5cx20partition.device: Dev dev-disk-by\x2dpartlabel-Basic\x5cx20data\x5cx20partition.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda4 and /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda5 (See also https://github.com/systemd/systemd/issues/2677 ... another user, whose report was closed as a duplicate, said his system boots up very slowly https://github.com/systemd/systemd/issues/2705 ) But I don't know whether this can cause slow booting, CC'ing Colin
CC: (none) => mageia
I did not walk away from the system, it happens without any intervantion being possible. But I noted something different. I routinely install nntp at installation time (when the system asks for the time zone). In this journal there are items on time zone which I would not expect if this is handled correctly. I checked MCC and found there that the clock synchronization was not set. I ticked it on, and found that it that not ask for the nntp package to install. This i would expect if I had forgotten to tick it on at installation time. I set it on in MCC and since then boot time has improved quite a bit, but not to the same level as M5. In cas you might ask: the journal I attached to bug 18028 today is of the same system with currently nntp configured OK. Oh, about the disk partitions: this laptop has 4 running systems: Win 10 (having 4 partitions of its own), an M5 "production" having a / and a /home partition, an M5 for testing and this M6 for testing , so it might look a bit complicated. So AFAICS, the slow boot has to do with time zone settings, but that shouldn't have such effect I presume???
(In reply to Marja van Waes from comment #3) > Btw, what is "double" the time? > > I see there's 5 minutes between > mrt 18 10:11:08 mach5.hviaene.thuis sddm-greeter[3025]: Message received > from daemon: HostName > > and > > mrt 18 10:16:46 mach5.hviaene.thuis sddm-greeter[3025]: Reading from > "/usr/share/xsessions/01plasma.desktop" > > But I suppose that you had walked away from the system, or does it really > take 7 minutes from starting the machine till seeing the login screen? > > (In reply to Herman Viaene from comment #4) > I did not walk away from the system, it happens without any intervantion > being possible. > But I noted something different. I routinely install nntp at installation > time (when the system asks for the time zone). In this journal there are > items on time zone which I would not expect if this is handled correctly. you're right, the 5 minute hang between the sddm-greeter lines that I pasted happens here: mrt 18 10:11:28 mach5.hviaene.thuis systemd-timesyncd[783]: Synchronized to time server 216.239.34.15:123 (time2.google.com). mrt 18 10:16:44 mach5.hviaene.thuis chronyd[1010]: Can't synchronise: no majority > I checked MCC and found there that the clock synchronization was not set. I > ticked it on, and found that it that not ask for the nntp package to > install. This i would expect if I had forgotten to tick it on at > installation time. I set it on in MCC and since then boot time has improved > quite a bit, but not to the same level as M5. Ben hit this, too, see bug 17563 which is as good as certain a duplicate of bug 17091 <snip> > So AFAICS, the slow boot has to do with time zone settings, but that > shouldn't have such effect I presume??? Maybe sddm can't handle a problem there? CC'ing neoclust
@ neoclust What I meant is: can't sddm-greeter just continue, regardless of time problems?
(In reply to Marja van Waes from comment #6) > @ neoclust > > What I meant is: can't sddm-greeter just continue, regardless of time > problems? assigning to you, because, other than maybe closing as dup of bug 17091, I wouldn't know what to do with it :-þ
Keywords: NEEDINFO => (none)Assignee: bugsquad => mageia
Created attachment 8209 [details] Journal boot RC
This problem disappeared in the subsequent sta1 ISO's, but is back in RC, but not so extreme. You can see in the journalrc.txt that there are gaps at 14:34:31 and 14:34:56
Again in RC of 22 July. Journal boot.txt uploaded,showing jumps at 21:35:31 to 21:35:49 and immediately to 21:36:29.
Created attachment 8266 [details] journal of rc dd 22 july
(In reply to Herman Viaene from comment #11) > Created attachment 8266 [details] > journal of rc dd 22 july Thanks :-) At first sight, I see two sddm segfaults. There is nothing about systemd-timesyncd. Do you mind also attaching boot.svg, that is the result of running: systemd-analyze plot > boot.svg (Just to rule out that there's something that gives more delay than the sddm segfaults)
(In reply to Herman Viaene from comment #10) > Again in RC of 22 July. Journal boot.txt uploaded,showing jumps at 21:35:31 > to 21:35:49 and immediately to 21:36:29. Sorry, I missed this comment... so there's indeed a time consumer before sddm was started for the first time!
Those sddm segfaults are bug 17653, btw. Removing neoclust as assignee, because the time jumps aren't related.
Assignee: mageia => bugsquad
@ Herman Is this bug still valid? If so, do you mind replacing attaching a fresh "journalctl -ab" output?
Whiteboard: (none) => NEEDINFO
No, I haven't noticed such timings anymore with the latest sta's.
Status: NEW => RESOLVEDResolution: (none) => FIXED