Should disks in a raid really prevent booting?

[Tom H]

On Wed, Mar 25, 2015 at 4:54 PM, Roger Heflin <rogerheflin at gmail.com> wrote:
> On Wed, Mar 25, 2015 at 3:05 PM, Tom Horsley <horsley1953 at gmail.com> wrote:
>> On Wed, 25 Mar 2015 12:33:24 -0600, Ronal B Morse wrote:
>>>
>>> You might have to update dracut, too.
>>>
>>> I'm not sure what the relationship between dracut and RAID configuration
>>> is. Are RAIDs entered into the initramfs?
>>
>> I don't know if any raid config info is in there, but it
>> definitely needs additional drivers in the initramfs (that's
>> how I eventually got the system to boot).
>>
>> I'm suspecting it knows enough to recognize the some of the
>> raid metadata then gets upset because there is no raid
>> driver loaded. I just wonder if the response to that could
>> be more useful than hanging forever :-).
>
> you now need "nofail" as an option so the automatic systemd crap will
> not stop on a missing fs.
>
> And I have also noticed that once systemd parses the fstab file
> changing it won't work, you have to reboot it to get it to figure out
> you removed it.
>
> There is probably a way to cancel what systemd is doing, but rebooting
> after updating fstab is simpler.
>
> Using nofail and/or updating fstab (removing entries) has allowed me
> to reboot the machine and get it up--but you have to fix the issue or
> make changes and reboot to get systemd to not keep trying.

Please bottom post.

When systemd parses "/etc/fstab", it creates .mount units in
"/run/systemd/generator{,.late}/", so don't necessarily need to
reboot. You could edit "/etc/fstab", edit the .mount unit(s), run
"systemctl daemon-reload", and restart the .mount unit(s).