Created attachment 1947475 [details]
system journal

Here's a system journal, when I started the system logged in, and then tried to reboot. Waited 60 seconds, then the reboot finally happened.

Created attachment 1947476 [details]
list of all packages

Proposing as a Beta blocker:
"Shutting down, rebooting, logging in and logging out must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops. "
https://fedoraproject.org/wiki/Fedora_38_Beta_Release_Criteria#Shutdown,_reboot,_login,_logout

I cannot reproduce on my laptop, which restarts and switches off just fine, but I am seeing this on a fully updated VM, too.

This happens also on bare metal when there is no GPU 3D acceleration (tested llvmpipe driver). And as expected, doesn't occur in VMs with 3D acceleration enabled (virtio). I'd guess mutter/gnome-shell would be the right component, but will leave re-assign for somebody more proficient.

+4 for Beta FE in https://pagure.io/fedora-qa/blocker-review/issue/1064 , marking accepted. Blocker vote is more split.

(In reply to František Zatloukal from comment #5)
> This happens also on bare metal when there is no GPU 3D acceleration (tested
> llvmpipe driver).

It would seem odd for a bug like this to be associated with GPU, but I suppose strange things happen sometimes. FWIW it happens for me on bare metal with AMD Radeon™ RX 570 Series graphics.

can someone who is seeing this please put 

GNOME_SESSION_DEBUG=1

in /etc/environment, reboot, reproduce, and then attach the full unfiltered output of

journactl -b

?

actually, just from reading the javascript, I think I see the problem...

gnome-shell has this code:

            let button = this.addButton({•                         
                action: () => {•                                   
                    this.close(true);•                             
                    let signalId = this.connect('closed', () => {• 
                        this.disconnect(signalId);•                
                        this._confirm(signal);•                    
                    });•                                           
                },•                                                
                label,•                                            
            });•                                                   

So you can see it calls close and then connects to the closed signal.  if calling close leads to the closed getting emitted right away, then the button wouldn't get confirmed until it's 60 second timeout of the dialog.

Looking at the close method:

    _closeComplete() {•               
        this._setState(State.CLOSED);•
        this.hide();•                 
        this.emit('closed');•         
•                                     
        if (this._destroyOnClose)•    
            this.destroy();•          
    }•                                
...
   close(timestamp) {•        
...
           this.ease({•                                        
               opacity: 0,•                                    
               duration: OPEN_AND_CLOSE_TIME,•                 
               mode: Clutter.AnimationMode.EASE_OUT_QUAD,•     
               onComplete: () => this._closeComplete(),•       
           });•                                                                                                  
...
    }•  

At some point somewhat recently gnome-shell got a change to make the ease function call onComplete right away when animations are disabled, so that change is incompatible with calling close before setting up the handler

Created attachment 1948242 [details]
endSessionDialog: Don't emit 'closed' until handler is connected

    Prior to commit 7bd98f3f5fb7e0d1220646b8a4ee7073534a8e8f animation
    onComplete handlers always occured at least after one main loop
    iteration.
    
    Now, if animations are disabled, they can get invoked immediately.
    
    That breaks the endSessionDialog button handler, which calls
    close before setting up the "closed" signal handler.
    
    This commit fixes the handler to get set up first.

i think that ^ should fix it.

scratch build here if anyone wants to try it Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=98341733

just to follow up, I was able to reproduce the issue, and confirm the scratch build makes it go away for me.

I'd still like someone not-me to try it, but assuming it gets one more yes vote, I'll do a "real" build.

We've got -5 beta blocker +6 final blocker in https://pagure.io/fedora-qa/blocker-review/issue/1064 , so confirming those.

Having the same problem, when testing today in a Virtualbox VM on my new Ryzen desktop

Luna, can you try the scratch builds? or was that with the scratch builds?

I've verified the scratch build fixes the issue for me in these cases:
- bare metal with animations off
- bare metal with llvmpipe
- VM without virgl

Bare metal had AMD GPU (Van Gogh/RDNA 2).

great thanks.

FEDORA-2023-8d52e0617f has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-8d52e0617f

(In reply to Michael Catanzaro from comment #7)
> FWIW it happens for me on bare
> metal with AMD Radeon™ RX 570 Series graphics.

Uh, I see that I do have animations disabled, but that must be a bug. I wonder what component is responsible for deciding whether to enable gnome-shell animations? gnome-shell itself, I guess?

maybe org.gnome.desktop.interface enable-animations is set to false? maybe you're screen casting ?

FEDORA-2023-8d52e0617f fixes the issue.

FEDORA-2023-8d52e0617f has been pushed to the Fedora 38 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-8d52e0617f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-8d52e0617f fixed it for me

*** Bug 2173139 has been marked as a duplicate of this bug. ***

FEDORA-2023-8d52e0617f has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.