Processing commands for cont...@bugs.debian.org:
> reassign 644876 mdadm
Bug #644876 [initramfs-tools] initramfs-tools: Boot failure from software RAID1
+ LVM2 by timing of mdadm + lvm initiation
Bug reassigned from package 'initramfs-tools' to 'mdadm'.
No longer marked as found in versions initr
reassign 644876 mdadm
tags 644876 + patch
thanks
Le mercredi 14 mars 2012 à 01:29, d'après
Dave Whitla :
> 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 replace the above with:
>
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
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 ver
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).
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
experimenta
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
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-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact li
also sprach Jort Koopmans [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, since this machi
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
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
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 [2011.10.12.2143
+0200]:
> > Common guys...can somebody look at my bugreport?
>
> We have. Let me offer some suggestions:
>
> - two days in FLOSS time is n
Thursday, October 13, 2011 9:06 AM martin f krafft wrote:
>also sprach Jort Koopmans [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.
also sprach Jort Koopmans [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 delay finding the ROOT d
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 ar
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)
|
init
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 b
17 matches
Mail list logo
