AFAIK postin scriptlets are executed immediately after unpacking, I think they can be ignored here and check for posttrans only should be sufficient. Or is this handled differently during an offline upgrade session?
I think you are right, but the dnf log (on stdout) of that is partial. During a recent
dnf update, I got:
- a log for the
auditpostin
[318/865] Upgrading audit-0:4.1.4-1.fc4 100% | 4.0 MiB/s | 508.6 KiB | 00m00s
>>> Running %post scriptlet: audit-0:4.1.4-1.fc43.x86_64
- but no log the
kernel-corepostin (it has a postin and a posttrans), only:
>>> Running %posttrans scriptlet: kernel-core-0:6.19.12-200.fc43.x86_64
Beware also that the dnf log if misleading for the triggers:
>>> Running %triggerin scriptlet: systemd-0:258.7-1.fc43.x86_64
>>> Running %triggerpostun scriptlet: systemd-0:258.7-1.fc43.x86_64
refers to the filetriggers of systemd, not the triggers.
I really hope no.
So are these commands the ones I should try running? Iām a bit confused as to whether that is your recommendation, or whether you and Mark are still thinking this through. (And thanks again for all your efforts here.)
Hi Larry,
it should be quite safe to run both blocks posted by @francismontagnac
( ofc, skip the first dnf reinstall command)
this should create files in /var/tmp/ which you should review
The file /var/tmp/rpms lists all files upgraded in the offline session.
The file /var/tmp/rpms-with-postin-or-posttrans will list all files identified to be reinstalled.
Maybe add the option āāskip-unavailableā to the dnf reinstall command
sudo dnf reinstall $(< /var/tmp/rpms-with-postin-or-posttrans) --skip-unavailable
Make sure system is up to date, before you run those commands
run sudo dnf update --refresh first
I think I know what happened, and I reproduced this in a VM. Itās the same issue
(Solved) Offline upgrade from 43 to 44 stuck (it was in infinite loop because of msttcore-fonts-installer) - #3 by paulatz
from your journal:
Apr 28 06:31:23 dnf5[1007]: Reinstalling:
Apr 28 06:31:23 dnf5[1007]: msttcore-fonts-installer noarch 2.6-1 onlyoffice 24.2 KiB
Apr 28 06:31:23 dnf5[1007]: replacing msttcore-fonts-installer noarch 2.6-1 <unknown> 23.8 KiB
Apr 28 06:31:23 dnf5[1007]: Downgrading:
1 Like
That ran well until near the end, where I got to scriptlet errors:
>>> Running %triggerpostun scriptlet: systemd-0:259.5-1.fc44.x86_64
>>> Finished %triggerpostun scriptlet: systemd-0:259.5-1.fc44.x86_64
>>> Scriptlet output:
>>> Failed to start jobs: Failed to enqueue some jobs, see logs for details: Invalid argument
>>>
>>> Running %triggerin scriptlet: systemd-0:259.5-1.fc44.x86_64
>>> Finished %triggerin scriptlet: systemd-0:259.5-1.fc44.x86_64
>>> Scriptlet output:
>>> Failed to start jobs: Failed to enqueue some jobs, see logs for details: Invalid argument
I have searched for systemd (lots of clicks) in log files in \var\log, and found nothing amiss (e.g. all return codes were 0 that me as a noob would recognize). dnf5.log included the same entries as above. \var\log\journal has only one file from 4 days ago.
I am holding off on rebooting for now, until I hear from you whether incomplete bits above may cause a problem with that.
You can ignore those messages.See: F41 dnf upgrade Failed to start jobs - #4 by zbyszek
For our information, how many RPMs have been re-installed ?
Ex, what gives:
wc -l /var/tmp/rpms*
PS: The directory separator in Unix is /, not \: far easier to type for markdown 
2892 /var/tmp/rpms
194 /var/tmp/rpms-with-postin-or-posttrans
3086 total
Appology for the ā\ā . Old habits are hard to break.
1 Like
This case is solved. I just booted into 44. Thank you all for your help, especially Francis and Mark.
1 Like
You should probably disable the onlyoffice repository, otherwise you may run into the very same issue when upgrading to f45 in November.
or next time upgrade with
sudo dnf system-upgrade download --releasever=X --disable-repo=onlyoffice
Thanks for this follow up, Mark.
Somehow it resulted in an upgrade to the fc45 beta, though. It put me on āKernel 7.1.0-0ā¦19.fc455x86_64 (64 bit)ā. Guess Iāll stay there unless something breaks.
Did you mean to have this user upgrade to rawhide? That is what happened when using --releasever=45
It seems he intended to upgrade from f43 to f44.
Of course not.
It should be clear from the text that this command can be used during the next system upgrade to F45 in November
I suggested to disable the onlyoffice repository, I did not say to run a system-upgrade now.
He did a few days ago. I would have never thought he would blindly run this command.
Guys, please think first before blindly running some commandsā¦
I guess it created a mess. A big misunderstanding. I think at this point it should still be possible to downgrade to F44. Let me first check this tomorrow. Itās almost 2.am local time.
1 Like
It was my fault; too many things going on over the weekend yesterday and I impulsively acted when I saw your message and had just a few spare minutes. Didnāt read carefully enough, and I thought the command would remove that repo for the f45 in the future. (Gotta slow down!)
I resurrected another ThinkPad a few days ago and put f44 on it, and that one is untouched. So I will leave f45 on this one a see if I can help out with beta testing until the official f45 release. So, no need for you to go to the trouble of rolling me back.
1 Like
Larry,
Are you really sure about that? I would point out that the nvidia drivers probably canāt be compiled most of the time, since the kernel is always a development kernel. The system would likely have to run on the kernelās own nouveau driver most of the time.
Please also note that this system will remain on the development branch. This means that when the F45 branch is created in a few months, you will need to switch to this new branch shortly thereafter.
If this isnāt your main system, then thatās probably not a big deal.
Otherwise, I would rather advise switching back to an official release. The switch is still fairly easy, but the more development progresses, the harder the downgrade becomes. You can also get more help here in this forum if not using rawhide.
I did test a procedure in a VM (clean F44 install upgraded to F45 and back to F44). The procedure should work on your system as well, though some adjustments may be necessary.
I would think that you should be able to downgrade back to f44 using dnf distro-sync --releasever=44 --allowerasing. Is that what you did when you tested it? or did you use a different procedure?
distro-sync or system-upgrade --releasever=44 wonāt work w/o some preliminary steps, Also clean up is necessary to get rid of some f45 rpms (2 in case of KDE f44 clean install + the 7.1.0-rc kernel)
system-upgrade would not work to move to a lower version number.
I have never had a reason to try moving back to a lower version so have not tried anything that might work reasonably well.
Since he did the upgrade to f45 and not specifically to rawhide, although they are presently the same, when f45 is branched it may just follow the branch and not remain on rawhide. ā just guessing.
explain pleaseā¦
May 10 07:19:54 systemd[1]: Starting dnf-system-upgrade.service - System Upgrade using DNF...
May 10 07:19:54 systemd[1]: Starting dnf5-offline-transaction.service - Offline upgrades/transactions using DNF 5...
[deleted]
May 10 07:19:54 dnf5[845]: Starting system upgrade. This will take a while.
May 10 07:19:55 dnf5[845]: Package Arch Version Repository Size
May 10 07:19:55 dnf5[845]: Removing dependent packages:
May 10 07:19:55 dnf5[845]: redhat-systemd-presets noarch 0:102-1.fc45 updates 1.0 KiB
May 10 07:19:55 dnf5[845]: redhat-systemd-presets-common noarch 0:102-1.fc45 updates 16.6 KiB
May 10 07:19:55 dnf5[845]: redhat-systemd-presets-desktop noarch 0:102-1.fc45 updates 140.0 B
May 10 07:19:55 dnf5[845]: Downgrading:
May 10 07:19:55 dnf5[845]: 7zip x86_64 0:25.01-5.fc44 fedora 3.3 MiB
May 10 07:19:55 dnf5[845]: replacing 7zip x86_64 0:25.01-5.fc45 updates 3.3 MiB
May 10 07:19:55 dnf5[845]: ImageMagick x86_64 1:7.1.2.13-2.fc44 fedora 88.0 KiB
May 10 07:19:55 dnf5[845]: replacing ImageMagick x86_64 1:7.1.2.13-2.fc45 updates 88.0 KiB
May 10 07:19:55 dnf5[845]: ImageMagick-libs x86_64 1:7.1.2.13-2.fc44 fedora 8.9 MiB
May 10 07:19:55 dnf5[845]: replacing ImageMagick-libs x86_64 1:7.1.2.13-2.fc45 updates 8.9 MiB
May 10 07:19:55 dnf5[845]: LibRaw x86_64 0:0.22.1-1.fc44 fedora 2.6 MiB
May 10 07:19:55 dnf5[845]: replacing LibRaw x86_64 0:0.22.1-1.fc45 updates 2.6 MiB
[deleted]
May 10 07:20:06 dnf5[845]: Transaction Summary:
May 10 07:20:06 dnf5[845]: Installing: 4 packages
May 10 07:20:06 dnf5[845]: Upgrading: 21 packages
May 10 07:20:06 dnf5[845]: Replacing: 1295 packages
May 10 07:20:06 dnf5[845]: Removing: 3 packages
May 10 07:20:06 dnf5[845]: Downgrading: 1274 packages
May 10 07:20:13 dnf5[845]: [ 1/2599] Verify package files 100% | 193.0 B/s | 1.3 KiB | 00m07s
May 10 07:20:14 dnf5[845]: [ 2/2599] Prepare transaction 100% | 1.7 KiB/s | 2.5 KiB | 00m02s
May 10 07:20:15 dnf5[845]: [ 3/2599] Downgrading libgcc-0:16.1.1 100% | 705.6 KiB/s | 272.3 KiB | 00m00s
May 10 07:20:15 dnf5[845]: [ 4/2599] Downgrading kf6-filesystem- 100% | 102.2 KiB/s | 3.7 KiB | 00m00s
May 10 07:20:15 dnf5[845]: [ 5/2599] Downgrading fonts-filesyste 100% | 23.3 KiB/s | 788.0 B | 00m00s
[deleted]
May 10 07:29:49 dnf5[845]: [2596/2599] Removing filesystem-0:3.18- 100% | 153.7 KiB/s | 24.4 KiB | 00m00s
May 10 07:29:49 dnf5[845]: [2597/2599] Removing setup-0:2.15.0-29. 100% | 1.4 KiB/s | 45.0 B | 00m00s
May 10 07:29:49 dnf5[845]: [2598/2599] Removing fedora-release-kde 100% | 3.3 KiB/s | 100.0 B | 00m00s
May 10 07:30:05 systemd[1]: Reload requested from client PID 9191 ('systemctl') (unit dnf5-offline-transaction.service)...
May 10 07:30:18 systemd[1]: Reload requested from client PID 9350 ('systemctl') (unit dnf5-offline-transaction.service)...
F45 is rawhide until the real f45 branch will be created sometime in mid August .
I was always under the impression that the releasever must be higher than the currently installed version (the command is after all system-upgrade). Your question made me check and that apparently is not the case. Thank you for making me check my understanding.
When I tested sudo dnf system-upgrade download --releasever=43 --allowerasing on my f44 system it appears that it should work directly with no issues.
Similarly sudo dnf distro-sync --releasever=43 --allowerasing seems like it should work with no issues on my f44 system.
In the past when a release is branched off rawhide, the updates will follow the rawhide version unless you specifically switch to the version that was branched off. At the time of the branch off you were asked to accept a new gpg key, and that is the clue.
So for the future version 54 you would run dnf updatge --releasever=45 when the times come.