0

I'm trying to update from 1.9.2.1 to 1.9.3.3 using Connect Manager. First attempt I checked for and selected to update all core packages to 1.9.3.3. This resulted in a heap of "conflict" errors, some packages updated and the site dead.

The dead site was because it modified permissions on several key files and folders from 644 to 666, resulting in Apache refusing to load. I fixed this by reverting permissions back as they should be. Connect Manager also dead for the same reason so fixed permissions there too.

Now I'm stuck. About half the core packages have updated to 1.9.3.3 and the other half not and won't. I get multiple errors like the following:

    Checking dependencies of packages
Already installed: community/Lib_Unserialize 1.9.3.3, skipping

CONNECT ERROR: Package community/Mage_Core_Modules 1.9.3.3 conflicts with: community/Magento_Mobile 1.9.2.1
Package community/Lib_Varien 1.9.3.3 conflicts with: community/Mage_Core_Modules 1.9.2.1
Package community/Lib_Google_Checkout 1.9.3.3 conflicts with: community/Mage_Core_Modules 1.9.2.1
Package community/Lib_Js_Calendar 1.51.1.9 conflicts with: community/Mage_Core_Modules 1.9.2.1
Package community/Lib_Js_Mage 1.9.3.3 conflicts with: community/Mage_Core_Modules 1.9.2.1
Package community/Lib_Phpseclib 1.9.3.3 conflicts with: community/Mage_Core_Modules 1.9.2.1
Package community/Mage_Locale_en_US 1.9.3.3 conflicts with: community/Mage_Core_Modules 1.9.2.1
Package community/Lib_Mage 1.9.3.3 conflicts with: community/Mage_Core_Modules 1.9.2.1
Package community/Lib_Magento 1.9.3.3 conflicts with: community/Mage_Core_Modules 1.9.2.1
Package community/Lib_Credis 1.9.3.3 conflicts with: community/Mage_Core_Modules 1.9.2.1
Package community/Lib_Pelago 1.9.3.3 conflicts with: community/Mage_Core_Modules 1.9.2.1
Package community/Lib_IDNA2 1.9.3.3 conflicts with: community/Mage_Core_Modules 1.9.2.1
Package community/Lib_ZF 1.12.10.8 conflicts with: community/Lib_Varien 1.9.2.1
Package community/Lib_Js_Prototype 1.9.3.3 conflicts with: community/Mage_Core_Modules 1.9.2.1, community/Lib_Js_Mage 1.9.2.1
Package community/Lib_ZF_Locale 1.12.10.8 conflicts with: community/Lib_ZF 1.12.10.1

If I try to update individually, it say it conflicts with others that are at 1.9.2.1. Yet if I try to update all, each packages says it conflicts with the version of others currently installed.

As I cannot believe Connect Manager would have been written to behave like this, anyone have any clue how to fix it so it's checking against the packages requested to be installed and not against packages already installed, which will obviously conflict with the each package being updated.

I tried clearing both normal and downloader caches. Makes no difference.

There are other questions like this but with no reasonable answer other than update Magento manually via FTP/SSH. Surely there must be an answer to get updates working correctly through Connect Mananger? Otherwise what's the point of having it!?

UPDATE: Tried using ./mage upgrade-all - same conflict errors

So tried ./mage upgrade-all --force - wow! Completely messed up the site - phew, it's the test copy! Critical files were deleted and the site was dead well beyond a permission issue. Had to restore from backup.

Tried again following other advice, this time just selecting to upgrade the Mage_All_Latest package. Same again, half of the core packages updated, half not and site dead because permissions are wrong. And I'm left with the same conflicts as above. Fixed permissions and tried updating just Mage_Core_Modules - same. Tried just Magento_Mobile - same.

One thing I have noticed is that upgrading creates a directory in pkginfo called Mage_All_Latest.txt - not a file, a directory. Anyhow, tried deleting that and made no difference.

1 Answer 1

1

It turns out the issue is down to a previous problem during Magento updates and a flaky Connect Manager. What's happening is that Connect Manager is bugging out at the first unexpected issue, leaving the site in such an inconsistent state it doesn't know what to do next.

The root cause appears to be a bug to do with long file names in the archive processing introduced in 1.7.x and still there. A bit ironic that Magento has a bug dealing with long names given it's impressive folder depths! See this for details and fix: Long file names and Magento Connect extension packager

This has resulted in many instances of Magento saving what should be a file as a folder. To track these down I ran:

find . -type d -name "*.*" -print

Review this results to see where a previous upgrade has gone wrong. To fix I downloaded a fresh copy of the Magento release we are on (1.9.2.1), deleted the problem files and replaced with fresh copies. For example, there were problems in app/code/core/Mage/ConfigurableSwatches so I deleted and replaced the entire ConfigurableSwatches folder. We had problems in 4 locations.

Then tried a small upgrade from 1.9.2.1 to 1.9.2.2 by upgrading just Mage_All_Latest. Before doing this, I cleared pkginfo/Mage_All_Latest.txt (could be a file or folder). That worked, mostly! For some reason it still bugs out clearing the cache/sessions and still leaves certain file permissions at 666 preventing the site from loading. That can be fixed with:

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
chmod 550 mage

It also still resulted in a pkginfo/Mage_All_Latest.txt folder. No idea why but deleting it fixes. Next tried going to 1.9.3.0 and that worked, aside from permissions. Then to 1.9.3.3, again ok'ish. Before each upgrade, I removed the faulty Mage_All_Latest.txt folder.

So if you're encountering this, fix the Archive/tar.php file, find/replace any corrupted "files became folders" and remove pkginfo/Mage_All_Latest.txt before each upgrade. Then upgrade the Mage_All_Latest package and fix the file permissions.

Worked for us!

1
  • 1
    Final thoughts: come on Magento. We all know how important it is to apply updates. The process of updating the core should be bullet-proof. Commented Jun 21, 2017 at 8:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.