Bug 1573538

Created attachment 1429297 [details]
fedora-28-ppc64le.ks

Created attachment 1429298 [details]
anaconda.log

Created attachment 1429299 [details]
dbus.log

Created attachment 1429300 [details]
program.log

Created attachment 1429301 [details]
syslog

Those are all the logs I have.  The other log files are all empty:

total 364
-rw-r--r--. 1 rjones rjones   5040 May  1 16:54 anaconda.log
-rw-r--r--. 1 rjones rjones   3603 May  1 16:54 dbus.log
-rw-r--r--. 1 rjones rjones      0 May  1 16:54 ifcfg.log
-rw-r--r--. 1 rjones rjones      0 May  1 16:54 packaging.log
-rw-r--r--. 1 rjones rjones    274 May  1 16:54 program.log
drwxr-xr-x. 2 rjones rjones   4096 May  1 16:54 pymp-f0xw1goh
-rw-r--r--. 1 rjones rjones      0 May  1 16:54 sensitive-info.log
-rw-r--r--. 1 rjones rjones      0 May  1 16:54 storage.log
-rw-------. 1 rjones rjones 346776 May  1 16:54 syslog
drwxr-xr-x. 2 rjones rjones   4096 May  1 16:54 tmux-0

I'm wondering if this might be related to bug 1569045, where apparently on some PPC64LE machines /sys/class/tty/console/active is an empty string. This can cause code that makes use of it to find the "real" hardware console by iterating from the top-level "console" alias to break down. And we do have such code in the Anaconda systemd service generator:

https://github.com/rhinstaller/anaconda/blob/master/data/systemd/anaconda-generator#L26

So could you check the content /sys/class/tty/console/active of ? And ideally any other console entry in /sys/class/tty/ that has the active property.

Also output from:

ls /sys/class/tty/* 

Would be useful.

There is also a second possibility - that this has been happening already in the past, but there was no timeout in <F28, so Anaconda just took really long to start but managed to start in the end. So could you try the same thing with F27 and attach the syslog output ? That would help us see if anaconda-shell console also used to restart over and over or if it's a new behavior.

And thanks in advance for all the logs! :)

# cat /sys/class/tty/console/active
tty0 hvc0

Created attachment 1430187 [details]
ttys

Output of ls /sys/class/tty/*

Created attachment 1430224 [details]
f27-syslog

syslog from Fedora 27 install

I'm seeing this on my armhfp virt-install, but not with aarch64, on the same x86 host.  I suspect the difference might be the speed of the VMs.  The armhpf VM gets to 'Welcome to Fedora' in about 400 seconds, but aarch64 take only about 40 seconds.  The f28 syslog in comment 5 show it takes 16 minutes to boot, so it's no speed daemon:

15:44:25,741 INFO systemd:Startup finished in 58.030s (kernel) + 10min 27.912s (initrd) + 4min 51.581s (userspace) = 16min 17.524s.

My successful aarch64 virt-install get to that line in only 8 minutes.

I think the timeouts might not be long enough for the slow virtualized CPUs.

"I think the timeouts might not be long enough for the slow virtualized CPUs."

Yeah, this seems pretty plausible to me. Non-accelerated virt is *extremely* slow.

Also potentially add in rhbz 1572944 for the RTC/random issue as a possibility to make things worse/slower too.

Fixed in a pull request: https://github.com/rhinstaller/anaconda/pull/1467

I suspect that timeout mod was a fig leaf. I got a little further trying to install F29 on emulated Aarch64 but not much further,

An unknown error has occured, look at the /tmp/anaconda-tb* file(s) for more details


===============================================================================
b'An unknown error has occurred'
===============================================================================
anaconda 29.17 exception report
Traceback (most recent call first):
  File "/usr/lib64/python3.6/site-packages/gi/overrides/BlockDev.py", line 869, in wrapped
    raise transform[1](msg)
  File "/usr/lib/python3.6/site-packages/blivet/formats/lvmpv.py", line 125, in _create
    blockdev.lvm.pvcreate(self.device, data_alignment=self.data_alignment)
  File "/usr/lib/python3.6/site-packages/blivet/threads.py", line 53, in run_with_lock
    return m(*args, **kwargs)
  File "/usr/lib/python3.6/site-packages/blivet/formats/__init__.py", line 513, in create

ne 438, in run_task
    self._task(*self._task_args, **self._task_kwargs)
  File "/usr/lib64/python3.6/site-packages/pyanaconda/installation_tasks.py", line 472, in start
    self.run_task()
  File "/usr/lib64/python3.6/site-packages/pyanaconda/installation_tasks.py", line 304, in start
    item.start()
  File "/usr/lib64/python3.6/site-packages/pyanaconda/installation_tasks.py", line 304, in start
    item.start()
  File "/usr/lib64/python3.6/site-packages/pyanaconda/installation.py", line 372, in doInstall
    installation_queue.start()
  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/threading.py", line 286, in run
    threading.Thread.run(self)
gi.overrides.BlockDev.LVMError: Failed to call the 'PvCreate' method on the '/com/redhat/lvmdbus1/Manager' object: Timeout was reached


The dbus log:
The dbus log has:
dbus-daemon[1484]: Failed to activate service 'org.fedoraproject.Anaconda.Modules.Storage': timed out (service_start_timeout=120000ms)

Ihave not as yet successfully installed either F29 or F28 on emulated Aarch64 on Qemu.

Hi Tom, your bug is a duplicate of #1586148. It is not related to this bug.