Re: 3.16.x on i686
On Wed, 2014-06-25 at 16:16 -0500, Bruno Wolff III wrote: > On Wed, Jun 25, 2014 at 14:10:31 -0700, > Adam Williamson wrote: > >On Wed, 2014-06-25 at 15:09 -0500, Bruno Wolff III wrote: > >> On Wed, Jun 25, 2014 at 12:56:41 -0700, > >> Adam Williamson wrote: > >> > > >> >http://koji.fedoraproject.org/koji/taskinfo?taskID=7076318 > >> > > >> >assuming it builds successfully (AdamW Patching C: Take Cover!), if you > >> >could test with that it'd be good. > >> > >> I'm installing it now. Should be about 30 minutes before I get back to > >> you with results. > > > >Hum, you can probably skip it - the patch isn't exactly wrong, but it's > >also not exactly right and also not exactly sufficient. as you can > >probably tell, this is getting complicated... > >https://bugs.freedesktop.org/show_bug.cgi?id=80537 > > Well it made things better. The several services that were erroneously being > started are no getting started. Yeah, but it doesn't do what the code is actually *supposed* to do, which is make those services depend on network-online.target . It would also break some other things the code currently does correctly. > However on the first reboot after installation the shutdown hung. I powered > off rather than wait for a timeout, since this happens relatively often > with systemd updates. However the two times the system has come up, the > network service (I use that in preference to NM) did not come up properly > and I had to manually start it to have working network access. I don't think that has anything to do with my change, but it's kinda academic :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On 2014-06-25 16:50 (GMT-0400) Felix Miata composed: On 2014-06-25 12:53 (GMT-0700) Adam Williamson composed: Good spot - that may very well be your issue, yeah, since you're using a CRT display. It would also explain why I can't reproduce the bug on my Intel graphics system, which is a laptop. The i915G at least also puts to sleep my 1440x900 LCD TV and my 1600x1200 Dell LCD. Which gfxchip is in your laptop? And is its kernel i686? I'm half done now doing upgrade on 64 bit 4000 series -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Wed, Jun 25, 2014 at 14:10:31 -0700, Adam Williamson wrote: On Wed, 2014-06-25 at 15:09 -0500, Bruno Wolff III wrote: On Wed, Jun 25, 2014 at 12:56:41 -0700, Adam Williamson wrote: > >http://koji.fedoraproject.org/koji/taskinfo?taskID=7076318 > >assuming it builds successfully (AdamW Patching C: Take Cover!), if you >could test with that it'd be good. I'm installing it now. Should be about 30 minutes before I get back to you with results. Hum, you can probably skip it - the patch isn't exactly wrong, but it's also not exactly right and also not exactly sufficient. as you can probably tell, this is getting complicated... https://bugs.freedesktop.org/show_bug.cgi?id=80537 Well it made things better. The several services that were erroneously being started are no getting started. However on the first reboot after installation the shutdown hung. I powered off rather than wait for a timeout, since this happens relatively often with systemd updates. However the two times the system has come up, the network service (I use that in preference to NM) did not come up properly and I had to manually start it to have working network access. systemctl status network ● network.service - LSB: Bring up/down networking Loaded: loaded (/etc/rc.d/init.d/network) Active: inactive (dead) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Wed, 2014-06-25 at 15:09 -0500, Bruno Wolff III wrote: > On Wed, Jun 25, 2014 at 12:56:41 -0700, > Adam Williamson wrote: > > > >http://koji.fedoraproject.org/koji/taskinfo?taskID=7076318 > > > >assuming it builds successfully (AdamW Patching C: Take Cover!), if you > >could test with that it'd be good. > > I'm installing it now. Should be about 30 minutes before I get back to > you with results. Hum, you can probably skip it - the patch isn't exactly wrong, but it's also not exactly right and also not exactly sufficient. as you can probably tell, this is getting complicated... https://bugs.freedesktop.org/show_bug.cgi?id=80537 > >sysv-generator actually landed in systemd-214 (not 209 as I'd thought), > >so it makes sense that we're only just now seeing this bug crop up. > > Do we want a bug for the dangling symlink handling? It would be nice if > they got cleaned up automatically. Barring that, a different message > that made it clear you should remove them as the current message wasn't > all that obvious about what was going on. eh, I don't know if it's really systemd's job to go around cleaning up /etc/init.d , and if it might not possibly have unintended consequences in some weird case? might want to make it a devel@ or systemd mailing list kickaround rather than a bug report. Providing more useful log info might be worth a bug report though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On 2014-06-25 12:53 (GMT-0700) Adam Williamson composed: Good spot - that may very well be your issue, yeah, since you're using a CRT display. It would also explain why I can't reproduce the bug on my Intel graphics system, which is a laptop. The i915G at least also puts to sleep my 1440x900 LCD TV and my 1600x1200 Dell LCD. Which gfxchip is in your laptop? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Wed, Jun 25, 2014 at 12:56:41 -0700, Adam Williamson wrote: http://koji.fedoraproject.org/koji/taskinfo?taskID=7076318 assuming it builds successfully (AdamW Patching C: Take Cover!), if you could test with that it'd be good. I'm installing it now. Should be about 30 minutes before I get back to you with results. sysv-generator actually landed in systemd-214 (not 209 as I'd thought), so it makes sense that we're only just now seeing this bug crop up. Do we want a bug for the dangling symlink handling? It would be nice if they got cleaned up automatically. Barring that, a different message that made it clear you should remove them as the current message wasn't all that obvious about what was going on. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Tue, 2014-06-24 at 22:50 -0500, Bruno Wolff III wrote: > On Tue, Jun 24, 2014 at 19:22:05 -0700, > Adam Williamson wrote: > > > >The most obvious thing is whether you have a SXXservice symlink > >in /etc/rc*.d; that constitutes the service being 'enabled' so far as > >SysV is concerned, and so in that case it seems correct for systemd to > >enable the runtime-generated systemd service. But there may be other > >reasons why this might happen, I think we'd best look at them case by > >case. > > I filed a bug (https://bugzilla.redhat.com/show_bug.cgi?id=1112908) for > plague. Plague has both a systemd entry and an init.d file (but not > files for any run levels) for the plague-server service. That seems odd, > but I don't know if that is the cause of the problem. So I think I have a handle on what's causing the bug of sysv services starting when they're not supposed to - turns out to be (I think) a fairly subtle bug in the sysv-generator code, if I'm right, then I'm proud of myself for figuring it out :P See https://bugzilla.redhat.com/show_bug.cgi?id=1112908#c9 . I'm currently running a systemd scratch build which I hope is going to fix the problem: http://koji.fedoraproject.org/koji/taskinfo?taskID=7076318 assuming it builds successfully (AdamW Patching C: Take Cover!), if you could test with that it'd be good. sysv-generator actually landed in systemd-214 (not 209 as I'd thought), so it makes sense that we're only just now seeing this bug crop up. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Wed, 2014-06-25 at 14:59 -0400, Felix Miata wrote: > On 2014-06-25 10:08 (GMT-0700) Adam Williamson composed: > > > On Wed, 2014-06-25 at 10:05 -0700, Adam Williamson wrote: > > >> I'm curious: why are you passing video= parameters on each one? Do > >> any/all of them work if you don't pass that parameter? > > > ...and does it work if you append an 'e': > > > video=1024x768e > > video=1024x768@60e doesn't help. > > On 2014-06-25 14:12 (GMT-0400) Adam Williamson composed: > > > That answers the first question, but not the second (or the third I sent > > as a follow-up). > > I thought I provided answers to all, so I'm not sure what might be missing. > Omitting both vga= and video= doesn't change anything, That's what I was looking for, thanks. > which I thought I > wrote early on in thread, I don't know, but it's hard to remember everything that's been said! > but may be in the bug I didn't yet submit. > > OTOH, might what's described at > http://lists.freedesktop.org/archives/intel-gfx/2014-June/047981.html be an > upstream solution forthcoming? Good spot - that may very well be your issue, yeah, since you're using a CRT display. It would also explain why I can't reproduce the bug on my Intel graphics system, which is a laptop. I might be able to whip up a test kernel for you later with that patch applied. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On 2014-06-25 10:08 (GMT-0700) Adam Williamson composed: On Wed, 2014-06-25 at 10:05 -0700, Adam Williamson wrote: I'm curious: why are you passing video= parameters on each one? Do any/all of them work if you don't pass that parameter? ...and does it work if you append an 'e': video=1024x768e video=1024x768@60e doesn't help. On 2014-06-25 14:12 (GMT-0400) Adam Williamson composed: That answers the first question, but not the second (or the third I sent as a follow-up). I thought I provided answers to all, so I'm not sure what might be missing. Omitting both vga= and video= doesn't change anything, which I thought I wrote early on in thread, but may be in the bug I didn't yet submit. OTOH, might what's described at http://lists.freedesktop.org/archives/intel-gfx/2014-June/047981.html be an upstream solution forthcoming? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On 25.06.2014 20:10, Felix Miata wrote: On 2014-06-25 10:05 (GMT-0700) Adam Williamson composed: So...these are three different machines? 3 out of 14 on which Rawhide is currently installed (test machines total 20+) here, among which are represented various flavors of MGA (400 & 550), SiS (Z7/Z9 XG20 core), Intel (810, 815, 845, 865, 915, 945, 965, 3100, 4100), ATI (rv200, rv250, rv370, rv380, rv516) & NVidia for video. I'm curious: why are you passing video= parameters on each one? Do any/all of them work if you don't pass that parameter? Most of my test machines get used most of the time with a '21"' CRT with preferred mode 1600x1200 reported as preferred mode 1280x1024 used at approximately 175% of normal viewing distance. Avoiding eyestrain requires 1152x864 or lower on the vttys unless I want to monkey with terminal font reconfiguration from default. My second most used test machine display is a 19" LCD TV with native mode 1440x900 that reports preferred 1280x1024 but supports 4:3 modes up to 1792x1344. It is used at similar distance, so also needs 1024x768 on the vttys for the same reason as the CRT. I also have 2 15" 1024x768, 17" & 19" 1280x1024 and 20" 1600x1200 LCD puter displays, 2 31.5" TVs, and an abundance of other CRTs to use as test conditions require, in addition to the LCDs used for my 24/7 systems that can be briefly pressed into test service when necessary. # yum install terminus-fonts-console - permanent system wide /etc/vconsole.conf FONT= e.g. 'latarcyrheb-sun32' or 'ter-v32b' - runtime local $ setfont latarcyrheb-sun32 $ setfont ter-v32b poma -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On 25.06.2014 20:09, Adam Williamson wrote: On Wed, 2014-06-25 at 19:58 +0200, poma wrote: On 25.06.2014 19:08, Adam Williamson wrote: On Wed, 2014-06-25 at 10:05 -0700, Adam Williamson wrote: On Wed, 2014-06-25 at 12:02 -0400, Felix Miata wrote: On 2014-06-25 08:12 (GMT-0700) Adam Williamson composed: Where did you see "X initialization fails"? I've been booting with 3 on cmdline. Anyway, here's 2 of 3 drm.debug=15 dmesgs captured: http://fm.no-ip.com/Tmp/Linux/F/dmsgI865Gf21k316rc2g01.txt ^ Er...this seems to be the log from the hardware you describe in your bug comment, but: http://fm.no-ip.com/Tmp/Linux/F/dmsgI945Gf21k316rc2g01.txt ^ What is this from? On 2014-06-24 23:54 (GMT-0400) Felix Miata composed: It's repeatable ... on i865G, i915G and i945G And the one in the middle: http://fm.no-ip.com/Tmp/Linux/F/dmsgI915Gf21k316rc2g01.txt So...these are three different machines? I'm curious: why are you passing video= parameters on each one? Do any/all of them work if you don't pass that parameter? ...and does it work if you append an 'e': video=1024x768e ? "'e' will force the display to be enabled, i.e. it will override the detection if a display is connected." https://www.kernel.org/doc/Documentation/fb/modedb.txt Felix: "... Otherwise when init seems near completion, the screen goes black and stays that way. ..." Obviously the screen is detected and enabled, Sorry, but nope: the point where it fails may be the point where the intel kernel driver does hotplug detection. however failing at Xorg initialisation, That's what I thought at first, but it isn't. He's booting with '3', i.e. not to X. Whoops! I missed it, and I'm not surprised. At the "vdso" breakage I used # systemctl set-default multi-user.target poma -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Wed, 2014-06-25 at 14:10 -0400, Felix Miata wrote: > On 2014-06-25 10:05 (GMT-0700) Adam Williamson composed: > > > So...these are three different machines? > > 3 out of 14 on which Rawhide is currently installed (test machines total 20+) > here, among which are represented various flavors of MGA (400 & 550), SiS > (Z7/Z9 XG20 core), Intel (810, 815, 845, 865, 915, 945, 965, 3100, 4100), ATI > (rv200, rv250, rv370, rv380, rv516) & NVidia for video. > > > I'm curious: why are you passing video= parameters on each one? Do > > any/all of them work if you don't pass that parameter? > > Most of my test machines get used most of the time with a '21"' CRT with > preferred mode 1600x1200 reported as preferred mode 1280x1024 used at > approximately 175% of normal viewing distance. Avoiding eyestrain requires > 1152x864 or lower on the vttys unless I want to monkey with terminal font > reconfiguration from default. That answers the first question, but not the second (or the third I sent as a follow-up). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On 2014-06-25 10:05 (GMT-0700) Adam Williamson composed: So...these are three different machines? 3 out of 14 on which Rawhide is currently installed (test machines total 20+) here, among which are represented various flavors of MGA (400 & 550), SiS (Z7/Z9 XG20 core), Intel (810, 815, 845, 865, 915, 945, 965, 3100, 4100), ATI (rv200, rv250, rv370, rv380, rv516) & NVidia for video. I'm curious: why are you passing video= parameters on each one? Do any/all of them work if you don't pass that parameter? Most of my test machines get used most of the time with a '21"' CRT with preferred mode 1600x1200 reported as preferred mode 1280x1024 used at approximately 175% of normal viewing distance. Avoiding eyestrain requires 1152x864 or lower on the vttys unless I want to monkey with terminal font reconfiguration from default. My second most used test machine display is a 19" LCD TV with native mode 1440x900 that reports preferred 1280x1024 but supports 4:3 modes up to 1792x1344. It is used at similar distance, so also needs 1024x768 on the vttys for the same reason as the CRT. I also have 2 15" 1024x768, 17" & 19" 1280x1024 and 20" 1600x1200 LCD puter displays, 2 31.5" TVs, and an abundance of other CRTs to use as test conditions require, in addition to the LCDs used for my 24/7 systems that can be briefly pressed into test service when necessary. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Wed, 2014-06-25 at 19:58 +0200, poma wrote: > On 25.06.2014 19:08, Adam Williamson wrote: > > On Wed, 2014-06-25 at 10:05 -0700, Adam Williamson wrote: > >> On Wed, 2014-06-25 at 12:02 -0400, Felix Miata wrote: > >>> On 2014-06-25 08:12 (GMT-0700) Adam Williamson composed: > >>> > > Where did you see "X initialization fails"? I've been booting with 3 on > > cmdline. Anyway, here's 2 of 3 drm.debug=15 dmesgs captured: > >>> > > http://fm.no-ip.com/Tmp/Linux/F/dmsgI865Gf21k316rc2g01.txt > >>> ^ > >>> > Er...this seems to be the log from the hardware you describe in your bug > comment, but: > >>> > > http://fm.no-ip.com/Tmp/Linux/F/dmsgI945Gf21k316rc2g01.txt > >>> ^ > What is this from? > >>> > >>> On 2014-06-24 23:54 (GMT-0400) Felix Miata composed: > >>> > It's repeatable ... on i865G, i915G and i945G > >>> > >>> And the one in the middle: > >>> > >>> http://fm.no-ip.com/Tmp/Linux/F/dmsgI915Gf21k316rc2g01.txt > >> > >> So...these are three different machines? > >> > >> I'm curious: why are you passing video= parameters on each one? Do > >> any/all of them work if you don't pass that parameter? > > > > ...and does it work if you append an 'e': > > > > video=1024x768e > > > > ? > > > > "'e' will force the display to be enabled, i.e. it will override the detection > if a display is connected." > https://www.kernel.org/doc/Documentation/fb/modedb.txt > > Felix: > "... Otherwise when init seems near completion, the screen goes black and > stays that way. ..." > > Obviously the screen is detected and enabled, Sorry, but nope: the point where it fails may be the point where the intel kernel driver does hotplug detection. > however failing at Xorg initialisation, That's what I thought at first, but it isn't. He's booting with '3', i.e. not to X. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On 25.06.2014 19:08, Adam Williamson wrote: On Wed, 2014-06-25 at 10:05 -0700, Adam Williamson wrote: On Wed, 2014-06-25 at 12:02 -0400, Felix Miata wrote: On 2014-06-25 08:12 (GMT-0700) Adam Williamson composed: Where did you see "X initialization fails"? I've been booting with 3 on cmdline. Anyway, here's 2 of 3 drm.debug=15 dmesgs captured: http://fm.no-ip.com/Tmp/Linux/F/dmsgI865Gf21k316rc2g01.txt ^ Er...this seems to be the log from the hardware you describe in your bug comment, but: http://fm.no-ip.com/Tmp/Linux/F/dmsgI945Gf21k316rc2g01.txt ^ What is this from? On 2014-06-24 23:54 (GMT-0400) Felix Miata composed: It's repeatable ... on i865G, i915G and i945G And the one in the middle: http://fm.no-ip.com/Tmp/Linux/F/dmsgI915Gf21k316rc2g01.txt So...these are three different machines? I'm curious: why are you passing video= parameters on each one? Do any/all of them work if you don't pass that parameter? ...and does it work if you append an 'e': video=1024x768e ? "'e' will force the display to be enabled, i.e. it will override the detection if a display is connected." https://www.kernel.org/doc/Documentation/fb/modedb.txt Felix: "... Otherwise when init seems near completion, the screen goes black and stays that way. ..." Obviously the screen is detected and enabled, however failing at Xorg initialisation, i.e. Xorg failing at initialisation, display just follows. And "video" res shouldn't affect the whole scene. Certainly not in my case, however I don't use it plymouth. :) poma -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Wed, 2014-06-25 at 10:05 -0700, Adam Williamson wrote: > On Wed, 2014-06-25 at 12:02 -0400, Felix Miata wrote: > > On 2014-06-25 08:12 (GMT-0700) Adam Williamson composed: > > > > >> Where did you see "X initialization fails"? I've been booting with 3 on > > >> cmdline. Anyway, here's 2 of 3 drm.debug=15 dmesgs captured: > > > > >> http://fm.no-ip.com/Tmp/Linux/F/dmsgI865Gf21k316rc2g01.txt > > ^ > > > > > Er...this seems to be the log from the hardware you describe in your bug > > > comment, but: > > > > >> http://fm.no-ip.com/Tmp/Linux/F/dmsgI945Gf21k316rc2g01.txt > > ^ > > > What is this from? > > > > On 2014-06-24 23:54 (GMT-0400) Felix Miata composed: > > > > > It's repeatable ... on i865G, i915G and i945G > > > > And the one in the middle: > > > > http://fm.no-ip.com/Tmp/Linux/F/dmsgI915Gf21k316rc2g01.txt > > So...these are three different machines? > > I'm curious: why are you passing video= parameters on each one? Do > any/all of them work if you don't pass that parameter? ...and does it work if you append an 'e': video=1024x768e ? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Wed, 2014-06-25 at 12:02 -0400, Felix Miata wrote: > On 2014-06-25 08:12 (GMT-0700) Adam Williamson composed: > > >> Where did you see "X initialization fails"? I've been booting with 3 on > >> cmdline. Anyway, here's 2 of 3 drm.debug=15 dmesgs captured: > > >> http://fm.no-ip.com/Tmp/Linux/F/dmsgI865Gf21k316rc2g01.txt > ^ > > > Er...this seems to be the log from the hardware you describe in your bug > > comment, but: > > >> http://fm.no-ip.com/Tmp/Linux/F/dmsgI945Gf21k316rc2g01.txt > ^ > > What is this from? > > On 2014-06-24 23:54 (GMT-0400) Felix Miata composed: > > > It's repeatable ... on i865G, i915G and i945G > > And the one in the middle: > > http://fm.no-ip.com/Tmp/Linux/F/dmsgI915Gf21k316rc2g01.txt So...these are three different machines? I'm curious: why are you passing video= parameters on each one? Do any/all of them work if you don't pass that parameter? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On 2014-06-25 08:12 (GMT-0700) Adam Williamson composed: Where did you see "X initialization fails"? I've been booting with 3 on cmdline. Anyway, here's 2 of 3 drm.debug=15 dmesgs captured: http://fm.no-ip.com/Tmp/Linux/F/dmsgI865Gf21k316rc2g01.txt ^ Er...this seems to be the log from the hardware you describe in your bug comment, but: http://fm.no-ip.com/Tmp/Linux/F/dmsgI945Gf21k316rc2g01.txt ^ What is this from? On 2014-06-24 23:54 (GMT-0400) Felix Miata composed: It's repeatable ... on i865G, i915G and i945G And the one in the middle: http://fm.no-ip.com/Tmp/Linux/F/dmsgI915Gf21k316rc2g01.txt ^ -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Wed, Jun 25, 2014 at 11:12 PM, Adam Williamson wrote: >> http://fm.no-ip.com/Tmp/Linux/F/dmsgI945Gf21k316rc2g01.txt > > What is this from? Thanks. I think it's from dmesg. Yours sincerely, Christopher Meng Noob here. http://cicku.me -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Wed, 2014-06-25 at 09:06 -0400, Felix Miata wrote: > On 2014-06-24 23:34 (GMT-0700) Adam Williamson composed: > > >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1104371 > ... > >> Are you sure what I described in that bug is different? > > > > Well, it's impossible to be *sure* unless you provide the necessary > > logs, as I mentioned above. > > > No-one can pretend to absolute knowledge of what is happening if all the > > info we have to go on is "X initialization fails". > > Where did you see "X initialization fails"? I've been booting with 3 on > cmdline. Anyway, here's 2 of 3 drm.debug=15 dmesgs captured: > > http://fm.no-ip.com/Tmp/Linux/F/dmsgI865Gf21k316rc2g01.txt Er...this seems to be the log from the hardware you describe in your bug comment, but: > http://fm.no-ip.com/Tmp/Linux/F/dmsgI945Gf21k316rc2g01.txt What is this from? Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On 24.06.2014 21:56, Felix Miata wrote: On 2014-06-23 17:07 (GMT-0400) Felix Miata composed: On 2014-06-23 11:34 (GMT-0700) Adam Williamson composed: All 3.16 kernels before 3.16.0-0.rc2.git0.1 are just fundamentally broken on i686, I think, unless you pass 'vdso=0'. I wouldn't bother messing with anything unless you're using the rc2 kernel, or passing vdso=0. That doesn't help here: root=/dev/sda17 ipv6.disable=1 net.ifnames=0 KEYTABLE=us noplymouth selinux=0 noresume splash=verbose vga=791 video=1024x768@60 3 vdso=0 With Kernel 3.16.0-0.rc1.git4.1.fc21.i686+PAE on i865G I have to use telnet or ssh. Otherwise when init seems near completion, the screen goes black and stays that way. I commented in someone else's bug (and got scolded): https://bugzilla.redhat.com/show_bug.cgi?id=1104371 No improvement with Kernel 3.16.0-0.rc2.git0.1.fc21.i686+PAE with or without vdso=0. Until your X.Org X11 video module is resolved you can place "xdriver=modesetting" in the kernel command line. Besides check there is no an active "Driver" directive as part of the Section "Device" somewhere in /etc/X11/xorg.conf[.d/*.conf]. "modesetting" == "modesetting_drv.so" poma -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On 2014-06-24 23:34 (GMT-0700) Adam Williamson composed: >> https://bugzilla.redhat.com/show_bug.cgi?id=1104371 ... Are you sure what I described in that bug is different? Well, it's impossible to be *sure* unless you provide the necessary logs, as I mentioned above. No-one can pretend to absolute knowledge of what is happening if all the info we have to go on is "X initialization fails". Where did you see "X initialization fails"? I've been booting with 3 on cmdline. Anyway, here's 2 of 3 drm.debug=15 dmesgs captured: http://fm.no-ip.com/Tmp/Linux/F/dmsgI865Gf21k316rc2g01.txt http://fm.no-ip.com/Tmp/Linux/F/dmsgI945Gf21k316rc2g01.txt -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Wed, Jun 25, 2014 at 3:24 AM, Adam Williamson wrote: > On Tue, 2014-06-24 at 19:48 -0500, Bruno Wolff III wrote: >> On Mon, Jun 23, 2014 at 13:52:10 -0500, >> Bruno Wolff III wrote: >> >On Mon, Jun 23, 2014 at 11:34:53 -0700, >> > Adam Williamson wrote: >> >> >> >>All 3.16 kernels before 3.16.0-0.rc2.git0.1 are just fundamentally >> >>broken on i686, I think, unless you pass 'vdso=0'. I wouldn't bother >> >>messing with anything unless you're using the rc2 kernel, or passing >> >>vdso=0. >> > >> >I'll be testing that shortly on x86_64 and on i686 tonight. But I am >> >seeing two different problems and I'd be surprised if either was that >> >problem. I suspect I am not getting far enough into the boot to see >> >that problem. >> >> 3.16.0-0.rc2.git0.1 is pretty broken too. I am definitely seeing two >> other issues. > > Well, it's a pretty early one, so this isn't surprising. The 'special' > thing about the vdso bug is it was, AFAICT, more or less a complete > showstopper for the i686 kernel, regardless of hardware: it happened on > any system you tried to boot an i686 kernel on. > >> >The one affecting raid has been filed. The other one is a crash early >> >> It looks like this one might be elsewhere in the I/O stack. When I got >> a live image to boot, dd reported /dev/sda3 as zero size which would >> explain why the superblock was bad. blkid returned info about the device >> so this seems really odd. And it only seems to happen on this one >> partition. > > Yup, file the bugs and hopefully they'll be fixed rapidly :) We're seeing the same issue with ARM booting, we filed bug 1109603 [1] but it's some what intermittent. Peter [1] https://bugzilla.redhat.com/show_bug.cgi?id=1109603 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Tue, Jun 24, 2014 at 04:30:59PM -0700, Adam Williamson wrote: > > I think the "Could not find init script" errors are probably due to this > 'dangling symlink' problem, and the fact that .service files are being > generated is intentional - just the way systemd is handling remaining > sysv services - and not a bug. That looks to me like an obvious bug. Not a killer one but still. systemd does so many things that it could easily check that it attempts to handle a dangling symlink and skip it instead of going into, at least, some long and noisy spurious loop. It could even leave in logs something like "Warning: old dangling symlinks in subdirectories of /etc/init.d" and possibly suggest running 'symlinks -d /etc/init.d' (or maybe even kill these leftovers itself but that would be likely going too far). Michał -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Tue, 2014-06-24 at 23:54 -0400, Felix Miata wrote: > On 2014-06-24 15:13 (GMT-0700) Adam Williamson composed: > > >> https://bugzilla.redhat.com/show_bug.cgi?id=1104371 > > > Well, I wouldn't say scolded. Hans just asked you politely to file a new > > bug, since you have clearly different hardware. The Intel i8xx adapters > > are notoriously tricky hardware, and quite different from later Intel > > adapters. I'd say most likely yes, you're seeing a bug which is > > different from both the general i686 vdso bug *and* Filipe's intel video > > bug; so Hans is correct to ask you to file a new one. Please boot an > > affected kernel with 'drm.debug=15', allow the bug to happen, then > > either ssh in and grab the output of 'dmesg' or reboot to a working > > kernel and grab the output of 'journalctl -b-1' to attach to your bug. > > Are you sure what I described in that bug is different? Well, it's impossible to be *sure* unless you provide the necessary logs, as I mentioned above. No-one can pretend to absolute knowledge of what is happening if all the info we have to go on is "X initialization fails". -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On 2014-06-24 15:13 (GMT-0700) Adam Williamson composed: https://bugzilla.redhat.com/show_bug.cgi?id=1104371 Well, I wouldn't say scolded. Hans just asked you politely to file a new bug, since you have clearly different hardware. The Intel i8xx adapters are notoriously tricky hardware, and quite different from later Intel adapters. I'd say most likely yes, you're seeing a bug which is different from both the general i686 vdso bug *and* Filipe's intel video bug; so Hans is correct to ask you to file a new one. Please boot an affected kernel with 'drm.debug=15', allow the bug to happen, then either ssh in and grab the output of 'dmesg' or reboot to a working kernel and grab the output of 'journalctl -b-1' to attach to your bug. Are you sure what I described in that bug is different? It's repeatable with http://mirrors.us.kernel.org/fedora/development/rawhide/i386/os/Packages/k/kernel-PAE-3.16.0-0.rc2.git0.1.fc21.i686.rpm on i865G, i915G and i945G, but not rv200 Radeon. I've filled in a new bug page, except I've not decided what to put in its summary, if it warrants subjecting to the triagers at all. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Tue, Jun 24, 2014 at 19:22:05 -0700, Adam Williamson wrote: The most obvious thing is whether you have a SXXservice symlink in /etc/rc*.d; that constitutes the service being 'enabled' so far as SysV is concerned, and so in that case it seems correct for systemd to enable the runtime-generated systemd service. But there may be other reasons why this might happen, I think we'd best look at them case by case. I filed a bug (https://bugzilla.redhat.com/show_bug.cgi?id=1112908) for plague. Plague has both a systemd entry and an init.d file (but not files for any run levels) for the plague-server service. That seems odd, but I don't know if that is the cause of the problem. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Tue, 2014-06-24 at 19:48 -0500, Bruno Wolff III wrote: > On Mon, Jun 23, 2014 at 13:52:10 -0500, > Bruno Wolff III wrote: > >On Mon, Jun 23, 2014 at 11:34:53 -0700, > > Adam Williamson wrote: > >> > >>All 3.16 kernels before 3.16.0-0.rc2.git0.1 are just fundamentally > >>broken on i686, I think, unless you pass 'vdso=0'. I wouldn't bother > >>messing with anything unless you're using the rc2 kernel, or passing > >>vdso=0. > > > >I'll be testing that shortly on x86_64 and on i686 tonight. But I am > >seeing two different problems and I'd be surprised if either was that > >problem. I suspect I am not getting far enough into the boot to see > >that problem. > > 3.16.0-0.rc2.git0.1 is pretty broken too. I am definitely seeing two > other issues. Well, it's a pretty early one, so this isn't surprising. The 'special' thing about the vdso bug is it was, AFAICT, more or less a complete showstopper for the i686 kernel, regardless of hardware: it happened on any system you tried to boot an i686 kernel on. > >The one affecting raid has been filed. The other one is a crash early > > It looks like this one might be elsewhere in the I/O stack. When I got > a live image to boot, dd reported /dev/sda3 as zero size which would > explain why the superblock was bad. blkid returned info about the device > so this seems really odd. And it only seems to happen on this one > partition. Yup, file the bugs and hopefully they'll be fixed rapidly :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Tue, 2014-06-24 at 19:45 -0500, Bruno Wolff III wrote: > On Tue, Jun 24, 2014 at 16:30:59 -0700, > Adam Williamson wrote: > > > >I think the "Could not find init script" errors are probably due to this > >'dangling symlink' problem, and the fact that .service files are being > >generated is intentional - just the way systemd is handling remaining > >sysv services - and not a bug. That's my reading on the situation > >anyway. You should find the generated .service files match the remaining > >sysv services you have in /etc/init.d ; that's the case for me: > > Thanks, that helped me get rid of extraneous boot output. > > I used: > rm -vf `find -L /etc/rc.d -lname '*'` > to remove these sym links. Tip: symlinks -d ./ > However this didn't solve my concern about some services attempting to > start that shouldn't. Yeah, like I said, the 'could not find init script' output and the generated services appear to be different issues. It seems that the generator stuff causes network.service to be run, for me. It creates a directory called /run/systemd/generator.late/network-online.target.wants and symlinks network.service in there - i.e. it's saying that network.service should be run as a part of the target network-online.target . I'm not sure if this is correct, or a bug. I'll have to talk to the systemd devs about it. I think we'd have to look into each specific case of a service being run to figure out exactly why - it'd help to see your entire /run/systemd/generator.late tree, for a start. > But now I'm thinking there might be some other > old config around that I should look for. I'm going to start with > plague-server since I never actually used that, but might have had to > disable it in the past. The most obvious thing is whether you have a SXXservice symlink in /etc/rc*.d; that constitutes the service being 'enabled' so far as SysV is concerned, and so in that case it seems correct for systemd to enable the runtime-generated systemd service. But there may be other reasons why this might happen, I think we'd best look at them case by case. dropping kernel list from CC, I don't think it wants these messages. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Mon, Jun 23, 2014 at 13:52:10 -0500, Bruno Wolff III wrote: On Mon, Jun 23, 2014 at 11:34:53 -0700, Adam Williamson wrote: All 3.16 kernels before 3.16.0-0.rc2.git0.1 are just fundamentally broken on i686, I think, unless you pass 'vdso=0'. I wouldn't bother messing with anything unless you're using the rc2 kernel, or passing vdso=0. I'll be testing that shortly on x86_64 and on i686 tonight. But I am seeing two different problems and I'd be surprised if either was that problem. I suspect I am not getting far enough into the boot to see that problem. 3.16.0-0.rc2.git0.1 is pretty broken too. I am definitely seeing two other issues. The one affecting raid has been filed. The other one is a crash early It looks like this one might be elsewhere in the I/O stack. When I got a live image to boot, dd reported /dev/sda3 as zero size which would explain why the superblock was bad. blkid returned info about the device so this seems really odd. And it only seems to happen on this one partition. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Tue, Jun 24, 2014 at 16:30:59 -0700, Adam Williamson wrote: I think the "Could not find init script" errors are probably due to this 'dangling symlink' problem, and the fact that .service files are being generated is intentional - just the way systemd is handling remaining sysv services - and not a bug. That's my reading on the situation anyway. You should find the generated .service files match the remaining sysv services you have in /etc/init.d ; that's the case for me: Thanks, that helped me get rid of extraneous boot output. I used: rm -vf `find -L /etc/rc.d -lname '*'` to remove these sym links. However this didn't solve my concern about some services attempting to start that shouldn't. But now I'm thinking there might be some other old config around that I should look for. I'm going to start with plague-server since I never actually used that, but might have had to disable it in the past. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Tue, 2014-06-24 at 19:52 -0400, Felix Miata wrote: > On 2014-06-24 16:35 (GMT-0700) Adam Williamson composed: > > > I'm using Firefox. The version field is a bit further down the form than > > you might be looking, perhaps? > > That's it, a list made obtuse by so many things in between out of logical > order, and populated by a big bunch of lines with single digits beginning > with 1 (instead of e.g. most recent versions at top). Bugzilla.novell.com has > a nice workaround for the illogical order: after first selecting openSUSE, > one sees in the product list such names as openSUSE 13.1, openSUSE 12.3, > openSUSE 12.2 So...it's kind of a mess. Bugzilla was really designed to be deployed as one instance per "software project", specifically, one-instance-per-Mozilla-browser. And then some years passed, and now we're here. :P bugzilla.redhat.com is a single bugzilla instance for two Linux distributions, a middleware stack, a couple of clouds, several virtualization systems, and Pete only knows what else. If Red Hat sprang into existence tomorrow with its current product range, we probably wouldn't create a single bugzilla instance and stuff all those products into it. We almost certainly wouldn't use quite the hierarchy we're currently saddled with. But the whole thing evolved sort of organically over the years, and it's rather difficult to change. I don't think we could easily switch over from having "Fedora" as a product with multiple versions to having multiple Fedora "products", and I'm not sure that would necessarily be a good change in all respects anyway. It is possible to tweak things in RHBZ to improve the experience, but you have to be quite careful to consider the impacts on *everything else in RHBZ*, so it all happens quite slowly, and is unfortunately quite internal to Red Hat. Every so often we kick around the idea of splitting Fedora out from RHBZ and getting its own BZ instance or using a different tracker, but it never quite happens...just one of those things, I guess :/ -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On 2014-06-24 16:35 (GMT-0700) Adam Williamson composed: I'm using Firefox. The version field is a bit further down the form than you might be looking, perhaps? That's it, a list made obtuse by so many things in between out of logical order, and populated by a big bunch of lines with single digits beginning with 1 (instead of e.g. most recent versions at top). Bugzilla.novell.com has a nice workaround for the illogical order: after first selecting openSUSE, one sees in the product list such names as openSUSE 13.1, openSUSE 12.3, openSUSE 12.2 -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Tue, 2014-06-24 at 19:33 -0400, Felix Miata wrote: > On 2014-06-24 16:12 (GMT-0700) Adam Williamson composed: > > >> I've been avoiding that lately because I search for an existing bug first, > >> and someone's wisdom has seen fit to make that unduly difficult by > >> excluding > >> any option in the product list to select a particular release or Rawhide > >> rather than simply "Fedora" (from a list totaling merely 5 items). > > > Eh? No, it hasn't. The two are separate fields. Fedora is the "Product". > > rawhide or 20 or 19 is the "version". You have to click the "Refresh > > Components/Versions/Releases/Milestones" button after selecting Fedora > > as the "Classification" and "Product", and then the correct options will > > be available. (Bugzilla isn't web 2.0-y enough to refresh it > > automatically). > > Does one need to be running Chrom* or Konq to be offered any versions to > select from? Hitting the refresh button produces no observable page change in > SM rv29 or FF rv28. I'm using Firefox. The version field is a bit further down the form than you might be looking, perhaps? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On 2014-06-24 16:12 (GMT-0700) Adam Williamson composed: I've been avoiding that lately because I search for an existing bug first, and someone's wisdom has seen fit to make that unduly difficult by excluding any option in the product list to select a particular release or Rawhide rather than simply "Fedora" (from a list totaling merely 5 items). Eh? No, it hasn't. The two are separate fields. Fedora is the "Product". rawhide or 20 or 19 is the "version". You have to click the "Refresh Components/Versions/Releases/Milestones" button after selecting Fedora as the "Classification" and "Product", and then the correct options will be available. (Bugzilla isn't web 2.0-y enough to refresh it automatically). Does one need to be running Chrom* or Konq to be offered any versions to select from? Hitting the refresh button produces no observable page change in SM rv29 or FF rv28. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Tue, 2014-06-24 at 16:13 -0700, Adam Williamson wrote: > On Wed, 2014-06-25 at 00:11 +0100, Peter Robinson wrote: > > >> >BTW, Adam, there are people running & testing Rawhide on i686! :) > > >> > > >> Yes, and I am backlogged getting bugs filed for issues I am having. > > >> I have at least two different problems with 3.16 kernels that make them > > >> unusable for me. > > >> > > >> There might be a problem with systemd creating init files for a bunch of > > >> services, since I am now seeing some services attempt to start at boot, > > >> that I can't disable. > > > > > > systemd doesn't just 'create init files', I don't think. It *does* have > > > a concept of dependencies, which could account for this effect. > > > > I'm seeing it, at least appear, to do something like this. There's a > > new binary, at least since systemd-208 in F-20 (sorry, shitty hotel > > wifi makes it too hard to do wider triage) called: > > > > /usr/lib/systemd/system-generators/systemd-sysv-generator > > > > > What services exactly are you talking about? > > > > I'm seeing the following style of messages in dmesg. The following is > > a sample but wc tells me there's 343 entries: > > > > [44437.200793] systemd-sysv-generator[24124]: Could not find init > > script for radvd.service > > [44437.200810] systemd-sysv-generator[24124]: Could not find init > > script for ebtables.service > > [44437.200814] systemd-sysv-generator[24124]: Could not find init > > script for oddjobd.service > > [44437.200818] systemd-sysv-generator[24124]: Could not find init > > script for spice-vdagentd.service > > [44437.200822] systemd-sysv-generator[24124]: Could not find init > > script for livesys-late.service > > [44437.200826] systemd-sysv-generator[24124]: Could not find init > > script for tcsd.service > > [44437.200831] systemd-sysv-generator[24124]: Could not find init > > script for livesys.service > > [44437.200837] systemd-sysv-generator[24124]: Could not find init > > script for radvd.service > > > > I can dig further if necessary in the next few days, I'm travelling at > > the moment and $dayjob is a bit intense so time is limited in the > > short term :( > > Huh, well that's interesting. I guess I'll look into it. So, I looked, and found: http://cgit.freedesktop.org/systemd/systemd/commit/src/sysv-generator?id=95ed3294c632f5606327149f10cef1eb34422862 if I'm reading that correctly, I think this is basically the way systemd is now handling legacy sysv initscripts - by generating systemd units for them in a transient directory (/run/systemd/generator.late) on the fly at boot time. That particular error is from the set_dependencies_from_rcnd function. I'm finding myself too dumb to figure out exactly what the generator is trying to do at that point, but I do notice that on my Rawhide system - which is pretty old, old enough to have been sysv at one point - I have a whole ton of dangling symlinks to old initscripts in /etc/rc*.d/, and at a glance, the "Could not find init script for foo.service" messages in my logs map quite nicely to all those dangling symlinks. I suspect if I cleaned them all up, the messages would go away. I think the "Could not find init script" errors are probably due to this 'dangling symlink' problem, and the fact that .service files are being generated is intentional - just the way systemd is handling remaining sysv services - and not a bug. That's my reading on the situation anyway. You should find the generated .service files match the remaining sysv services you have in /etc/init.d ; that's the case for me: [adamw@adam isos]$ ls /etc/init.d/ functions livesys-late network vboxadd vboxadd-x11 livesysnetconsoleREADME vboxadd-service [adamw@adam isos]$ ls /run/systemd/generator.late/ livesys-late.service network-online.target.wants vboxadd-service.service livesys.service network.service vboxadd-x11.service netconsole.servicevboxadd.service -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Wed, 2014-06-25 at 00:11 +0100, Peter Robinson wrote: > >> >BTW, Adam, there are people running & testing Rawhide on i686! :) > >> > >> Yes, and I am backlogged getting bugs filed for issues I am having. > >> I have at least two different problems with 3.16 kernels that make them > >> unusable for me. > >> > >> There might be a problem with systemd creating init files for a bunch of > >> services, since I am now seeing some services attempt to start at boot, > >> that I can't disable. > > > > systemd doesn't just 'create init files', I don't think. It *does* have > > a concept of dependencies, which could account for this effect. > > I'm seeing it, at least appear, to do something like this. There's a > new binary, at least since systemd-208 in F-20 (sorry, shitty hotel > wifi makes it too hard to do wider triage) called: > > /usr/lib/systemd/system-generators/systemd-sysv-generator > > > What services exactly are you talking about? > > I'm seeing the following style of messages in dmesg. The following is > a sample but wc tells me there's 343 entries: > > [44437.200793] systemd-sysv-generator[24124]: Could not find init > script for radvd.service > [44437.200810] systemd-sysv-generator[24124]: Could not find init > script for ebtables.service > [44437.200814] systemd-sysv-generator[24124]: Could not find init > script for oddjobd.service > [44437.200818] systemd-sysv-generator[24124]: Could not find init > script for spice-vdagentd.service > [44437.200822] systemd-sysv-generator[24124]: Could not find init > script for livesys-late.service > [44437.200826] systemd-sysv-generator[24124]: Could not find init > script for tcsd.service > [44437.200831] systemd-sysv-generator[24124]: Could not find init > script for livesys.service > [44437.200837] systemd-sysv-generator[24124]: Could not find init > script for radvd.service > > I can dig further if necessary in the next few days, I'm travelling at > the moment and $dayjob is a bit intense so time is limited in the > short term :( Huh, well that's interesting. I guess I'll look into it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Tue, 2014-06-24 at 19:01 -0400, Felix Miata wrote: > On 2014-06-24 15:13 (GMT-0700) Adam Williamson composed: > > > Hans just asked you politely to file a new bug > > I've been avoiding that lately because I search for an existing bug first, > and someone's wisdom has seen fit to make that unduly difficult by excluding > any option in the product list to select a particular release or Rawhide > rather than simply "Fedora" (from a list totaling merely 5 items). Eh? No, it hasn't. The two are separate fields. Fedora is the "Product". rawhide or 20 or 19 is the "version". You have to click the "Refresh Components/Versions/Releases/Milestones" button after selecting Fedora as the "Classification" and "Product", and then the correct options will be available. (Bugzilla isn't web 2.0-y enough to refresh it automatically). > OTOH, the > component list with a gazillion items to search through only shows 6.5 at a > time, almost as bad as Windows' idiotic tiny window lists showing 3 out of > many. Yeah, that's annoying. > Why? Because Bugzilla. But, try: https://bugz.fedoraproject.org/xorg-x11-drv-intel for a handy shortcut. > Is Fedora overwhelmed by people available to do triage? Oh, if only. Still, there's probably a fairly small number of people running i8xx hardware on Rawhide at this point. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
>> >BTW, Adam, there are people running & testing Rawhide on i686! :) >> >> Yes, and I am backlogged getting bugs filed for issues I am having. >> I have at least two different problems with 3.16 kernels that make them >> unusable for me. >> >> There might be a problem with systemd creating init files for a bunch of >> services, since I am now seeing some services attempt to start at boot, >> that I can't disable. > > systemd doesn't just 'create init files', I don't think. It *does* have > a concept of dependencies, which could account for this effect. I'm seeing it, at least appear, to do something like this. There's a new binary, at least since systemd-208 in F-20 (sorry, shitty hotel wifi makes it too hard to do wider triage) called: /usr/lib/systemd/system-generators/systemd-sysv-generator > What services exactly are you talking about? I'm seeing the following style of messages in dmesg. The following is a sample but wc tells me there's 343 entries: [44437.200793] systemd-sysv-generator[24124]: Could not find init script for radvd.service [44437.200810] systemd-sysv-generator[24124]: Could not find init script for ebtables.service [44437.200814] systemd-sysv-generator[24124]: Could not find init script for oddjobd.service [44437.200818] systemd-sysv-generator[24124]: Could not find init script for spice-vdagentd.service [44437.200822] systemd-sysv-generator[24124]: Could not find init script for livesys-late.service [44437.200826] systemd-sysv-generator[24124]: Could not find init script for tcsd.service [44437.200831] systemd-sysv-generator[24124]: Could not find init script for livesys.service [44437.200837] systemd-sysv-generator[24124]: Could not find init script for radvd.service I can dig further if necessary in the next few days, I'm travelling at the moment and $dayjob is a bit intense so time is limited in the short term :( Peter -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On 2014-06-24 15:13 (GMT-0700) Adam Williamson composed: Hans just asked you politely to file a new bug I've been avoiding that lately because I search for an existing bug first, and someone's wisdom has seen fit to make that unduly difficult by excluding any option in the product list to select a particular release or Rawhide rather than simply "Fedora" (from a list totaling merely 5 items). OTOH, the component list with a gazillion items to search through only shows 6.5 at a time, almost as bad as Windows' idiotic tiny window lists showing 3 out of many. Why? Is Fedora overwhelmed by people available to do triage? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Mon, 2014-06-23 at 17:07 -0400, Felix Miata wrote: > On 2014-06-23 11:34 (GMT-0700) Adam Williamson composed: > > > All 3.16 kernels before 3.16.0-0.rc2.git0.1 are just fundamentally > > broken on i686, I think, unless you pass 'vdso=0'. I wouldn't bother > > messing with anything unless you're using the rc2 kernel, or passing > > vdso=0. > > That doesn't help here: > > root=/dev/sda17 ipv6.disable=1 net.ifnames=0 KEYTABLE=us noplymouth selinux=0 > noresume splash=verbose vga=791 video=1024x768@60 3 vdso=0 > > With Kernel 3.16.0-0.rc1.git4.1.fc21.i686+PAE on i865G I have to use telnet > or ssh. Otherwise when init seems near completion, the screen goes black and > stays that way. I commented in someone else's bug (and got scolded): > https://bugzilla.redhat.com/show_bug.cgi?id=1104371 Well, I wouldn't say scolded. Hans just asked you politely to file a new bug, since you have clearly different hardware. The Intel i8xx adapters are notoriously tricky hardware, and quite different from later Intel adapters. I'd say most likely yes, you're seeing a bug which is different from both the general i686 vdso bug *and* Filipe's intel video bug; so Hans is correct to ask you to file a new one. Please boot an affected kernel with 'drm.debug=15', allow the bug to happen, then either ssh in and grab the output of 'dmesg' or reboot to a working kernel and grab the output of 'journalctl -b-1' to attach to your bug. Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On 2014-06-23 17:07 (GMT-0400) Felix Miata composed: On 2014-06-23 11:34 (GMT-0700) Adam Williamson composed: All 3.16 kernels before 3.16.0-0.rc2.git0.1 are just fundamentally broken on i686, I think, unless you pass 'vdso=0'. I wouldn't bother messing with anything unless you're using the rc2 kernel, or passing vdso=0. That doesn't help here: root=/dev/sda17 ipv6.disable=1 net.ifnames=0 KEYTABLE=us noplymouth selinux=0 noresume splash=verbose vga=791 video=1024x768@60 3 vdso=0 With Kernel 3.16.0-0.rc1.git4.1.fc21.i686+PAE on i865G I have to use telnet or ssh. Otherwise when init seems near completion, the screen goes black and stays that way. I commented in someone else's bug (and got scolded): https://bugzilla.redhat.com/show_bug.cgi?id=1104371 No improvement with Kernel 3.16.0-0.rc2.git0.1.fc21.i686+PAE with or without vdso=0. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On 2014-06-23 11:34 (GMT-0700) Adam Williamson composed: All 3.16 kernels before 3.16.0-0.rc2.git0.1 are just fundamentally broken on i686, I think, unless you pass 'vdso=0'. I wouldn't bother messing with anything unless you're using the rc2 kernel, or passing vdso=0. That doesn't help here: root=/dev/sda17 ipv6.disable=1 net.ifnames=0 KEYTABLE=us noplymouth selinux=0 noresume splash=verbose vga=791 video=1024x768@60 3 vdso=0 With Kernel 3.16.0-0.rc1.git4.1.fc21.i686+PAE on i865G I have to use telnet or ssh. Otherwise when init seems near completion, the screen goes black and stays that way. I commented in someone else's bug (and got scolded): https://bugzilla.redhat.com/show_bug.cgi?id=1104371 -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On 23.06.2014 20:44, Bruno Wolff III wrote:
On Mon, Jun 23, 2014 at 20:10:32 +0200,
poma wrote:
You're talking about systemd-214-3.fc21(2014-06-23), right?
systemd-214-2.fc21
I haven't tested systemd-214-3.fc21 yet to see if the problem is still there.
I'm spinning md1, what worries you there?
https://bugzilla.redhat.com/show_bug.cgi?id=442
# mdadm --examine /dev/sd[az][0-9]|grep 'Level\|'^\ *State''|awk '{print
$1,$3,$4}'|sort|uniq
Raid : raid1
State clean
# uname -r
3.16.0-0.rc2.git0.1.fc21.x86_64
poma
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Mon, Jun 23, 2014 at 11:34:53 -0700, Adam Williamson wrote: systemd doesn't just 'create init files', I don't think. It *does* have a concept of dependencies, which could account for this effect. Something is creating ones during boot since about a month ago. They are in a scratch location that gets recreated each boot. What services exactly are you talking about? Plague is one example. I also seem to have a selinux problem blocking consolekit so that sound doesn't work in enforcing mode. What desktop are you using? It'd be good if you could file the bug for this, filing SELinux denials via sealert is pretty fast. XFCE. So far I am just working on the kernel change that seems to have md being more picky about md raid1 superblocks and just doing workarounds for the rest. All 3.16 kernels before 3.16.0-0.rc2.git0.1 are just fundamentally broken on i686, I think, unless you pass 'vdso=0'. I wouldn't bother messing with anything unless you're using the rc2 kernel, or passing vdso=0. I'll be testing that shortly on x86_64 and on i686 tonight. But I am seeing two different problems and I'd be surprised if either was that problem. I suspect I am not getting far enough into the boot to see that problem. The one affecting raid has been filed. The other one is a crash early in boot, and I thought I had heard there were some nouveau regressions and that could affect that machine. I need to get netconsole setup again to capture the crash dump, but have given it lower priority because it seems like something others are likely to run into. The raid thing is weird in that it affects only one of my raid devices. And there may be something odd about the superblock, that gets checked more carefully in 3.16, than 3.15. Though I didn't see any commits that indicated a change in md raid superblock checking recently. I have an upstream bug filed for that as well. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Mon, Jun 23, 2014 at 20:10:32 +0200, poma wrote: You're talking about systemd-214-3.fc21(2014-06-23), right? systemd-214-2.fc21 I haven't tested systemd-214-3.fc21 yet to see if the problem is still there. I'm spinning md1, what worries you there? https://bugzilla.redhat.com/show_bug.cgi?id=442 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Mon, 2014-06-23 at 12:36 -0500, Bruno Wolff III wrote: > On Mon, Jun 23, 2014 at 19:13:36 +0200, > poma wrote: > > > >BTW, Adam, there are people running & testing Rawhide on i686! :) > > Yes, and I am backlogged getting bugs filed for issues I am having. > I have at least two different problems with 3.16 kernels that make them > unusable for me. > > There might be a problem with systemd creating init files for a bunch of > services, since I am now seeing some services attempt to start at boot, > that I can't disable. systemd doesn't just 'create init files', I don't think. It *does* have a concept of dependencies, which could account for this effect. What services exactly are you talking about? > I also seem to have a selinux problem blocking consolekit so that sound > doesn't work in enforcing mode. What desktop are you using? It'd be good if you could file the bug for this, filing SELinux denials via sealert is pretty fast. > So far I am just working on the kernel change that seems to have md being > more picky about md raid1 superblocks and just doing workarounds for the > rest. All 3.16 kernels before 3.16.0-0.rc2.git0.1 are just fundamentally broken on i686, I think, unless you pass 'vdso=0'. I wouldn't bother messing with anything unless you're using the rc2 kernel, or passing vdso=0. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On 06/23/2014 07:36 PM, Bruno Wolff III wrote: On Mon, Jun 23, 2014 at 19:13:36 +0200, poma wrote: BTW, Adam, there are people running & testing Rawhide on i686! :) Yes, and I am backlogged getting bugs filed for issues I am having. I have at least two different problems with 3.16 kernels that make them unusable for me. There might be a problem with systemd creating init files for a bunch of services, since I am now seeing some services attempt to start at boot, that I can't disable. I also seem to have a selinux problem blocking consolekit so that sound doesn't work in enforcing mode. So far I am just working on the kernel change that seems to have md being more picky about md raid1 superblocks and just doing workarounds for the rest. I don't use ConsoleKit, nor do I need it. And is it supposed to be depreciated & outdated? You're talking about systemd-214-3.fc21(2014-06-23), right? I'm spinning md1, what worries you there? poma -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Mon, Jun 23, 2014 at 19:13:36 +0200, poma wrote: BTW, Adam, there are people running & testing Rawhide on i686! :) Yes, and I am backlogged getting bugs filed for issues I am having. I have at least two different problems with 3.16 kernels that make them unusable for me. There might be a problem with systemd creating init files for a bunch of services, since I am now seeing some services attempt to start at boot, that I can't disable. I also seem to have a selinux problem blocking consolekit so that sound doesn't work in enforcing mode. So far I am just working on the kernel change that seems to have md being more picky about md raid1 superblocks and just doing workarounds for the rest. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On 06/23/2014 06:28 AM, Adam Williamson wrote: On Mon, 2014-06-23 at 05:03 +0200, poma wrote: Not only LightDM, but all tested display managers refuse to work. There might be a general strike on i686 avenue. :) Already reported, diagnosed and fixed upstream. https://bugzilla.redhat.com/show_bug.cgi?id=1110968 . I expect jwb will backport the patch on Monday. Thanks for info. Yeah, as Lubomir stated "vdso=0" works with broken ones, and 3.16.0-0.rc2.git0.3.fc21.i686 PASSED BTW, Adam, there are people running & testing Rawhide on i686! :) poma -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On Mon, 2014-06-23 at 05:03 +0200, poma wrote: > Not only LightDM, but all tested display managers refuse to work. > There might be a general strike on i686 avenue. :) Already reported, diagnosed and fixed upstream. https://bugzilla.redhat.com/show_bug.cgi?id=1110968 . I expect jwb will backport the patch on Monday. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: 3.16.x on i686
On 22.06.2014 04:34, poma wrote: 3.16.0-0.rc1.git4.1.fc21.i686 #1 Not tainted LightDM, SDDM, GDM are failing. Interestingly, there are no errors in Xorg.0.log, (II) NOUVEAU(0): Output DVI-I-1 connected startx works for user and startxfce4 for root. :) journal: systemd[1]: Starting Light Display Manager... systemd[1]: Started Light Display Manager. systemd[1]: lightdm.service: main process exited, code=killed, status=11/SEGV systemd[1]: Unit lightdm.service entered failed state. systemd[1]: lightdm.service holdoff time over, scheduling restart. systemd[1]: Stopping Light Display Manager... systemd[1]: Starting Light Display Manager... systemd[1]: Started Light Display Manager. systemd[1]: lightdm.service: main process exited, code=killed, status=11/SEGV systemd[1]: Unit lightdm.service entered failed state. systemd[1]: lightdm.service holdoff time over, scheduling restart. systemd[1]: Stopping Light Display Manager... systemd[1]: Starting Light Display Manager... systemd[1]: Started Light Display Manager. systemd[1]: lightdm.service: main process exited, code=killed, status=11/SEGV systemd[1]: Unit lightdm.service entered failed state. systemd[1]: lightdm.service holdoff time over, scheduling restart. systemd[1]: Stopping Light Display Manager... systemd[1]: Starting Light Display Manager... systemd[1]: Started Light Display Manager. systemd[1]: lightdm.service: main process exited, code=killed, status=4/ILL systemd[1]: Unit lightdm.service entered failed state. systemd[1]: lightdm.service holdoff time over, scheduling restart. systemd[1]: Stopping Light Display Manager... systemd[1]: Starting Light Display Manager... systemd[1]: Started Light Display Manager. systemd[1]: lightdm.service: main process exited, code=killed, status=11/SEGV systemd[1]: Unit lightdm.service entered failed state. systemd[1]: lightdm.service holdoff time over, scheduling restart. systemd[1]: Stopping Light Display Manager... systemd[1]: Starting Light Display Manager... systemd[1]: lightdm.service start request repeated too quickly, refusing to start. systemd[1]: Failed to start Light Display Manager. systemd[1]: Unit lightdm.service entered failed state. lightdm[1863] bad frame in sigreturn frame:bf8231bc ip:b7506000 sp:bf8232ac orax: in libglib-2.0.so.0.4100.0[b7506000+1000] lightdm[1898] bad frame in sigreturn frame:bfb8e4fc ip:7c sp:0 orax: in lightdm[8048000+38000] lightdm[1910] bad frame in sigreturn frame:bfc49f3c ip:7c sp:0 orax: in lightdm[8048000+38000] lightdm[1934] bad frame in sigreturn frame:bf96b0fc ip:7c sp:0 orax: in lightdm[8048000+38000] # rpm -qf /usr/lib/libglib-2.0.so.0.4100.0 glib2-2.41.0-2.fc21.i686 systemctl[1135]: segfault at b7cc ip b77421cd sp bfd7a060 error 4 in systemctl[b76f4000+9c000] systemctl[1143]: segfault at b8cc ip b779e1cd sp bf97d7f0 error 4 in systemctl[b775+9c000] systemctl[1152]: segfault at b8cc ip b77431cd sp bf9be350 error 4 in systemctl[b76f5000+9c000] systemctl[1160]: segfault at b9cc ip b778d1cd sp bfd62c10 error 4 in systemctl[b773f000+9c000] systemctl[1169]: segfault at b9cc ip b76f81cd sp bf83fcf0 error 4 in systemctl[b76aa000+9c000] systemctl[1177]: segfault at b7cc ip b77281cd sp bfbafcf0 error 4 in systemctl[b76da000+9c000] systemctl[1185]: segfault at b9cc ip b77361cd sp bff6a680 error 4 in systemctl[b76e8000+9c000] systemctl[1193]: segfault at b7cc ip b77001cd sp bff62eb0 error 4 in systemctl[b76b2000+9c000] systemctl[1201]: segfault at b8cc ip b76e31cd sp bf943bf0 error 4 in systemctl[b7695000+9c000] systemctl[1209]: segfault at b9cc ip b76bb1cd sp bfd088c0 error 4 in systemctl[b766d000+9c000] systemctl[1217]: segfault at b8cc ip b77a91cd sp bfe9c470 error 4 in systemctl[b775b000+9c000] systemctl[1225]: segfault at b9cc ip b773d1cd sp bfc7dd90 error 4 in systemctl[b76ef000+9c000] Selinux is not an issue. Downgrade of glib2 doesn't help. Building and installing newer versions of systemd and lightdm doesn't help also. All this doesn't happen with 3.15.0-1.fc21.i686! Something is strange with that turtle. :) 3.16.0-0.rc2.git0.1.fc21.i686 #1 Not tainted systemd-214-3.gita900b82.20140622.fc21.i686 lightdm[2262] bad frame in sigreturn frame:bfbe133c ip:7c sp:0 orax: in lightdm[8048000+38000] lightdm[2277] bad frame in sigreturn frame:bff2087c ip:5ec sp:0 orax: in lightdm[8048000+38000] systemd-journald[346]: Received request to flush runtime journal from PID 1 systemd[1]: Unit lightdm.service entered failed state. [+0.00s] DEBUG: Starting Light Display Manager 1.11.3, UID=0 PID=2074 lightdm.service: main process exited, code=killed, status=4/ILL Unit lightdm.service entered failed state. lightdm.service holdoff time over, scheduling restart. lightdm.service: main process exited, code=killed, status=4/ILL Unit lightdm.service entered failed state. lightdm.service holdoff time over, scheduling restart. lightdm.service: main process exited, code=kill
