Created attachment 412615 [details]
Description of problem:
A LV could not be brought down since it was an active swap device.
Version-Release number of selected component (if applicable):
With the attached patch the install succeeded. I'm not entirely sure about it; will attach a complete backtrace as well so that you can eventually come up with a better solution.
Created attachment 412616 [details]
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release. Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release. This request is not yet committed for
I assume this is how you created the live images:
I'd like to know how did you start the installer: on livecd it's supposed to be run through the 'liveinst' script, which has an unconditional 'swapoff -a' call in it:
I tested F13 LiveCD with a swap on an LV and the install went smoothly.
(In reply to comment #5)
> I assume this is how you created the live images:
> I'd like to know how did you start the installer: on livecd it's supposed to be
> run through the 'liveinst' script, which has an unconditional 'swapoff -a' call
> in it:
That swapoff is way too early. The volume group in question was initialized by anaconda and a swap device with lv on it was also created. I'm not sure what called swapon against it, maybe it was anaconda as well?
> I tested F13 LiveCD with a swap on an LV and the install went smoothly.
That's strange, since I used Fedora scripts to build the live media. However, the issue is perfectly reproducible, so I suggest you try that yourself. Either build your own live media, or I can share mine somehow if you stop by at #fedora-cs.
We have fixes for livecds on RHEL-6, can we get a qa_ack please?
So far I have identified those two F13 fixes we need to merge over the rhel6 in order to fix this.
f8f27c14140377d9a9a6c3c32294f27ee771af1f (the core fix for this bug)
57b6bc9de084c36681ad35faaf9a258163634875 (arbitrary complex dir structures)
c971e7fe9c00e33c66118f3ef53b5ce764b02924 (selected keyboard)
ad8cbf88d3dfe2a0189f09392b4ab97698f43b80 (syslog file)
0c496dc1069cb56ce444c4a11b0469348dedcc1a (udev environment)
*** Bug 591399 has been marked as a duplicate of this bug. ***
those f13-patches will have to be merged too:
Should be working in anaconda-13.21.42-1.
Those patches were cherry-picked from f13 to fix this:
If I try a liveinst with anaconda-13.21.45-1.el6 I get.
umount: /media/*: not found
No volume groups found
Traceback (most recent call last):
File "/usr/sbin/anaconda", line 697, in <module>
File "/usr/sbin/anaconda", line 376, in check_memory
if opts.stage2.startswith(('http', 'ftp', '@')):
AttributeError: 'NoneType' object has no attribute 'startswith'
that's a known issue fixed in a later anaconda. See bug 595284.
I've done a default install with 0707.4 LiveCD image today. I've logged in into GNOME and started the anaconda installer via the desktop icon. I didn't get any traceback or error. Installation completed and I was able to boot into the newly installed system. Moving to VERIFIED.
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.