Description of problem: It's not working... Download rps and it stuffs up! Version-Release number of selected component: anaconda-28.22.10 The following was filed automatically by anaconda: anaconda 28.22.10 exception report Traceback (most recent call first): File "/usr/lib64/python3.6/site-packages/pyanaconda/payload/dnfpayload.py", line 965, in install raise payload.PayloadError(msg) File "/usr/lib64/python3.6/site-packages/pyanaconda/installation_tasks.py", line 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 361, 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 291, in run threading.Thread.run(self) pyanaconda.payload.PayloadError: Payload error - DNF installation has ended up abruptly: sssd-common < 1.16.1-3.fc28 conflicts with sssd-nfs-idmap-1.16.1-3.fc28.x86_64Traceback (most recent call last): File "/usr/lib64/python3.6/site-packages/pyanaconda/payload/dnfpayload.py", line 279, in do_transaction base.do_transaction(display=display) File "/usr/lib/python3.6/site-packages/dnf/base.py", line 867, in do_transaction raise dnf.exceptions.TransactionCheckError(msg) dnf.exceptions.TransactionCheckError: sssd-common < 1.16.1-3.fc28 conflicts with sssd-nfs-idmap-1.16.1-3.fc28.x86_64 Additional info: addons: com_redhat_kdump, com_redhat_docker blivet-gui-utils.log: cmdline: /usr/bin/python3 /sbin/anaconda cmdline_file: BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-S-dvd-x86_64-28 quiet executable: /sbin/anaconda hashmarkername: anaconda kernel: 4.16.3-301.fc28.x86_64 product: Fedora release: Cannot get release name. type: anaconda version: 28 Potential duplicate: bug 1514998
Created attachment 1431579 [details] File: anaconda.log
Created attachment 1431580 [details] File: dbus.log
Created attachment 1431581 [details] File: dnf.librepo.log
Created attachment 1431582 [details] File: environ
Created attachment 1431583 [details] File: hawkey.log
Created attachment 1431584 [details] File: lorax-packages.log
Created attachment 1431585 [details] File: lsblk_output
Created attachment 1431586 [details] File: lvm.log
Created attachment 1431587 [details] File: nmcli_dev_list
Created attachment 1431588 [details] File: os_info
Created attachment 1431589 [details] File: program.log
Created attachment 1431590 [details] File: storage.log
Created attachment 1431591 [details] File: syslog
Created attachment 1431592 [details] File: ifcfg.log
Created attachment 1431593 [details] File: packaging.log
Created attachment 1431594 [details] File: anaconda-tb
Similar problem has been detected: Another attempted net install of f28 server... This is becoming a joke Perhaps the net install image should make it easier to access a previously downloaded image... Or perhaps the live images should offer more options for install... Anyway, it ain't working addons: com_redhat_kdump, com_redhat_docker blivet-gui-utils.log: cmdline: /usr/bin/python3 /sbin/anaconda cmdline_file: BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-S-dvd-x86_64-28 quiet hashmarkername: anaconda kernel: 4.16.3-301.fc28.x86_64 package: anaconda-28.22.10 product: Fedora reason: pyanaconda.payload.PayloadError: Payload error - DNF installation has ended up abruptly: sssd-common < 1.16.1-3.fc28 conflicts with sssd-nfs-idmap-1.16.1-3.fc28.x86_64Traceback (most recent call last): release: Cannot get release name. version: 28
Similar problem has been detected: Jesus wept! This was just trying to install the simplest base system on which to build something that works and - guess what - it didn't work!!! The install process of f28 has to be the most worst most broken experience I have had installing fedora since fc1!!! For 3 days I've been trying to get my system back up and running - what on earth is going on!!! addons: com_redhat_kdump, com_redhat_docker blivet-gui-utils.log: cmdline: /usr/bin/python3 /sbin/anaconda cmdline_file: BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-S-dvd-x86_64-28 rd.live.check quiet linux repo=hd:sdc hashmarkername: anaconda kernel: 4.16.3-301.fc28.x86_64 package: anaconda-28.22.10 product: Fedora reason: pyanaconda.payload.PayloadError: Payload error - DNF installation has ended up abruptly: Transaction check error: release: Cannot get release name. version: 28
Similar problem has been detected: installing F28/x86_64/MATE desktop via kickstart, crash occur. hope this is only conflict between foomatic and foo2hiperc packages. addons: com_redhat_docker, com_redhat_kdump blivet-gui-utils.log: cmdline: /usr/bin/python3 /sbin/anaconda cmdline_file: BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-E-dvd-x86_64-28 inst.ks=http://adm.hanzlici.cz/ks/28/tezap64-ks.cfg net.ifnames=0 hashmarkername: anaconda kernel: 4.16.3-301.fc28.x86_64 package: anaconda-28.22.10 product: Fedora reason: pyanaconda.payload.PayloadError: Payload error - DNF installation has ended up abruptly: Transaction check error: release: Cannot get release name. version: 28
In this case, it seemss be conflict between foomatic-db and foo2hiperc packages: rpm -Uv foo2hiperc-0.20170412-7.fc28.x86_64.rpm Preparing packages... file /usr/share/foomatic/db/source/driver/foo2hiperc-z1.xml from install of foo2hiperc-0.20170412-7.fc28.x86_64 conflicts with file from package foomatic-db-4.0-57.20180102.fc28.noarch
The main report is conflict which needs to be solved in the sssd package spec file. For comment 20: Frantisek please file a separate bug for the foomatic package. Thank you both for these reports and sorry for this bad user experience. Fedora has thousands of packages and it is basically impossible to test every package combination.
I wonder how it may happen on SSSD side as pretty much anything has changed for quite a while in the spec file. Also, please, would be really helpful to have the steps to reproduce the issue.
This is another example of DNF failure: DNF installation has ended up abruptly: sssd-common < 1.16.1-3.fc28 conflicts with sssd-nfs-idmap-1.16.1-3.fc28.x86_64 %package nfs-idmap Summary: SSSD plug-in for NFSv4 rpc.idmapd Group: Applications/System License: GPLv3+ Conflicts: sssd-common < %{version}-%{release} How come 1.16.1-3.fc28 can be subject of this conflict for the sssd-nfs-idmap 1.16.1-3.fc28?
Not sure but maybe you are experiencing similar issue as described in bug 1574917.
OK folks, enough grumpy stuff - I think I might be able to shed some light on this and this Bug 1574917. It's seems there's two problems and this is only the first... My partitioning scheme: /boot /boot/efi / /home /opt /usr/local /var swap (think that's it...) After my first install - which went fine back Thursday 18.04.03 night - I rsynced my backups to: /home /opt /usr/local And... /var Then, I've been trying to do the install again - because I stuffed up some stuff in /etc with my back up - and, it's not been working. The reason for having those partitions separate is because there's stuff I'd like to preserve on them - of course. So, naturally, I've not reformatted those partitions on subsequently. Now, the install process requires a reformat of /, but - it does not require a reformat of /var... And, so with every subsequent re-install attempt there's been the remnant rpms under /var/cache - which I suspect have been causing conflicts If my guess is correct, then this is a but with Anaconda for not enforcing a reformat of /var on install... The other bug is desperately slow mirrors which cause Anaconda to time-out on big installs like a net install of Workstation - and the failure to pick up the process where from where it bails out. Thus causing wasted hours (a lot of them). Yet another bug not, so closely related, is the failure of Anaconda to provide sensible options to locate a local iso. When I used 'inst.askmethod' in the hope of accessing a downloaded Workstation live iso - the only partitions which were shown under Anaconda where /boot and /boot/efi. Go figure!!! They weren't even mounted. Now, after repartitioning /var and attempting to install the smallest core only, I've succeeded in building a Workstation on top of that with my desired partitioning layout. I'm not sure this is the way it should have been...
I'm moving this bug back to anaconda as it doesn't seem related to SSSD.
Thank you morgan for debugging this. It is hard to spot this in logs. In general this is tricky to solve. There are too many directories which you may want to keep without formatting and also directories which would result in an unbootable system or failed installation. We can add partition containing this directory to the "reformat is mandatory" list. But I'm sure that there will be plenty of other directories elsewhere causing similar error. Basically you always should format / /usr /var /etc ... but we don't want to enforce you to do so because there could be a valid reason to avoid formatting. Also if we did force the reformat on those partitions there will be user who would create separate partition for /var/cache or similar which will result in the same problem.
No worries - pleasure's all mine :) I can see that it's a bit of a dog -> tail situation trying to keep up with what to enforce a reformat of - perhaps there could be some helpful words of wisdom somewhere just to stop anyone preserving /var/cache on a separate partition... Re the second (third?) point above - not being able to mount a iso, or at least not being presented with somewhere sensible to look for an iso to mount - I realise that /boot and /boot/efi were probably under sysimage - but, any need for a separate bug for that?
(In reply to morgan read from comment #28) > ... > Re the second (third?) point above - not being able to mount a iso, or at > least not being presented with somewhere sensible to look for an iso to > mount - I realise that /boot and /boot/efi were probably under sysimage - > but, any need for a separate bug for that? Please file a separate bug for that issue. It would be most probably lost in this bug otherwise. Thank you.
Similar problem has been detected: I am setting up Fedora via Net Install ISO as Windows 10/Fedora dual boot on a Dell XPS 15 9560 2017 laptop. I selected the KDE Workstation package, with some extra software packages. Once the installation process gets to "Preparing transaction from installation source", I get is error pop up. addons: com_redhat_docker, com_redhat_kdump blivet-gui-utils.log: cmdline: /usr/bin/python3 /sbin/anaconda cmdline_file: BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-WS-dvd-x86_64-28 quiet nouveau.modeset=0 hashmarkername: anaconda kernel: 4.16.3-301.fc28.x86_64 package: anaconda-28.22.10 product: Fedora reason: pyanaconda.payload.PayloadError: Payload error - DNF installation has ended up abruptly: Transaction check error: release: Cannot get release name. version: 28
If Anaconda has the smarts to distinguish between system partitions and data portions - which it does - and refuses to allow an install without the repartition of '/', then it should at least flag a reparation of other system portions (eg /usr /var /etc /var/cache etc) by the default checking of the format check-box - even if the user can then uncheck it if they want.
*** Bug 1574917 has been marked as a duplicate of this bug. ***
Fixed in a pull request: https://github.com/rhinstaller/anaconda/pull/1747
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.