RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1221517 - Boot Screen with System Updates is Similar to Normal Boot Screen
Summary: Boot Screen with System Updates is Similar to Normal Boot Screen
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gnome-packagekit
Version: 7.1
Hardware: All
OS: All
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Richard Hughes
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-05-14 08:57 UTC by Jiri Hnidek
Modified: 2019-07-30 15:27 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-07-30 15:27:35 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Jiri Hnidek 2015-05-14 08:57:33 UTC
Description of problem:

When user (student in this case) click at: “Restart and install updates”, then computer is restarted and updates are installed during boot process. The boot screen looks exactly the same screen as during normal boot. Installing of updates can take very long (20-30 minutes). When other student come to the classroom and he or she see non-progress boot screen, then he or she usually consider to do press power off button and do hard power-off of the computer. It usually cause corruption of rpm database.

Version-Release number of selected component (if applicable):

7.x

How reproducible:

Restart RedHat 7 Desktop with "Restart and install updates"

Actual results:

Boot screen that looks exactly the same as normal boot screen.

Expected results:

Boot screen with different colour, more information about installing, may be some progress bar.

Additional info:
https://blogs.gnome.org/hughsie/2012/06/04/offline-os-updates-looking-forward-to-gnome-3-6/
https://wiki.gnome.org/Design/OS/SoftwareUpdates

Comment 2 Jiri Hnidek 2015-05-14 12:29:46 UTC
I'm sorry, I was wrong about appearance of Boot screen in "update mode". It is switched to text mode after while and it shows some string "Installing updates" and text progress bar. Probably it's not enough for our students :-/.

Fast fix of my problems is to create file:

 /etc/dconf/db/local.d/01-updates

containing following configuration:

 [org/gnome/settings-daemon/plugins/updates]
 active=false

Of course, it is necessary to run:

 dconf update

You can check configuration with:

 gsettings get org.gnome.settings-daemon.plugins.updates active

Normal user should not be able to install updates.

Comment 3 Rafal Luzynski 2015-11-06 21:11:09 UTC
Isn't it fixed as bug 1267949?


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