Control: fixed -1 3.2.5-6
On Sun, 2015-01-18 at 16:03 +, Ben Hutchings wrote:
Version: 3.3-1
The proposed change to udevadm was made in version 3.3-1 but was
accidentally omitted from the changelog.
Actually, it is mentioned in the changelog but in a version that was
never uploaded.
The wait_for_udev patch cannot possibly fix the original problem, of
md devices not starting because their components are slow to come up,
because the wait_for_udev only happens *after* the attempt to assemble
md devices. If you change nothing else, there's still only a single
attempt at
reassign 644876 mdadm
tags 644876 + patch
thanks
Le mercredi 14 mars 2012 à 01:29, d'après
Dave Whitla dave.whi...@wotifgroup.com :
The condition will never be true because udevsettle was a symlink to
/sbin/udevadm which has been absent from Debian since Lenny.
Try editing this file to
I believe this might be the culprit:
In /usr/share/initramfs-tools/scripts/local-top/mdadm:
if [ -x $(command -v udevsettle) ]; then
verbose log_begin_msg Waiting for udev to process events
udevsettle 10
verbose log_end_msg
fi
The condition will never be true because udevsettle was a
On Sun, 2011-10-23 at 14:05 +0300, Touko Korpela wrote:
[..]
madduck called testing for experimental version of mdadm. where it can be
downloaded?
My bad, I missed the initscripts package from sid (instead of testing).
I must note that none of the involved packages are available in
experimental
On Mon, Oct 24, 2011 at 11:01:01AM +0200, Jort Koopmans wrote:
On Sun, 2011-10-23 at 14:05 +0300, Touko Korpela wrote:
[..]
madduck called testing for experimental version of mdadm. where it can be
downloaded?
My bad, I missed the initscripts package from sid (instead of testing).
I must
On Mon, 2011-10-24 at 14:03 +0300, Touko Korpela wrote:
[..]
I know difference between sid and experimental. Is there more recent version
of mdadm available than is in sid now? (experimental suite doesn't have it)
Not that I know of. As you mention, experimental does not contain a
newer
Is there anything else I can do to triage this bug? I'd be happy to try
any suggestions to get this bug solved (in a future release).
Waiting for any response,
Jort Koopmans
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
On Sun, Oct 23, 2011 at 12:09:11PM +0200, Jort Koopmans wrote:
Is there anything else I can do to triage this bug? I'd be happy to try
any suggestions to get this bug solved (in a future release).
Waiting for any response,
Jort Koopmans
madduck called testing for experimental version of
also sprach Jort Koopmans jort.koopm...@gmail.com [2011.10.12.2143 +0200]:
In the mean while I've checked another solution; moving the call
to the local-top scripts till after the ROOTDELAY loop (within the
local file).
init-top/udev also uses it.
This works in my config. But this would
Thursday, October 13, 2011 9:06 AM martin f krafft wrote:
also sprach Jort Koopmans jort.koopm...@gmail.com [2011.10.12.2143 +0200]:
In the mean while I've checked another solution; moving the call
to the local-top scripts till after the ROOTDELAY loop (within the
local file).
init-top/udev
Hi Martin,
First of all, thanks for helping me out.
On Thu, 2011-10-13 at 11:10 +0200, martin f krafft wrote:
also sprach Jort Koopmans jort.koopm...@gmail.com [2011.10.12.2143
+0200]:
Common guys...can somebody look at my bugreport?
We have. Let me offer some suggestions:
- two days
Hi Will,
Instead of patching this here and there with band aids, I suggest
that everyone with an interest instead invests time in testing
mdadm/experimental, which provides event-based assembly,
I was wondering what documentation the reporter was following.
I haven't seen RAID on USB
Thursday, October 13, 2011 10:07 AM Jort Koopmans wrote:
Instead of patching this here and there with band aids, I suggest
that everyone with an interest instead invests time in testing
mdadm/experimental, which provides event-based assembly,
I was wondering what documentation the reporter
also sprach Jort Koopmans jort.koopm...@gmail.com [2011.10.13.1148 +0200]:
First of all, thanks for helping me out.
(I did not CC the bug report at the time…)
- if you are criticising initramfs/mdadm, then it helps to
reproduce the output you are seeing, ideally after set -x.
True,
Common guys...can somebody look at my bugreport?
In the mean while I've checked another solution; moving the call to the
local-top scripts till after the ROOTDELAY loop (within the local file).
This works in my config. But this would delay finding the ROOT dir in
normal instances (where devices
Additional thoughts;
As I'm no expert on the whole initramfs boot sequence I'm unsure about
the total workings of timing of device scanning, mdadm + lvm2 routines
and rootdelay.
Imho it should be something like this;
init Device scanning
|
some scanning delay parameter (for slow devices)
|
Package: initramfs-tools
Version: 0.98.8
Severity: important
Dear kernelteam,
After installing a vanilla debian kernel (2.6.32-5-amd64) to 2 similar USB
thumbdrives in software RAID1 and using LVM2 an error occurs at boot stating
ROOT can not be found. In my case / is locted on an lv managed
18 matches
Mail list logo
