Bug 1317195 - No update or progress indication at all
Summary: No update or progress indication at all
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf-plugins-extras
Version: 26
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
Assignee: rpm-software-management
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1470343 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-12 22:45 UTC by Christian Stadelmann
Modified: 2018-01-06 10:36 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-29 15:32:04 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Output of `dnf system-upgrade log -1` after a successful distribution upgrade (1.28 MB, text/plain)
2016-07-14 00:39 UTC, Christian Stadelmann
no flags Details
complete syslog of reboot process, output of `journalctl -b -1` (1.28 MB, text/plain)
2016-07-14 00:40 UTC, Christian Stadelmann
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github rpm-software-management dnf-plugin-system-upgrade issues 53 0 None open No update or progress indication at all 2020-10-01 07:17:21 UTC

Description Christian Stadelmann 2016-03-12 22:45:21 UTC
Description of problem:
When doing a `dnf system-upgrade reboot` I see no progress indication. I don't see any indication at all that shows me that a system upgrade is running

Version-Release number of selected component (if applicable):
a fully updated F23 with dnf-plugin-system-upgrade 0.7.1-1.fc23

How reproducible:
I don't know. This might be specific to systems without plymouth installed.

Steps to Reproduce:
1. `dnf update --refresh`
2. `dnf install dnf-plugin-system-upgrade`
3. `dnf system-upgrade download --releasever=23`
4. `dnf system-upgrade reboot`

Actual results:
After rebooting I get the usual systemd notices about services that started or stopped. The last one I see is "Starting Switch Root..."

Expected results:
Some indication that a system upgrade is running. Preferaby including a progress indication.

Additional info:
I only knew my system was updating because the HDD LED was blinking and I had syslog cloned on some tty. A different user could just have used the power button to kill this update inbetween.

Comment 1 Jan Včelák 2016-04-24 19:43:01 UTC
Same problem here. I also don't have plymouth.

Some indication is clearly needed. I almost restarted the computer during the upgrade because I thought that the init just got stuck. However I logged in on the second terminal and fired journalctl -f to find out that the upgrade was really in progress.

Comment 2 Will Woods 2016-04-26 22:10:45 UTC
(In reply to Jan Včelák from comment #1)
> Same problem here. I also don't have plymouth.
> 
> Some indication is clearly needed. I almost restarted the computer during
> the upgrade because I thought that the init just got stuck. However I logged
> in on the second terminal and fired journalctl -f to find out that the
> upgrade was really in progress.

What did the journal log messages look like? Did the journal contain the usual dnf output?

Comment 3 Jan Včelák 2016-04-26 22:38:20 UTC
(In reply to Will Woods from comment #2)
> What did the journal log messages look like? Did the journal contain the
> usual dnf output?

Yes, it did look like a dnf output.

Comment 5 Will Woods 2016-07-11 19:15:53 UTC
A few questions for people seeing this bug - you can use the commands listed to find the answers.

* What plymouth packages are installed? (`rpm -qa "plymouth*"`)
* What arguments are in your kernel boot commandline? (`cat /proc/cmdline`)
* Have you modified your systemd configuration? (`rpm -V systemd | grep etc`)

Finally - could you attach the log output from your upgrade?
(`sudo dnf system-upgrade log -1 > upgrade.log`)

Comment 6 Christian Stadelmann 2016-07-11 20:43:54 UTC
(In reply to Will Woods from comment #5)
> * What plymouth packages are installed? (`rpm -qa "plymouth*"`)
None. I uninstalled all of them from a Fedora Workstation. If you try to reproduce, be careful not to run into bug #1059485

> * What arguments are in your kernel boot commandline? (`cat /proc/cmdline`)
besides initramfs and filesystems, there is only this:
rhgb quiet LANG=de_DE.UTF-8

> * Have you modified your systemd configuration? (`rpm -V systemd | grep etc`)
Yes, /etc/systemd/journald.conf: 

[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitInterval=30s
#RateLimitBurst=1000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#SystemMaxFiles=100
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#RuntimeMaxFiles=100
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=no
#ForwardToKMsg=no
ForwardToConsole=yes
#ForwardToWall=yes
TTYPath=/dev/tty12
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info
MaxLevelWall=alert

[End of /etc/systemd/journal.conf]

Only because of having syslog forwarded to tty12 I knew that dnf was working. I don't think this config file is related though.

> Finally - could you attach the log output from your upgrade?
> (`sudo dnf system-upgrade log -1 > upgrade.log`)

I can't do that right now, this needs some time.
Steps I'll do to reproduce:
1. install Fedora 23 into virtual machine
2. uninstall plymouth
3. upgrade kernel (to work around bug #1059485)
4. upgrade dnf, dnf plugins, probably other stuff
5. reboot
6. run dnf system-upgrade with logs as requested in comment #5

[I'm not clearing needinfo so I'll get reminded in case I forget to provide the log file. Clear it if you can reproduce yourself.]

Comment 7 Will Woods 2016-07-11 21:03:14 UTC
So - we used to print the upgrade output to the console, but that meant that people who *did* have plymouth installed saw duplicated output - see https://github.com/rpm-software-management/dnf-plugin-system-upgrade/issues/13

That happened because plymouth had made a change that made it duplicate plymouth "display-message" text into the "details" view - see https://bugs.freedesktop.org/show_bug.cgi?id=29035

Our fix was to hide the DNF upgrade output, so only the "display-message" text appears in the "details" view of plymouth. Which, unfortunately, means that if you don't have plymouth, you don't see any output.

I talked with the plymouth maintainer about this, and we agree that the right answer is probably to have DNF send its output to the console like before, and revert plymouth's behavior to avoid the duplicated messages.

He's reopened the plymouth bug to see if we can revert plymouth's behavior, and I will probably submit a patch to revert commit dcc3349 and put DNF output back on the text console.

Comment 8 Christian Stadelmann 2016-07-14 00:39:50 UTC
Created attachment 1179526 [details]
Output of `dnf system-upgrade log -1` after a successful distribution upgrade

reliable steps to reproduce:
1. install a new (blank) Fedora 23 (build 10)
2. reboot into the new F23 installation
3. `dnf remove plymouth\*`
4. `dnf upgrade kernel\*`
5. `dnf install dnf-plugin-system-upgrade` (version 0.7.1-2.fc23)
6. reboot, make sure plymouth is missing
7. `dnf system-upgrade download --releasever 24`
8. `dnf system-upgrade reboot`
9. `dnf system-upgrade log -1 > dnf_system-upgrade_log_-1.log`

Comment 9 Christian Stadelmann 2016-07-14 00:40:40 UTC
Created attachment 1179527 [details]
complete syslog of reboot process, output of `journalctl -b -1`

Comment 10 Kamil Páral 2016-07-19 08:53:36 UTC
For the record: plymouth is available even on a minimal install by default, therefore this bug doesn't affect default Fedora installations. People have to remove plymouth manually to be affected by this issue. (That doesn't mean it's not an important bug, I'm just stating the fact for QA purposes).

Comment 11 Christian Stadelmann 2016-09-28 18:52:28 UTC
Same issue on F24 → F25 update.

Comment 12 Will Woods 2016-10-13 22:09:15 UTC
It's fixed in git:

 https://github.com/rpm-software-management/dnf-plugin-system-upgrade/commit/430454b

So it'll be fixed in the next build of the plugin.

The DNF team had said they were going to pull the system-upgrade plugin into dnf-plugins-extras (or maybe dnf-plugins-core?), but I don't think that's happened yet.

I'm no longer maintaining the plugin, though, so.. I don't know when it'll get built. I'll ask the DNF team about it.

Comment 13 Tim Coote 2016-11-23 14:27:09 UTC
It used to be the case that the supported upgrade mechanisms worked for headless machines. 

Is the bug described here a result of the regression that headless upgrades no longer show any progress, or a separate issue as headless upgrade tracking would depend on having an extra machine?

Comment 14 Christian Stadelmann 2016-11-23 15:36:33 UTC
(In reply to Tim Coote from comment #13)
> Is the bug described here a result of the regression that headless upgrades
> no longer show any progress, or a separate issue as headless upgrade
> tracking would depend on having an extra machine?

I don't understand what you mean. Is this a question for me?

While this update happens, ttys are working so a local console login is possible. I haven't tried ssh though, so I haven't tried headless.

Comment 15 Tim Coote 2016-11-23 15:59:40 UTC
I don't know who would care about such a regression (if anyone). Do you think I should raise a separate bug?

As a rule, a headless box is in a datacentre somewhere, so ttys don't work too well.

iirc, previous supported upgrade processes either used vnc to provide graphical progress, or allowing ssh'ing to confirm that something was going on.

Unobservable activity that goes on for many minutes is, in general, not a good experience.

Comment 16 Will Woods 2016-12-01 17:39:16 UTC
(In reply to Tim Coote from comment #15)
> I don't know who would care about such a regression (if anyone). Do you
> think I should raise a separate bug?
> 
> As a rule, a headless box is in a datacentre somewhere, so ttys don't work
> too well.
> 
> iirc, previous supported upgrade processes either used vnc to provide
> graphical progress, or allowing ssh'ing to confirm that something was going
> on.
> 
> Unobservable activity that goes on for many minutes is, in general, not a
> good experience.

That's not really relevant to the bug here, which concerns problems with console output during upgrades when plymouth isn't present.

Requests for new features should probably go somewhere else, like in github: https://github.com/rpm-software-management/dnf-plugin-system-upgrade/issues

Comment 17 Christian Stadelmann 2017-04-23 23:45:06 UTC
Same issue on update from Fedora 25 to Fedora 26 using python3-dnf-plugin-system-upgrade-0.7.1-4.fc25.noarch.

Comment 18 Fedora End Of Life 2017-11-16 18:42:45 UTC
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. 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 '25'.

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 25 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.

Comment 19 Marek Blaha 2017-11-29 15:32:04 UTC
Hi, please upgrade to latest dnf-plugins-extras, which (from Fedora 26 onwards) provides system-upgrade plugin. This issue should be already fixed. 
I tried upgrade 26->27 on system without plymouth installed and I got a lot of messages on console describing process of upgrade in details.
In case of any problems, don't hesitate to reopen the bug.

Comment 20 Marek Blaha 2017-11-29 15:58:32 UTC
*** Bug 1470343 has been marked as a duplicate of this bug. ***

Comment 21 Christian Stadelmann 2017-11-29 19:36:45 UTC
(In reply to Marek Blaha from comment #19)
> Hi, please upgrade to latest dnf-plugins-extras, which (from Fedora 26
> onwards) provides system-upgrade plugin. This issue should be already fixed. 
> I tried upgrade 26->27 on system without plymouth installed and I got a lot
> of messages on console describing process of upgrade in details.
> In case of any problems, don't hesitate to reopen the bug.

May I ask which version you refer to? Is it 2.0.4 from updates-testing? I did a system upgrade 6 days ago with dnf-plugins-extra 2.0.3 and still got no progress indication.

Comment 22 Marek Blaha 2017-11-30 06:26:41 UTC
Yes, I used 2.0.4 and everything went well. When testing this, I used this steps (on fresh virtual fedora 26 server):

1. dnf remove 'plymouth*'
2. dnf upgrade
3. dnf system-upgrade download --releasever=27
4. dnf system-upgrade reboot

But the only difference between 2.0.3 and 2.0.4 is running dnf after reboot cacheonly. So probably, uninstalling of plymouth is not enough to reproduce this bug.

Comment 23 Christian Stadelmann 2018-01-06 10:36:18 UTC
(In reply to Marek Blaha from comment #22)
> Yes, I used 2.0.4 and everything went well. When testing this, I used this
> steps (on fresh virtual fedora 26 server):
> 
> 1. dnf remove 'plymouth*'
> 2. dnf upgrade
> 3. dnf system-upgrade download --releasever=27
> 4. dnf system-upgrade reboot
> 
> But the only difference between 2.0.3 and 2.0.4 is running dnf after reboot
> cacheonly. So probably, uninstalling of plymouth is not enough to reproduce
> this bug.

As written above (comment #6), you need to regenerate your initramfs after uninstalling plymouth, otherwise the change will not be applied and your initramfs will still contain plymouth.


Note You need to log in before you can comment on or make changes to this bug.