Am 27.02.2016 um 10:01 schrieb Mader, Alexander:
> On Fri, 26 Feb 2016 23:45:01 +0100 "Mader, Alexander" wrote:
>> On Mon, 22 Feb 2016 18:19:58 + Chris Boot wrote:
>>> Adding "rootdelay=15" to the kernel command-line probably fixes this
>>> (can't test as we can't just reboot this production se
Samuel Thibault, on Thu 10 Mar 2016 14:45:20 +0100, wrote:
> Dmitry Smirnov, on Mon 29 Feb 2016 18:46:10 +1100, wrote:
> > I tried adding "rootdelay=4" to kernel boot parameters but it did not help.
>
> I had tried rootdelay=15, it didn't help me either.
Ok, I had to increase that to 45 seconds t
Hello,
Dmitry Smirnov, on Mon 29 Feb 2016 18:46:10 +1100, wrote:
> I tried adding "rootdelay=4" to kernel boot parameters but it did not help.
I had tried rootdelay=15, it didn't help me either.
Samuel
I got hit by this regression too. :(
After recent update of one of my Jessie systems, new kernel 3.16.0-4 failed
to assemble healthy mdadm RAID:
1.665134] md0: failed to create bitmap (-22)
mdadm: failed to RUN_ARRAY /dev/md/0: Invalid argument
mdadm: /dev/md/1 has been started with 2 d
On Sat, 27 Feb 2016 10:01:21 +0100 "Mader, Alexander"
wrote:
> On Fri, 26 Feb 2016 23:45:01 +0100 "Mader, Alexander"
> wrote:
> > On Mon, 22 Feb 2016 18:19:58 + Chris Boot wrote:
> > > Adding "rootdelay=15" to the kernel command-line probably fixes this
> > > (can't test as we can't just reb
On Fri, 26 Feb 2016 23:45:01 +0100 "Mader, Alexander"
wrote:
> On Mon, 22 Feb 2016 18:19:58 + Chris Boot wrote:
> > Adding "rootdelay=15" to the kernel command-line probably fixes this
> > (can't test as we can't just reboot this production server at will) but
> > this isn't a nice fix.
> I j
On Mon, 22 Feb 2016 18:19:58 + Chris Boot wrote:
> Adding "rootdelay=15" to the kernel command-line probably fixes this
> (can't test as we can't just reboot this production server at will) but
> this isn't a nice fix.
Hello,
I just tried "rootdelay=15" as well as "rootdelay=30" to no avail.
Thanks. Would you be able at all check if the RAID was always rebuilt
on each boot? From past boot logs or some such.
Regards,
Dimitri.
On 22 February 2016 at 18:19, Chris Boot wrote:
> Hi folks,
>
> I think that this bug is a regression due to the fix for #784070, which
> was fairly recently p
Hi folks,
I think that this bug is a regression due to the fix for #784070, which
was fairly recently pushed to both unstable and *stable*. We have at
least one client server that got bitten by this and failed to boot.
I suspect the incremental assembly, which breaks booting from degraded
arrays,
Package: mdadm
Version: 3.3.2-5+deb8u1
Followup-For: Bug #814036
Dear Maintainer,
first of all: thank you for providing and maintaining this packeage for Debian!
* What led up to the situation?
After update to the current version around January, 23rd, or so the home volume
does not
assembl
Control: reassign -1 mdadm
On Sun, 2016-02-07 at 20:07 +0100, Samuel Thibault wrote:
> Package: initramfs-tools
> Version: 0.120
> Severity: important
>
> Hello,
>
> Our server failed to reboot this afternoon. initrd was stuck trying to
> get the root device, running local-block in a loop before
Package: initramfs-tools
Version: 0.120
Severity: important
Hello,
Our server failed to reboot this afternoon. initrd was stuck trying to
get the root device, running local-block in a loop before starting an
emergency shell. There, running mdam -A --scan discovered everything
and exitting the sh
12 matches
Mail list logo