I have 3 slow machines, two from 2008 and one from 2013. When I was repeatedly attempting to install F43 from the GNOME Workstation Live, it would always hang near the end, usually at Finalization, Configuring installed system (though the progress circle continued to spin). On the machine from 2013, this would happen part of the time, though I occasionally got completed installs. Even when it appears to hang, the install seems fine if I reboot the machine. I filed https://bugzilla.redhat.com/show_bug.cgi?id=2406677 against F43 back in October. This happened with F44 when I first created a F44 VM with Fedora-Workstation-Live-44-20260206.n.2.x86_64.iso using virt-manager. On my next attempt, I used Fedora-Workstation-Live-44-20260219.n.0.x86_64.iso and the same thing happened. This is described at https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/UL4CA7AO267RI5MHZNB6QX7W4D43KTK7/ . I saved the files /tmp/*.log from the first attempt with the 20260219 ISO. Kamil Paral told me to create a bug with all the files /tmp/*log (so including syslog) but on later attempts to reproduce I see no such file, only the ones I originally saved. I have been unable to reproduce so far even though it happened on both of the first two tries. Therefore I'm attaching the files /tmp/*.log from the first 20260219 attempt where it hung. Reproducible: Sometimes Steps to Reproduce: 1. Attempt a GNOME Workstation Live install on a slow machine (AFAIK it's associated with the machine being slow) using default settings (in my case it allocated 4096 MB and 2 CPUs to the VM). Actual Results: Sometimes the installer appears to hang, usually at Finalization, Configuring installed system, even though the progress circle continues to spin. When it's in this state, attempting to access the storage editor menu in the top right will cause it to crash with some error. Attempting to automatically report the bug will fail after entering the Bugzilla API key, it'll just say "Verifying..." forever. If I reboot, the install seems to be fine, however. I have no way of knowing if the install actually was complete. Expected Results: The installer should finish and state that it was successful. Additional Information: My 3 machines: Lenovo ThinkCentre M58p (from 2008) with 16 GiB of RAM, Compaq Presario SR5413WM (from 2008) with 4 GiB of RAM, Lenovo ThinkPad X131e (from 2013) with 4 GiB of RAM. For the F44 install attempts I created a virt-manager VM using the M58p as host.
Created attachment 2130766 [details] /tmp/anaconda.log
Created attachment 2130767 [details] /tmp/anaconda-webui.log
Created attachment 2130768 [details] /tmp/dbus.log
Created attachment 2130769 [details] /tmp/journal.log
Created attachment 2130770 [details] /tmp/packaging.log
Created attachment 2130771 [details] /tmp/program.log
Created attachment 2130772 [details] /tmp/storage.log
My original assumption was that you're seeing an out-of-memory situation. So try to give the VM at least 5-6 GB RAM instead (on that host with 16GB RAM) and see if it makes any difference. (I just tested a installation with 3.5 GB RAM and it completed, but oh boy the UI was frozen very often, because the compressed RAM just couldn't keep up). But also, looking into your journal, I see a kernel panic: Feb 19 18:23:49 localhost-live kernel: ------------[ cut here ]------------ Feb 19 18:23:49 localhost-live kernel: [CRTC:37:crtc-0] vblank wait timed out Feb 19 18:23:49 localhost-live kernel: WARNING: drivers/gpu/drm/drm_atomic_helper.c:1920 at drm_atomic_helper_wait_for_vblanks.part.0+0x250/0x2b0, CPU#1: kworker/u10:6/5001 Feb 19 18:23:49 localhost-live kernel: Modules linked in: libfc scsi_transport_fc iscsi_ibft dm_crypt vfat fat dm_round_robin dm_multipath raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 uinput snd_seq_dummy snd_hrtimer rfkill nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables qrtr snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core kvm_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hwdep iTCO_wdt snd_seq intel_pmc_bxt iTCO_vendor_support snd_seq_device kvm snd_pcm joydev i2c_i801 snd_timer irqbypass i2c_smbus snd pcspkr lpc_ich soundcore virtio_balloon tun vsock_loopback vmw_vsock_virtio_transport_common zram vmw_vsock_vmci_transport vsock lz4hc_compress vmw_vmci lz4_compress overlay erofs netfs isofs virtio_net net_failover virtio_gpu failover virtio_dma_buf serio_raw nvme_tcp nvme_fabrics nvme_core nvme_keyring Feb 19 18:23:49 localhost-live kernel: nvme_auth hkdf sunrpc be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls cxgb3i cxgb3 mdio libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi loop fuse i2c_dev nfnetlink qemu_fw_cfg Feb 19 18:23:49 localhost-live kernel: CPU: 1 UID: 0 PID: 5001 Comm: kworker/u10:6 Not tainted 6.19.2-300.fc44.x86_64 #1 PREEMPT(lazy) Feb 19 18:23:49 localhost-live kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-9.fc43 06/10/2025 Feb 19 18:23:49 localhost-live kernel: Workqueue: events_unbound commit_work Feb 19 18:23:49 localhost-live kernel: RIP: 0010:drm_atomic_helper_wait_for_vblanks.part.0+0x257/0x2b0 Feb 19 18:23:49 localhost-live kernel: Code: ff ff 84 c0 74 84 48 8d 74 24 10 4c 89 ff e8 50 8b 3c ff 45 85 ed 0f 85 e7 fe ff ff 48 8d 3d f0 41 de 01 48 8b 53 20 8b 73 60 <67> 48 0f b9 3a e9 cf fe ff ff 48 8b 5c 24 40 48 8b 6c 24 48 4c 8b Feb 19 18:23:49 localhost-live kernel: RSP: 0018:ffffcd69c3f6fd78 EFLAGS: 00010246 Feb 19 18:23:49 localhost-live kernel: RAX: 0000000000000001 RBX: ffff8b9ae2980040 RCX: ffff8b9ad1854a38 Feb 19 18:23:49 localhost-live kernel: RDX: ffff8b9ac02a4e78 RSI: 0000000000000025 RDI: ffffffffa60a4b30 Feb 19 18:23:49 localhost-live kernel: RBP: 0000000000000000 R08: 000000d4774d69f6 R09: 0000000000000001 Feb 19 18:23:49 localhost-live kernel: R10: 0000000000000001 R11: ffff8b9a145a8000 R12: 0000000000000000 Feb 19 18:23:49 localhost-live kernel: R13: 0000000000000000 R14: ffff8b9ac10ec280 R15: ffff8b9ad1854a30 Feb 19 18:23:49 localhost-live kernel: FS: 0000000000000000(0000) GS:ffff8b9b951e7000(0000) knlGS:0000000000000000 Feb 19 18:23:49 localhost-live kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Feb 19 18:23:49 localhost-live kernel: CR2: 00007f82adee4000 CR3: 000000011f486000 CR4: 00000000000426f0 Feb 19 18:23:49 localhost-live kernel: Call Trace: Feb 19 18:23:49 localhost-live kernel: <TASK> Feb 19 18:23:49 localhost-live kernel: ? __pfx_autoremove_wake_function+0x10/0x10 Feb 19 18:23:49 localhost-live kernel: drm_atomic_helper_commit_tail+0xa8/0xc0 Feb 19 18:23:49 localhost-live kernel: commit_tail+0xee/0x150 Feb 19 18:23:49 localhost-live kernel: process_one_work+0x190/0x350 Feb 19 18:23:49 localhost-live kernel: worker_thread+0x244/0x380 Feb 19 18:23:49 localhost-live kernel: ? __pfx_worker_thread+0x10/0x10 Feb 19 18:23:49 localhost-live kernel: kthread+0xfa/0x240 Feb 19 18:23:49 localhost-live kernel: ? finish_task_switch.isra.0+0x82/0x2a0 Feb 19 18:23:49 localhost-live kernel: ? __pfx_kthread+0x10/0x10 Feb 19 18:23:49 localhost-live kernel: ? __pfx_kthread+0x10/0x10 Feb 19 18:23:49 localhost-live kernel: ret_from_fork+0x130/0x1a0 Feb 19 18:23:49 localhost-live kernel: ? __pfx_kthread+0x10/0x10 Feb 19 18:23:49 localhost-live kernel: ret_from_fork_asm+0x1a/0x30 Feb 19 18:23:49 localhost-live kernel: </TASK> Feb 19 18:23:49 localhost-live kernel: ---[ end trace 0000000000000000 ]--- So that might be another reason for a hang/crash. I'm surprised to see this in a VM. If you can reproduce the crash again, it would be very useful to collect the system journal (`journalctl -b > journal.txt`) afterwards and attach it. I don't see any OOM here in this journal, but it can just mean it tried really hard but hasn't yet reached the point where it had to kill something.
The one time it seemed to be hung and then crashed, I was deliberately loading my host down by running my other 4 GB F44 VM at the same time, and watching video on the host. It also seems that the proper way to send Ctrl-Alt-Fn is to use the "Send Key" in the VM menu, I was trying to do it directly from the keyboard when the crash happened. Anyway, since I'm having trouble reproducing, I'm going to try again with LESS RAM (2 GiB) but not loading down the host. I'll also download the latest branched image which I believe has the 6.19.3 kernel, the image I was using has 6.19.2 and I think that might be fixed in the latest kernel.
I was wrong, the latest image Fedora-Workstation-Live-44-20260224.n.0.x86_64.iso still has the 6.19.2 kernel but I'll use it anyway.
Also, in the test list thread I noted that I originally was experiencing this issue on my hosts when installing F43 Gold, including the one with 16 GiB. So I don't think it's RAM. When installing F43, I was also able to get an automatic bug report at https://bugzilla.redhat.com/show_bug.cgi?id=2406677 by attempting to access the storage editor menu (otherwise it would have just hung forever).
OK, 2 GiB is definitely not enough, the installer crashed before I even started the install. Tried again with 4 GiB and loading the host down like before but it finished the install. Will keep trying.
OK, I think I know why I couldn't reproduce. In my latest attempts, I was going back and forth between the graphical installer UI (on F2) and a VT (on F3) to monitor what was happening. Apparently that interaction prevents the hang. In my latest attempt I avoided interacting or going to a VT until the hang happened (which it did). When it does, I can still get to a VT to collect the logs. In addition to the usual 7 files /tmp/*log (I still don't see a file /tmp/syslog), I saved the output of 'journalctl -b' during the hang as journal1.txt, and the output after triggering the crash by attempting to access the storage editor menu as journal2.txt. From my earlier attempts monitoring the contents of /tmp during the install, it appears that journal.log is only created around the time the install is finished, the other 6 files (anaconda.log, anaconda-webui.log, dbus.log, packaging.log, program.log, storage.log) exist much earlier. Does the existence of journal.log in fact prove that the install is done? If so, I could just check for that when the hang happens. It would be nice if the UI was updated so I don't have to do that, but whatever.
Created attachment 2130894 [details] /tmp/anaconda.log
Created attachment 2130895 [details] /tmp/anaconda-webui.log
Created attachment 2130896 [details] /tmp/dbus.log
Created attachment 2130897 [details] /tmp/journal.log
Created attachment 2130898 [details] /tmp/packaging.log
Created attachment 2130899 [details] /tmp/program.log
Created attachment 2130900 [details] /tmp/storage.log
Created attachment 2130901 [details] output of 'journalctl -b' during UI hang, but before triggering crash by trying to access storage editor menu
Created attachment 2130902 [details] output of 'journalctl -b' after triggering crash by trying to access storage editor menu
BTW, the error when I triggered the crash is again "Installation failed" and "Error details" "Cannot parse given Error object" (which happens to be the same error when I tried with 2 GiB and the installer crashed before I even started it). As before, when I enter my Bugzilla API key and click Next, it just says "Validating..." forever, so automatic reporting is impossible.
I did try the same thing once last night with 6 GiB of RAM instead of 4 GiB, without interacting with it, and the installer finished anyway. But even if RAM has something to do with it, I know that the installer is capable of finishing with 4 GiB, since it does when I interact with it during the install (which if anything should require more RAM). In earlier attempts, when I was running a VT during the install, I think I noticed it running "dracut" when the UI said it was still installing the boot loader. It's possible that the UI is lagging and sometimes showing an earlier stage than what it's actually doing, which could account for why it sometimes fails to report the install finishing.
I don't see any exact cause of failure. The kernel crash is still there, though, which is concerning and might be the reason of your troubles (there is no crash for me in my VMs). It might be related to libvirt passing the CPU bits into the VM, I have no idea. A few notes: * My note about /tmp/syslog was wrong, it's not present on Live images, so you don't need to be concerned about it * Please don't overload your host when doing a VM install. We're trying to debug an issue here, we don't want any more variables in the process. The memory allocation should be dedicated to the VM, so it shouldn't have any impact, that is until your host runs out of memory and starts killing processes, and then it's game over, things break randomly. So let's not do that. * On repeated installs, things might not always have the same result. Especially with low memory situations. Fedora uses RAM compression to improve memory starvation, but it might sometimes compress better and sometimes worse, according to current RAM contents. And the processes take different amount of RAM based on various factors, like your current hardware, disk layout, etc. So the fact that you can install the VM with 4GB RAM sometimes doesn't have to mean it's good enough. Definitely don't go any lower on RAM assignment. Please attach your VM XML here. Go to virt-manager -> VM -> View -> Details -> Overview -> XML, save to a file and upload it here. My current thoughts are: 1) We should consider increasing the RAM requirement at least for Workstation. In my experience, 4GB RAM is clearly struggling a lot. The animations are stuttering during install, as compressed RAM tries to keep up. The minimal recommended value should probably be 6GB RAM. 2) The reason why your laptops with 4 GB RAM don't finish install (but your VM often does) might be related to the fact, that on bare metal, your actual available RAM is lower than in a VM (the iGPU reserves a decent chunk of it). 3) The kernel tracebacks might be a potential cause of your issues in your VMs.
The last time I did bare metal installs was with 43 Gold, and I had the same trouble with all 3 machines, including the one with 16 GiB. The only one which EVER was able to show a completed install was the fastest one, the one laptop (Lenovo X131e) with 4 GiB. The desktop with 16 GiB never did (I'm using it anyway as my main machine since it seems normal running 43). With 44, so far I've only done the install in a virt-manager VM. I've already deleted the 44 VM (since apparently it won't stay in Paused mode when I quit virt-manager). I should be able to reproduce easily now that I know not to interact with it during the install. Would it be helpful to try to reproduce in a VM with 43 Gold? The kernel traceback probably didn't exist back then. I'll include the VM XML next time, should I also include the other log files?
There can be two different reasons, low memory for those 4GB RAM situations and something else (kernel?) for the 16GB RAM machine. But it's weird that it manifests the same way. Honestly, I don't know. I think we have enough logs for the moment, but anaconda devs will be probably needed to look into them. Just attaching the VM XML is helpful to see if you have something non-standard in its configuration.
I used all the default settings when setting up the VM (4096 MB, 2 cores, 20 GB storage). The host Hardware Information is # System Details Report --- ## Report details - **Date generated:** 2026-02-27 06:30:09 ## Hardware Information: - **Hardware Model:** Lenovo ThinkCentre M58p - **Memory:** 16.0 GiB - **Processor:** Intel® Core™2 Duo E8400 × 2 - **Graphics:** Intel® Q45/Q43 - **Disk Capacity:** 2.0 TB ## Software Information: - **Firmware Version:** 5CKT77AUS - **OS Name:** Fedora Linux 43 (Workstation Edition) - **OS Build:** (null) - **OS Type:** 64-bit - **GNOME Version:** 49 - **Windowing System:** Wayland - **Kernel Version:** Linux 6.18.13-200.fc43.x86_64
Ok. Please do attach the VM XML, though. (A two-core host, oh wow. That really must be slow.)
Created attachment 2131291 [details] Requested output from F44 VM (same configuration as before) I recreated the F44 VM with the same configuration as before, and verified that it hangs during install. Attaching the associated XML.
I created a new VM which is basically identical to the configuration above. I assigned it 4GB RAM and two cores, and to simulate your slow machine, I switched my host system to powersave mode, which limited it to just 1.5 GHz frequency for each core. The installation was very slow (step 3/4 took ~5 minutes, step 4/4 took 1-2 minutes), but it finished fine. I tested two passes. So whatever the race condition or other issue is, I don't seem to be able to replicate it.
(In reply to Andre Robatino from comment #13) > Does the > existence of journal.log in fact prove that the install is done? If so, I > could just check for that when the hang happens. Could someone answer the above question about whether /tmp/journal.log is only created when the install is finished? If it is, I can just check for that when the UI freezes up, in case this can't be fixed. All three of my current machines are too old/slow to avoid this issue completely but they seem fine if I just reboot after the install hangs (referring to my F43 Gold installs), and I don't want to replace them for now.