• Failed to install 17.10 due to pm_errno 49 (conflicting files)


    This is whats really fraustrating with Antergos!!! All that time and bandwidth, to wait for the installer to finish and when its already past 2 hours and its suppose to be finished, it just CRAPS out without any way of re-starting from where you left off. this might not be an issue with those that have “free” internet but for those affected by capping its not a fun way.

    At least a method to recheck the cached/downloaded files for any corruption, and redownload whats necessary and continue from where you stopped would be a good option, heck even arch-anywhere is able to continue where it left off…

    log just gives me nothing to help…

    https://hastebin.com/mufehiyowi.sql

    UPDATE:
    Please disregard the log as this clearly is something to do with mirror issues although not sure why thats the case since mirrors are created using pacman-mirrorlists, but thats a different issue since installation should not continue if there are issues at the early part during install already.

    [ERROR] pac.py(161) finalize_transaction(): Can't finalize alpm transaction: transaction failed, pm_errno 49 (conflicting files), [('intel-ucode', '/install/boot/intel-ucode.img', None)]
    

    This is the more important issue.

  • @retrowertz
    The log file reveals pacman had difficulty downloading several packages during the installation process. When pacman then proceeded to check the integrity of the downloaded files, it issued the errors and refused to continue, resulting in the aborted installation.

    This is expected behavior, not an error. What you experienced was not the Antergos installer failing on you. Instead it was a natural error coming from how pacman operates. Cnchi simply caught pacman error and raised its own exception, terminating the installation, since it can’t handle missing or corrupt files (nor should it).

    I however completely understand your frustration. It’s been mine for a long time too. Net installers, like Arch’s and Antergos’ have been a bane on my Linux experience and have caused me quite a few financial burdens in the past. I hate them and sincerely miss the days when Arch had an offline installer.

    However, if your internet connection is stable (is it?) your problems happened because of bad mirrors, instead of bad internet. What I suggest you do is this:

    1. Start the live CD and exit the installer once it fires up.
    2. Open the browser in the Live CD and navigate to:
      Arch mirror list generator
    3. On that page make sure you enable http, https, ipv4 and use mirror status.
      Use mirror status is very important and is the reason you are doing this, so don’t skip it.
    4. From the country list CTRL + Left Click those countries you wish. Include countries near you, but also “reliable” internet countries like UK, US or France.
    5. Open a terminal issue:
      $ sudo nano /etc/pacman.d/antergos-mirrorlist.
      Delete everything in this file and copy/paste from the generated list on your browser.
    6. Remove the comment symbol # from the first 5 or so mirrors.
      If you wish you can also change the order of these first 5 mirrors, placing on top those near you. But only change the top 5!
    7. Save and exit.
    8. Still on the terminal now issue:
      $ sudo pacman -Syy.
    9. When it is over launch Cnchi again with the following command:
      $ sudo -E cnchi -dv --disable-rank-mirrors.
      This makes sure it doesn’t try to rank your mirrors again.
    10. Install.

    This is all to ensure that you start an Antergos installation with the most reliable mirrors possible and minimize the chance of download errors.

  • Im not new to antergos, and I have already done what you said because in the past this was the same issue (17.2), also followed this guide https://forum.antergos.com/topic/3267/how-to-choose-your-mirrors-before-installing-antergos and nothing completed installing and all are failing right after the installer has finished downloading stuff and started installing packages, which from my past experience, with the time that has already past since the start of installation, its suppose to be only a few minutes and it should have been already done.

  • On that case, clearly you have some sort of internet connection problem. You must understand that what you are experiencing is by far not what a normal Antergos user does. And your logs do reveal issues downloading certain packages.

    The failed packages are returning a 403 error, which usually indicates a proxy issue. What confuses me is that not all packages do. Just some. But in any case are you under any proxy?

  • yeah, theres something wrong with my internet, wherein arch installed fine after this. i have more failed installations with antergos that any other distro(arch based or not) that fetches directly from server during installs.

    thanks anyways for the great help!

  • I’ll repeat: You must understand that what you are experiencing is by far not what a normal Antergos user does.

    thanks anyways for the great help!

    I’m trying to. Does that bother you so much? Perhaps you’d prefer I just shutup and leave you to your problem? I can do that. It is not that you are giving me anything in return, other than barking.

    Anyways, if Arch has installed fine on your machine that still means you have an internet problem. Like I said your experience is rare among Antergos users.

    However that piece of knowledge gave me an hint: Edit your pacman.conf file and make sure you replace curl in the XferCommand option with wget. The option should read:

    XferCommand=/usr/bin/wget --passive-ftp -c -O %o %u
    
  • thanks. maybe next time. internet is capped for the day and weekend is approaching…

    thanks.

  • @Krugar said in Failed( again! ) to install Antergos..........!!!!:

    However that piece of knowledge gave me an hint: Edit your pacman.conf file and make sure you replace curl in the XferCommand option with wget.

    @Krugar could this make a difference? We could set this as default…

  • wget : Its ability to recover from a prematurely broken transfer and continue downloading

    is the only thing comes to my mind in curl vs. wget

    But i see this “hack” often for problems with internet connection and also for problems with banning in thouse countries… and powerpill comes to my mind also :)

    [updates once a week] = [90% less problems]
    http://gofccyourself.com
    my-blog#k
    how to add system logs
    i3 GNOME

  • @karasu said in Failed( again! ) to install Antergos..........!!!!:

    @Krugar could this make a difference? We could set this as default…

    I am not entirely sure. Probably not. I’d need @retrowertz report after he tried, or go through the same problem myself. But that would be one of the first things I’d try since curl is known to choke with some proxies (local or further away down the pipe), while wget will carry on unconcerned. That was at least my rationale in order to start diagnosing his problem.

    However a proxy can reject connections on so many basis, it is hard to say. Often the solution isn’t replacing the default downloader, but instead changing its options. For instance, See here for a rare situation in which a proxy was rejecting connections because of pacman’s user-agent string. That is one case where changing pacman to use wget wouldn’t help any.

  • In pacman.conf the options (namely -f) given to curl indicate that curl doesn’t show output on server errors and some other scripts should handle server error conditions. Could the problem actually be with those “other” scripts, maybe they don’t handle server errors properly in all cases?
    I am really just guessing here, but there must have been reasons to use the -f option with curl.
    EDIT: in pacman.conf, wget was not given any such options.

  • from: pacman.conf.5.en
    XferCommand = /path/to/command %u

    If set, an external program will be used to download all remote files. All instances of %u will be replaced with the download URL. If present, instances of %o will be replaced with the local filename, plus a “.part” extension, which allows programs like wget to do file resumes properly.

    This option is useful for users who experience problems with built-in HTTP/FTP support, or need the more advanced proxy support that comes with utilities like wget.

    [updates once a week] = [90% less problems]
    http://gofccyourself.com
    my-blog#k
    how to add system logs
    i3 GNOME

  • @manuel said in Failed( again! ) to install Antergos..........!!!!:

    I am really just guessing here, but there must have been reasons to use the -f option with curl.
    EDIT: in pacman.conf, wget was not given any such options.

    It’s based on how pacman works. It expects curl to return >0 when failing a download, so that it can then process the error itself.

    One of the side-effects of not having -f is that curl returns 0 on failed attempts and the caller needs to then parse the output file to investigate if there was any error. With f curl returns >0 (usually 22) when failing.

    Try this:

    $ curl -f http://www.google.com/test.txt > foo
    $ echo $?
    $ ls -l foo
    

    You’ll notice that curl printed the HTTP 404 error to the screen and that also returned in error (22), facilitating the error catching by the caller (on this case pacman, but could be a bash script, for instance). In addition the output file is a 0-byte file.

    Now, do the same commands, but without -f and you will notice that all that information is lost. No error is printed to the screen, curl returns without error and the output file is not 0-byte. The only way pacman would have to know if there was an error was to open and parse the downloaded file, which contains the HTTP error.

  • @Krugar
    Thanks for the explanation. I tried it and it behaves just as you described. Funny, because from the curl manual page I thought that the -f option would cause just the opposite behaviour …

  • im reluctant to proceed, as each server does not have “.sig” files.

    https://hastebin.com/ifomobivij.rb

    UPDATE: suicide installation using wget failed… looks to me like its the same error…

    0_1507253849642_Screenshot from 2017-10-06 01-34-27.png

    https://hastebin.com/cujuzinilu.sql

    I am seeing this, looks like the 1st sign of a major error:

    [ERROR] pac.py(161) finalize_transaction(): Can't finalize alpm transaction: transaction failed, pm_errno 49 (conflicting files), [('intel-ucode', '/install/boot/intel-ucode.img', None)]
    

    does this thing!!! failed just because this does not want to share an EFI partition with other distro?

  • Looks the same as https://forum.antergos.com/topic/8018/can-t-install-antergos-cinnamon-error-while-checking-integrity where Cinnamon, Gnome and Mate DE installations have been failing.

    I typically have rock solid internet and when there are problems it’s usually serious.

  • The latest 17.10 install media just worked on a virtualbox with Gnome DE (no messing with mirrorlist and all additional software options disabled).
    Going to try a Cinnamon shortly.

  • thanks for the info. cinnamon atm has known install issue though, better wait till confirm fixes are in place.

  • Cinnamon install (with all additional software options ticked) completed successful in Vbox too.

    Theme error on first boot however (which I also had with the Gnome install). Resolved by selecting default theme.

    Thanks devs :)

  • The joys of a theme that’s hardcoded in the toolkit.
    J.

Posts 33Views 1666
Log in to reply