Bug 787744

Summary: "rd.luks=0 rd.md=0 rd.dm=0" required for kernel boot, otherwise anaconda crashes
Product: [Fedora] Fedora Reporter: Josef Skladanka <jskladan>
Component: anacondaAssignee: Will Woods <wwoods>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: anaconda-maint-list, awilliam, g.kaviyarasu, jonathan, kparal, pcfe, robatino, samuel-rhbugs, satellitgo, vanmeeuwen+fedora
Target Milestone: ---Keywords: CommonBugs, Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: https://fedoraproject.org/wiki/Common_F17_bugs#pxe-plymouth-params RejectedBlocker AcceptedNTH
Fixed In Version: anaconda-17.14-1.fc17 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-03-23 17:45:56 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 494832, 752652    
Attachments:
Description Flags
Anaconda Logs
none
anaconda-tb-32yVOR
none
analyzer
none
architecture
none
cmdline
none
component
none
description
none
duphash
none
environ
none
event_log
none
executable
none
exnFileName
none
hashmarkername
none
hostname
none
kernel
none
os_release
none
package
none
product
none
reason
none
release
none
version none

Description Josef Skladanka 2012-02-06 16:09:58 UTC
Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Josef Skladanka 2012-02-06 16:14:21 UTC
/me hates that browser sends form on Enter...

Description of problem:

After booting into the installer, and clicking on "Basic Storage Devices", following error shows up.

Full logs are attached.

--

anaconda 17.5 exception report
Traceback (most recent call first):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 77, in getLUKSPassphrase
    raise RuntimeError("device is already mapped")
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 1224, in handleUdevLUKSFormat
    self.__passphrases)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 1703, in handleUdevDeviceFormat
    self.handleUdevLUKSFormat(info, device)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 1077, in addUdevDevice
    self.handleUdevDeviceFormat(info, device)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 1945, in _populate
    self.addUdevDevice(dev)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 1896, in populate
    self._populate(progressWindow)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 466, in reset
    cleanupOnly=cleanupOnly)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 102, in storageInitialize
    storage.reset()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 382, in dispatch
    self.dir = self.steps[self.step].target(self.anaconda)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 247, in go_forward
    self.dispatch()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/gui.py", line 1200, in nextClicked
    self.anaconda.dispatch.go_forward()
RuntimeError: device is already mapped

Comment 2 Josef Skladanka 2012-02-06 16:15:00 UTC
Created attachment 559678 [details]
Anaconda Logs

Comment 3 Brian Lane 2012-02-06 18:53:49 UTC
Please attach logs as individual plain/text attachments. It makes it much easier to evaluate bug than having to download and untar things locally.

Comment 4 Josef Skladanka 2012-02-07 08:53:07 UTC
Created attachment 559874 [details]
anaconda-tb-32yVOR

Attaching files separately

Comment 5 Josef Skladanka 2012-02-07 08:53:34 UTC
Created attachment 559875 [details]
analyzer

Comment 6 Josef Skladanka 2012-02-07 08:53:56 UTC
Created attachment 559876 [details]
architecture

Comment 7 Josef Skladanka 2012-02-07 08:54:23 UTC
Created attachment 559877 [details]
cmdline

Comment 8 Josef Skladanka 2012-02-07 08:54:46 UTC
Created attachment 559878 [details]
component

Comment 9 Josef Skladanka 2012-02-07 08:55:08 UTC
Created attachment 559879 [details]
description

Comment 10 Josef Skladanka 2012-02-07 08:55:28 UTC
Created attachment 559880 [details]
duphash

Comment 11 Josef Skladanka 2012-02-07 08:55:59 UTC
Created attachment 559881 [details]
environ

Comment 12 Josef Skladanka 2012-02-07 08:56:35 UTC
Created attachment 559882 [details]
event_log

Comment 13 Josef Skladanka 2012-02-07 08:57:07 UTC
Created attachment 559883 [details]
executable

Comment 14 Josef Skladanka 2012-02-07 08:57:36 UTC
Created attachment 559884 [details]
exnFileName

Comment 15 Josef Skladanka 2012-02-07 09:00:22 UTC
Created attachment 559886 [details]
hashmarkername

Comment 16 Josef Skladanka 2012-02-07 09:02:09 UTC
Created attachment 559887 [details]
hostname

Comment 17 Josef Skladanka 2012-02-07 09:02:48 UTC
Created attachment 559888 [details]
kernel

Comment 18 Josef Skladanka 2012-02-07 09:03:18 UTC
Created attachment 559889 [details]
os_release

Comment 19 Josef Skladanka 2012-02-07 09:06:36 UTC
Created attachment 559890 [details]
package

Comment 20 Josef Skladanka 2012-02-07 09:07:27 UTC
Created attachment 559891 [details]
product

Comment 21 Josef Skladanka 2012-02-07 09:07:52 UTC
Created attachment 559892 [details]
reason

Comment 22 Josef Skladanka 2012-02-07 09:08:21 UTC
Created attachment 559893 [details]
release

Comment 23 Josef Skladanka 2012-02-07 09:08:46 UTC
Created attachment 559894 [details]
version

Comment 24 Brian Lane 2012-02-07 17:18:54 UTC
Add this to your kernel cmdline. dracut needs to be told not to activate luks, md and dm:

rd.luks=0 rd.md=0 rd.dm=0

Comment 25 Josef Skladanka 2012-02-08 11:44:09 UTC
(In reply to comment #24)
Installation can be successfully completed, after adding these parameters to kernel cmdline.

Even though, this IMHO is an Alpha blocker per criterion "The installer must be able to complete an installation using the entire disk, existing free space, or existing Linux partitions methods, with or without encryption or LVM enabled."

Comment 26 Adam Williamson 2012-02-08 16:58:31 UTC
Brian, under what circumstances exactly will this bug be encountered?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 27 Brian Lane 2012-02-08 23:13:31 UTC
This was a problem with lorax. Fixed in lorax-17.3-1

Comment 28 Adam Williamson 2012-02-10 17:15:35 UTC
Discussed at blocker review meeting of 2012-02-10. Agreed to accept this as a blocker per criterion "The installer must be able to complete an installation using the text, graphical and VNC installation interfaces" to be on the safe side, though we'd really prefer to know exactly what the trigger for it is. This should be fixed in TC2, Josef please re-test. Thanks!



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 29 Brian Lane 2012-02-11 00:37:17 UTC
'rd.luks=0 rd.md=0 rd.dm=0' was missing from the boot cmdline generated by lorax so dracut would try to activate arrays and encrypted volumes.

Comment 30 Josef Skladanka 2012-02-16 10:45:08 UTC
I'm still hitting this bug, just tested on F17 Alpha RC2. Workaround still works.

Comment 31 Brian Lane 2012-02-16 15:29:47 UTC
What does your kernel cmdline look like? (cat /proc/cmdline from tty2)

Comment 32 Josef Skladanka 2012-02-20 12:59:33 UTC
(In reply to comment #31)
> What does your kernel cmdline look like? (cat /proc/cmdline from tty2)

Hi, sorry for the delay. The /proc/cmdline contains

repo=nfsiso:nfs.englab.brq.redhat.com:/pub/fedora/fedora-alt/stage/17-Alpha.RC2/Fedora/x86_64/iso/Fedora-17-Alpha-x86_64-DVD.iso root=live:http://download.englab.brq.redhat.com:/pub/fedora/fedora-alt/stage/17-Alpha.RC2/Fedora/x86_64/os/LiveOS/squashfs.img initrd=F17/Alpha.RC2/x86_64/initrd.img BOOT_IMAGE=F17/Alpha.RC2/x86_64/vmlinuz.

Comment 33 Josef Skladanka 2012-02-20 13:57:58 UTC
On the other hand, this might be related just to PXE boot, since I can't reproduce it with DVD image on USB stick.
Would this still count as an Alpha blocker?

Comment 34 Adam Williamson 2012-02-20 16:29:53 UTC
Booting via DVD with RC2 I do see rd.luks=0 rd.md=0 rd.dm=0 in the /proc/cmdline, so it does look like it's okay for non-PXE boot.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 35 Brian Lane 2012-02-20 16:43:06 UTC
Yes, you need to make sure 'rd.luks=0 rd.md=0 rd.dm=0' is included so that dracut doesn't activate any luks or RAID devices.

Comment 36 Josef Skladanka 2012-02-21 09:49:37 UTC
(In reply to comment #35)
> Yes, you need to make sure 'rd.luks=0 rd.md=0 rd.dm=0' is included so that
> dracut doesn't activate any luks or RAID devices.

Just to be sure - does this really mean, that _every_ PXE boot setup needs to add these parameters 'by hand'? I'd suppose that kernel & initrd should sort this out autonomously.

Comment 37 Adam Williamson 2012-02-21 16:19:15 UTC
Only PXE boots on systems which have LUKS or RAID devices. :)



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 38 Brian Lane 2012-02-21 18:25:29 UTC
(In reply to comment #36)
> (In reply to comment #35)
> > Yes, you need to make sure 'rd.luks=0 rd.md=0 rd.dm=0' is included so that
> > dracut doesn't activate any luks or RAID devices.
> 
> Just to be sure - does this really mean, that _every_ PXE boot setup needs to
> add these parameters 'by hand'? I'd suppose that kernel & initrd should sort
> this out autonomously.

No, you shouldn't need to do this by hand -- you just need to add it to the kernel cmdline in your PXE config file. And yes, they shouldn't be needed if there are no RAID or luks partitions on the target.

Comment 39 Josef Skladanka 2012-02-22 09:05:19 UTC
Which basically means, that every setup needs to add these parameters, as you (usually) can not be sure about the configuration of every machine. And on top of that, this works without any problem with F16 (the rd.foobar parameters are not included in the PXE config). So from my point of view, this behaviour looks like a regression bug.

So to update my question: What is the reason, for F17 behaving this way, when F16 is OK.

Comment 40 Brian Lane 2012-02-23 21:29:21 UTC
The initrd for f17 is different. It is a live system that launches anaconda. We are moving to try and make the installer more like a real system.

Comment 41 Kamil Páral 2012-02-24 09:46:51 UTC
Brian, does that mean that you can't force "rd.luks=0 rd.md=0 rd.dm=0" directly from your initrd? If it is technically possible, I don't see a reason to force all system administrators all over the world to add these options manually to every PXE setup out there. Of course it can documented, but approaches "that just work" are so much better. 

Thanks in advance for more detailed explanation.

Comment 42 Adam Williamson 2012-02-27 16:24:28 UTC
we should document this for alpha somehow.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 43 Adam Williamson 2012-02-28 06:41:45 UTC

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 44 Kamil Páral 2012-03-02 16:25:13 UTC
After discussion with bcl and wwoods on IRC I'm reopening this bug. It should be possible to set "rd.luks=0 rd.md=0 rd.dm=0" as defaults and therefore we wouldn't have to add it manually to pxe setups and patch virt-install and similar tools.

Comment 45 Kamil Páral 2012-03-07 13:02:17 UTC
This was already approved as an Alpha blocker, then it got closed and we lost track of it. Proposing as F17 Beta blocker (or Final), because 
a) this breaks some tools (like virt-install and virt-manager) 
b) forces PXE maintainers to fix all their setups 
c) crashes anaconda in certain cases (which fails release criteria).

Comment 46 Adam Williamson 2012-03-10 04:05:20 UTC
Discussed at 2012-03-09 blocker review meeting. Agreed the bug is rejected as a blocker: it doesn't really prevent direct kernel boot of the installer from working, you just need to specify some parameters for it. i.e. it's 'easily workaroundable'. accepted as NTH, if the fix is not too invasive. However, we would definitely like to see the bug fixed.

Note that the original report of this bug affected *all cases*, as it stands now, the bug affects only cases like PXE boot where the user manually specifies the kernel parameters - it's less serious than it used to be.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 47 Kamil Páral 2012-03-20 15:19:19 UTC
This seems to be fixed in F17 Beta TC2. Anaconda doesn't crash anymore and doesn't need those rd.* options on the command line.

Comment 48 Fedora Update System 2012-03-23 05:18:35 UTC
anaconda-17.14-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/anaconda-17.14-1.fc17

Comment 49 Fedora Update System 2012-03-23 17:10:39 UTC
Package anaconda-17.14-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-17.14-1.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-4546/anaconda-17.14-1.fc17
then log in and leave karma (feedback).

Comment 50 Fedora Update System 2012-03-23 17:45:56 UTC
anaconda-17.14-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.