Bug 2180673

Summary:	Environment customizations (e.g. disabling update notifications) only apply to 'liveuser', not subsequently-created accounts
Product:	[Fedora] Fedora	Reporter:	Matt Fagnani <matt.fagnani>
Component:	livesys-scripts	Assignee:	Neal Gompa <ngompa13>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	38	CC:	awilliam, kde-sig, ngompa13, rdieter, robatino
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	RejectedBlocker RejectedFreezeException
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-05-30 22:56:12 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Matt Fagnani 2023-03-22 03:19:14 UTC

Description of problem:

I booted the F38 KDE Plasma live images Fedora-KDE-Live-x86_64-38-20230318.n.0.iso and Fedora-KDE-Live-x86_64-38-20230320.n.0.iso in GNOME Boxes QEMU/KVM VMs. I created a new user with the standard account type in System Settings. I logged out of the liveuser session. I logged in as the second user from sddm. An update notification Updates available and the update widget in the System Tray was shown after a minute or two in the second user's session. This update notification wasn't shown in the liveuser session.

The F38 final blocker criterion "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image." might be violated, but I'm unsure if that only applies to the liveuser's account. https://fedoraproject.org/wiki/Fedora_38_Final_Release_Criteria#Update_notification

Version-Release number of selected component (if applicable):
plasma-discover-5.27.3-1.fc38.x86_64
kf5-plasma-5.104.0-2.fc38.x86_64
qt5-qtbase-5.15.8-6.fc38.x86_64

How reproducible:
I saw the update notification in at least 4 sessions of the second user which was most which lasted at least a minute.

Steps to Reproduce:
1. Boot a F38 KDE Plasma installation updated to 2023-3-21 with updates-testing enabled
2. Log in to Plasma on Wayland
3. Install GNOME Boxes if it isn't already with sudo dnf install gnome-boxes
4. Download Fedora-KDE-Live-x86_64-38-20230320.n.0.iso from https://koji.fedoraproject.org/koji/buildinfo?buildID=2172856
5. Start GNOME Boxes
6. Boot Fedora-KDE-Live-x86_64-38-20230320.n.0.iso in a GNOME Boxes QEMU/KVM VM with EFI enabled, 3D acceleration disabled, 3 GiB RAM
7. Start System Settings in Plasma 5.27.3 on Wayland in the VM
8. Select Users in System Settings
9. Select Add New User in Users in System Settings
10. Create a new user with standard account type and a password
11. Close System Settings
12. Log out of Plasma from the Application Launcher menu's Leave menu
13. Log in to Plasma on Wayland as the second user that was created
14. When Plasma starts, wait until the update notification is shown which usually happened after a minute or two

Actual results:
Update notifications were shown for the second user created in F38 KDE Plasma live image VMs

Expected results:
Update notifications wouldn't be shown for the second user created in F38 KDE Plasma live image VMs

Additional info:

Comment 1 Fedora Blocker Bugs Application 2023-03-22 03:24:01 UTC

Proposed as a Blocker and Freeze Exception for 38-final by Fedora user mattf using the blocker tracking app because:

  Update notifications were shown for the second user created in F38 KDE Plasma live image VMs. The F38 final blocker criterion "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image." might be violated, but I'm unsure if that only applies to the liveuser's account. https://fedoraproject.org/wiki/Fedora_38_Final_Release_Criteria#Update_notification

Comment 2 Adam Williamson 2023-03-22 06:09:18 UTC

I'd say this isn't even really a bug.

The customizations to the live environment are only done, and really can only be done, for the precreated user (liveuser). (I mean, you could imagine a mechanism to make them apply to newly-created accounts, but it would be a whole new feature that just doesn't exist, and quite a lot of development work for a corner case). They all apply to that user's config specifically. It's really not intended or envisaged that you create more user accounts in a live session.

It's definitely not a blocker or FE, to me.

Comment 3 Matt Fagnani 2023-03-22 15:14:55 UTC

I only proposed this as a blocker based on the criterion's "...must not do so when running as a live image." The criterion could specify that only applies to the liveuser's session.

Comment 4 Matt Fagnani 2023-03-22 17:19:40 UTC

I created the second user in a VM running the live image Fedora-KDE-Live-x86_64-38-20230318.n.0.iso to reproduce the black screen problem on logout with the second user as I reported at https://bugzilla.redhat.com/show_bug.cgi?id=2179591

Comment 5 Adam Williamson 2023-03-22 23:45:30 UTC

-5 blocker and -3 FE in https://pagure.io/fedora-qa/blocker-review/issue/1125 , marking rejected.

Comment 6 Adam Williamson 2023-03-22 23:46:47 UTC

Re-assigning to livesys-scripts which I *guess* is the most logical place for this. I think we may just close it as WORKSFORME or WONTFIX, though.

Comment 7 Neal Gompa 2023-03-23 00:36:55 UTC

This is pretty much by design. I'm not even certain how we could reliably do this properly for other users.

I don't think we envisioned user creation happening in non-persistent live environments, either. And in a scenario where you have full-disk overlay persistence, then updates would make sense to expose and allow.

Comment 8 Adam Williamson 2023-05-30 22:56:12 UTC

Let's just close this, I don't think we're gonna be doing anything about it.