[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RAID installation (Kirkwood) QNAP TS-420U

On Sat, 2015-07-11 at 15:05 +0200, Nagel, Peter (IFP) wrote:
> Am 11.07.2015 um 11:12 schrieb Ian Campbell:
> > According to my reading of the release notes that you linked to either
> > nofail or noauto on the appropriate line in the fstab is supposed to do
> > just that. Reading further at
> > http://www.freedesktop.org/software/systemd/man/systemd.mount.html I
> > think nofail is the one you want in your particular case:
> >
> >          With nofail this mount will be only wanted, not required, by
> >          local-fs.target or remote-fs.target. This means that the boot
> >          will continue even if this mount point is not mounted
> >          successfully.
> >
> > You might need to regenerate the initramfs and reflash the kernel+initrd
> > afterwards.
> >
> > Ian.
> May be I'm wrong but I thought the options "nofail" and "noauto" are 
> recommended for removable or optional mount points only

noauto mostly is as you say. However nofail (AIUI) just means "carry on
even if this device cannot be mounted", which I thought would apply to
your case, but I think I've misunderstood the situation because...

>  - in my case the 
> raid device is used for the root-partition (/).

... there is no way of continuing without the root partition.

So I'm afraid this has been a red-herring, sorry.

I was about to suggest that you start by filing a bug against the
"mdadm" package (the RAID utilities), since the maintainers of that
ought to be best placed to either fix the issue or identify the actual
subsystem which isn't behaving. However there looks to be a few entries
in https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=mdadm which seem
relevant to your situation, e.g. #770002, #714155. If having looked
through that list and found the none of them seem to apply to your case
then I would suggest filing a bug against that package.

Alternatively you might first want to try the debian-users list for more
generic user support rather than the ARM specific knowledge of the folks
on this list.


Reply to: