Bug 1472999 - ValueError: device is already in tree
ValueError: device is already in tree
Status: NEW
Product: Fedora
Classification: Fedora
Component: python-blivet (Show other bugs)
26
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: blivet-maint-list@redhat.com
Fedora Extras Quality Assurance
abrt_hash:a6be6482f134a9b6db36de07b3a...
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-19 15:44 EDT by larsehauge
Modified: 2017-10-28 18 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-20 13:25:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: anaconda-tb (386.08 KB, text/plain)
2017-07-19 15:44 EDT, larsehauge
no flags Details
File: anaconda.log (8.53 KB, text/plain)
2017-07-19 15:44 EDT, larsehauge
no flags Details
File: environ (508 bytes, text/plain)
2017-07-19 15:44 EDT, larsehauge
no flags Details
File: journalctl (255.78 KB, text/plain)
2017-07-19 15:44 EDT, larsehauge
no flags Details
File: lsblk_output (3.58 KB, text/plain)
2017-07-19 15:44 EDT, larsehauge
no flags Details
File: nmcli_dev_list (2.10 KB, text/plain)
2017-07-19 15:44 EDT, larsehauge
no flags Details
File: os_info (518 bytes, text/plain)
2017-07-19 15:44 EDT, larsehauge
no flags Details
File: program.log (31.07 KB, text/plain)
2017-07-19 15:44 EDT, larsehauge
no flags Details
File: storage.log (77.02 KB, text/plain)
2017-07-19 15:44 EDT, larsehauge
no flags Details
File: ifcfg.log (3.40 KB, text/plain)
2017-07-19 15:44 EDT, larsehauge
no flags Details
Requested logs generated by anaconda crash reporter (136.38 KB, application/octet-stream)
2017-10-20 12:26 EDT, Dennis W. Tokarski
no flags Details
Archive of VM log files from failed f26 install described in previous post. (72.64 KB, application/octet-stream)
2017-10-28 18:26 EDT, Dennis W. Tokarski
no flags Details

  None (edit)
Description larsehauge 2017-07-19 15:44:21 EDT
Description of problem:
Having trouble installing both Fedora 26 from USB and Fedora 25 from DVD.

This report is from the USB with Fedora 26.
The installer is started, but the error message with unknown error comes as soon as user input is required.

I tried to update the BIOS after failing to install Fedora. 
However that also failed, but luckly the computer rebooted as normal afterwards.
Not sure if these to issues are connected.

Any assistance would be highly appreciated.

Lars

Version-Release number of selected component:
anaconda-core-26.21.11-1.fc26.x86_64

The following was filed automatically by anaconda:
anaconda 26.21.11-1 exception report
Traceback (most recent call first):
  File "/usr/lib/python3.6/site-packages/blivet/devicetree.py", line 148, in _add_device
    raise ValueError("device is already in tree")
  File "/usr/lib/python3.6/site-packages/blivet/threads.py", line 45, in run_with_lock
    return m(*args, **kwargs)
  File "/usr/lib/python3.6/site-packages/blivet/populator/helpers/partition.py", line 111, in run
    self._devicetree._add_device(device)
  File "/usr/lib/python3.6/site-packages/blivet/populator/populator.py", line 306, in handle_device
    device = helper_class(self, info).run()
  File "/usr/lib/python3.6/site-packages/blivet/threads.py", line 45, in run_with_lock
    return m(*args, **kwargs)
  File "/usr/lib/python3.6/site-packages/blivet/populator/populator.py", line 154, in _add_slave_devices
    self.handle_device(slave_info)
  File "/usr/lib/python3.6/site-packages/blivet/threads.py", line 45, in run_with_lock
    return m(*args, **kwargs)
  File "/usr/lib/python3.6/site-packages/blivet/populator/helpers/mdraid.py", line 55, in run
    self._devicetree._add_slave_devices(self.data)
  File "/usr/lib/python3.6/site-packages/blivet/populator/populator.py", line 306, in handle_device
    device = helper_class(self, info).run()
  File "/usr/lib/python3.6/site-packages/blivet/threads.py", line 45, in run_with_lock
    return m(*args, **kwargs)
  File "/usr/lib/python3.6/site-packages/blivet/populator/helpers/mdraid.py", line 216, in run
    self._devicetree.handle_device(array_info, update_orig_fmt=True)
  File "/usr/lib/python3.6/site-packages/blivet/populator/populator.py", line 345, in handle_format
    helper_class(self, info, device).run()
  File "/usr/lib/python3.6/site-packages/blivet/threads.py", line 45, in run_with_lock
    return m(*args, **kwargs)
  File "/usr/lib/python3.6/site-packages/blivet/populator/populator.py", line 318, in handle_device
    self.handle_format(info, device)
  File "/usr/lib/python3.6/site-packages/blivet/threads.py", line 45, in run_with_lock
    return m(*args, **kwargs)
  File "/usr/lib/python3.6/site-packages/blivet/populator/populator.py", line 519, in _populate
    self.handle_device(dev)
  File "/usr/lib/python3.6/site-packages/blivet/threads.py", line 45, in run_with_lock
    return m(*args, **kwargs)
  File "/usr/lib/python3.6/site-packages/blivet/populator/populator.py", line 454, in populate
    self._populate()
  File "/usr/lib/python3.6/site-packages/blivet/threads.py", line 45, in run_with_lock
    return m(*args, **kwargs)
  File "/usr/lib/python3.6/site-packages/blivet/blivet.py", line 271, in reset
    self.devicetree.populate(cleanup_only=cleanup_only)
  File "/usr/lib/python3.6/site-packages/blivet/threads.py", line 45, in run_with_lock
    return m(*args, **kwargs)
  File "/usr/lib/python3.6/site-packages/blivet/osinstall.py", line 1175, in storage_initialize
    storage.reset()
  File "/usr/lib64/python3.6/threading.py", line 864, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib64/python3.6/site-packages/pyanaconda/threads.py", line 251, in run
    threading.Thread.run(self)
ValueError: device is already in tree

Additional info:
addons:         com_redhat_kdump
cmdline:        /usr/libexec/system-python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz root=live:CDLABEL=Fedora-WS-Live-26-1-5 rd.live.image quiet
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         4.11.8-300.fc26.x86_64
other involved packages: python3-blivet-2.1.9-1.fc26.noarch, system-python-libs-3.6.1-8.fc26.x86_64
product:        Fedora
release:        Fedora release 26 (Twenty Six)
type:           anaconda
version:        26
Comment 1 larsehauge 2017-07-19 15:44:28 EDT
Created attachment 1301305 [details]
File: anaconda-tb
Comment 2 larsehauge 2017-07-19 15:44:30 EDT
Created attachment 1301306 [details]
File: anaconda.log
Comment 3 larsehauge 2017-07-19 15:44:31 EDT
Created attachment 1301307 [details]
File: environ
Comment 4 larsehauge 2017-07-19 15:44:34 EDT
Created attachment 1301308 [details]
File: journalctl
Comment 5 larsehauge 2017-07-19 15:44:35 EDT
Created attachment 1301309 [details]
File: lsblk_output
Comment 6 larsehauge 2017-07-19 15:44:37 EDT
Created attachment 1301310 [details]
File: nmcli_dev_list
Comment 7 larsehauge 2017-07-19 15:44:39 EDT
Created attachment 1301311 [details]
File: os_info
Comment 8 larsehauge 2017-07-19 15:44:41 EDT
Created attachment 1301312 [details]
File: program.log
Comment 9 larsehauge 2017-07-19 15:44:43 EDT
Created attachment 1301313 [details]
File: storage.log
Comment 10 larsehauge 2017-07-19 15:44:44 EDT
Created attachment 1301314 [details]
File: ifcfg.log
Comment 11 larsehauge 2017-07-20 13:25:23 EDT
Solved it by disconnecting the other drives physically (disconnecting SATA).
Was then able to install Fedora. 

Closing the bug report.
Comment 12 Dennis W. Tokarski 2017-10-19 10:31:09 EDT
Similar problem has been detected:

Just start the installer for f26. Local dvd iso, netinstall, doesn't matter.
No user interaction is required.

When the first language selection window appears there will be a
brief pause--just a few seconds--then the unexpected error message
dialog pops up.

As usual since about f14, anaconda is puking on lvm-on-md. Some
releases have worked, most have not, and on a few it's the presence
of a luks layer in there somewhere which causes it to choke.  I have
lvm-on-luks-on-md (raid6).

Strangely, when I very wisely tested this scenario on a vm it worked.
Thus encouraged, I began the installation on real hardware and this
is the result.

This exact bug seems to have been reported in July. When I can get
logged into Bugzilla I'll look that up and put a pointer here.

addons:         com_redhat_docker, com_redhat_kdump
cmdline:        /usr/libexec/system-python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-S-dvd-x86_64-26 quiet
hashmarkername: anaconda
kernel:         4.11.8-300.fc26.x86_64
package:        anaconda-26.21.11-1
product:        Fedora
reason:         ValueError: device is already in tree
release:        Cannot get release name.
version:        26
Comment 13 Dennis W. Tokarski 2017-10-19 10:45:28 EDT
Ah, I see the installer bug reporter dropped this into the existing bug report.

This really should not have been closed. Having to rip open the system and physically disconnect random drives until the installer starts to work is >>NOT<< a solution.
Comment 14 Jiri Konecny 2017-10-20 04:37:15 EDT
Hello Dennis,

First, we didn't close the bug reporter does.

Second, in general it is not that easy support everything users can create. There are really big number of configurations users can create and everything is still evolving so please bear with us.

I'm opening this issue and changing components to the storage library.
Comment 15 David Lehman 2017-10-20 11:16:42 EDT
Dennis, can you attach the logs from your failed installation?
Comment 16 Dennis W. Tokarski 2017-10-20 12:26 EDT
Created attachment 1341336 [details]
Requested logs generated by anaconda crash reporter

This log set is one I had saved from the boot attempt just prior to the one which generated the auto-report. Nothing was changed between the two occasions and the observed behavior was identical.

Oh btw, this machine has two raid6 arrays of four drives each. The production set is 4x1TB and the other is 4x250GB. The latter is just used for as-needed bulk storage. The logs I just provided ran on that configuration.

I have since followed lars' inspiration and removed the SATA interface card for the bulk store array, leaving just the production array and a couple of DVD drives. Rebooting the installer produced the same result.
Comment 17 David Lehman 2017-10-20 13:21:34 EDT
The root cause of the problem you are having, Dennis, is that sda and sdi both have the same "UUID" value of "aaaaaaaa", which leads to partitions sda1 and sdi1 both having the same UUID: "aaaaaaaa-1". There is a requirement that UUIDs actually be unique. I don't know off the top of my head how to change one of them to satisfy this requirement.
Comment 18 David Lehman 2017-10-20 13:22:44 EDT
To clarify, I'm referring to the partition table UUID, on which the partition UUIDs are based.
Comment 19 David Lehman 2017-10-20 14:13:10 EDT
The original reporter apparently cloned the partition table on one drive across at least two others without modifying the duplicates so their UUIDs were unique.
Comment 20 Dennis W. Tokarski 2017-10-28 18:17:07 EDT
OK, now that's just bizarre. Not the UUID uniqueness requirement,
that's entirely reasonable. It's also new with f25, by the way,
which explains why I've never run into this before.

No, what was bugging me here is how my partition UUIDs came to
be 0xaaaaaaaa in the first place. I could just--barely!--accept
that I hit that lucky one in 2^32 chance on one of them. But
that and two others as well? No. Just no.

I'm pretty sure what happened is this...

This is a multiboot system (was f18/16/14) and what's now the
bulk store array used to be the production array. When the
4x1TB hardware arrived and it came time to install f20, I
would have hooked up the new drives to the f18 system and
tested them with badblocks.  Probably at some point once it
finished I started another round and then decided not to
wait for it, interrupting part way into the write-pattern-
0xAA pass.

Then I would have manually partitioned the first 1TB drive
and cloned the remainders with

   sfdisk-d /dev/sde | sfdisk /dev/sdf ... then g and h.

When this is done using f18 sfdisk, the label-id is not
copied, at least not if the destination is already non-0,
and neither is a new one generated. So there I had three
drives with all 0xaa for UUIDs. And no installation I've
ever done since has cared until now. Which is fine.

I made up a VM to test this scenario, tried the f26 install
on it, and got the result reported here. So far so good.
Then I used hexedit to give the last three drives unique
UUIDs, after which the installation showed the first
language selection display, blanked the screen, and did
nothing more. On vc 1 at the bottom of the screen it
said "Pane is dead".

Since editing the UUIDs didn't seem to cause any harm 
I tried this on the bare metal machine. There the install
finished without issue, leaving me with a shiny new
f26 system. No idea why that worked and the VM didn't.

So, my immediate problem here is solved now that you've
identified that crucial clue. Thanks for that!

There remains the mystery of why the similarly configured
VM wouldn't install and what the different failure mode
means.

I will attach the VM logs in case you care to pursue that.
Comment 21 Dennis W. Tokarski 2017-10-28 18:26 EDT
Created attachment 1344884 [details]
Archive of VM log files from failed f26 install described in previous post.

I've also prepared an archive containing these logs,
a README, and the qcow2 images of the four drives
used by the VM as well as the xml machine definition.

It's 6+ GB though. If you want to look at this I can
push it up to a host with a faster connection than
I've got. It'll take a while to make available.

Let me know if you want it.

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