we don't know which raids are required for rootfs, but using deduction,
once rootfs did appear we know which raids were not required.
So we could for each incomplete non-rootfs raid do:
mdadm --remove incomplete-md-device
arbitrary-member-device-of-incomplete-array
mdadm --incremental --run
But this needs re-testing with recent RAID package.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/259145
Title:
degraded NON-root raids never --run on boot
To manage notifications about this bug
This is an mdadm issue, not a mountall one.
** Changed in: mountall (Ubuntu)
Status: Triaged = Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/259145
Title:
degraded NON-root raids
** Changed in: mountall (Ubuntu)
Status: Incomplete = Triaged
--
degraded NON-root raids never --run on boot
https://bugs.launchpad.net/bugs/259145
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
Because they might change after a reboot?
We *explicitly* support people doing that.
Dropping to a rescue shell is the support if a new raid set up with
another (rescue) system comes up degraded upon reboot. But I don't see
why supporting that should prevent a proper raid setup. One that will
On Tue, 2010-04-20 at 16:22 +, ceg wrote:
Because they might change after a reboot?
We *explicitly* support people doing that.
Dropping to a rescue shell is the support if a new raid set up with
another (rescue) system comes up degraded upon reboot. But I don't see
why supporting
On Mon, 2010-04-19 at 09:39 +, ceg wrote:
I understand the md device dependencies are not available in fstab, I am
not sure though what should prevent going through the filesystems and
identifying their dependencies in the running system?
Because they might change after a reboot?
We
I understand the md device dependencies are not available in fstab, I am
not sure though what should prevent going through the filesystems and
identifying their dependencies in the running system?
In the suggestion the fstab gets merely used as a starting point, a list
of filesystems that get set
You said:
* For each filesystem mentioned in fstab that depends on a an array
This is the problem; fstab only gives us a filesystem UUID or LABEL in
many cases, we simply *DO NOT KNOW* that's going to turn out to be on a
RAID array.
--
degraded NON-root raids never --run on boot
Raid systems introduce redundancy to be able to keep working even if
parts of the system fail.
I think the init.d/mdadm scripts (early/late or simillar) that debian
uses to assemble and run degraded arrays on boot have been removed
because all arrays are set up using udev. But we don't have any
Sorry about the spam there, hit the wrong button.
The problem with this approach is that we generally don't *know* that a
given filesystem is on a degraded RAID, because the RAID is not
activated - so we can't see the filesystem UUID inside it.
mountall already provides the ability to drop to a
** Summary changed:
- degraded non-root raids don't appear on boot
+ degraded NON-root raids never --run on boot
--
degraded NON-root raids never --run on boot
https://bugs.launchpad.net/bugs/259145
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
** Description changed:
Systems with say /home on raid won't come up booting when raid was
degraded during downtime.
An init script like /etc/init.d/mdadm-degrade - or because of already
doing that kind of watchdog functionality - mountall needs to --run
particular necessary arrays
13 matches
Mail list logo
