This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 575417 - udev 151-4 currently breaks something related to the watchdog timer
udev 151-4 currently breaks something related to the watchdog timer
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
16
All Linux
low Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Fedora Extras Quality Assurance
: Reopened
: 575557 575580 576111 576321 576402 576484 (view as bug list)
Depends On:
Blocks: 575557
  Show dependency treegraph
 
Reported: 2010-03-20 12:45 EDT by Bruno Wolff III
Modified: 2013-02-13 21:40 EST (History)
17 users (show)

See Also:
Fixed In Version: udev-151-7.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-13 21:40:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Bruno Wolff III 2010-03-20 12:45:59 EDT
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:
Comment 1 Frank Murphy 2010-03-21 05:03:48 EDT
Also happening in F14\Rawhide with udev-151-5.fc14

Downgrade to  151-4.fc13 likewise fixed the problem with rawhide.
Comment 2 Frank Murphy 2010-03-21 05:05:01 EDT
(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*
Comment 3 Harald Hoyer 2010-03-22 05:55:24 EDT
*** Bug 575580 has been marked as a duplicate of this bug. ***
Comment 4 Harald Hoyer 2010-03-22 05:55:50 EDT
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?
Comment 5 Zdenek Kabelac 2010-03-22 08:07:27 EDT
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.
Comment 6 Harald Hoyer 2010-03-22 08:44:42 EDT
 boot with "rd_blacklist=iTCO_wdt" on the kernel command line to get into the system
Comment 7 Frank Murphy 2010-03-22 08:59:32 EDT
(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?
Comment 8 Frank Murphy 2010-03-22 09:02:10 EDT
(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.
Comment 9 Milan Broz 2010-03-22 09:05:09 EDT
Oh, great, even desktop intel machine rebooting after upgrade,
and the rd_blacklist=iTCO_wd seems not to work here.
Comment 10 Fabian Deutsch 2010-03-22 09:12:05 EDT
I've also got this problem on a MacBook 2.1 (white, quite old).
Blacklisting the module iTCO_wdt helps (no wonder).
Comment 11 Fabian Deutsch 2010-03-22 09:20:56 EDT
Updating to 151-5 does solve the problem. I can not either find the given line above.
Comment 12 Harald Hoyer 2010-03-22 09:27:19 EDT
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
Comment 13 Harald Hoyer 2010-03-22 09:30:34 EDT
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
Comment 14 Milan Broz 2010-03-22 09:43:54 EDT
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.
Comment 15 Wolfgang Ulbrich 2010-03-22 09:53:00 EDT
Under fedora 14 with udev-151-7.fc14.x86_64 everthing is fine :)
Great work and thx for quick reaction.
Comment 16 Wolfgang Ulbrich 2010-03-22 09:55:45 EDT
Under fedora 14 with udev-151-7.fc14.x86_64 everthing is fine :)
Great work and thx for quick reaction.
Comment 17 Fedora Update System 2010-03-22 10:00:49 EDT
udev-145-18.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/udev-145-18.fc12
Comment 18 Bruno Wolff III 2010-03-22 10:13:52 EDT
I tried udev-151-6.fc13.i686 and udev startup succeeds, there are no warnings about the watchdog timer and the system stays up.
Comment 19 Frank Murphy 2010-03-22 10:37:57 EDT
(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
Comment 20 Bruno Wolff III 2010-03-22 11:28:17 EDT
I tried udev-151-7.fc13.i686 on three machines and it looks OK as well.
Comment 21 Harald Hoyer 2010-03-23 05:44:51 EDT
*** Bug 576111 has been marked as a duplicate of this bug. ***
Comment 22 Fedora Update System 2010-03-23 06:26:09 EDT
udev-151-7.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/udev-151-7.fc13
Comment 23 Benjamín Valero Espinosa 2010-03-23 10:59:14 EDT
It also happens in Fedora 12 Testing Updates.
Comment 24 Harald Hoyer 2010-03-23 12:16:35 EDT
(In reply to comment #23)
> It also happens in Fedora 12 Testing Updates.    

https://admin.fedoraproject.org/updates/udev-145-19.fc12
Comment 25 Fedora Update System 2010-03-23 19:32:37 EDT
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
Comment 26 Fedora Update System 2010-03-23 19:40:03 EDT
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
Comment 27 Harald Hoyer 2010-03-24 05:08:48 EDT
*** Bug 576321 has been marked as a duplicate of this bug. ***
Comment 28 Harald Hoyer 2010-03-24 06:06:23 EDT
*** Bug 576402 has been marked as a duplicate of this bug. ***
Comment 29 Harald Hoyer 2010-03-24 06:07:39 EDT
*** Bug 576484 has been marked as a duplicate of this bug. ***
Comment 30 Stephen John Smoogen 2010-03-24 08:55:44 EDT
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.
Comment 31 Harald Hoyer 2010-03-24 09:07:28 EDT

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
Comment 32 Stephen 2010-03-24 11:25:07 EDT
udev-145-8.fc14  works for me
Comment 33 Fabian Deutsch 2010-03-24 11:31:00 EDT
for me too.
Comment 34 The Source 2010-03-24 11:34:26 EDT
udev-145-19 works on my laptop.
Comment 35 damian 2010-03-24 18:14:11 EDT
*** Bug 575557 has been marked as a duplicate of this bug. ***
Comment 36 Fedora Update System 2010-03-25 18:35:29 EDT
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.
Comment 37 Fedora Update System 2010-03-25 18:38:52 EDT
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.
Comment 38 Fabian Deutsch 2010-07-07 09:28:46 EDT
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?
Comment 39 Frank Murphy 2010-07-07 10:40:28 EDT
(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?
Comment 40 Fabian Deutsch 2010-07-07 10:49:36 EDT
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.
Comment 41 Frank Murphy 2010-07-07 11:20:51 EDT
(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
Comment 42 Fabian Deutsch 2010-07-07 12:30:10 EDT
(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 ...
Comment 43 Frank Murphy 2010-07-07 13:54:07 EDT
(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.
Comment 44 Frank Murphy 2010-07-07 14:01:51 EDT
kernel bz.
https://bugzilla.redhat.com/show_bug.cgi?id=612271
Comment 45 Harald Hoyer 2010-07-08 04:45:49 EDT
rawhide's udev is not involved in the problem.
Comment 46 Armelius Cameron 2012-06-03 08:32:09 EDT
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.
Comment 47 Andre Robatino 2012-06-03 14:55:31 EDT
I don't know if it's the same bug, but reopened it and changed Version to 16.
Comment 48 Fedora End Of Life 2013-01-16 20:10:34 EST
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
Comment 49 Fedora End Of Life 2013-02-13 21:40:19 EST
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.

Note You need to log in before you can comment on or make changes to this bug.