Since anaconda-29.6-1.fc29 landed in Rawhide, all live and disk image composes are failing with errors like this:
2018-03-29 11:06:19,944 INFO livemedia-creator: 11:06:19 Anaconda DBus modules failed to start on time.
2018-03-29 11:06:19,945 INFO livemedia-creator: 11:06:19 Anaconda DBus modules failed to start on time.
See e.g. https://pagure.io/dusty/failed-composes/issue/114 for task links, with anaconda logs (in the live media tasks, you won't find any in the image build tasks). anaconda.dbus.log seems to contain a traceback:
Traceback (most recent call last):
File "/usr/lib64/python3.6/runpy.py", line 193, in _run_module_as_main
File "/usr/lib64/python3.6/runpy.py", line 85, in _run_code
File "/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/__main__.py", line 4, in <module>
from pyanaconda.modules.storage.storage import StorageModule
File "/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/storage.py", line 23, in <module>
from pyanaconda.modules.storage.disk_initialization import DiskInitializationModule
ModuleNotFoundError: No module named 'pyanaconda.modules.storage.disk_initialization'
This is an automatic F29 Beta blocker, as it prevents the compose of many release-blocking images: https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Automatic_blockers
I think this is a Makefile issue; the module's in git master, but doesn't get into the tarball or the package. We just need to add the right bits to get it into the tarball. I'll send a PR soon.
vponkovca and mkolman beat me to it:
This will be fixed in 29.7.
(In reply to Adam Williamson from comment #2)
> vponkovca and mkolman beat me to it:
> This will be fixed in 29.7.
Yep & already built: https://koji.fedoraproject.org/koji/taskinfo?taskID=26044096
We have had Rawhide composes since then, so let's close this.
I see this on fedora 27 and fedora 28 beta 1.3 and beta nightly as of 20180429, thus I'm completely unable to install fedora. Which iso can I use to install which doesn't have this problem?
I don't think you could possibly be seeing this on Fedora 27. The code that results in this error (and the error itself) do not exist in F27. It is new code in F28.
Ok, I'll try another F27 install to check if I remember correctly. I see F28 was just released. Is there any build that contains this fix, nightly, rawhide etc that I can try out?
No F27 or F28 build was ever affected by this, AFAIK. If you're having problems with F27 or F28 installs, none of them are this. You must be hitting some other bug. I can't help you with that until I have any kind of information at all that might indicate what bug that might be.
F28 does have the "Anaconda DBus modules failed to start on time" error, so you could possibly be seeing that error on F28 (not F27). But if so, the cause must be something else. It's a fairly generic error message, it could appear for various reasons.
Ok, I guess I was wrong on F27. The installer silently fails. If I do sudo -i and run anaconda manually, I get an encoding error. https://pastebin.com/qZWiXxWw
Just tested F28 now, with the same result. Running the installer from the drawer / activities doesn't work, without any error message. Running in a terminal after sudo -i results in the same errors,
Anaconda DBus modules failed to start on time.
There's no other error details. Should I open another bug with details?
I do see the 'utf-8' codec can't decode byte 0xc0 in position 0 in the logs as well on F28, am wondering if that can be the underlying issue?
Torgeir: yes, almost certainly it is. Basically it looks like this is causing blivet, which acts as the storage backend for anaconda, to fall over when examining udev info for storage devices as part of storage initialization; in F28 and later anaconda was modularized to some extent, so this is manifesting as the storage initializing 'module' failing to start up. It's almost certainly the same basic bug.
I'm gonna repaste your traceback here, as it'll expire from pastebin at some point:
[root@hackintosh ~]# anaconda --loglevel debug
Starting installer, one moment...
anaconda 27.20.4-1 for anaconda bluesky (pre-release) started.
* installation log files are stored in /tmp during the installation
* shell is available on TTY2 and in second TMUX pane (ctrl+b, then press 2)
* when reporting a bug add logs from /tmp as separate text/plain attachments
Traceback (most recent call last):
File "/sbin/anaconda", line 658, in <module>
matched = device_matches("LABEL=OEMDRV", disks_only=True)
File "/usr/lib64/python3.6/site-packages/pyanaconda/storage_utils.py", line 897, in device_matches
single_spec_matches = udev.resolve_glob(full_spec)
File "/usr/lib/python3.6/site-packages/blivet/udev.py", line 155, in resolve_glob
for dev in get_devices():
File "/usr/lib/python3.6/site-packages/blivet/udev.py", line 73, in get_devices
dev = device_to_dict(device)
File "/usr/lib/python3.6/site-packages/blivet/udev.py", line 48, in device_to_dict
result = dict(device.properties)
File "/usr/lib/python3.6/site-packages/pyudev/device/_device.py", line 1085, in __getitem__
File "/usr/lib/python3.6/site-packages/pyudev/_util.py", line 67, in ensure_unicode_string
value = value.decode(sys.getfilesystemencoding())
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc0 in position 0: invalid start byte
From that traceback, this actually looks like it's in pyudev, so can you please file a new bug against 'python-pyudev' to report this? However, I think we're going to need to figure out what the actual device is, and what property of the device pyudev is choking on; clearly what's going on here is it's encountering a rather unusual value as a property of a udev device (one that's not, apparently, valid UTF-8).
Ok, bug id is 1573555.