From: Lewis Shobbrook <mylists@blue-matrix.org>
To: dean gaudet <dean@arctic.org>
Cc: linux-raid@vger.kernel.org, dr@jones.dk
Subject: Re: Raid5 & Debian Yaird Woes
Date: Sat, 4 Feb 2006 09:58:17 +1100 [thread overview]
Message-ID: <200602040958.20183.mylists@blue-matrix.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0602021859490.15679@twinlark.arctic.org>
On Friday 03 February 2006 2:02 pm, you wrote:
Hi Dean,
Thanks for the suggestions.
> On Thu, 2 Feb 2006, dean gaudet wrote:
> > i've never looked at yaird in detail -- but you can probably use
> > initramfs-tools instead of yaird...
>
> i take it all back... i just tried initramfs-tools and it failed to boot
> my system properly... whereas yaird almost got everything right.
>
> the main thing i'd say yaird is doing wrong is that it is specifying the
> root raid devices explicitly rather than allowing mdadm to scan the
> partitions list and assemble by UUID...
>
> maybe try the patch below on your yaird configuration and then run:
>
> dpkg-reconfigure linux-image-`uname -r`
>
> which will rebuild your initrd with this change... then see if it survives
> your boot testing.
>
> -dean
>
> p.s. this patch has been submitted to debian bugdb...
>
> --- /etc/yaird/Templates.cfg 2006/02/03 02:44:49 1.1
> +++ /etc/yaird/Templates.cfg 2006/02/03 02:46:15
> @@ -299,8 +299,7 @@
> SCRIPT "/init"
> BEGIN
> !mknod <TMPL_VAR NAME=target> b <TMPL_VAR NAME=major> <TMPL_VAR
> NAME=minor> - !mdadm --assemble <TMPL_VAR NAME=target> --uuid <TMPL_VAR
> NAME=uuid> \ - ! <TMPL_LOOP NAME=components> <TMPL_VAR
> NAME=dev></TMPL_LOOP>
> + !mdadm -Ac partitions <TMPL_VAR NAME=target> --uuid <TMPL_VAR
> NAME=uuid> END SCRIPT
> END TEMPLATE
I applied the patch as well as modified the mdadm.conf, as you suggested in
the previous email, and the system restarted without problem!
A positive step forward.
Removing a drive however, results in a disruption to the boot process
requiring user input (ctrl D) in the admin console to kick things off again.
Notably it works from this point, where previously I had encountered kernel
panic.
Is there any way to avoid this requirement for input, so that the system skips
the missing drive as the raid/initrd system did previously?
If you have a system restart after a power outage combined with a degraded
array, the server would be unacceptably kept offline until manual
intervention occurred.
Cheers & Thanks,
Lewis
next prev parent reply other threads:[~2006-02-03 22:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-03 1:29 Raid5 & Debian Yaird Woes Lewis Shobbrook
2006-02-03 2:13 ` dean gaudet
2006-02-03 2:14 ` Lewis Shobbrook
2006-02-03 3:02 ` dean gaudet
2006-02-03 22:58 ` Lewis Shobbrook [this message]
2006-02-04 0:22 ` dean gaudet
2006-02-04 8:35 ` Jonas Smedegaard
2006-02-04 22:07 ` Lewis Shobbrook
2006-02-07 2:52 ` dean gaudet
2006-04-24 15:13 ` Jonas Smedegaard
2006-04-24 15:20 ` Jonas Smedegaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200602040958.20183.mylists@blue-matrix.org \
--to=mylists@blue-matrix.org \
--cc=dean@arctic.org \
--cc=dr@jones.dk \
--cc=linux-raid@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).