Description of problem: On update to release for FC35 for Systemd , ReaR backup failed due to no hardlink for /usr/lib/systemd/systemd-udevd Version-Release number of selected component (if applicable): Release 247.3 onwards How reproducible: Always Steps to Reproduce: 1.Update to systemd-247.3 or later (FC35) 2.install and run ReaR 2.6-4 (FC34) 3.run /usr/sbin/rear -v mkbackup Actual results: Backup failed due to missing hardlink to /usrr/lib/systemd/systemd-udevd Expected results: Create a USB backup of the Fedora FC35 installation Additional info: The first occurrence on 4th Feb 2021 included another soft-link in the same directory, but it did not occur on the latest update, done on 17th Feb, 2021. Solution is to remove the soft-links created, and replace with hard-links, identify links by running "readlink <path and filename>", remove soft-link and create hard-link using ln <from path and filename> <to path and filename>
Sorry, but a backup program cannot dictate whether symlinks are used or not. Using symlinks to provide alternative names for programs is often done, see /usr/sbin/halt, /usr/sbin/poweroff, /usr/sbin/telinit, /usr/sbin/mount.ntfs, etc, etc. I have no idea why rear would care about this, but anyway, it needs to be fixed there.
OK, that is fine - I will raise it as a bug on ReaR. The point was that all was working correctly for FC34 Rawhide, and without changing the version of ReaR, whatever changes occured in Systemd for version 247.3 caused the backup to fail, so it is clear where the change had occurred. Initially I was not sure about the package causing the issue since full upgrade was done, but after replacing the sym-link with a hardlink using the same name, the backup software was working. A further, separate upgrade to only Systemd 247.3-2 was done, resulting in the hardlink being replaced by a soft-link, it was apparent what caused the problem. I reiterate that the ReaR package remained the same. With the latest systemd-udev 247-3.3 which has just been released, it has resulted in the same change occuring, whilst all other /usr/lib/sysmd/systemd-* entries remain as hard-links, exactly as they had been in FC34 and before.
> OK, that is fine - I will raise it as a bug on ReaR. I already reassigned this bug to rear.
Thanks for raising this, rear should definitely not care about hard- vs. softlinks. The backup runs without issue on my system - none of the symlinks in /usr/lib/systemd cause an error. At which step of the backup did rear fail for you? Can you share your config & a backup log?
I do not have them to hand, I guess in the next day or two I will find my way clear to send the data. Do you want a failed log, as I do not think the failed ones are stored.? I will dig back through the log-files, see if I can find a log with the details.
Created attachment 1759526 [details] ReaR backup failure_ReaR 2.6-4.fc35 ReaR backup of FC35 Rawhide installation failed, due to no hard-link for /usr/lib/systemd/systemd-udevd Once the softlink to /bin/udevadm was replaced with a hard link, the backup was successful. Same result as the previous version of ReaR, 2.6-3.fc35
Thanks for the log, that helps. The issue isn't directly related to the hard/softlink systemd-udev -> udevadm, but rather to tar trying to create a hardlink from /lib/systemd... to /usr/lib/systemd... for some reason. I don't quite know why, there aren't any hardlinks involved there, /lib is simply symlinked to /usr/lib. Can you try if this build: https://koji.fedoraproject.org/koji/taskinfo?taskID=62741173 fixes the issue for you?
Created attachment 1759623 [details] hardlink issue appears to be resolved, but no backup written From the log it appears that the hard-link issue is resolved, however no backup was written using 2.6-5 from koji repo, as linked above.
My apologies, I forgot to restore the .conf file after installing the rpm..... Dohhh :-( All is working correctly now, Thanks Christopher and team for resolving this issue. Cheers.
Thank you for reporting & testing. Cheers.
FEDORA-2021-0e592dd575 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-0e592dd575
FEDORA-2021-e6e4122aed has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2021-e6e4122aed
FEDORA-2021-e6e4122aed has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-e6e4122aed` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-e6e4122aed See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-073d76fe19 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-073d76fe19` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-073d76fe19 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-073d76fe19 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-e6e4122aed has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-0e592dd575 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.