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:

https://github.com/rhinstaller/anaconda/commit/9892d86f5401af671d07234a6dcac93b1fd20ac3
https://github.com/rhinstaller/anaconda/commit/b1f579a7b725fe6ced3b6ecf8dcb03b333e24ef2

This will be fixed in 29.7.

(In reply to Adam Williamson from comment #2)
> vponkovca and mkolman beat me to it:
> 
> https://github.com/rhinstaller/anaconda/commit/
> 9892d86f5401af671d07234a6dcac93b1fd20ac3
> https://github.com/rhinstaller/anaconda/commit/
> b1f579a7b725fe6ced3b6ecf8dcb03b333e24ef2
> 
> 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__
    return ensure_unicode_string(value)
  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
[root@hackintosh ~]#

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).

Thanks!

Ok, bug id is 1573555.