| Summary: | Fedora16 installer not detecting an existing installation on system with multipath | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | IBM Bug Proxy <bugproxy> | ||||||
| Component: | device-mapper-multipath | Assignee: | Ben Marzinski <bmarzins> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | urgent | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 16 | CC: | agk, anaconda-maint-list, bmarzins, dledford, dwysocha, fdinitto, g.kaviyarasu, hamzy, harald, heinzm, jkachuck, jonathan, kay, lvm-team, msnitzer, pknirsch, prockai, vanmeeuwen+fedora, wgomerin | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | ppc64 | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2013-02-14 00:56:04 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Attachments: |
|
||||||||
|
Description
IBM Bug Proxy
2012-01-23 16:21:59 UTC
------- Comment From hamzy.com 2012-01-23 14:10 EDT-------
[anaconda root@pfdioc03b ~]# vi /lib/udev/rules.d/10-dm.rules
[anaconda root@pfdioc03b ~]# cp /lib/udev/rules.d/10-dm.rules /etc/udev/rules.d/
[anaconda root@pfdioc03b ~]# udevadm control --reload-rules
[anaconda root@pfdioc03b ~]# multipath -F
[anaconda root@pfdioc03b ~]# ls -l /sys/devices/virtual/block
total 0
drwxr-xr-x. 8 root root 0 Jan 23 16:32 dm-0
drwxr-xr-x. 8 root root 0 Jan 23 16:32 loop0
drwxr-xr-x. 8 root root 0 Jan 23 16:32 loop1
drwxr-xr-x. 8 root root 0 Jan 23 16:32 loop2
drwxr-xr-x. 7 root root 0 Jan 23 16:32 loop3
drwxr-xr-x. 7 root root 0 Jan 23 16:32 loop4
drwxr-xr-x. 7 root root 0 Jan 23 16:32 loop5
drwxr-xr-x. 7 root root 0 Jan 23 16:32 loop6
drwxr-xr-x. 7 root root 0 Jan 23 16:32 loop7
Okay, I modified /lib/udev/rules.d/10-dm.rules to the above attached file. I then pressed the back button in the installer to the first screen. After unloading the multipath device and reloading udev rules, I went through the selection screens until the point where the existing OS should be detected (but hostname screen is shown).
DM_UDEV_HAMZY_START=1
DM_UDEV_HAMZY_START2=1
DM_UDEV_HAMZY_START3=1
DM_UDEV_HAMZY_START4=1
DM_UDEV_HAMZY_START5=1
DM_UDEV_HAMZY_START6=1
DM_UDEV_HAMZY_DONE=1
DM_UDEV_HAMZY_START=1
DM_UDEV_HAMZY_START2=1
DM_UDEV_HAMZY_START3=1
DM_UDEV_HAMZY_START4=1
DM_UDEV_HAMZY_START5=1
DM_UDEV_HAMZY_START6=1
DM_UDEV_HAMZY_DONE=1
DM_UDEV_HAMZY_START=1
DM_UDEV_HAMZY_START2=1
DM_UDEV_HAMZY_START3=1
DM_UDEV_HAMZY_START4=1
DM_UDEV_HAMZY_START5=1
DM_UDEV_HAMZY_START6=1
DM_UDEV_HAMZY_DONE=1
DM_UDEV_HAMZY_START=1
DM_UDEV_HAMZY_START2=1
DM_UDEV_HAMZY_START3=1
DM_UDEV_HAMZY_START4=1
DM_UDEV_HAMZY_START5=1
DM_UDEV_HAMZY_START6=1
DM_UDEV_HAMZY_DONE=1
DM_UDEV_HAMZY_START=1
DM_UDEV_HAMZY_START2=1
DM_UDEV_HAMZY_START3=1
DM_UDEV_HAMZY_START4=1
DM_UDEV_HAMZY_START5=1
DM_UDEV_HAMZY_START6=1
DM_UDEV_HAMZY_DONE=1
As you can see above, I am not creating a debug environment variable for one of the dm_disable conditions. It looks like it was imported from somewhere via:
IMPORT{db}="DM_UDEV_DISABLE_DISK_RULES_FLAG"
Created attachment 557033 [details]
10-dm.rules file with extra debugging variables
------- Comment (attachment only) From hamzy.com 2012-01-23 14:04 EDT-------
------- Comment From hamzy.com 2012-01-23 14:26 EDT------- I also check to see if /lib/udev/rules.d/11-dm-lvm.rule was setting the flag, but it does not look that way. [anaconda root@pfdioc03b ~]# for ((i = 0; i <= 4; i = i + 1)) do echo "=== dm-$i ==="; udevadm test --action=change /devices/virtual/block/dm-$i 2>&1 | grep DM_UDEV; done DM_UDEV_HAMZY_START=1 DM_UDEV_HAMZY_START2=1 DM_UDEV_HAMZY_START3=1 DM_UDEV_HAMZY_START4=1 DM_UDEV_HAMZY_START5=1 DM_UDEV_HAMZY_START6=1 DM_UDEV_HAMZY_DONE=1 DM_UDEV_YZMAH_START=1 DM_UDEV_YZMAH_START1=1 DM_UDEV_YZMAH_START2=1 DM_UDEV_YZMAH_LVM_DONE=1 DM_UDEV_HAMZY_START=1 DM_UDEV_HAMZY_START2=1 DM_UDEV_HAMZY_START3=1 DM_UDEV_HAMZY_START4=1 DM_UDEV_HAMZY_START5=1 DM_UDEV_HAMZY_START6=1 DM_UDEV_HAMZY_DONE=1 DM_UDEV_YZMAH_START=1 DM_UDEV_YZMAH_START1=1 DM_UDEV_YZMAH_START2=1 DM_UDEV_YZMAH_LVM_DONE=1 DM_UDEV_HAMZY_START=1 DM_UDEV_HAMZY_START2=1 DM_UDEV_HAMZY_START3=1 DM_UDEV_HAMZY_START4=1 DM_UDEV_HAMZY_START5=1 DM_UDEV_HAMZY_START6=1 DM_UDEV_HAMZY_DONE=1 DM_UDEV_YZMAH_START=1 DM_UDEV_YZMAH_START1=1 DM_UDEV_YZMAH_START2=1 DM_UDEV_YZMAH_LVM_DONE=1 DM_UDEV_HAMZY_START=1 DM_UDEV_HAMZY_START2=1 DM_UDEV_HAMZY_START3=1 DM_UDEV_HAMZY_START4=1 DM_UDEV_HAMZY_START5=1 DM_UDEV_HAMZY_START6=1 DM_UDEV_DISABLE_DISK_RULES_FLAG=1 DM_UDEV_HAMZY_DONE=1 DM_UDEV_YZMAH_START=1 DM_UDEV_YZMAH_START1=1 DM_UDEV_YZMAH_START2=1 DM_UDEV_YZMAH_LVM_DONE=1 DM_UDEV_HAMZY_START=1 DM_UDEV_HAMZY_START2=1 DM_UDEV_HAMZY_START3=1 DM_UDEV_HAMZY_START4=1 DM_UDEV_HAMZY_START5=1 DM_UDEV_HAMZY_START6=1 DM_UDEV_DISABLE_DISK_RULES_FLAG=1 DM_UDEV_HAMZY_DONE=1 DM_UDEV_YZMAH_START=1 DM_UDEV_YZMAH_START1=1 DM_UDEV_YZMAH_START2=1 DM_UDEV_YZMAH_LVM_DONE=1 Hey Harald,
Can you take a look at this defect? I don't know DM_UDEV_DISABLE_DISK_RULES_FLAG is being set. It seems that the line:
IMPORT{db}="DM_UDEV_DISABLE_DISK_RULES_FLAG"
Is pulling this flag from an internal database. What code is setting that flag inside udev?
Created attachment 557310 [details]
11-dm-lvm.rules file with extra debugging variables
------- Comment (attachment only) From hamzy.com 2012-01-24 15:41 EDT-------
(In reply to comment #4) > Hey Harald, > > Can you take a look at this defect? I don't know > DM_UDEV_DISABLE_DISK_RULES_FLAG is being set. It seems that the line: > > IMPORT{db}="DM_UDEV_DISABLE_DISK_RULES_FLAG" > > Is pulling this flag from an internal database. What code is setting that flag > inside udev? you have to ask the device-mapper/lvm guys. It's their flag, which they store in the udev DB basically, I think, it's because, if they have already seen the dm device and it's disabled, they set the flag in "/lib/udev/rules.d/10-dm.rules" Just read 10-dm.rules (and watch for "dm_disable") and ask the device-mapper team for details. ------- Comment From hamzy.com 2012-01-25 10:29 EDT------- As I've stated previously in the defect, I've included 10-dm.rules in this defect with a debugging version and none of the dm_disable gotos are being executed. Hey Doug, Could you take a look at this defect for me. I am trying to understand how this flag is being set in udev. How does the device-mapper/lvm2 code store this flag in the udev database? I am not seeing it set by the udev rules. Do you have some special API to tell udev to set flags? Also, Harald, have I written 10-dm.rules correctly to debug this problem? I'm not the right person to answer your questions. I handle the MD raid stuff, not the LVM/Multipath stuff. However, I would suggest looking in 40-multipath.rules as those are going to be relevant to these multipath devices. And I know they want to reference a multipath configuration file on the system during normal operation, I don't know if they are managing to pull that configuration off the hard disk during an upgrade however. Hi Kay, Can you help me debugging this problem? Have I written 10-dm.rules correctly to debug this problem? I suspect Ben Marzinski knows a lot more about the multipath part here as he's maintaining the device-mapper-multipath component. Anything you can see here going wrong, Ben? Thanks & regards, Phil Multipathd set that flag in order to keep blkid from running whenever the device is reloaded. If all paths are down and multipath is queueing IO, this will keep the the device stuck open. Unfortunately this is causing problems with reinstalls. The issue is that if udev doesn't run blkid on every udev change event, the data is removed from the udev database. It's possible to fix this in 10-dm.rules, but not without causing other issues. Since devices that are set to queue forever when all paths are down can get stuck open on any IO that happens to them after all paths have failed, we decided that solving this one case wasn't worth the other complications it created, so the patch that sets that flag will get removed in RHEL and fedora. I'm re-assigning this bug to device-mapper-multipath, unless anyone has any objections. This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. 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 WONTFIX if it remains open with a Fedora 'version' of '16'. 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 prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 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 to click on "Clone This Bug" and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |