| Summary: | /dev/md/ symlinks are not always created | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Marius Vollmer <mvollmer> |
| Component: | mdadm | Assignee: | Nigel Croxon <ncroxon> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 24 | CC: | agk, dledford, Jes.Sorensen, mvollmer, ncroxon, xni |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-02 13:20:24 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. This is not an issue. One has to reboot to get the symlink. (In reply to Nigel Croxon from comment #2) > This is not an issue. One has to reboot to get the symlink. Ouch, this is quite disappointing, IMO. (In reply to Marius Vollmer from comment #3) > (In reply to Nigel Croxon from comment #2) > > This is not an issue. One has to reboot to get the symlink. > > Ouch, this is quite disappointing, IMO. Also, is it a bug that "--assemble --scan" creates the symlink (which you might fix), or can we rely on that? Have you tested an upstream kernel? Does it react the same way? (In reply to Nigel Croxon from comment #5) > Have you tested an upstream kernel? No. Could you answer the question in comment 4? > Also, is it a bug that "--assemble --scan" creates the symlink (which you might fix), or can we rely on that? No you can not rely on that. You must reboot to be in a known good state. |
Description of problem: Sometimes a mdraid device has a symlink in /dev/md/, sometimes it does not. Version-Release number of selected component (if applicable): mdadm-3.4-2.fc24.x86_64 How reproducible: 100% Steps to Reproduce: # mdadm --create /dev/md127 --run --level raid1 --name ARR --raid-devices 2 /dev/vdb /dev/vdc mdadm: Note: this array has metadata at the start and may not be suitable as a boot device. If you plan to store '/boot' on this device please ensure that your boot-loader understands md/v1.x metadata, or use --metadata=0.90 mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md127 started. # ls -l /dev/md/ ls: cannot access '/dev/md/': No such file or directory # mdadm --stop /dev/md127 mdadm: stopped /dev/md127 # mdadm --assemble --run /dev/md127 /dev/vdb /dev/vdc mdadm: /dev/md127 has been started with 2 drives. # ls -l /dev/md/ ls: cannot access '/dev/md/': No such file or directory # mdadm --stop /dev/md127 mdadm: stopped /dev/md127 # mdadm --assemble --run --scan --uuid 2a00b81e:afddd9dd:9c72d13d:0e72b02b mdadm: /dev/md/ARR has been started with 2 drives. # ls -l /dev/md/ total 0 lrwxrwxrwx. 1 root root 8 Nov 22 12:15 ARR -> ../md127 # reboot [...] # ls -l /dev/md/ total 0 lrwxrwxrwx. 1 root root 8 Nov 22 12:18 ARR -> ../md127 Actual results: The symlink in /dev/md/ is created by "--assemble --scan --uuid" and by a reboot, but not by "--create" or "--assemble" without "--scan". Expected results: The symlink is always created. Additional info: I am pretty sure this also happens on Fedora 25, but I did the steps above on Fedora 24 out of convenience. Because UDisks2 and Storaged use "--assemble --scan" to start a mdraid device, and because they prefer symlinks in /dev/md to /dev/md127 etc, the preferred device name of a mdraid device changes along a create/stop/start sequence.