| Summary: | Upgrading via mgaapplet + screenlocker kicks in -> normal level user locked out | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Morgan Leijström <fri> |
| Component: | RPM Packages | Assignee: | Mageia tools maintainers <mageiatools> |
| Status: | REOPENED --- | QA Contact: | |
| Severity: | major | ||
| Priority: | High | CC: | davidwhodgins, mageia, ouaurelien, thierry.vignaud |
| Version: | Cauldron | Keywords: | IN_ERRATA8, IN_ERRATA9, IN_RELEASENOTES8, IN_RELEASENOTES9 |
| Target Milestone: | Mageia 10 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | MGA8TOO, MGA9TOO | ||
| Source RPM: | mgaonline-3.31-1.mga8.src.rpm | CVE: | |
| Status comment: | |||
|
Description
Morgan Leijström
2019-08-09 23:41:22 CEST
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) =>
OLD I believe nothing have changed. As it is major i think it should be tested before closing. Status:
RESOLVED =>
REOPENED 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 =>
mageiatools
Aurelien Oudelet
2021-01-18 20:06:36 CET
Source RPM:
dkms-nvidia-current =>
mgaonline-3.31-1.mga8.src.rpm 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). 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 =>
High 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 10 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 |