Description of problem: Upgrate from Mageia2 to Mageia3 was stoped with lines: "detecting looping forever while trying to resolve dependancies. Aborting... Try again with '-w --debug' options.", after "searching installed packages" process. All updates about Mageia2 is installed before upgrating. The image file of Mageia3: Mageia-3-x86_64-DVD.iso with "Thu Jun 6 15:49:47 CEST 2013" in DATE.txt, md5 - checked. Image file has borned on DVD. Version-Release number of selected component (if applicable): How reproducible: Start upgrate from Mageia2 to Mageia3 using the Mageia3 DVD without connection to the Internet. Steps to Reproduce: 1. Prepare DVD winh Mageia3. On boot choose Install Mageia3. 2. Do not choose any additional media, exept core and nonfree (in the DVD). 3. Reproducible: Steps to Reproduce:
can you make a zip of your folder /root/drakx and attach it here ?
Yes, I'll do that. Just I have to restore the old system, now I'm using Mageia3 from clear installation. It will take for some time.
Created attachment 4194 [details] Here is a necessary directory as requested
Looks like the log is showing the original Mageia 2 install, not the upgrade attempt, so nothing useful there that I can see. To debug this, a formatted usb stick will be needed. Run the upgrade again, till it reaches the point of the error, then switch to a console (alt+f2), and enter "bug /dev/sdb1", and then attach the report.bug.gz from the upgrade attempt, from the usb stick. Replace /dev/sdb1 with the correct device, if the usb stick is assigned to a different device.
CC: (none) => davidwhodgins
Created attachment 4195 [details] This archive contains ddebug.log This archive contains ddebug.log with lines 74476-74477 and text "* error: detecting looping forever while trying to resolve dependancies. Aborting... Try again with '-vv --debug' options at /usr/lib/perl5/vendor_perl/5.16.3/x86_64-linux-thread-multi/URPM/Resolve.pm line 1060." This is the same with a text in bug message. About creating report.bug.gz. Unfortunately, (alt+f2) didn't switched me to the console. Only a message box appears with text like "screenshot with bug will be saved in /root/DrakX-screenshots/...". So, I've decided to turn the computer off, then boot with Live-DVD and copy directories, that may be useful, from a hard disk as is, at the bug occurred.
Created attachment 4196 [details] Screenshot from /root/DrakX-screenshots/
Looks like the trigger is ... * not selecting perl-SVN-1.7.9-1.mga3.x86_64 since the more recent perl-SVN-1.7.10-1.mga2.x86_64 is installed The mga2 package was updated in bug 10479. Now the question is why is the mga2 package being considered newer than the mga3 package. We can't easily change anything on the installer iso images. Is there anything we can do in a Mageia 2 update, to fix this? Adding Oden to the cc list for subversion, and Theirry for urpmi.
CC: (none) => oe, thierry.vignaud
1.7.10-1 is superior than 1.7.9-1 whatever the mga distro :/ added sysadmin if one of them has an ideas
CC: (none) => sysadmin-bugsSeverity: normal => critical
To be able to resolve this you have 2 options: you need online medias active during the upgrade or uninstall perl-SVN before the update (and probably some deps like git-svn) and re-install it after the upgrade
CC: (none) => tmb
This is normal. This always works: urpmi.removemedia -a urpmi.addmedia --distrib ftp://ftp.sunet.se/pub/Linux/distributions/mageia/distrib/3/x86_64/ urpmi --auto-select
Not so simple for mga3. There is also the /usr move to cope with, something a simple --auto-select wont cope with.
Meaning you need to follow the instructions at: https://wiki.mageia.org/en/Mageia_3_Release_Notes#Upgrading_via_the_Internet
As Thomas said, take notes of which packages you have to uninstall. It's not recommended to use for example "rpm -e --nodeps perl-SVN" but in this case you you will do "urpmi perl-SVN" after the install. "--nodeps" could reduce recursive uninstallations of packages that not really have to be uninstalled, without going into that deeper.
Oh, right. mga2 -> mga3 needs special treatment.
well there is no way to close such issue without users manipulations (ie mirrors side maybe) ?
Well, mirrors are OK. matching perl-SVN-1.7.10-1.2.mga3 is in updates tree. so this is an offline upgrade issue, something we cant fix without releasing updated isos.... but then there will be new security updates... and we are back to the same issue ...
This kind of problem is liable to happen after every release. I have certainly seen similar problems before on earlier releases. Perhaps the "recommendation" to enable online repositories during the upgrade should be made more emphatic, by adding a warning that the upgrade may fail if they are not: https://wiki.mageia.org/en/Mageia_3_Release_Notes#Using_the_Mageia_3_DVD_to_Upgrade We could even go further and state explicitly that offline upgrades are not supported. (It is, after all, impossible to "test" for this sort of situation.)
The only true fix for these kind of problems is of course to never bump versions for updates, but that requires *a lot of people* in the sec- and qateam.
ok indeed. (In reply to James Kerr from comment #17) > Perhaps the "recommendation" to enable online repositories during the > upgrade should be made more emphatic, by adding a warning that the upgrade > may fail if they are not: > https://wiki.mageia.org/en/ > Mageia_3_Release_Notes#Using_the_Mageia_3_DVD_to_Upgrade > > We could even go further and state explicitly that offline upgrades are not > supported. (It is, after all, impossible to "test" for this sort of > situation.) Please, feel free to do.
I have added a paragraph to that section of the Release Notes. I hope it is acceptable. I've closed this bug as WONTFIX, although it might be more accurate to say "can't fix" :)
Status: NEW => RESOLVEDResolution: (none) => WONTFIX
Adding Anne to the cc list. I thought urpmi would look at the release tag before looking at the Version tag, in deciding what should be considered "newer". If that's not the case, perhaps we should be creating new iso images, on a regular basis, with the updates included.
CC: (none) => ennael1
Nope, rpm & urpmi always prioritize: 1. epoch 2. version 3. release And this has happend for every release when a package on the iso has been updated on previous release so it'has newer version than on the iso what really gets urpmi into trouble here is the perl-* stuff so it shows up this fast. As we have a new perl and urpmi depends on that it gets on the first packages that need to be installed, and other stuff that depends on the older perl is not possible to keep, but the higher version says it should stay As for recreating new isos regularly, it was suggested for mga2, but dropped since it would pretty much has killed QA...
Thinking about this some more. It could be possible to manipulate the rpm database so that for example "perl-SVN-1.7.10-1.mga2" becomes "perl-SVN-1.7.9-0.1.mga2" for known offending packages by using some type of special update package, writing directly to the rpm database. However this must be bullet proof so that the database isn't corrupted.
Tnis problem blocked made my system unbootable as well. Not allowing off-line release upgrades is not a good solution. It can be advantageous for various reasons to do an upgrade instead of a clean install, and many users won't have online access during upgrade (or even a clean install). (That is my case, no internet at all during install. Although after reboot I *usually* have fairly good internet access, to update then. A good solution would be to automatically downgrade offending packages. This would not produce a system less secure than a clean install. (Except for maybe some rare corner cases.) And the advice to do an update after install would be the same as for any clean install without internet access. BTW, although I usually temporarily uninstall many optional packages for upgrades, to speed up the install, (doing online updates after reboot), this is the first time in many mdk/mdv/mga upgrades that I have been totally blocked by such a problem. So it seems that something must have changed in the install configuration. * Reopening since IMO it is important to fix. * Only the looping problem needs fixing, by downgrading offending packages or other solution. Changing other software won't be necessary, since it won't be long before other updates are issued, thus requiring update during or after install. (Although it might be a good idea to include the latest kernel for mga3, if that has changed.) If it is not fixed, anyone upgrading to Mageia 3 without online being available will be stuck with the same problem. For the next 6 months or more.
Status: RESOLVED => REOPENEDCC: (none) => andre999mgaResolution: WONTFIX => (none)
Summary: Error while upgrating. Line: "detecting looping forever while trying to resolve dependancies". => Error while upgrating. Line: "detecting looping forever while trying to resolve dependancies". (pkg updates in mga2 > iso mga3)
*** Bug 14066 has been marked as a duplicate of this bug. ***
CC: (none) => luiscrespocostas
@all: any good in keeping this BR open? If so, IMO the subject & the assignee need to change.
Keywords: (none) => NEEDINFO
Some thoughts ... Since mga2 is already gone and mga3 soon will be, don't think that there is any point in keeping this bug open. mga2 -> mga3 was more problematic than usual for upgrades. We just need to ensure that future release dvd's have everything to make a bootable system, including downgrading if necessary. With the recommended subsequent update for off-line upgrades, everything should be ok. So I'd suggest closing this bug as "OLD".
Thanks andre999mga@laposte.net. Closing then. Anyone disagreeing can reopen it.
Status: REOPENED => RESOLVEDResolution: (none) => OLD