* 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 usplash_write are
* 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 verified
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 see if it
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
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 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 general
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 in udev...
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:
snipp
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 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:
snipp
mika's case is general enough, it affects lilo on almost any
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 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 bandaid-wait
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. So we
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 to
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
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
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
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 affected.
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
* 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
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
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
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
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
23 matches
Mail list logo
