Fix dismiss() called from worker thread without event loop

[h8d13]

Steps to reproduce:

• Press exit (instead of reboot, chroot) at the end of archinstall

[svartkanin]

I cannot reproduce this, my installation was able to exit just fine.

Can you share a reproducible configuration file

[h8d13]

Lol you test minimal cfg when I'm talking about UI bugs ? Must be making fun of me. Or just "mauvaise foix". I've had this crash several times over or I wouldn't be reporting it/bothering to fix it.

I also must have hallucinated the traceback attached 🤷‍♂️

Anyways, I'm sure you are aware:

_exec_callback creates an OS thread per LoadingScreen
Believe should be:

109 +  @work                                                                                                                                                  
110 +  async def _exec_callback(self) -> None:  

not thread=True

_show_async new worker per screen push

1177 -  @work                                                                                                                                                 
1178 -  async def _show_async(self, screen: Screen[Result[ValueT]]) -> Result[ValueT]:                                                                        
1177 +  async def show(self, screen: Screen[Result[ValueT]]) -> Result[ValueT]:                                                                               
1178      return await self.push_screen_wait(screen)
1179  
1180 -  async def show(self, screen: Screen[Result[ValueT]]) -> Result[ValueT]:                                                                               
1181 -    return await self._show_async(screen).wait()   

Which already fixes a large part of this screen redrawing, but we are still inherently creating about 80 apps within your create/destroy cycles.

https://textual.textualize.io/guide/workers/

--

Now as to this in general, I will say it again here, I think it should have been held back on your drafts before slowing down others trying to contribute too and before it was fully functional.

[codefiles]

I am not able to reproduce this either. The screenshot also shows your fork path in the prompt at the end. Are you testing your fork or archinstall? In #4244 the path in the traceback also shows your fork. You have mentioned issues before that I can't reproduce and I have suspected your are testing your fork. This should be obvious but if you are testing archinstall and reporting issues for archinstall, you should be using archinstall in those tests, not your fork.

[h8d13]

My fork has upstream branch which is just master ?? You do know branches can do that when you point an upstream source ? and my fork the module is named after it, to avoid confusion (it also doesn't use -textual).

$ git log                     
commit f736b8c4ec9c2b16d98db914824eb283a6a8b032 (HEAD -> sync, upstream/master, upstream/HEAD, origin/sync)
Author: HADEON <52324046+h8d13@users.noreply.github.com>
Date:   Tue Feb 17 03:19:11 2026 +0100

    install gfx before DE/WM/Server (#4238)

commit 8edab9fafd04a3049c8ad880f76b26802eac6706
Author: codefiles <11915375+codefiles@users.noreply.github.com>
Date:   Mon Feb 16 21:15:07 2026 -0500

    Move get_unique_path_for_device() to disk.utils (#4242)

If you guys do not want to address these things, (which btw are very apparent) I'm happy to walk away from them again.

[codefiles]

I think you are confused. I just want to be able to reproduce issues that are reported to confirm and investigate them. Both svartkanin and I have tried to reproduce it and can't. Can you help with that?

[h8d13]

Not confused in general, confused at the nonchalant responses:

I report a UI issue and Svart tests a minimal config with just bootloader/minimal ?
Same for you who tests EFI NVRAM into QEMU/KVM.

I test on physical hardware, and came across this bug several times. Provided full traceback and explanations as to why it happens. + Fixes. I don't see how I can be much clearer.

[codefiles]

Also your prompt shows the git branch being used as patch-systemdhooks not upstream or am I misinterpreting the prompt?

[h8d13]

Also your prompt shows the git branch being used as patch-systemdhooks not upstream or am I misinterpreting the prompt?

Which is branched from upstream...

[codefiles]

That is not upstream, how can I know what you have or have not changed in this new branch?

[h8d13]

That is not upstream, how can I know what you have or have not changed in this new branch?

Aight im done you must be trolling at this point. https://github.com/h8d13/archinstoo/tree/patch-systemdhooks

There are no bugs and

[codefiles]

That was a rhetorical question. I have no interest in your fork or investigating it when working on archinstall.

[h8d13]

Right thats one of the main issues to this project we could help each other instead feels like you're all up on ego 😉

[codefiles]

You are projecting hard. This is the last time I will repeat this, I just want to reproduce the issue.

[h8d13]

Lol projecting the fact that neither svart or you test properly, yes that I will project.

2026-02-17.14-36-21.mp4

I gave clear examples, related issues and here is me reproducing it again :)

[h8d13]

Branch has no changes but 20 lines inside installer.py as seen here public

For the rror to occur you'd hhave to actually use the menu like explained above #4236 (comment)

[codefiles]

So not upstream? Why would you just not use upstream to demonstrate this? The video adds nothing more than what the screenshot already shows. I want to see a video of you git clone https://github.com/archlinux/archinstall.git and then run that. Please.

[h8d13]

I'm in no way doing that again just because you don't trust my git usage. It's honestly insulting. It has 1 commit to change to systemd hooks, how would that effect that traceback ?

You're moving goalpost instead of just accepting something with the UI is borken or how it resets after installs/or even operates more globally. You asked to reproduce, and I just did :)

[codefiles]

It is clear you can't reproduce it with master.

[h8d13]

You're a good dev, and sometimes also a very good reviewer. But here you are deeply wrong just like with efistub :)

If you checked out the UI implementation, you'd know why happens in master too.

[codefiles]

Drop all this and just provide a video. For all that you have done already creating the video should be easy. Don't misrepresent me, I never said anything in regards to the patch, only reproducibility. I never disagreed with the change. Reread what I have commented and see what it is that I have said.

[h8d13]

You comments suggested I was "confused" and on the wrong git repo ?? You do know you can git clone -b correct?
And svart didn't bother to test properly

Nope you go figure it out for yourself now, I think I had provided a lot of valuable info :) Maybe you can learn something too