Description of problem: Trying to upgrade an Mga7 installation to Mga8. Unfortunately, it died midway through updating the Mga7 to Mga8 (there were about 2000 packages that it said it needed to upgrade, but after about 1000 of them were updated, it quit, on installation problems. www.theory.physics.ubc.ca/mga8-install/index.html is a photo taken of the screen with the dependency error. I could not continue. If I clicked ok, it dumped me back in the "do you have other media" and if I added an ftp source, it would grind on again bringing down the repository synthesis files, and I would try again finally and it might install another 20 packages and then give a similar error message. At 20 a time, it would take me about a full day getting everything updated (except that the number it would do decreased on successive attempts.) Ie, trying to update an Mga7 installation failed miserably. I tried to use the Recovery on the installation usb, and it would claim to be setting up grub to allow me to boot into both an old Mga7 and a new Mga8 grub possibilities, but if on boot I chose the Mga8 possibility it would boot up the old Mga 7 (on partition vnme0n1p1) rather than the nvme0n1p6 partion. (I wanted to try use urpmi --auto-update on that partial Mga8 update, but I could not boot into that. ) I would really love to be able to update an old Mga to a new release, but anytime I have tried, something like the above has happened. Doing a clean install is possible but is a REAL REAL pain as all of the configuration that I spent a year or two getting right on Mga7 has to be redone, wasting days of time. (Yes, I still have the /etc directory on the Mga7, but there are about 500 configuration files in /etc, that have to be redone, and a bunch of them have completely changed (eg postfix) between Mga7 and 8, making me waste time debugging why say postfix has entirely stopped working. Version-Release number of selected component (if applicable): Mga8 installation iso. How reproducible: I tried about 8 times and failed every time. Steps to Reproduce: Try to update an Mga7 to Mga8. Fail.
Apparently you are trying a 64-bit upgrade on a system with 32-bit/i586 devel packages installed. ISTR reading the 32-bit devel packages bork this upgrade path.
CC: (none) => rolfpedersen
This is clearly written in Mageia 8 Release Notes: A 64 bit system must have any 32 bit development libraries uninstalled first. You can identify these by the word "devel" in the name. To know if your system houses such libraries you can use the command: rpm -qa --queryformat "%{NAME}-%{version}-%{RELEASE}-%{ARCH}\n" |grep i586 |grep devel https://wiki.mageia.org/en/Mageia_8_Release_Notes#Upgrading_from_Mageia_7
Thank you both for these helpful comments. That is almost certainly the cause. > trying to update an Mga7 installation failed miserably > updating the Mga7 to Mga8 (there were about 2000 packages I successfully upgraded a system with 3,300 packages, even though it took ages. We understand the importance of being able to do this and avoid the potential pain you describe. So start again after purging the 32-bit -devel packages. But having a 1/2 upgraded system is unhealthy, and if you cannot boot into it to continue the upgrade... I wonder whether using the Classic DVD 'update=upgrade' option might help the situation. This is confusing: > Recovery on the installation usb, and it would claim to be setting up > grub to allow me to boot into both an old Mga7 and a new Mga8 grub > the old Mga 7 (on partition vnme0n1p1) rather than the nvme0n1p6 partion Did you have one or two M7 installations? What happens if you choose the the 'old M7' entry? It is always a good idea to back up the original partition before the upgrade - if you have the system resources (another system to work from, and the disc space somewhere for the backup).
CC: (none) => lewyssmith
I had two M7 distros installed. In fact I copied one into an empty partition, changed the root in /etc/fstab altered the boot/grub2/grub.cfg in that new partition (having discovered by painful attempts that it is that grub.cfg that is read by the boot process, not the one that I run the mcc boot setup in). I carefully followed the instructions in the Release Notes with the Mirror source. That was another disaster. After rerunning the urpmi --auto-update --auto --force 10 times, I was still getting problems. After a long time trying to see how I could fix this, I discovered that there were 256 .mga9 packages installed explaining why the system was complaining that there the new package was depending on things older than the installed. I think that whatever mirror it was I was connnected to still had mga8 being equivalent to cauldron, or something, which totally fucked up the update (sorry about the language but it is hard to come up with a more polite term.) I am now going to start again using the princeton site, and not a mirror. Having users being destroyed by bad mirrors is not a good advertisement! Anyway, I will report again after I have wasted another 4 hours.
OK, this time I deliberately chose the princeton mirror, and the system first installed about 350 packages, and then installed about 3500 packages. At the end rerunning the command, it installed 2 packages. It left a bunch of orphans, which I did not get rid of. It also left about 250 mga7 packages behind. Most are supplanted by mga8 packages I presume (with a different name like flatpack-4.0.1-5.mga7 flatpak-1.10.2-1.mga8 or lib64aom0-1.0.0-0.20180925gitd0076f5.mga7 lib64aom2-2.0.1-3.mga8 and others whose package has dissappeared? cups-common-debuginfo-2.2.13-1.4.mga7 cups-debuginfo-2.2.13-1.4.mga7 cups-debugsource-2.2.13-1.4.mga7 or a bunch of python2 mga7 files I presume it does no harm to leave any of these mga7 files there, except that they take up space. The question is whether things break if I remove them? Anyway, This leaves two things which should be changed. a) There should be an error message during the installation stating that i586 devel packages need to be removed (ie there should be a test in on the installation DVD/usb to test to see if i586 development packages exist) b) The system should not be choosing bad mirrors or should have a menu as on the DVD/usb from which the user can choose a site to populate /etc/urpmi/urpmi.cfg from in the urpmi.addmedia (or at least test to make sure that it is a genuine Mga8 repository).
(In reply to w unruh from comment #5) > OK, this time I deliberately chose the princeton mirror, and the system > first installed about 350 packages, and then installed about 3500 packages. > At the end rerunning the command, it installed 2 packages. It left a bunch > of orphans, which I did not get rid of. It also left about 250 mga7 packages > behind. Most are supplanted by mga8 packages I presume (with a different > name like > flatpack-4.0.1-5.mga7 > flatpak-1.10.2-1.mga8 > or > lib64aom0-1.0.0-0.20180925gitd0076f5.mga7 > lib64aom2-2.0.1-3.mga8 Theses are leaved untouched as they *can* be used by external, out-of-repository softwares. If you have only Mageia's provided RPM, they can be removed. > and others whose package has dissappeared? > cups-common-debuginfo-2.2.13-1.4.mga7 > cups-debuginfo-2.2.13-1.4.mga7 > cups-debugsource-2.2.13-1.4.mga7 Unsure of it. > or a bunch of python2 mga7 files > I presume it does no harm to leave any of these mga7 files there, except > that they take up space. The question is whether things break if I remove > them? Python2 stuff can be safely removed as soon as you don't have external source software that rely on these outaded/obsolete python version. > Anyway, This leaves two things which should be changed. > a) There should be an error message during the installation stating that > i586 devel packages need to be removed (ie there should be a test in on the > installation DVD/usb to test to see if i586 development packages exist) This can be a useful enhancement. mgaapplet should detects i586 devel RPM installed and should display such error message. > b) The system should not be choosing bad mirrors or should have a menu as on > the DVD/usb from which the user can choose a site to populate > /etc/urpmi/urpmi.cfg from in the urpmi.addmedia (or at least test to make > sure that it is a genuine Mga8 repository). We don't have control on registered mirror in our API and $MIRROLIST script *normally* should use the nearest *https* mirror next you. This has been switched on in Mageia 8 development. I still think it is good for security but, several https mirrors are sometimes in bad configuration. I will report this. But, if you have previously chosen a specific mirror, mgaapplet should preserve this setting. In facts, this is already reported here: https://bugs.mageia.org/show_bug.cgi?id=28727 Let's convert this Bug report into an enhancement request about mgaapplet about i586 stuff. There is also this https://bugs.mageia.org/show_bug.cgi?id=6068 request about improving the mgaapplet upgrade dialog. i586 devel stuff information should land there also. Assigning.
Whiteboard: (none) => MGA8TOOVersion: 8 => CauldronSummary: Installtion update quits on dependency hell. => mgaonline should prevent upgrading to newer distribution version when some 32 bits devel RPM are installedSource RPM: Installation DVD/USB => mgaonline-3.31-2.mga9.src.rpmCC: (none) => ouaurelienAssignee: bugsquad => mageiatools
Blocks: (none) => 28736
I agree with Aurélien's comment 6 about checking for dreaded 32-bit -devel pkgs, and making this bug a request for same.
CC: lewyssmith => (none)
The debuginfo packages come from the debug repositories such as http://mirror.math.princeton.edu/pub/mageia/distrib/8/x86_64/media/debug/tainted/updates/ They are only useful when it's necessary to get a back trace with line numbers and source code for those lines in a core dump, for debugging. Ether remove the packages or enable the mga8 debug repos and run "urpmi --auto-update"
CC: (none) => davidwhodgins
I've updated https://wiki.mageia.org/mw-en/index.php?title=How_to_choose_the_right_Mageia_upgrade_method&action=edit§ion=6 to recommend disabling or removing all debug and third party repos prior to removing all of the packages shown by "urpmq --not-available".