Cannot load EndeavourOS in vmware
Loading is extending to almost 20 minutes without actually loading? I’m new to EndeavourOS; this is my second try…
Welcome to the community 
The screenshot doesn’t seem to indicate a problem.
Please post the following information so we can try and help:
- what is the host machine operating system
- how much RAM and disk space are assigned to the VM?
- what is the host graphics card
- have you tried using VirtualBox instead of VMware
Thanks
Edit: I edited your title to help the community focus on the core problem.
Thanks for your response. If you look at the last line it says something like 13 minutes; my second attempt was 22 minutes. I made an assumption that something is looping and it looked endless - 22 minutes is an awful long boot up time. This was on first installation.
My laptop is an ASUS 14" w/ Intel 7 Gen 11; host is Ubuntu with KDE Plasma desktop. In VMware I assigned 8 GB ram and 20 GB disk; host graphics are Intel ARC I believe, whatever came with the laptop. I’ve installed a few different Linux distros before on this machine without issue. (Mint, Zorin…) My host NVMe is 512 GB with approx 50% free space.
I tried to install Endeavour as Other 64 bit Linux in vmware but it only gets this far when booting.
Not sure if this is an issue, but I’ve always installed EOS as an "Arch” system, not Other.
Never had an issue like you’re experiencing. Give that a try. 
I have never seen a device like that on vmware. What kind of disks did you choose?
That shouldn’t matter.
Hi @brucejam,
It is not clear what kind of VM manager you use. I guess it is VirtualBox.
VirtualBox is fine of course. I have no tips for VirtualBox, though.
If you need/want to stick with VirtualBox you can ignore the following.
The use of quickemu.
A tool that makes QEMU really easy to download and run an ISO in a VM.
yay quickemu
mkdir ~/emu
cd ~/emu
# Download and setup vm automatically
quickget endeavouros titan-neo-2026.04.27
Or use quickbox, a GUI for quickemu.
Quickemu GUI (GTK/QT)
yay quickbox
@made-lief OP says they are using VMware.
I use VirtualBox with success to install and test many distros, including the various EOS options.
It is in the official repos and would be my suggestion here.
@brucejam
I agree there is an issue. Not sure what’s causing it. I usually use 4 GB memory and 28 GB drive space on vmware. I purposely downloaded the latest EOS ISO and installed in vmware and got the same result. It’s taking way too long to load if it ever does. I didn’t wait to find out. Instead i tried loading another distro using CachyOS. I used grub as the bootloader btw.
Installed CachyOS on vmware and rebooted into it. It loads instantly!
Thanx to all for your responses. This is looking more like a VMware issue than an EOS problem. I;'ve used VMware (ESX) for years (not saying how many lol). Currently it is the VMware desktop client on my laptop. Never used virtualbox or even Windows virtual machines. I think I will pivot to VMware support and see if they have any suggestions. I’d like to stick to VMware as I have other vm’s I use.
If I get any answers from VMware support I will post them here.
I also prefer vmware for a number of reasons. I am currently checking eos on vmware again because normally i always test every ISO on vmware and if there was a problem i would have noticed at the time. I am using ® Workstation Pro 26H1. version 26.0.0.25388281
Something has changed because it did work when the ISO was put out. At least on my hardware that I tested it on.
Another option is vm-curator, a much-easier TUI for QEMU/KVM virtual machines.
I test all our ISOs in vmware. The ISO was working fine at the time it was released.
This only started failing with recent package changes.
I am skeptical this is a vmware issue.
I will look into this today and report back.
Thank you dalto. I await your test results. Cheers
I am using VMware® Workstation 17 Pro version 17.6.2 build-24409262.
I found the issue.
It is an incompatibility between the latest version of systemd and dracut. Updating to dracut 112 fixes it. However, 112 was released less than 2 hours ago so I am hesitant to push it. Let me try backporting the fix instead.
Of course, that would require me to determine which commit actually fixes this issue.
Yes …
\[ricklinux@rick-ms7c91 \~\]$ dracut --version
dracut 111
Ricklinux - thanx for the url to dracut info. Gotta confess though, most of it is over my head. Suffice to say it is part of the boot process. Big question now is ‘How do I fix the boot issue?’
Have to wait for an answer from @dalto. This is also above my head. I just pointed out that my system has dracut version 111 and it is showing the same issues. As i stated when the ISO’s were put out they were tested with vmware. That’s mostly what i use and others test with it too. Not sure how he determined it was an incompatibility with systemd and dracut. 