Bug 595930
Summary: | please update to 1.0pre2 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | James Ralston <ralston> |
Component: | mcelog | Assignee: | Prarit Bhargava <prarit> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 14 | CC: | bugzilla, Colin.Simpson, dgp-bz, d.hawke, djuran, dylan.swift, edgar.hoch, ehabkost, erinn.looneytriggs, gregor.binder, igeorgex, infertux, jcm, jonathan, mak_s, Marc.Herbert+rhzilla, mattia.verga, mishu, nicolas.mailhot, nsoranzo, okrh, orion, paul, ppisar, prarit, pza, rh001, richardfearn, rpm, sclark46, steven.chapel, tpeplt, wbiker |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | mcelog-1.0-0.1.pre3.fc14 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-10-08 18:02:48 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
James Ralston
2010-05-25 22:50:14 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping please update this for f14. my laptop complains hourly about 'no such device', which is fixed in 1.0pre2. ok Dave. I'll do it. I pinged Anton a couple of weeks back to see if one of those guys in Brno was taking over mcelog, but I'll take care of it for the moment. mcelog-1.0-0.1.pre3.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/mcelog-1.0-0.1.pre3.fc14 I'll keep this package, and just pay better attention to it now Andi is doing mcelog again. I've done all the updates for devel, F14, F13 just now. *** Bug 623550 has been marked as a duplicate of this bug. *** *** Bug 615530 has been marked as a duplicate of this bug. *** 1.0pre3 looks god in rawhide, fixes 615530 for me. mcelog-1.0-0.1.pre3.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update mcelog'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/mcelog-1.0-0.1.pre3.fc14 Bug 615530 still occurs for me. $rpm -q mcelog mcelog-1.0-0.1.pre3.fc14.x86_64 After installing, I rebooted. At the next hour I got: /etc/cron.hourly/mcelog.cron: read: No such device Hmm, looks good for me on fc14 as well. Phil - what is your hardware? Ah, bug 615530 not fixed for me on a Dell Inspiron 6400 with Core2 T5500. I getting the problem on an old Intel(R) Core(TM)2 CPU 6300: http://www.smolts.org/client/show/pub_d4133dd0-8cc6-41ec-959c-d909c02811e9 Failing for me: /etc/cron.hourly/mcelog.cron: read: No such device ========================================== mcelog-0.9pre1-0.1.fc13.x86_64 yum says mcelog is update to day and I'm on F14. rpm -qa| grep release fedora-release-14-1.noarch For people complaining about the "read: No such device", please note: 1. The error only occurs the first time that /dev/mcelog is read after the host boots. For subsequent attempts, it won't fail. 2. It fails due to a bug in the kernel, not mcelog. (See comment 17 in bug 615530.) In effect, this problem has to be fixed upstream (in the kernel); there's nothing that mcelog can do about it. Except, in talking with Andi he has agreed to a fix to the read handling in mcelog so we'll retry on failure (I need to check his logic). I'm slightly concerned that he didn't seem desperate to fix the upstream breakage, but that is another issue and one that is in hand. So, to be clear, I will be pushing a second update with the fix for the first run of mcelog on next boot causing a read error too. From root Sun Dec 26 07:01:01 2010 Return-Path: <root> Date: Sun, 26 Dec 2010 07:01:01 -0500 From: root (Cron Daemon) To: root Subject: Cron <root@localhost> run-parts /etc/cron.hourly Content-Type: text/plain; charset=UTF-8 Auto-Submitted: auto-generated X-Cron-Env: <SHELL=/bin/bash> X-Cron-Env: <PATH=/sbin:/bin:/usr/sbin:/usr/bin> X-Cron-Env: <MAILTO=root> X-Cron-Env: <HOME=/root> X-Cron-Env: <LOGNAME=root> X-Cron-Env: <USER=root> Status: R /etc/cron.hourly/mcelog.cron: read: No such device # rpm -q mcelog mcelog-0.9pre1-0.1.fc13.x86_64 hi, i have the same error on 4 machines. mcelog version: mcelog-0.9pre1-0.1.fc13.x86_64 kernel: 2.6.35.10-74.fc14.x86_64 any solutions in the meantime that are not reported? greetings gregor Hi, I have mcelog-1.0-0.1.pre3.fc14.x86_64 kernel 2.6.37-1.fc15.x86_64 and I still get: /etc/cron.hourly/mcelog.cron: read: No such device Hi, forgot to add Core 2 CPU T5600 Hi all, Problem is still there. mcelog mcelog-0.9pre1-0.1.fc13.x86_64 kernel 2.6.35.13-91.fc14.x86_64 Hourly I get: /etc/cron.hourly/mcelog read: No such device. On the command line I tried the command manually and it works without errors. mcelog --ignorenodev --filter >> /var/log/mcelog greetings, Wolfgang I had the same experience as Wolfgang in Comment 22, but I tried a variant that is sort-of documented in `man mcelog`: mcelog --ignorenodev --filter --logfile=/var/log/mcelog This produced an SELinux error! Seems odd to me that SELinux prevents mcelog from reaching its own file but doesn't prevent a shell redirect, but hey ... In any case, I'm now getting a new error: /etc/cron.hourly/mcelog.cron: mcelog: Cannot open log file /var/log/mcelog. Exiting. So I made a new SELinux module to repair that. The security context of /var/log/mcelog as created by the shell redirect (default cron job) is: system_u:object_r:cron_log_t:s0 I also deleted the /var/log/mcelog file and ran mcelog with the --logfile= option, and it created a new logfile with the security context: unconfined_u:object_r:var_log_t:s0 Anyhow I'm reporting this as an SELinux bug, though I can't see how it would be related to the underlying error (read: No such device). I am, however, happy to report that I am no longer getting the emails! To recap, here are the steps I took: 1) edit /etc/cron.hourly/mcelog to read: mcelog --ignorenodev --filter --logfile=/var/log/mcelog 2) delete /var/log/mcelog https://bugzilla.redhat.com/show_bug.cgi?id=720315 It turns out that it's not as simple as deleting the file, as SELinux expects a certain context that mcelog doesn't provide. See the other bug report for details. "... please update to 1.0pre2" Wow, a year after bug reported and this still has not been fixed for Fedora 14. There is NO update to the above release in any of the Fedora 14 repositories - at least non that I could find. Why hasn't this been pushed to the Fedora 14 repositories? Has this application been abandoned? I still have mcelog 0.8pre2. I have updated system with latest updates (i.e. yum update) - still not updated. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Please download an up karma if the package works on f14: http://koji.fedoraproject.org/koji/buildinfo?buildID=204431 Thanks, P. mcelog-1.0-0.1.pre3.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. Does not seemed to be fixed. Lenovo T500 Laptop - Intel Centrino 2 vPro Installed --> mcelog-1.0-0.1.pre3.fc14.x86_64.rpm Still getting mail messages with... /etc/cron.hourly/mcelog.cron: read: No such device yum list mcelog ==> mcelog.x86_64 2:1.0-0.1.pre3.fc14 installed also... yum complains that package is not signed. I used rpm to install it. Maybe it did not install correctly. I'll use ... yum --nogpgcheck reinstall mcelog-1.0-0.1.pre3.fc14.x86_64.rpm I'll update if any change. mcelog-1.0-0.1.pre3.fc14.x86_64 Still get the after boot error message. I can fix the annoyance with 2>/dev/null in the cron job, but every mcelog update overwrites it. Maybe the script should just have 2>&1, logging the failure. |