Summary: | sys-fs/mdadm: handling root-on-raid in init.d on shutdown | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Duncan <1i5t5.duncan> |
Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED NEEDINFO | ||
Severity: | enhancement | CC: | fuzz, mattsch, mihais23, mmokrejs |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 119380 | ||
Bug Blocks: |
Description
Duncan
2012-05-01 15:29:18 UTC
blindly ignoring the return value isn't good. if we could tell mdadm to stop all devices except for ones listed on the command line, that might be a good extension. and if you could do it by mount point, that'd be even better. Just a "real world" update. I upgraded my system and am presently not running mdraid, tho I expect I will be again in the future. So I can't do any tests, etc, ATM. Here's a thought: With root on md/raid (at least without an initr* that starts it), the kernel must start at least the root md before launching usermode (init, etc), so the initscript (and mdadm itself) doesn't need to touch it. What about leaving the rootmd out of mdadm.conf? Then it won't try to start (ok, the kernel already starts it) or stop, thus eliminating the problem. The problem with that is that mdadm in monitor mode won't see it either, so one would have to monitor the rootmd some other way if desired. Also, without that md listed in mdadm.conf, mdadm maintenance on that md would be much more complicated, since all parameters would need supplied as they couldn't be pulled from mdadm.conf. Another alternative: Rewrite the initscript to take a list of mds to start and stop. It could then iterate that list, starting/stopping each one in the list specifically, instead of using mdadm's config to manage everything at once. Then the rootmd could simply be left out of that list, but it'd still be listed in mdadm.conf, so monitor mode would still see it, and the usual mdadm maintenance commands would "just work". But, that's a big change from the current script's solution of just letting udev and mdadm automate most of it. It's a lot of extra work, and would be a big enough change that it'd quite likely add a number of bugs and could possibly break currently working systems, if the admin wasn't paying attention when he upgraded and screwed up the config-file updates. Additionally, the way the current setup works, if there are md/raid devices that aren't normally started at boot, but that might be started manually by the admin later, the mdraid script will still catch and shut them down as long as they're in mdadm.conf. If we switched to specific md enumeration and only managed those in that list, it wouldn't shut down any others started manually during a session, as it does now. Cleaning out old bugs from the my bugs list I came across this one. Not only do I not use btrfs raid modes instead of mdraid these days, but I switched to systemd as well and am thus no longer tracking openrc initscripts. As I have no idea if this remains an issue or not, I'm closing it. If anyone on CC or coming across this bug believes it should still be open, please comment in an update dealing current status and I can reopen. Resolving as NEEDINFO for now. |