From https://bugs.mageia.org/show_bug.cgi?id=25216#c6 : Description of problem: Main problem: If user leaves after starting updating, and comes back after screen saver kicks in, it is impossible to log in the normal way. There is a message telling how to log in, but i think most users are not comfortable, see my experience below. Additionally, Plasma logout function in menu fails until reboot. We should tell the user how to shut down/reboot. Or even better if we could patch the menu to work; the CLI shutdown and reboot commands seem to work. Is there some way to tell the user that reboot is needed for continued reliable operation (or was there, an i forgot i had seen it?) But if user leaves for coffe while updating, and screen saver kicks in. Well this could be split in two bugs but they are related. My recent experience: Updated, had to go, came back much later, screen saver had kicked in and I and was greeted with a black screen and white text that said unlocking had failed and i should run "loginctl unlock-session c2" from another terminal. I Ctrl-Alt-F1 to that terminal and saw it repeatedly output a screen full of NVIDIA messages amongst them "API mismatch". It is not very user friendly to switch to tty and input that command being interrupted by scrolling messages... Because users may loose unsaved work when they fail to re-login the bug severity may be "Critical" but on the other hand it have been like this for long... so i set it major.
Morgan Thank you for the reference to https://bugs.mageia.org/show_bug.cgi?id=25216#c6 which duplicates this bug (but not marking it as such) for Mageia 6; for which an update was pushed today. That was nVidia specific. Can you say what video hardware & driver you are using in Mageia 7? Since tmb dealt with the other bug, I am assigning this one to him initially for his wisdom. Please re-assign it as you see fit. I wonder whether bug 25008 is related.
Assignee: bugsquad => tmb
As i wrote this bug is for this specific issue, which i last saw when testing bug 25216, which is pushed as you say. Which is why i issued this bug. Ops i set wrong release! And yes i forgot to state clearly: using nvidia-current
Version: 7 => 6
I will probably see later when i upgrade if valid for mga7 too, but i guess so.
Hi, thanks for reporting this bug. We are sorry, but we no longer maintains this version of Mageia. Please upgrade to the latest version and reopen this bug against that version if this bug exists there. As a result we are setting this bug to CLOSED:OLD
Resolution: (none) => OLDCC: (none) => ouaurelienStatus: NEW => RESOLVED
I believe nothing have changed. As it is major i think it should be tested before closing.
Status: RESOLVED => REOPENEDResolution: OLD => (none)Version: 6 => 7
https://askubuntu.com/questions/972778/locked-out-of-kde-while-upgrading Does the behavior was like above link?
I think i did not see that message, but instead the instruction how to do it (which is far better :) ), sea last half of comment 0. As per my description "screen full of NVIDIA messages amongst them "API mismatch". I believe system was unable to show a GUI at all. I believe kernel and drivers maintainers should decide if to close this bug as old or keep open. - If it is possible it can happen again. Maybe make it block screen savers during update - always, or when certain parts are updated.
Assignee: tmb => kernel
Yeah you're right after all. Doing the following QA: On a M7 Plasma, updated, default settings. $ mgaapplet --testing Screen locked 5 minutes later: TTY1 locked. A message asks user to log on TTY2 and issue: # loginctl unlock-session c2 This never does not function well, nvidia card. Upgrade seems to run in background but lambda user will not get any clue on what's going on. So, mgaapplet-upgrade-helper should be called with systemd-inhibitor: a command like this: $ systemd-inhibitor --what=idle:sleep:shutdown --mode=block mgaapplet-upgrade-helper I wonder if this must be the same to all gurpmi launching. Reassigning. Raising release blocker.
Assignee: kernel => mageiatoolsSummary: Update + user away -> normal level user locked out -> may loose work => Upgrading M7 to M8 via mgaapplet + user away -> normal level user locked outTarget Milestone: --- => Mageia 8CC: (none) => mageia, thierry.vignaudPriority: Normal => release_blocker
Source RPM: dkms-nvidia-current => mgaonline-3.31-1.mga8.src.rpmVersion: 7 => CauldronWhiteboard: (none) => MGA7TOO
Inhibiting lock seems like a very bad idea security wise. Most people don't stay in front of their computer while upgrading a lot of packages, so it should get locked if it is configured to lock when users are away (like many companies requires). Instead whatever breaks should be fixed. If distro upgrades can not be done in plasma, then we should explicitly log the user out and do the upgrade through some background service.
(In reply to Pascal Terjan from comment #9) > Inhibiting lock seems like a very bad idea security wise. > > Most people don't stay in front of their computer while upgrading a lot of > packages, so it should get locked if it is configured to lock when users are > away (like many companies requires). > > Instead whatever breaks should be fixed. > > If distro upgrades can not be done in plasma, then we should explicitly log > the user out and do the upgrade through some background service. Yeah, security related this can't be done. But, all new Plasma instance, app,... can't load due to a new glibc, new libraries,... So, this should really be user loggued out and with a GUI. Or, use DNF system-upgrade ?
(In reply to Aurelien Oudelet from comment #10) > But, all new Plasma instance, app,... can't load due to a new glibc, new > libraries,... > > So, this should really be user loggued out and with a GUI. > Or, use DNF system-upgrade ? Or warn the user that he must save his work before starting the upgrade because the machine will reboot automatically.
No, the machine does not reboot automatically if you use mgaapplet to upgrade. If you "dnf system-upgrade" it is the case as it does upgrade right after a reboot and reboot automatically.
(In reply to Aurelien Oudelet from comment #12) > No, the machine does not reboot automatically if you use mgaapplet to > upgrade. Sorry for being unclear: my previous comment included an implicit reboot (I know it doesn't do it for now, but this should be implemented if some key packages are being updated).
Status?
CC: (none) => davidwhodgins
This is since some time in release notes in the form of instructions how to upgrade. (The DNF immediate reboot too, BTW, #11 ) Now I added a note and link to instructions, also citing this bug, at https://wiki.mageia.org/en/Mageia_8_Errata#Upgrade_issues
Keywords: (none) => IN_ERRATA8, IN_RELEASENOTES8
considering this is not a new issue, and would need a lot of integration and testing ... there is nothing that can or will be fixed for Mga8 within a reasonable time frame... so not a blocker for mga8 release
Priority: release_blocker => HighTarget Milestone: Mageia 8 => Mageia 9
On dev and qa list today, because of several users are being hit: https://ml.mageia.org/l/arc/qa-discuss/2021-04/msg00154.html https://ml.mageia.org/l/arc/dev/2021-04/msg00083.html Andrews Farm added that it have in the past also hit install from Live Plasma, so we should also check if Live installer, the one launched from desktop, is affected.
We have this noted in https://wiki.mageia.org/en/Mageia_9_Release_Notes#Online-Upgrade and we note and point it from errata. One user that hit this upgrading to 9: https://forums.mageia.org/en/viewtopic.php?t=15112 Developers: Could systemd-inhibit be used by the updater, urpmi in general, to hinder screen locking? https://www.freedesktop.org/software/systemd/man/latest/systemd-inhibit.html
Target Milestone: Mageia 9 => Mageia 10Keywords: (none) => IN_ERRATA9, IN_RELEASENOTES9Whiteboard: MGA7TOO => MGA8TOO, MGA9TOO
Somehow the line got missing in 9 rel notes, now reinstated.
Summary: Upgrading M7 to M8 via mgaapplet + user away -> normal level user locked out => Upgrading via mgaapplet + screenlocker kicks in -> normal level user locked out