Created attachment 11328 [details] dnf.rpm.log While upgrading according to the instructions here https://wiki.mageia.org/en/Mageia_7_Release_Notes#Upgrading_online.2C_using_DNF_.28CLI.29 after doing "dnf system-upgrade reboot" the system rebooted and the upgrade started fine, but seemed to stall after the scriptlet for java-1.8.0-openjdk-headless-1:1.8.0.222-1.b10.1.mga7.x86_64 was run. There was nothing that showed anything was still being installed, even the led that shows hard disk activity was dark. However, after rebooting and checking dnf.rpm.log, I saw that upgrading had continued for another 48 minutes until the reboot. In case it matters: rpm-1:4.14.2.1-12.mga7.x86_64 was upgraded in the same second (2019-10-19T16:35:24) as java-1.8.0-openjdk-headless-1:1.8.0.222-1.b10.1.mga7.x86_64 was upgraded, lib64rpm8-1:4.14.2.1-12.mga7.x86_64 had been installed 2 seconds earlier. And two dnf packages were installed twice: 3 seconds before the screen froze: 2019-10-19T16:35:21Z INFO Installed: dnf-data-4.2.6-1.mga7.noarch 2019-10-19T16:35:21Z INFO Upgraded: mageia-dnf-conf-1.0-2.mga7.noarch and again almost 10 minutes later: 2019-10-19T16:45:07Z INFO Installed: dnf-data-4.2.6-1.mga7.noarch 2019-10-19T16:45:08Z INFO Upgraded: mageia-dnf-conf-1.0-2.mga7.noarch @ Neal Do you have a link to an upstream bug report about those rpm glitches?
(In reply to Marja Van Waes from comment #0) > Created attachment 11328 [details] > dnf.rpm.log > > While upgrading according to the instructions here > https://wiki.mageia.org/en/Mageia_7_Release_Notes#Upgrading_online. > 2C_using_DNF_.28CLI.29 > after doing "dnf system-upgrade reboot" the system rebooted and the upgrade > started fine, but seemed to stall after the scriptlet for > java-1.8.0-openjdk-headless-1:1.8.0.222-1.b10.1.mga7.x86_64 was run. > > There was nothing that showed anything was still being installed, even the > led that shows hard disk activity was dark. > > However, after rebooting and checking dnf.rpm.log, I saw that upgrading had > continued for another 48 minutes until the reboot. > > In case it matters: > > rpm-1:4.14.2.1-12.mga7.x86_64 was upgraded in the same second > (2019-10-19T16:35:24) as > java-1.8.0-openjdk-headless-1:1.8.0.222-1.b10.1.mga7.x86_64 was upgraded, > lib64rpm8-1:4.14.2.1-12.mga7.x86_64 had been installed 2 seconds earlier. > > And two dnf packages were installed twice: > > 3 seconds before the screen froze: > 2019-10-19T16:35:21Z INFO Installed: dnf-data-4.2.6-1.mga7.noarch > 2019-10-19T16:35:21Z INFO Upgraded: mageia-dnf-conf-1.0-2.mga7.noarch > > and again almost 10 minutes later: > 2019-10-19T16:45:07Z INFO Installed: dnf-data-4.2.6-1.mga7.noarch > 2019-10-19T16:45:08Z INFO Upgraded: mageia-dnf-conf-1.0-2.mga7.noarch > > @ Neal > > Do you have a link to an upstream bug report about those rpm glitches? Hmm, I misunderstood the issue. I don't think that was a reporting glitch (those are considerably more obvious), but instead the KMS screensaver kicked in and stopped updating the screen. Normally just pressing an arrow key or something will cause it to start updating again. Reporting glitches look like when the output looks incomplete or corrupt and then it stops loading new data on screen. It's more obvious that it's a reporting glitch if you're seeing this in a Plymouth splash screen. If you're just seeing it print text output into KMS, then it may just be the display going to "sleep" improperly.
Also, to note, system upgrades in DNF are operated *entirely* from the original rpm + dnf version, so the Mageia 7 versions of the packages have no impact until the transaction is done (usually).
Source RPM: rpm-4.13.1-3.2.mga6, rpm-4.14.2.1-12.mga7, dnf => rpm-4.13.1-3.2.mga6Version: 7 => 6
Created attachment 11335 [details] picture from the screen where it stopped (In reply to Neal Gompa from comment #1) > (In reply to Marja Van Waes from comment #0) > > > > @ Neal > > > > Do you have a link to an upstream bug report about those rpm glitches? > > Hmm, I misunderstood the issue. I don't think that was a reporting glitch > (those are considerably more obvious), but instead the KMS screensaver > kicked in and stopped updating the screen. > Normally just pressing an arrow > key or something will cause it to start updating again. I did get the screen to reload, but it stopped at exactly the same spot instead of much further. > > Reporting glitches look like when the output looks incomplete or corrupt To me, it looked neither incomplete nor corrupt. There were only many duplicate lines (which is likely unrelated). I'll attach a picture from the "frozen" screen. > and > then it stops loading new data on screen. It's more obvious that it's a > reporting glitch if you're seeing this in a Plymouth splash screen. If > you're just seeing it print text output into KMS, then it may just be the > display going to "sleep" improperly. I doubt the display was trying to go to sleep, because this happened to me in cauldron too, but then after being logged in and while using "dnf distrosync". Xfce wasn't frozen, but the terminal in which I was running DNF stopped updating its output. pstree showed that DNF hadn't quit and after reboot I found there, too, that many, many more packages had been upgraded/installed than were in the file to which I had piped the DNF output. Anyway, if that can still be caused by KMS, what should I add to the kernel parameters for the "Intel 810 and later" card on that laptop, to disable KMS? nomodeset i915.modeset=0 ?
Summary: DNF upgrade Mga6-7 seems to freeze, but upgrade continues without any way to know it does, caused by rpm glitches in reporting via the callback in librpm => DNF upgrade Mga6-7 seems to freeze, but upgrade continues without any way to know it does
So far, I haven't been able to reproduce this issue. For me, system upgrades actually complete as intended, and the text output shows up just fine continuously...
Mageia 6 is EOL.
Status: NEW => RESOLVEDResolution: (none) => OLD