Description of problem: Basic Server install Version-Release number of selected component: anaconda-23.19.3-1 The following was filed automatically by anaconda: anaconda 23.19.3-1 exception report Traceback (most recent call first): File "/usr/lib64/python3.4/subprocess.py", line 1457, in _execute_child raise child_exception_type(errno_num, err_msg) File "/usr/lib64/python3.4/subprocess.py", line 859, in __init__ restore_signals, start_new_session) File "/usr/lib64/python3.4/site-packages/pyanaconda/iutil.py", line 201, in startProgram preexec_fn=preexec, cwd=root, env=env, **kwargs) File "/usr/lib64/python3.4/site-packages/pyanaconda/iutil.py", line 279, in _run_program env_prune=env_prune) File "/usr/lib64/python3.4/site-packages/pyanaconda/iutil.py", line 358, in execWithRedirect log_output=log_output, binary_output=binary_output)[0] File "/usr/lib64/python3.4/site-packages/pyanaconda/iutil.py", line 336, in execInSysroot return execWithRedirect(command, argv, stdin=stdin, root=getSysroot()) File "/usr/lib64/python3.4/site-packages/pyanaconda/kickstart.py", line 1653, in execute iutil.execInSysroot("systemctl", ["enable", svc]) File "/usr/lib64/python3.4/site-packages/pyanaconda/install.py", line 79, in doConfiguration ksdata.services.execute(storage, ksdata, instClass) File "/usr/lib64/python3.4/threading.py", line 868, in run self._target(*self._args, **self._kwargs) File "/usr/lib64/python3.4/site-packages/pyanaconda/threads.py", line 253, in run threading.Thread.run(self, *args, **kwargs) FileNotFoundError: [Errno 2] No such file or directory: 'systemctl' Additional info: addons: com_redhat_kdump cmdline: /usr/bin/python3 /sbin/anaconda cmdline_file: BOOT_IMAGE=/images/pxeboot/vmlinuz noselinux ip=172.18.92.70::172.18.92.65:255.255.255.192:cfl.lc.digifarma.nl::off noipv6 nameserver=172.18.92.65 inst.stage2=hd:UUID=c98f6f60-f5fe-4bf9-b500-8e918649636a executable: /sbin/anaconda hashmarkername: anaconda kernel: 4.2.0-300.fc23.x86_64 product: Fedora release: Cannot get release name. type: anaconda version: 23
Created attachment 1073377 [details] File: anaconda-tb
Created attachment 1073378 [details] File: anaconda.log
Created attachment 1073379 [details] File: dnf.log
Created attachment 1073380 [details] File: dnf.rpm.log
Created attachment 1073381 [details] File: environ
Created attachment 1073382 [details] File: lsblk_output
Created attachment 1073383 [details] File: nmcli_dev_list
Created attachment 1073384 [details] File: os_info
Created attachment 1073385 [details] File: program.log
Created attachment 1073386 [details] File: storage.log
Created attachment 1073387 [details] File: syslog
Created attachment 1073388 [details] File: ifcfg.log
Created attachment 1073389 [details] File: packaging.log
Sep 15 11:04:40 CRIT systemd-222-2.fc23.x86_64 was supposed to be installed but is not! I have no idea how it happened, but based on dnf.log your rpm transaction got hosed.
The error shows when installing from a network repo. I checked and the package is there. From the http log I found that the package is downloaded during the installation process. After that I reproduced this in an installation from the server dvd iso images. Can I conclude that the package is not corrupt?
It looks like this error is relating to a problem in installing the efi bootloader, as I see a message saying there might be aproblem in kernel or firmware that may give a problem in installing the bootloader. With this message the error occupeer. Without this message I don't see the error.
*** Bug 1263944 has been marked as a duplicate of this bug. ***
This error is a regression from Beta_23_TC1, where it does not occure. The error is related to the 'noselinux' cli parameter. Without 'noselinux' Fedora installs without a problem.
Does not look like dnf issue => reassigning back to anaconda.
(In reply to Michal Luscon from comment #19) > Does not look like dnf issue => reassigning back to anaconda. What would cause all of the "<package> was supposed to be installed but is not!" messages, then?
Assigning back to dnf since it is absolutely a dnf issue to either install the packages requested or raise an exception.
Ok, I mistakenly supposed that you expected packages to be installed. The whole responsibility of transaction processing is on RPM and unfortunately, it does not provide any useful error information to DNF in this case. Florian, I would guess this is similar to the issue which we had discussed on IRC recently (see comment #18).
Looks like this is cause by the failing scriptlets. RPM skips the installation of packages if the PREIN scriptlet fails. Unfortunately I did not find any error message from the scriptlet themselves. As a large number of scriptlets fails it is likely that the install root is broken in some important way - like not having /proc mounted.
*** Bug 1266170 has been marked as a duplicate of this bug. ***
Is this still broken? I think we fixed that somehow but I can't find the fix right now...