Red Hat Bugzilla – Bug 575417
udev 151-4 currently breaks something related to the watchdog timer
Last modified: 2013-02-13 21:40:19 EST
Description of problem: On one of my machines where the iTCO_wdt module gets loaded broke after I went to udev-151-4.fc13 (from koji) and rebooted. udev 151-3 works normally. I get the following error message: iTCO_wdt: Unexpected close, not stopping watchdog! Then about a minute or two later the machine reboots. Though the boot process continues in up until that point. I have about enough time to do a graphical login. I can do a bit more if I boot to run level 1 or 3. Reverting to 151-3.fc13 fixed the problem. Version-Release number of selected component (if applicable): 151-4.fc13 How reproducible: On another machine the console output during the boot suggests that udev startup failed, but there isn't an error saying why. This may or may not be related. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Also happening in F14\Rawhide with udev-151-5.fc14 Downgrade to 151-4.fc13 likewise fixed the problem with rawhide.
(In reply to comment #1) > Also happening in F14\Rawhide with udev-151-5.fc14 > > Downgrade to 151-4.fc13 likewise fixed the problem with rawhide. Typo: downgrade to *151-3.fc13*
*** Bug 575580 has been marked as a duplicate of this bug. ***
Ok, I need your help to localize the bug. 1. install udev-151-4.fc13 2. comment out the line #324 "touch_recursive /dev > "$udev_root/null" 2>&1" if this does not fix the issue, could you try to find the patch in the specfile, which causes the issue?
Ok - I've noticed same issue on my Lenovo T61 - As a hotfix - I've just added blacklist iTCO_wdt to /etc/modprobe.d/blacklist.cong It's pretty awkward to do anything with the machine - as my watchdog reboots machine in 30 seconds. So the only solution is to boot with init=/bin/sh - as otherwise machine practically reboots really soon after boot.
boot with "rd_blacklist=iTCO_wdt" on the kernel command line to get into the system
(In reply to comment #4) > Ok, I need your help to localize the bug. > > 1. install udev-151-4.fc13 > 2. comment out the line #324 "touch_recursive /dev > "$udev_root/null" 2>&1" What file do I find this in? still coming to terms with grep. > > if this does not fix the issue, could you try to find the patch in the > specfile, which causes the issue?
(In reply to comment #5) > Ok - I've noticed same issue on my Lenovo T61 - > > As a hotfix - I've just added blacklist iTCO_wdt to > /etc/modprobe.d/blacklist.cong this has also worked for me on 151-4, > > It's pretty awkward to do anything with the machine - as my watchdog reboots > machine in 30 seconds. > > So the only solution is to boot with init=/bin/sh - as otherwise machine > practically reboots really soon after boot. grub set to boot to telinit 3, then startx. works for me now, after blacklisting.
Oh, great, even desktop intel machine rebooting after upgrade, and the rd_blacklist=iTCO_wd seems not to work here.
I've also got this problem on a MacBook 2.1 (white, quite old). Blacklisting the module iTCO_wdt helps (no wonder).
Updating to 151-5 does solve the problem. I can not either find the given line above.
Here is the fix: --- /sbin/start_udev 22 Mar 2010 10:08:46 -0000 1.89 +++ /sbin/start_udev 22 Mar 2010 13:26:38 -0000 @@ -59,7 +59,7 @@ touch_recursive() { ( cd $1; for i in *; do - [[ -c "$i" || -b "$i" ]] && touch "$i" + [[ -c "$i" || -b "$i" ]] && touch --no-create "$i" [ -d "$i" ] && touch_recursive "$i" done ) return 0
how to fix a rebooting machine: 1. boot with "init=/bin/sh" 2. # mount -o remount,rw / 3. apply fix in comment #12 4. reboot
ok, that seems to work. --no-create causes that device node is not opened, just the timestamp is changed. But device node already exists - so it is side effect of that switch what helps.
Under fedora 14 with udev-151-7.fc14.x86_64 everthing is fine :) Great work and thx for quick reaction.
udev-145-18.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/udev-145-18.fc12
I tried udev-151-6.fc13.i686 and udev startup succeeds, there are no warnings about the watchdog timer and the system stays up.
(In reply to comment #15) > Under fedora 14 with udev-151-7.fc14.x86_64 everthing is fine :) > Great work and thx for quick reaction. udev-151-7.fc14.x86_64 boots fine. with the blacklist iTCO_wdt remmed out from blacklist.conf
I tried udev-151-7.fc13.i686 on three machines and it looks OK as well.
*** Bug 576111 has been marked as a duplicate of this bug. ***
udev-151-7.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/udev-151-7.fc13
It also happens in Fedora 12 Testing Updates.
(In reply to comment #23) > It also happens in Fedora 12 Testing Updates. https://admin.fedoraproject.org/updates/udev-145-19.fc12
udev-151-7.fc13 has been pushed to the Fedora 13 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 udev'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/udev-151-7.fc13
udev-145-19.fc12 has been pushed to the Fedora 12 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 udev'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/udev-145-19.fc12
*** Bug 576321 has been marked as a duplicate of this bug. ***
*** Bug 576402 has been marked as a duplicate of this bug. ***
*** Bug 576484 has been marked as a duplicate of this bug. ***
Yesterday udev-145-16.fc12 showed up in updates testing (not 19). This caused my system to start going into infinite reboots yesterday which it had not done before. I needed to go into the blacklist file and add blacklist iTCO_wdt to get system to be stable.
udev-145-8.fc14 works for me
for me too.
udev-145-19 works on my laptop.
*** Bug 575557 has been marked as a duplicate of this bug. ***
udev-145-19.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
udev-151-7.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
This problem appeard again after upgrading to kernel-2.6.35-0.25.rc4. udev: 158-2 So I reopen this bug. Can someone reproduce this problem?
(In reply to comment #38) > This problem appeard again after upgrading to kernel-2.6.35-0.25.rc4. > > udev: 158-2 > > So I reopen this bug. Can someone reproduce this problem? Rawhide?
Yes(In reply to comment #39) > (In reply to comment #38) > > This problem appeard again after upgrading to kernel-2.6.35-0.25.rc4. > > > > udev: 158-2 > > > > So I reopen this bug. Can someone reproduce this problem? > > Rawhide? Yes.
(In reply to comment #40) > Yes(In reply to comment #39) > > (In reply to comment #38) > > > This problem appeard again after upgrading to kernel-2.6.35-0.25.rc4. > > > > > > udev: 158-2 > > > > I have downgraded to udev: 158-1 still cannot boot beyond checking edd That is the last two kernels + one from koji cannot boot. kernel-2.6.35-0.24.rc3.git7.fc14 kernel-2.6.35-0.25.rc4.git0.fc14 kernel-2.6.35-0.27.rc4.git0.fc14
(In reply to comment #41) > (In reply to comment #40) > > Yes(In reply to comment #39) > > > (In reply to comment #38) > > > > This problem appeard again after upgrading to kernel-2.6.35-0.25.rc4. > > > > > > > > udev: 158-2 > > > > > > > > I have downgraded to udev: 158-1 > still cannot boot beyond checking edd So I understand it correctly that you can also not boot your system completely? > That is the last two kernels + one from koji cannot boot. > kernel-2.6.35-0.24.rc3.git7.fc14 > kernel-2.6.35-0.25.rc4.git0.fc14 > kernel-2.6.35-0.27.rc4.git0.fc14 Yes. I've also noticed that. I've got the kernels a: /boot/vmlinuz-2.6.35-0.23.rc3.git6.fc14.i686 b: /boot/vmlinuz-2.6.35-0.24.rc3.git7.fc14.i686 c: /boot/vmlinuz-2.6.35-0.25.rc4.git0.fc14.i686 installed. But can not boot a and b (did not try c). But this problem occured after the update of the following packages: Jul 06 19:39:29 Installed: libmodman-1.0.1-5.fc14.i686 Jul 06 19:39:31 Updated: libproxy-0.4.4-5.fc14.i686 Jul 06 19:39:40 Updated: libvirt-client-0.8.2-1.fc14.i686 Jul 06 19:39:42 Updated: corosync-1.2.6-1.fc14.i686 Jul 06 19:39:44 Updated: corosynclib-1.2.6-1.fc14.i686 Jul 06 19:39:52 Updated: gnome-bluetooth-libs-2.90.0-2.fc14.i686 Jul 06 19:39:56 Installed: ebtables-2.0.9-5.fc13.i686 Jul 06 19:39:58 Updated: pangomm-2.26.2-1.fc14.i686 Jul 06 19:40:01 Updated: 2:gimp-libs-2.6.9-5.fc14.i686 Jul 06 19:40:04 Installed: atkmm-2.21.2-1.fc14.i686 Jul 06 19:40:06 Updated: hunspell-1.2.11-3.fc14.i686 Jul 06 19:40:08 Updated: hunspell-devel-1.2.11-3.fc14.i686 Jul 06 19:40:12 Updated: gtkmm24-2.21.1-1.fc14.i686 Jul 06 19:40:53 Updated: 2:gimp-2.6.9-5.fc14.i686 Jul 06 19:41:00 Updated: libvirt-0.8.2-1.fc14.i686 Jul 06 19:41:03 Updated: gnome-bluetooth-2.90.0-2.fc14.i686 Jul 06 19:41:05 Updated: libvirt-python-0.8.2-1.fc14.i686 Jul 06 19:41:06 Updated: libproxy-bin-0.4.4-5.fc14.i686 Jul 06 19:41:07 Updated: glpk-4.43-2.fc14.i686 Jul 06 19:41:08 Updated: xbacklight-1.1.1-1.fc14.i686 Jul 06 19:41:42 Installed: kernel-2.6.35-0.25.rc4.git0.fc14.i686 Jul 06 19:41:43 Updated: libproxy-python-0.4.4-5.fc14.noarch Jul 06 19:41:45 Updated: autoconf-2.66-2.fc14.noarch Jul 06 19:41:50 Updated: kernel-headers-2.6.35-0.25.rc4.git0.fc14.i686 Jul 06 19:41:52 Updated: publican-doc-2.0-0.fc14.noarch Jul 06 19:45:19 Installed: kernel-devel-2.6.35-0.25.rc4.git0.fc14.i686 The kernel seems to be the only relevant thing updated and I did not change the hardware. So I wonder what happened. It helps me to blacklist iTCO_wdt. What I've also obserrved, normally the system shuts down after the 30seconds timeout. But in one case (when using the kernel param rdblacklist=iTCO_wdt), the system stayed alive longer, but then finally was also shut down ...
(In reply to comment #42) > > still cannot boot beyond checking edd > > So I understand it correctly that you can also not boot your system completely? Correct. I will open a bugzilla against the kernel, and see where if progresses from there.
kernel bz. https://bugzilla.redhat.com/show_bug.cgi?id=612271
rawhide's udev is not involved in the problem.
It seems that I hit this old bug with Fedora 16, udev-173-3, kernel 3.3.5-2.fc16.x86_64 on a Dell latitude. I've described my experience here previously: http://lists.fedoraproject.org/pipermail/users/2012-May/418234.html I wasn't able to find solution then, so I re-installed my machine completely, and hit this issue again, except that this time my google search brought me to this bug. I am able to work around the continously rebooting process by booting with "emergency", remound / as readwrite, edit /etc/modproble.d/blacklist.conf to add iTCO_wdt as blacklist, and reboot. Just in case this is relevant, I just recently added my own udev rules to automatically mount my encrypted external harddrive with luks/dm-crypt before this happened (not sure if it's just coincidence). I can paste my udev rules here if it'd help. If this is not the same issue, I apologize, and I'll open a new bug report. If it is, please re-open this bug.
I don't know if it's the same bug, but reopened it and changed Version to 16.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.