* maximilian attems <[EMAIL PROTECTED]> [20070315 01:15]:
> On Thu, Mar 15, 2007 at 12:17:33AM +0100, Michael Prokop wrote:
> > * David Härdeman <[EMAIL PROTECTED]> [20070314 20:58]:
[...]
> > It would be fine to provide some output while running the "sleep
> > $ROOTDELAY" so users without usplas
On Thu, Mar 15, 2007 at 12:17:33AM +0100, Michael Prokop wrote:
> * David Härdeman <[EMAIL PROTECTED]> [20070314 20:58]:
>
> > Feel free to install the new initramfs-tools, then apply the
> > above patch to udev, install, regenerate the initramfs image and
> > try booting with rootdelay=20 and
* David Härdeman <[EMAIL PROTECTED]> [20070314 20:58]:
> Feel free to install the new initramfs-tools, then apply the
> above patch to udev, install, regenerate the initramfs image and
> try booting with rootdelay=20 and see if it pauses 20 secs at the
> right stage of the boot.
Ok, just veri
On Fri, Feb 23, 2007 at 04:55:00PM +0100, maximilian attems wrote:
On Fri, Feb 23, 2007 at 04:39:52PM +0100, David Härdeman wrote:
On Fri, February 23, 2007 16:28, maximilian attems said:
No, unfortunately it seems that the times between loading the usb host
controller, loading usb-storage and s
On Fri, Feb 23, 2007 at 04:39:52PM +0100, David Härdeman wrote:
> On Fri, February 23, 2007 16:28, maximilian attems said:
>
> No, unfortunately it seems that the times between loading the usb host
> controller, loading usb-storage and spawning the usb-storage-scan thread
> are all asynchronous. S
On Fri, February 23, 2007 16:28, maximilian attems said:
> On Fri, Feb 23, 2007 at 03:05:44PM +0100, David Härdeman wrote:
>> Exactly, considering the low amount of complaints, I'd say there's a
>> tiny minority that is actually affected by this bug.
>>
>> Secondly, there is no way to have the band
On Fri, Feb 23, 2007 at 03:05:44PM +0100, David Härdeman wrote:
>
> Exactly, considering the low amount of complaints, I'd say there's a tiny
> minority that is actually affected by this bug.
>
> Secondly, there is no way to have the bandaid-wait for usb-storage users
> only, instead it would hit
On Fri, February 23, 2007 14:16, maximilian attems said:
> On Fri, Feb 23, 2007 at 01:46:08PM +0100, David Härdeman wrote:
>> On Fri, February 23, 2007 12:11, maximilian attems said:
>> > On Fri, 23 Feb 2007, David Härdeman wrote:
>
>> > mika's case is general enough, it affects lilo on almost any
On Fri, Feb 23, 2007 at 01:46:08PM +0100, David Härdeman wrote:
> On Fri, February 23, 2007 12:11, maximilian attems said:
> > On Fri, 23 Feb 2007, David Härdeman wrote:
> > mika's case is general enough, it affects lilo on almost any
> > root beside ide and quick sata controller
> > and grub for
On Fri, February 23, 2007 12:11, maximilian attems said:
> On Fri, 23 Feb 2007, David Härdeman wrote:
>
>> maks...any progress on this bug?
>
> no.
> latest initramfs-tools is on mentors without any #401916 yet.
>
>> A new package which exports ROOTDELAY would be nice, then the rest can
>> be fixed
On Fri, 23 Feb 2007, David Härdeman wrote:
> maks...any progress on this bug?
no.
latest initramfs-tools is on mentors without any #401916 yet.
> A new package which exports ROOTDELAY would be nice, then the rest can be
> fixed in udev...
well i don't feel that is enough.
mika's case is genera
maks...any progress on this bug?
A new package which exports ROOTDELAY would be nice, then the rest can be
fixed in udev...
--
David Härdeman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Mon, Feb 19, 2007 at 11:36:29PM +0100, Michael Prokop wrote:
* David Härdeman <[EMAIL PROTECTED]> [20070219 22:15]:
+# Check for problematic devices
+problem=0
+
+# USB / FireWire
+if $(grep -q "usb\|ieee1394" /proc/devices); then
+ problem=1
+fi
How about:
if $(ps | grep -q usb-stor
On Mon, Feb 19, 2007 at 11:02:10PM +0100, maximilian attems wrote:
Quoting David Härdeman <[EMAIL PROTECTED]>:
I've attached a patch against the udev and initramfs-tools source
packages that implement the following changes...please review:
...
2) Checks in udev for scsi/firewire/usb have been a
* David Härdeman <[EMAIL PROTECTED]> [20070219 22:15]:
> I've attached a patch against the udev and initramfs-tools source packages
> that implement the following changes...please review:
> 1) ROOTDELAY is exported by initramfs-tools and used in udev if set
> 2) Checks in udev for scsi/fire
Bonsoir David!
ok back after reading some code. :)
Quoting David Härdeman <[EMAIL PROTECTED]>:
> Oh, I missed that variable...I've written a patch now to export it.
yup ack.
> I've attached a patch against the udev and initramfs-tools source
> packages that implement the following changes..
Quoting Frans Pop <[EMAIL PROTECTED]>:
> On Monday 19 February 2007 21:22, David Härdeman wrote:
> > The only problem with the approach is that a large majority of all
> > machines have usb which means that we'll slow down the boot for all
> > those machines even though a small minority are affec
Frans Pop wrote:
On Monday 19 February 2007 21:22, David Härdeman wrote:
The only problem with the approach is that a large majority of all
machines have usb which means that we'll slow down the boot for all
those machines even though a small minority are affected.
That's a very, very ugly sol
On Monday 19 February 2007 21:22, David Härdeman wrote:
> The only problem with the approach is that a large majority of all
> machines have usb which means that we'll slow down the boot for all
> those machines even though a small minority are affected.
That's a very, very ugly solution then. I'd
On Mon, Feb 19, 2007 at 07:21:08PM +0100, maximilian attems wrote:
heya david,
Hey Maks :)
On Fri, 16 Feb 2007, David Härdeman wrote:
Short-term solution:
Therefore, I think the best short-term solution (considering the
ever-impending Etch release) would be to add the "root_wait=" boot
para
heya david,
thanks for your excellent writeup.
yes i fully agree with your analysis,
will just followup on small nits..
On Fri, 16 Feb 2007, David Härdeman wrote:
> Short-term solution:
>
> Therefore, I think the best short-term solution (considering the
> ever-impending Etch release) would be
I've spent more time researching this by reading kernel code, checking the
boot process of other distros and trolling through mailing list archives
and I think I have a pretty good picture of the problem now.
Description:
Basically udevsettle will return once all modules have been loaded and no
Have any of you guys who can reproduce this been able to do the additional
tests suggested in the bug report yet? This is one of the few remaining RC
bugs which is present in both Etch and Sid so it would be nice to make
some progress...
--
David Härdeman
--
To UNSUBSCRIBE, email to [EMAIL PR
23 matches
Mail list logo
