Bug 1166876

Summary: Traceback trying virt URL install with F21 aarch64 tree
Product: [Fedora] Fedora Reporter: Cole Robinson <crobinso>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 21CC: amulhern, anaconda-maint-list, bcl, dlehman, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mchehab, vpodzime
Target Milestone: ---   
Target Release: ---   
Hardware: aarch64   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-11-21 21:25:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Full boot/install output none

Description Cole Robinson 2014-11-21 20:23:11 UTC
Created attachment 959964 [details]
Full boot/install output

I tried installing F21 aarch64 beta in a VM via virt-install's URL support. This essentially asks qemu to boot:

kernel=$TREE/os/images/pxeboot/vmlinuz
initrd=$TREE/os/images/pxeboot/initrd.img
kernelargs= inst.repo=$TREE

The tree I used is: http://dl.fedoraproject.org/pub/fedora-secondary/releases/test/21_Beta/Server/aarch64/os/

You can see more info about the virt setup here: https://fedoraproject.org/wiki/Architectures/AArch64/Install_with_QEMU

The kernel boots, dracut downloads the anaconda image, but we get a back trace from python-blivet before anaconda shows us anything:

Starting installer, one moment...
Traceback (most recent call last):
  File "/sbin/anaconda", line 919, in <module>
    from pyanaconda import geoloc
  File "/usr/lib64/python2.7/site-packages/pyanaconda/geoloc.py", line 109, in <module>
    from pyanaconda import network
  File "/usr/lib64/python2.7/site-packages/pyanaconda/network.py", line 40, in <module>
    from blivet.devices import FcoeDiskDevice, iScsiDiskDevice
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 74, in <module>
    from .devices import BTRFSDevice, BTRFSSubVolumeDevice, BTRFSVolumeDevice, DirectoryDevice, FileDevice, LVMLogicalVolumeDevice, LVMThinLogicalVolumeDevice, , NFSDevice, NoDevice, OpticalDevice, PartitionDevice, TmpFSDevice, devicePathToName
  File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 51, in <module>
    from .formats import get_device_format_class, getFormat, DeviceFormat
  File "/usr/lib/python2.7/site-packages/blivet/formats/__init__.py", line 510, in <module>
    collect_device_format_classes()
  File "/usr/lib/python2.7/site-packages/blivet/formats/__init__.py", line 108, in collect_device_format_classes
    globals()[mod_name] = __import__(mod_name, globals(), locals(), [], -1)
  File "/usr/lib/python2.7/site-packages/blivet/formats/fs.py", line 34, in <module>
    from .. import platform
  File "/usr/lib/python2.7/site-packages/blivet/platform.py", line 440, in <module>
    platform = getPlatform()
  File "/usr/lib/python2.7/site-packages/blivet/platform.py", line 438, in getPlatform
    raise SystemError("Could not determine system architecture.")
SystemError: Could not determine system architecture.

Pane is dead

Comment 2 David Shea 2014-11-21 20:32:32 UTC
In the future, please attach the log files from /tmp when reporting on a crash from anaconda, in particular the /tmp/anaconda-tb-* file.

In the case of aarch64, it should be detected as an efi platform, which blivet does by looking for the existence of /sys/firmware/efi. I notice these lines early in the boot messages:

[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi: UEFI not found.

So it looks like either a problem with the kernel or a problem in a dtb file.

Comment 3 Cole Robinson 2014-11-21 20:49:24 UTC
Hmm. Maybe qemu loading the kernel directly causes UEFI to be completely ignored.

Comment 4 Cole Robinson 2014-11-21 21:25:04 UTC

*** This bug has been marked as a duplicate of bug 1128341 ***