On Tue, Sep 20, 2005 at 11:28:17PM +0200, Marco d'Itri wrote: > FYI. It's unreproducible even by the submitter.
That's one of the problems with a synchronous udevstart. It should go away for a lot of other reasons too and I refused all the "coldplug" patches for udevstart for that reason. I expect udevstart kills (alarm) itself after 2 minutes, while it hangs in the *_id programs. There is no easy fix for this. Making udevsynthesize working good enough, which should not have this problem, seems like the best option. Kay > ----- Forwarded message from Stephen Frost <[EMAIL PROTECTED]> ----- > > Subject: Bug#329226: udevstart breaks when device not responding > Reply-To: Stephen Frost <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > X-Debian-PR-Message: report 329226 > X-Debian-PR-Package: udev > X-Debian-PR-Keywords: > From: Stephen Frost <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > > Package: udev > Version: 0.070-2 > Severity: Important > > Greetings, > > When installing udev for the first time on a system which has access > to snapshots of other partitions (on my SAN), and those snapshots were > disabled (which means IO failures when trying to read them), udev > failed to install rather badly. > > Populating the new /dev filesystem temporarily mounted on > /tmp/udev.vrFxvY/... > > ... > > [587655.084649] SCSI error : <5 0 0 0> return code = 0x8000002 > [587655.084682] sdc: Current: sense key: Hardware Error > [587655.084713] <<vendor>> ASC=0x84 ASCQ=0x0ASC=0x84 ASCQ=0x0 > [587655.084750] end_request: I/O error, dev sdc, sector 6 > > ... > > root 8075 0.0 0.0 2944 1424 pts/1 S+ 11:19 0:00 \ > /bin/sh -e /var/lib/dpkg/info/udev.postinst configure > root 8111 0.2 0.0 2200 1144 pts/1 S+ 11:19 0:00 \ > /sbin/udevstart > root 8480 0.0 0.0 1820 444 pts/1 D+ 11:19 0:00 \ > /sbin/vol_id --export /tmp/udev.gzcWTS/.tmp-8-32 > > ... > > dpkg: error processing udev (--configure): > subprocess post-installation script returned error exit status 1 > > ... > > I enabled the snapshots for the moment to get udev installed. I'm > curious as to what would happen if I rebooted while the snapshots were > disabled though. I do need udev, unfortunately, because multipath > depends on it. I'm pretty sure this is a situation udev needs to be > able to handle though. > > Thanks, > > Stephen > > ----- End forwarded message ----- > ----- Forwarded message from Stephen Frost <[EMAIL PROTECTED]> ----- > > Subject: Bug#329226: udevstart breaks when device not responding > Reply-To: Stephen Frost <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > X-Debian-PR-Message: report 329226 > X-Debian-PR-Package: udev > X-Debian-PR-Keywords: > From: Stephen Frost <[EMAIL PROTECTED]> > To: Marco d'Itri <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > X-Editor: Vim http://www.vim.org/ > X-Info: http://www.snowman.net > X-Operating-System: Linux/2.4.24ns.3.0 (i686) > X-Uptime: 12:19:49 up 101 days, 8:35, 12 users, load average: 0.07, 0.10, > 0.09 > X-Spam-Level: > X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER > autolearn=no version=2.60-bugs.debian.org_2005_01_02 > > * Marco d'Itri ([EMAIL PROTECTED]) wrote: > > On Sep 20, Stephen Frost <[EMAIL PROTECTED]> wrote: > > > dpkg: error processing udev (--configure): > > > subprocess post-installation script returned error exit status 1 > > Did you try to kill some process? I can't see how an error could be > > propagated from vol_id to postinst. > > Nope, I didn't kill any processes. It took it a while to fail. In case > it gets lost in irc: > > 12:10 <Snow-Man> Md: It's in the bug log > 12:11 <Snow-Man> Md: Basically, vol_id was failing. > 12:11 <Snow-Man> 'cause it was trying to read the device, and the device > was, like, 'uh, no.' > 12:11 <Snow-Man> I didn't kill off any processes, no... > 12:12 <Snow-Man> Md: Well, alright, vol_id was the process which was > running when I was seeing > stuff in dmesg show up (the stuff that's in the bug > log) > 12:12 <Snow-Man> Md: It's possible there was some other issue making > udevstart fail.. > 12:13 <Snow-Man> Md: But when I enabled the snapshots, I saw vol_id go > past the first set of things > it was being run on. > 12:13 <Snow-Man> (--export /tmp/udev.gzcWTS/.tmp-8-32 went to, like, > 8-16, etc, iirc) > 12:14 <Snow-Man> It looked like udevstart was running vol_id multiple > times, and checking if it > worked or not each time, and if it didn't, was exiting > unhappily. > > It seems to me that vol_id errors should probably be non-fatal, but I'm > not entirely sure what it's doing. In this instance I would still want > the appropriate scripts to be run for the device (to properly set up the > multipath stuff for the device) even if the device can't be read at the > moment. > > Thanks, > > Stephen > > > > ----- End forwarded message ----- > > -- > ciao, > Marco > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
