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 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 Wed, Jun 25, 2014 at 3:24 AM, Adam Williamson awill...@redhat.com 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 br...@wolff.to wrote: On Mon, Jun 23, 2014 at 11:34:53 -0700, Adam Williamson awill...@redhat.com 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 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 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 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 Wed, Jun 25, 2014 at 11:12 PM, Adam Williamson awill...@redhat.com 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 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, 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 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
dnf errors or kernel* rpm problems?
dnf upgrade doesn't show an error while updating the kernel packages but there are missing entries in grub2.conf after an upgrade that should be for the new kernel that was downloaded and, supposedly, installed. If I attempt a dnf reinstall of the kernel and related rpms then I get the following errors: Package Arch Version Repository Size Reinstalling: kernel x86_643.16.0-0.rc2.git0.1.fc21rawhide 86 k kernel-core x86_643.16.0-0.rc2.git0.1.fc21rawhide 18 M kernel-modules x86_643.16.0-0.rc2.git0.1.fc21rawhide 17 M kernel-headers x86_643.16.0-0.rc2.git0.1.fc21rawhide985 k kernel-tools-libs x86_643.16.0-0.rc2.git0.1.fc21rawhide 92 k replacing kernel-tools-libs.x86_64 3.15.0-0.rc7.git0.1.fc21 replacing kernel-tools-libs.x86_64 3.15.0-0.rc8.git1.2.fc21 replacing kernel-tools-libs.x86_64 3.16.0-0.rc0.git11.1.fc21 kernel-modules-extrax86_643.16.0-0.rc2.git0.1.fc21rawhide2.2 M Transaction Summary Total size: 38 M Downloading Packages: Total 3.7 GB/s | 38 MB 00:00 Running transaction check Transaction check succeeded. Running transaction test Error: Transaction check error: file /usr/lib64/libcpupower.so.0.0.0 from install of kernel-tools-libs-3.16.0-0.rc2.git0.1.fc21.x86_64 conflicts with file from package kernel-tools-libs-3.15.0-0.rc7.git0.1.fc21.x86_64 file /usr/lib64/libcpupower.so.0.0.0 from install of kernel-tools-libs-3.16.0-0.rc2.git0.1.fc21.x86_64 conflicts with file from package kernel-tools-libs-3.15.0-0.rc8.git1.2.fc21.x86_64 file /usr/lib64/libcpupower.so.0.0.0 from install of kernel-tools-libs-3.16.0-0.rc2.git0.1.fc21.x86_64 conflicts with file from package kernel-tools-libs-3.16.0-0.rc0.git11.1.fc21.x86_64 Error Summary - Dependencies resolved. Package Arch Version Repository Size Reinstalling: kernel x86_643.16.0-0.rc2.git0.1.fc21rawhide 86 k kernel-core x86_643.16.0-0.rc2.git0.1.fc21rawhide 18 M kernel-modules x86_643.16.0-0.rc2.git0.1.fc21rawhide 17 M kernel-headers x86_643.16.0-0.rc2.git0.1.fc21rawhide985 k replacing kernel-headers.x86_64 3.16.0-0.rc0.git11.1.fc21 kernel-tools-libs x86_643.16.0-0.rc2.git0.1.fc21rawhide 92 k replacing kernel-tools-libs.x86_64 3.15.0-0.rc7.git0.1.fc21 replacing kernel-tools-libs.x86_64 3.15.0-0.rc8.git1.2.fc21 replacing kernel-tools-libs.x86_64 3.16.0-0.rc0.git11.1.fc21 kernel-modules-extrax86_643.16.0-0.rc2.git0.1.fc21rawhide2.2 M Transaction Summary Total size: 38 M Downloading Packages: Total 3.7 GB/s | 38 MB 00:00 Running transaction check Transaction check succeeded. Running transaction test Error: Transaction check error: file /usr/lib64/libcpupower.so.0.0.0 from install of kernel-tools-libs-3.16.0-0.rc2.git0.1.fc21.x86_64 conflicts with file from package kernel-tools-libs-3.15.0-0.rc7.git0.1.fc21.x86_64 file /usr/lib64/libcpupower.so.0.0.0 from install of kernel-tools-libs-3.16.0-0.rc2.git0.1.fc21.x86_64 conflicts with file from package kernel-tools-libs-3.15.0-0.rc8.git1.2.fc21.x86_64 file /usr/lib64/libcpupower.so.0.0.0 from install of kernel-tools-libs-3.16.0-0.rc2.git0.1.fc21.x86_64 conflicts with file from package kernel-tools-libs-3.16.0-0.rc0.git11.1.fc21.x86_64 file /usr/include/linux/audit.h from install of kernel-headers-3.16.0-0.rc2.git0.1.fc21.x86_64 conflicts with file from package kernel-headers-3.16.0-0.rc0.git11.1.fc21.x86_64 file /usr/include/linux/btrfs.h from install of kernel-headers-3.16.0-0.rc2.git0.1.fc21.x86_64 conflicts with file from package kernel-headers-3.16.0-0.rc0.git11.1.fc21.x86_64 file /usr/include/linux/can.h from install of kernel-headers-3.16.0-0.rc2.git0.1.fc21.x86_64 conflicts with file from package kernel-headers-3.16.0-0.rc0.git11.1.fc21.x86_64 file /usr/include/linux/can/bcm.h from install of kernel-headers-3.16.0-0.rc2.git0.1.fc21.x86_64 conflicts with file from package kernel-headers-3.16.0-0.rc0.git11.1.fc21.x86_64 file
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 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 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 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 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=Big mama 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 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 Tue, 2014-06-24 at 22:50 -0500, Bruno Wolff III wrote: On Tue, Jun 24, 2014 at 19:22:05 -0700, Adam Williamson awill...@redhat.com 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, Jun 25, 2014 at 12:56:41 -0700, Adam Williamson awill...@redhat.com 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 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, 2014-06-25 at 15:09 -0500, Bruno Wolff III wrote: On Wed, Jun 25, 2014 at 12:56:41 -0700, Adam Williamson awill...@redhat.com 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 Wed, Jun 25, 2014 at 14:10:31 -0700, Adam Williamson awill...@redhat.com 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 awill...@redhat.com 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 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, 2014-06-25 at 16:16 -0500, Bruno Wolff III wrote: On Wed, Jun 25, 2014 at 14:10:31 -0700, Adam Williamson awill...@redhat.com 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 awill...@redhat.com 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
dracut shell instead of anaconda :-(
http://fm.no-ip.com/Tmp/Linux/F/rdsosreportF21wd500.txt plain http://fm.no-ip.com/Tmp/Linux/F/rdsosreportF21wd501.txt rd.debug Can anyone look at either of these rdsosreports and tell me if there's anything I can do other than wait for the next builds of installation kernel, initrd squashfs and try again? Are any of the three on the mirrors now known to be broken? http://alt.fedoraproject.org/pub/fedora/linux/development/rawhide/i386/os/LiveOS/squashfs.img 2014-06-25 11:06 289M http://alt.fedoraproject.org/pub/fedora/linux/development/rawhide/i386/os/isolinux/initrd.img 2014-06-25 11:09 41M http://alt.fedoraproject.org/pub/fedora/linux/development/rawhide/i386/os/isolinux/vmlinuz 2014-06-24 14:45 5.8M Overview: Trying to HTTP install starting from Grub Core2duo CPU 3000 series video 2G RAM Target partition sdc11 sda sdb not involved except to host Grub on sda -- 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
Call for gnupg 1.4.17 testing
I have built the new version of gnupg that fixes a security issue, among other things. If you can, please test the new build and leave feedback so we can get these stable ASAP. F19 build - https://admin.fedoraproject.org/updates/FEDORA-2014-7678/gnupg-1.4.17-1.fc19 F20 build - https://admin.fedoraproject.org/updates/FEDORA-2014-7676/gnupg-1.4.17-1.fc20 Thanks! -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: dracut shell instead of anaconda :-(
This was due to a util-linux bug, pjones patched it this afternoon and tonight's compose should be better. We hope. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Fedora 19 updates-testing report
The following Fedora 19 Security updates need testing: Age URL 243 https://admin.fedoraproject.org/updates/FEDORA-2013-19963/openstack-glance-2013.1.4-1.fc19 55 https://admin.fedoraproject.org/updates/FEDORA-2014-5896/nrpe-2.15-2.fc19 44 https://admin.fedoraproject.org/updates/FEDORA-2014-6233/dpkg-1.16.14-1.fc19 35 https://admin.fedoraproject.org/updates/FEDORA-2014-6553/chicken-4.8.0.6-2.fc19 33 https://admin.fedoraproject.org/updates/FEDORA-2014-6597/drupal7-views-3.8-1.fc19 13 https://admin.fedoraproject.org/updates/FEDORA-2014-7274/tor-0.2.4.22-2.fc19 12 https://admin.fedoraproject.org/updates/FEDORA-2014-7333/ReviewBoard-1.7.26-2.fc19,python-django-evolution-0.6.9-4.fc19 12 https://admin.fedoraproject.org/updates/FEDORA-2014-7322/thunderbird-24.6.0-1.fc19 7 https://admin.fedoraproject.org/updates/FEDORA-2014-7490/sos-3.1-1.fc19 6 https://admin.fedoraproject.org/updates/FEDORA-2014-7496/readline-6.2-8.fc19 4 https://admin.fedoraproject.org/updates/FEDORA-2014-7572/kdelibs-4.11.5-4.fc19 4 https://admin.fedoraproject.org/updates/FEDORA-2014-7570/asterisk-11.10.2-2.fc19 4 https://admin.fedoraproject.org/updates/FEDORA-2014-6774/claws-mail-3.10.1-1.fc19,claws-mail-plugins-3.10.0-1.fc19,libetpan-1.5-1.fc19 4 https://admin.fedoraproject.org/updates/FEDORA-2014-7603/zabbix-2.0.12-3.fc19 4 https://admin.fedoraproject.org/updates/FEDORA-2014-7610/perl-Email-Address-1.905-1.fc19 2 https://admin.fedoraproject.org/updates/FEDORA-2014-7654/samba-4.0.19-1.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2014-7645/couchdb-1.6.0-2.fc19,erlang-ibrowse-4.0.1-1.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2014-7690/seamonkey-2.26.1-1.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2014-7679/libreoffice-4.1.6.2-7.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2014-7678/gnupg-1.4.17-1.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2014-7734/xen-4.2.4-6.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2014-7716/python-simplejson-3.5.3-1.fc19 The following Fedora 19 Critical Path updates have yet to be approved: Age URL 191 https://admin.fedoraproject.org/updates/FEDORA-2013-22326/fedora-bookmarks-15-5.fc19 117 https://admin.fedoraproject.org/updates/FEDORA-2014-3245/testdisk-6.14-2.fc19.1,ntfs-3g-2014.2.15-1.fc19 13 https://admin.fedoraproject.org/updates/FEDORA-2014-7270/qt-4.8.6-9.fc19 13 https://admin.fedoraproject.org/updates/FEDORA-2014-7285/gupnp-av-0.12.6-1.fc19 12 https://admin.fedoraproject.org/updates/FEDORA-2014-7322/thunderbird-24.6.0-1.fc19 11 https://admin.fedoraproject.org/updates/FEDORA-2014-7395/squashfs-tools-4.3-6.fc19 8 https://admin.fedoraproject.org/updates/FEDORA-2014-7462/btrfs-progs-3.14.2-1.fc19 8 https://admin.fedoraproject.org/updates/FEDORA-2014-7453/kde-workspace-4.11.10-2.fc19 6 https://admin.fedoraproject.org/updates/FEDORA-2014-7496/readline-6.2-8.fc19 6 https://admin.fedoraproject.org/updates/FEDORA-2014-7498/pcre-8.32-9.fc19 4 https://admin.fedoraproject.org/updates/FEDORA-2014-7559/polkit-qt-0.103.0-10.fc19 4 https://admin.fedoraproject.org/updates/FEDORA-2014-7572/kdelibs-4.11.5-4.fc19 2 https://admin.fedoraproject.org/updates/FEDORA-2014-7654/samba-4.0.19-1.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2014-7735/gcc-4.8.3-1.fc19,libtool-2.4.2-24.fc19,gcc-python-plugin-0.12-16.fc19,dragonegg-3.3-2.fc19 The following builds have been pushed to Fedora 19 updates-testing dragonegg-3.3-2.fc19 edelib-2.1-2.fc19 fedpkg-1.16-1.fc19 gambas3-3.5.4-1.fc19 gcc-4.8.3-1.fc19 gcc-python-plugin-0.12-16.fc19 glusterfs-3.5.1-1.fc19 grub2-2.00-26.fc19 ibus-table-1.8.3-1.fc19 ibus-table-others-1.3.0.20140625-1.fc19 libtool-2.4.2-24.fc19 mingw-gsm-1.0.13-1.fc19 openscap-1.0.9-1.fc19 perl-Config-Generator-0.8-1.fc19 perl-PerlIO-via-Timeout-0.29-2.fc19 python-simplejson-3.5.3-1.fc19 sddm-0.2.0-0.29.20140623gitdb1d7381.fc19 wine-mono-4.5.2-4.fc19 xen-4.2.4-6.fc19 Details about builds: dragonegg-3.3-2.fc19 (FEDORA-2014-7735) GCC plugin to use LLVM optimizers and code generators Update Information: This update updates gcc to 4.8.3, fixing over 270 bugs since gcc-4.8.2-7.fc19. ChangeLog: * Wed Jun 25 2014 Jakub Jelinek ja...@redhat.com 3.3-2 - Rebuild for gcc-4.8.3-1.fc19. edelib-2.1-2.fc19 (FEDORA-2014-7719) Small and portable C++ library for EDE
