• Antergos installer crashes at the end

    @karasu I’ve tried to install KDE again and yet with no success

    I get the following error:

    2018-06-20 20:42:05 [DEBUG] pac.py(556) cb_log(): checking sha256sum for /install/var/cache/pacman/pkg/antergos-midnight-timers-1.0-3-any.pkg.tar.xz
    2018-06-20 20:42:05 [DEBUG] pac.py(556) cb_log(): returning error 34 from check_validity : Ungültiges oder beschädigtes Paket

    It seems it’s a faulty package / checksum, the file is downloaded from http://repo.antergos.info/antergos/x86_64/

    I’ve appended whole log files for the installation with the previous mentioned steps taken on github linstall fails caused by checksum error (openbox/KDE) #906

    Since I start to run out of Ideas I’ll stick to gnome it seems.

  • since editing means spam for some reason…

    I’ve tried to remove the package from the package.xml and I get the same error at lib32-mesa-18.0.4-2-x86_64

  • @karasu
    I noticed while modifying my reflector-antergos program that for an unknown reason I had to change the “reference” file from https://repo.antergos.info/$repo/$arch/main.files.tar.gz to http://mirrors.antergos.com/$repo/$arch/main.files.tar.gz because the files were not the same (as I have assumed for a long time now).

    I use the reference file for checking that the same file on a ranked mirror is up to date. Previously repo.antergos.info worked well, but now it is not working at all and I must use mirrors.antergos.com instead.

    So this made me thinking, is it possible that in cnchi the corrupted file download problem could have a similar reason? Is the corruption check based on information from a source that is not in the same “release level” than the files to be checked?

    Hopefully you get the idea what I’m trying to say, as English is not my native language…

  • @manuel looks like very related to the issue ;)
    Also as the hack from @searedvandal do nothing else than ranking the mirrors and use https only for archmirrors, and only a new list for antergos-mirrors mixed http and https ones… but i do not have
    Server = http://mirrors.antergos.com/$repo/$arch inside…

  • @karasu
    I studied the problem further, tried to install Antergos KDE just a moment ago.
    I manually set both mirrorlists to be good.

    The strange thing is that in /tmp/cnchi-alpm.log the sha256 checks suddenly stop (after many successful checks) with a package (this time unzip), but according to the log, the checksum for the unzip package is correct (I checked it manually)!
    For some reason cnchi erroneously thinks the checksum is wrong.

  • I have so far done the install in a VM for XFCE, MATE, GNOME, Openbox and KDE. Currently doing Deepin. XFCE, MATE and GNOME succeeds and I confirm that the intial boot works as expected. Openbox and KDE fails with the same invalid checksum or corrupt package errors.

    And yeah, my hack did nothing else than rank the mirrors with the reflector scripts. So it has to be something related to one or more of the mirrors.

  • i just install openbox without an issue withe the hack from @searedvandal

  • I don’t know if this will help or not, but I just installed Openbox on a SSD using the LIVE iso on a thumb drive and just did a totally normal install and left the Cnchi option for mirrors as was. Installed without a glitch. By the way, the iso was downloaded about a month ago and Cnchi did install an updated Cnchi before starting the install

    If bad mirrors are becoming the suspect, perhaps it should be inquired as to location of users having problems. In my case I am located in Colorado, USA and it worked perfect. I would assume that Cnchi would attempt to use mirrors located as close to the user as possible. Evidently Cnchi chose a good one for me. Maybe others in another areas of the world are coming up with corrupt mirrors?

    Perhaps it could be temporarily programmed into a dev’s Chchi so that anytime it thinks it has found a bad mirror, it would list the mirror’s name into a bad actors file. Maybe it could be determined exactly what percent of mirrors are causing problems, then they could be checked out by someone? Just a suggestion, probably a silly one, but who knows.

  • I’ve done testing all evening with installing each of the desktop environment options available. Testing done in a VirtualBox VM. I did not select any extra packages and I let Cnchi rank the mirrors on every install.

    My findings are:

    Install completed: XFCE, MATE, GNOME, Deepin, Cinnamon and Base.
    Install failed: KDE and Openbox.

    I wasn’t able to get out the logs due to some issue with sending the amount of text to the pastebins. And I kept up a rather high speed getting through all the DE options to see which ones completed and which ones failed. I can go over the two options that failed again tomorrow if needed, and extract the logs another way if they fail again.

    I did two more attempts at Openbox after I was done with the entire list. The first attempt I closed Cnchi and launched the cnchi-dev binary from terminal. This one failed as well. Second attempt I cloned the master branch of the Cnchi github, version 0.16.something.

    Other than the installer looking a lot better, there wasn’t much change. It still failed at the same point. Due to invalid checksum or corrupted package. To me it looked like every time an installation failed, Cnchi has chosen different mirrors to download from, and different packages failed the integrity checks.

    If we assume Cnchi does everything correctly, and this is strictly a mirror issue, is there really that many “bad” mirrors on the mirrorlist? And why is Cnchi choosing them, if they’re “bad”?

    When I say “bad”, I mean the mirrors are either not synced, have a completion_pct below 1.0 or are just slow. Which is, from what I understand, how Cnchi chooses the mirrors?

    If we look at the other way around, if the mirrors are in fact “good”, and it is Cnchi that somehow causes the installs to fail, what could be the possible points of failure? Is it the download of the packages, the implementation of the integrity checks, false positives? I’m assuming that Cnchi just passes the package list to pacman and it’s pacman that does the downloading and integrity checks?

    I have no answers, I just needed to get my thoughts down on paper so I don’t stay up pondering over this all night long. Sorry for the ramblings :-)

    I hope my findings are of some help. My advice to any experiencing issues installing when choosing either KDE or Openbox would be to choose either one of the other desktop environments, or the Base installation. If the install then succeeds, one can install the antergos-kde-meta or antergos-openbox-meta packages via pacman to install the packages Cnchi would have installed if one had chosen it during install.

    If you choose the Base install, you may also have to install the antergos-common-meta. I’m not sure if that gets install when choosing Base installation. As for the user selected packages you may miss if you choose Base install, you can look them up in the packages.xml file on the Cnchi github repo, and install them via pacman manually.

  • @searedvandal said in Antergos installer crashes at the end:

    When I say “bad”, I mean the mirrors are either not synced, have a completion_pct below 1.0 or are just slow. Which is, from what I understand, how Cnchi chooses the mirrors?

    We could think about this… to be honest, cnchi just chooses mirrors based on speed (most of the time will be the nearest mirrors to the user). It does not check if it is updated or not…

    Something like this could be implemented:

  • @karasu

    Yeah, I think it would be beneficial to use some more criteria than just speed when Cnchi chooses mirrors. Maybe one can look at leveraging the reflector script for this purpose as that already gets the information from the mirror status service?

  • @searedvandal
    The reflector-antergos downloads a “reference check file” from each mirror and checks (at least)

    • download speed for ranking
    • possible timeout errors
    • timestamp of the reference file
    • reference file contents

    and if problems are detected, the mirror is marked as ignored (= commented out). The good mirrors are ordered into file antergos-mirrorlist.

  • @manuel

    Yeah, that’s what I used in my workaround I linked in a previous post to get the good antergos mirrors. Very handy little tool that I also used on my main daily Antergos machine :)

  • I’m not sure if this would help, but I did post some findings of my own in another thread, trying to narrow down the issue further, as I have been trying to install KDE Antergos over the past few days without success.

  • Reference to this one for information


    But stay here for discussion ;)

  • May /var/log/pacman.log will give some exact output of checksum errors?

  • Many thanks for bringing attention to this @joekamprad – In the previous thread, you stated that you didn’t see clementine having a dependency on liblastfm-qt5, and it technically doesn’t, but it requires either the -qt4 or -qt5 variant:


    You’ll note that liblastfm is present in that list of dependencies, and per the log I posted in that same previous thread, when installing it manually, pacman asks which variant to install. I believe Cnchi uses the default, which would be liblastfm-qt5, and this fails the signature check, so the entire installation of KDE fails.

    Hoping to have a solution soon, as I am dying to install KDE Antergos on my primary box! Thanks again for helping to get to the bottom of it all.

  • do you guys see that:


    we have a mirror status now !✌

  • @joekamprad This means thats its all OK now?

  • @andreasdimo79 no not all but at least we can see if there are failed antergos mirrors.
    As you can see there are 4 failing mirrors, and cnchi is only ranking them, it do not check the complete health of the mirrors… and same on the used Arch Mirrors https://www.archlinux.org/mirrors/status/#outofsync

    And then we got a problem with Antergos Buildserver at the moment, seems he is on holidays and do not build any packages … what is the problem for the KDE install at the moment… as a dependency needs to be rebuilded to get a correct checksum… (liblastfm-qt5)

installer65 crashes30 Posts 72Views 6002
Log in to reply
Bloom Email Optin Plugin

Looks like your connection to Antergos Community Forum was lost, please wait while we try to reconnect.