Various boot failures following fresh installation / ISO generation

Question

Hello,
It would seem that fresh Arch installations in the last couple of days are providing quite a few errors / failures during bootup. None of these occurred before then, which also seems to affect ISOs generated over the last couple of days too. Having looked into it, the issues seem to be primarily related the automatic activation of dcpcd, ip6tables, iptables, and the krb5 (Kerberos) services. I determined this after comparing the systemctl outputs of an ISO generated a week ago to one I created today. The difference was that the former used WICD and the latter NetworkManager. However, I do not believe NM somehow activated these.
Also noticed failures related to nscd and WPA supplicant. At face value the nscd issue seems identical to a bug report made in 2005: https://bugs.archlinux.org/task/2697
Relevant journalctl entries for nscd:
Aug 28 18:47:41 evo nscd[235]: 235 cannot create /var/db/nscd/passwd; no persistent database used
Aug 28 18:47:41 evo nscd[235]: 235 cannot create /var/db/nscd/group; no persistent database used
Aug 28 18:47:41 evo nscd[235]: 235 cannot create /var/db/nscd/hosts; no persistent database used
Aug 28 18:47:41 evo nscd[235]: 235 cannot create /var/db/nscd/services; no persistent database used
Aug 28 18:47:41 evo nscd[235]: 235 cannot create /var/db/nscd/netgroup; no persistent database used
Still looking into the WPA supplicant issue. Found some old bug reports for other distros (i.e debian and Ubuntu), but nothing yet for Arch. Relevant journalctl entries for WPA supplicant:
Aug 28 18:49:03 evo systemd[1]: Dependency failed for WPA supplicant daemon (interface- and nl80211 driver-specific version).
Aug 28 18:49:03 evo systemd[1]: Dependency failed for WPA supplicant daemon (interface- and wired driver-specific version).
Aug 28 18:49:03 evo systemd[1]: Dependency failed for WPA supplicant daemon (interface-specific version).
Bit of an odd one I am still puzzled about is the failure of dmraid during ISO bootup. Again, this was not automatically activated before, but is now, resulting in (unsurprising) failure. Installation and ISO generation methods have not changed in the least, so am a tad perplexed! Can anyone offer any insight while I continue to investigate? Well, other than the most obvious suspicion, which is services for installed elements now automatically activate.
Much appreciated,
Carl

Answer 1

I have the same problem on a fresh install.
After running systemctl --state = failed I get the following:
  UNIT                                               LOAD    ACTIVE    SUB         DESCRIPTION
● ip6tables.service                        loaded   failed      failed      IPv6 Packet Filtering Framework
● iptables.service                          loaded   failed      failed      Packet Filtering Framework
● krb5-kadmind.service                loaded   failed      failed      Kerberos 5 administration server
● krb5-kdc.service                         loaded   failed     failed       Kerberos 5 KDC
● mdadm.service                          loaded   failed      failed      MDADM Event Monitor
● systemd-journal-upload.service loaded  failed      failed      Journal Remote Upload Servic
In my case I could make iptables and ip6tables torn after reading the wiki and do the following:
# touch /etc/iptables/iptables.rules
# systemctl start iptables
# touch /etc/iptables/ip6tables.rules
# systemctl start ip6tables
As for krb5 I could not even solve the problem, the problem is in the configuration file /etc/krb5.conf but when I compare the file with another previous installation on another computer there is no difference between them. I have not found much documentation about this topic.
A side effect is that there is no way that achieves connexion via wifi. If I connect to a wired network no problem, but it is impractical to take a very long cable wherever I carry a laptop.