wonder why spamming (more or less) worked for us and no one else? must have been the right sequence? When given the selection of mirrors and boxes to check…I kept all the countries in my hemisphere and a handful in Europe…I changed that up a couple times in my ‘spam’…I did due diligence. that last install felt like boxing.
I’m just running an install again and it’s working like normal. When i tried above it was replicating what the OP tried using f2fs. This time I used ext4 with erase disc and swap file without issue.
Edit: Using manual partitioning you can select f2fs but I’m not sure whether this is set up to work this way 
Normally i change the files in calamares first to add f2fs in partition.conf
Edit: I do use US mirrors as well as Canada.
1 Like
those two plus mexico and brazil with a sprinkle of poland, UK, and spain might have broke the dam for me.
I saw on another thread that disabling IPV6 worked for the poster.
this .iso a mystery
edit: partitions hand-made in gparted same as I always do
@thefrog
Well there must have been some issue with the mirrors before because I’m running the install again and using manual partitions with f2fs and it is working now. Both installs proceeded normally without hanging. I don’t normally use manual partitioning so i hadn’t tried different file systems this way from the drop down menu. Using erase disc it only gives ext4 and btrfs so normally i would add f2fs by changing the partion.conf file in Calamares before running the install.
2 Likes
I have to do a debian install in the next few days. I don’t anticipate the same drama 
1 Like
would be nice to get the mirrorlists generated in such cases… devs are not fully able to reproduce the issue only bet in the dark about mirrors with issues could be used.
cat /etc/pacman.d/mirrorlist | eos-sendlog
i never could get the url back for the eos-sendlog yesterday for posting. I tried a couple of times yesterday so I have no clue what the issue was. I was able to install this morning with no issues. So it apparently is cleared up. 
1 Like
I updated the mirrors numerous times and i don’t think that was the issue. It seemed to be having an issue getting the arch linux keyring right at the beginning at 9-10% and then what ever it’s doing directly after up to about 13% and it just was hanging. Some users reporting letting it run upwards of 3 hours. I couldn’t get it to work either and i even started looking at my download speeds and got after my ISP and starting checking it. But then i tried again last night and it was back to normal and i was able to install a few times testing it. My mirrors are only Canada and US and they were all updating and ranking instantly. 
1 Like
i was not able in any my attempts to get it reproducing this issue… we only see that strange thing were it stops to fetch packages without timing out and after a long time simply starts again to fetch packages.
Very hard to catch the underlaying issue.
3 Likes
that’s a hint i can try to check about..
2 Likes
I have been experiencing the same issue. I will attempt to try to install through the online method today as it seems people are reporting that it is working now. My first attempt took me 7 1/2 hours (I ran it overnight because it was taking a entire day to install). It never created a error within those 7 1/2 hours my second attempt I used the offline installer and it installed almost instantly like in the past however when I went to do a full system upgrade the install had major amounts of unreachable mirror errors and it took a lot of tooth and nail to try to get the Canadian & American mirrors to work. I eventually had to remove the EndeavourOS mirrors and use CachyOS mirrors to be able to get the system to upgrade using sudo pacman -Syy.
I also tried CachyOS which is also using the Calamares installer and their online installer worked instantly. By doing that, I did determine it is only a EndeavourOS issue and not something occurring between all Arch Linux distributions using Calamares installer.
If someone can show the contents of file
/etc/pacman.d/mirrorlist
on the installer when the install is stuck (at 13% or another percentage). The
command would be
cat /etc/pacman.d/mirrorlist | eos-sendlog
and then show the returned address here.
Also, if someone has already finished the install after hours of waiting, the same command applies, show the address here.
Will this only show arch mirrors? Correct? Is it possible that a bad endeavouros mirror is the culprit?
Correct, only Arch mirrors. EndeavourOS mirrors should not be the culprit (this time) according to my testing.
But if anyone sees a problem with the EndeavourOS mirrors, please let me know as soon as possible.
I did an install this morning and it was all working fine. But yesterday at this time it wasn’t. I couldn’t pin it down to any mirrors per say. It just seemed to not want to get the first packages needed to get started the pacstrap process and start installing.
Just doing another install and this is the mirror list it’s using for me and my location.
It is installing right now without any issue.
install log
https://0x0.st/XWEv.txt
Gonna add my insight here
i tried to install EndeavorOS six months ago with the exact same behavior, so either its a wild coincidence, or there are deeper mirror issues.
Personally just looking through the mirrorlist i think their is a heavy bias to EU/JP mirrors and from a western connection that’s is the worst case scenario.
Still even at that the speed shouldn’t be 150KB/s worst case connection to JP i should still be able to sustain at least 1MB/s
And that was my observation, trying to install both six months ago and within the last 2 days, download speeds from the mirrors were no more than 150KB/s and average more like 60KB/s
Due to the nature of how the installer is setup you don’t get any useful messages from it it just sticks at 13% with the last useful message saying Downloading xxxxx package… and it’ll sit there for 30, 40 an hour… until it moves to another set of packages…
This should probably also be re-evaluated in the future, more feedback from the installer in these cases, because this is why it looks like it has stalled. it will just stick there at various %'s with no meaningful feedback from the installer…
1 Like
Six months ago would have been a totally different ISO. I believe there were and are mirror issues occasionally and this is just the nature of the beast. EOS has made strides in attempting alleviate mirror issues during the install but it is not possible to correct or fix every issue that may happen at any given time. I have very fast internet and normally my installs take about 4 minutes. Sometimes they can be a bit longer also. I usually know when there are mirror issues and i update the mirrors when necessary. This time it didn’t seem to me to be a mirror issue but it was some type of issue with the process whether it is network related or what i couldn’t say but i assume that. It seems to be working fine now and i have done a number of installs at least in my location and mirror lists.
1 Like
Thanks for the mirrorlist!
Couldn’t find any problematic mirrors there (in the beginning of the list), but then again, it is next to impossible to know the status and reliability of each mirror at a given time point because they constantly change somewhat.
1 Like
I both agree and disagree on some points.
Yes, the mirrors are dynamic and thus difficult to predict. and i would certainly agree that you can’t fix every single problem.
However, when an issue is what I’m going to call, ongoing, as you can find many posts about the same issue for EOS, it is a problem that shouldn’t happen, and a problem that is very much hurting the image of EOS, given one of its actual goals is to be Arch without the install headaches… Well, that’s going to earn it a certain label…
If you read just a few posts on Reddit about EOS they will cite things like this, it’s just crapper arch, or it’s buggy and so on… many citing installer or config issues… i mean take that as you will, but if you discount those sort of claims it’s going to impact the projects reputation i think personally.
Honestly, I would re-evaluate how the installers handle mirrors. i would forcefully pin the installer mirrors to a subset of known good mirrors hosted on for example edu servers or something that is extremely unlikely ever to go down… and also to have at least decent throughput.
Because for me, this issue was compounded, by the fact that no matter what i told the installer to do, refresh, and update the mirrorlist went through the process like 6 or 7 times, and nothing, i don’t know if that was a fluke do this one specific issue, or not, i only state that from my perspective view of having this issue occur multiple times over large periods of time. there at least seems to be perhaps a deeper issue… whether that be server-side or on the ISO itself.
And again, i want to reiterate, the installer needs to give more feedback, simply sticking at installing base system 13% for 1h:30m with nothing useful in the log is a large part of the confusion here… it needs to have at minimal a download progress bar… that way it will be easy to visualize that okay its a download problem not a, it’s just broken problem…
Otherwise those people that say it’s broken or that it has bugs are making factual claims at that point…
2 Likes