Bug 1302616 - Missing luks encrypted drive while choosing the install target
Missing luks encrypted drive while choosing the install target
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
23
Unspecified Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: David Lehman
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-28 04:38 EST by Kevin Raymond
Modified: 2016-12-20 13:15 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-20 13:15:32 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
journalctl (814.97 KB, text/plain)
2016-01-28 04:42 EST, Kevin Raymond
no flags Details

  None (edit)
Description Kevin Raymond 2016-01-28 04:38:30 EST
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 Kevin Raymond 2016-01-28 04:42 EST
Created attachment 1119079 [details]
journalctl
Comment 2 Kevin Raymond 2016-01-28 04:42:25 EST
Oops, some shortcut just submitted my draft..

Bug issue:

Using F23 workstation Live install (usb), I could not select the luks encrypted drive. It is missing.

I tried to unlock it first before starting anaconda, and I got the following backtrace:

backtrace Traceback (most recent call last):
  File "/usr/lib64/python3.4/site-packages/pyanaconda/threads.py", line 253, in run
    threading.Thread.run(self, *args, **kwargs)
  File "/usr/lib64/python3.4/threading.py", line 868, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3.4/site-packages/blivet/osinstall.py", line 1157, in storageInitialize
    storage.reset()
  File "/usr/lib/python3.4/site-packages/blivet/blivet.py", line 279, in reset
    self.devicetree.populate(cleanupOnly=cleanupOnly)
  File "/usr/lib/python3.4/site-packages/blivet/devicetree.py", line 554, in populate
    self._populator.populate(cleanupOnly=cleanupOnly)
  File "/usr/lib/python3.4/site-packages/blivet/populator.py", line 1623, in populate
    self._populate()
  File "/usr/lib/python3.4/site-packages/blivet/populator.py", line 1692, in _populate
    self.addUdevDevice(dev)
  File "/usr/lib/python3.4/site-packages/blivet/populator.py", line 715, in addUdevDevice
    device = self.addUdevDMDevice(info)
  File "/usr/lib/python3.4/site-packages/blivet/populator.py", line 305, in addUdevDMDevice
    slave_devices = self._addSlaveDevices(info)
  File "/usr/lib/python3.4/site-packages/blivet/populator.py", line 274, in _addSlaveDevices
    raise DeviceTreeError(msg)
blivet.errors.DeviceTreeError: failed to add slave fedora-00 of device luks-8e2ebe1b-5846-4f14-8808-bf7280b3325c
Comment 3 David Lehman 2016-01-28 09:41:38 EST
The LUKS-encrypted devices in your system are LVM logical volumes -- not drives. I say that not to be argumentative, but because it's a very important distinction. When you select disks, you are only going to be presented with disks -- not LVM logical volumes. The part where you deal with LVM logical volumes is later, and only if you choose to configure storage manually. What you want to do on the disk selection screen is select the disks that you want to make available. After that, you will deal with devices contained by those disks in a separate step. Please try again and report back with your results.
Comment 4 Kevin Raymond 2016-01-28 09:50:27 EST
Yes sure, sorry for the distinction.

To be precise, I have the following hard drives:
1 SSD 128 GB
2 HDD 500 GB each under a RAID 1 container

At first stage, Anaconda only offers me the SSD and the USB dongle.
I can't select the Hard drive.

The device are found, and I am able to mount the HDD using nautilus.
But if I try to start anaconda with this disk unlocked, I get the backtrace.


My first issue is understanding why anaconda does not show this disk. It should be about the RAID thing and not the LUKS LVM volumes as you explained.
My actual system has been installed using anaconda under F20.
But with an other computer, same configuration (RAID1) it passed.

I will probably install in the SSD only to add later the HDD to hold /home (my initial wish) to move forward.

Tell me if I can try debug a bit more.
Thx
Comment 5 David Lehman 2016-01-28 10:40:05 EST
I did notice that sda is marked as a spare in the fwraid array, which means the array only has one active member: sdb. This is not a configuration we support installing to since RAID arrays must meet basic requirements such as not being degraded (a single-member RAID1 is degraded) before being considered suitable as a target for an OS installation.
Comment 6 Kevin Raymond 2016-01-29 05:23:23 EST
ok thanks for the clue.
I do not know why the secondary disk has been defined as spare. I don't know deeply how works hardware RAID controllers, I haven't changed default settings from the previous install.

However I noticed that under the Fedora 23 Live I have only one disk under /dev/md*. Under Fedora 20 I had two, but only one active reading "mdadm --detail /dev/md127" (or 126..) (I tried to grow the container but it was asking for two spares..)

I just dropped the partition table of the disks. And was able to select it under Anaconda.
After a fresh install of Fedora 23, I had two active RAID disks under the array.
But after a reboot, I don't have any /dev/md* devices.
There might be something to configure there.

Thanks for your help.
At least, can't we have a warning about hidden disks?

This ticket might be invalid...
Comment 7 Fedora End Of Life 2016-11-24 10:14:29 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. 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 '23'.

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 23 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.
Comment 8 Fedora End Of Life 2016-12-20 13:15:32 EST
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 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. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.