Description of problem: Downloaded x86_64 (only) cauldron tree from distro.ibiblio.org weeks ago and kept it current until today. Added a symlink from cauldron to "3" and performed additional wget to ensure all was current. Tried to upgrade 64-bit Mageia2; but this failed with errors trying to access 32-bit core. This is my first upgrade which has totally failed in over 15 years. Unchecked 32-bit core; but this didn't help. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. Download x86_64 tree 2. setup boot.iso on usb with unetbootin 3. boot from usb and select upgrade. Argh! Forgot to keep a copy of log... off to try again.... Reproducible: Steps to Reproduce:
Created attachment 4000 [details] media.cfg file during upgrade attempt
Just tried doing a fresh install and it failed the same way: looking for 32-bit core... Surely, we shouldn't need to also download the 32-bit core to do a 64-bit install...?
Summary: x86_64 upgrade fails -- looking for 32-bit core... => x86_64 upgrade fails -- looking for 32-bit core... install also fails looking for 32-bit
as a workaround you can download 700mo of the 32bit repo rsync -avPHS --partial --delete-after --exclude=*.rpm --exclude=SRPMS --exclude=*/media/debug rsync://...
CC: (none) => thierry.vignaud
Downloaded i586 in addition to x86_64 from distro.ibiblio.org/mageia/distrib/3/{i586,x86_64} I now have: $ du -s * 29G i586 39G x86_64 (incl. debug/testing stuff I didn't intend to grab) yet, for the first time since switching to Linux in 1998, can't update (Mageia 2 to 3)... Here's a slideshow of the full sequence I'm seeing... the last 2 photos just show that the process loops to try again. I've tried unchecking all the 32 bit media; but still get the same errors. Is the installer expecting to find 32 bit media in a particular place which differs from the distro directory structure on ftp?
Created attachment 4118 [details] slideshow of failing update
Firefox doesn't appear to display attachment 4118 [details] full size. Download it and use display, gimp or whatever you prefer to see it properly, if needed.
Attachment 4118 is obsolete: 0 => 1
Created attachment 4119 [details] updated with generated montage rather than c&paste
Tried a number of times to update from 2 to 3; but always failed as above. I probably need to open a separate bug; but don't yet have enough specifics, so documenting latest issues here. The other day, checked for updates via mcc, and saw over 900 updates available; so just hit Apply.... big mistake!!! LOTS of things just stopped working correctly... protocol issues, can no longer compile, etc... Reboot failed to shutdown; lots of trash on screen. Had to kill power. On reboot, system came up in multi-user (6 VTYs and ssh available); but KDE won't start (silently). Even python3 won't run: $ python3 Could not find platform independent libraries <prefix> Could not find platform dependent libraries <exec_prefix> Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>] Fatal Python error: Py_Initialize: Unable to get the locale encoding LookupError: no codec search functions registered: can't find encoding Aborted I have 76GB of i586 and x86_64 repositories and still get the above reported upgrade problem. At them moment, I am working on getting ready to install mga4beta because 2-to-3 won't work, and now mga3 updates got applied to an mga2 system, destroying it... :(
First, when you have such an issue, you should attach your /root/Drakx/report.bug.xz (or if the error happens before partitionning, plug a USB key and run the "bug" command on tty2 then attach the report.bug.xz file found on the USB key). Secondly, the errors you saw are likely due b/c you performed an incomplete upgrade. Adding the whole online mirrors and performing urpmi --auto-select should fix them As for the mga2 -> mga3 upgrade, it has been performed successfully by quite a number of people. Here the thing that is different is that you used your own local mirror and you likely had 32bit packages installed, which could not be upgraded and broke the upgrade. Note that if you use a partial local mirror, you could have trimmed the 32 bit media from x86_64/media/media_info/media.cfg, this would have prevented the "cannot parse *32bit* synthesis" error messages. So please attach your /root/Drakx/report.bug.xz As for "incl. debug/testing stuff I didn't intend to grab", just look at the documentation of the tool you're using to mirror about excluding the directories you didn't want
Keywords: (none) => NEEDINFO
Also, next time, please use <F2> instead of taking photos (screenshots would be more readable)
Summary: x86_64 upgrade fails -- looking for 32-bit core... install also fails looking for 32-bit => x86_64 install | upgrade fails -- looking for 32-bit core...
Trying to install mga4 on a new machine fails looking for "Core 32bit Release". Unchecked all 32bit items (updates need to be unchecked first), and install proceeds; but complains of missing Tainted which is no checked; then continues... :?
Installed mga4(64) on two machines and 32-bit sources are still checked on 64-bit-only trees: ftp://.../mageia/distrib/4/x86_64/*
Not sure if this is the same thing, but a fresh MGA4 install today from an up-to-date local mirror (x86_64 and i586) of distrib-coffee gets: problem reading synthesis file of medium "Core 32bit Updates" tty3 shows this message right after the line: examining syntesis file [/mnt/var/lib/urpmi/synthesis.hdlist.Core 32bit Updates.cz] This is a copy taken from the mirror and written to the / partition, and "cat" from tty2 can access it just fine. I can't get "bug" output because although the MGA4 install kernel recognizes the connection of both a USB Flash Drive and a USB Floppy drive, no devices are created for them. If you click OK to the above message, the install tries to proceed, but fails after you choose "Custom" desktop with an error abuot "available_flag". Clicking OK to the dumps you back to Custom Disk selection. If I then uncheck Core 32bit Updates in the repository list, the install proceeds with no errors.
CC: (none) => ftg
Mageia 3 changed to end-of-life (EOL) status 4 months ago. http://blog.mageia.org/en/2014/11/26/lets-say-goodbye-to-mageia-3/ Mageia 3 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad
Status: NEW => RESOLVEDResolution: (none) => OLD
this bug is still present in mga5. In fact, the end result now causes mga5 to fail to upgrade/install wireless. mga3 and mga4 at least gave me a working system; mga5 does not. See bug 16209
Status: RESOLVED => REOPENEDVersion: 3 => 5Resolution: OLD => (none)
Installed mga5 on a friends laptop a few days ago and still had to uncheck the 32-bit sources.
Closing this report as INVALID, since no report.bug.xz has been attached, even if that was requested very long ago. For more information about how to get the requested information for non-Live installer, see: https://wiki.mageia.org/en/Triage_guide#Traditional_installer Feel free to reopen and supply the requested information.
Status: REOPENED => RESOLVEDCC: (none) => marja11Resolution: (none) => INVALID
Created attachment 7919 [details] log up to failure wanting 32bit on 64bit install in virgin VBox VM Does no-one even bother to try this? I have another brand new laptop on its way; delivery scheduled for Tuesday. So I will check again on a real machine at that time. In the meanwhile, installing into a VirtualBox VM... this ddebug.log was extracted from the .vdi. The install got to point of complaining about 32-bit core. Clicked Next and these 32-bit media are also selected: - Core 32bit Release - Core 32bit Updates - Nonfree 32bit Release - Nonfree 32bit Updates The following is everything on that fresh virtual disk (un to this point in the intall) in case there's something else you want... # ll -R * dev: total 0 etc: total 16 drwxr-xr-x 2 root root 4096 Jun 5 12:21 profile.d/ drwxr-xr-x 2 root root 4096 Jun 5 12:21 rpm/ drwxr-xr-x 4 root root 4096 Jun 5 12:21 sysconfig/ drwxr-xr-x 3 root root 4096 Jun 5 12:21 urpmi/ etc/profile.d: total 0 etc/rpm: total 4 -rw-r--r-- 1 root root 25 Jun 5 12:21 macros etc/sysconfig: total 8 drwxr-xr-x 4 root root 4096 Jun 5 12:21 console/ drwxr-xr-x 2 root root 4096 Jun 5 12:21 network-scripts/ etc/sysconfig/console: total 8 drwxr-xr-x 2 root root 4096 Jun 5 12:21 consolefonts/ drwxr-xr-x 2 root root 4096 Jun 5 12:21 consoletrans/ etc/sysconfig/console/consolefonts: total 0 etc/sysconfig/console/consoletrans: total 0 etc/sysconfig/network-scripts: total 0 etc/urpmi: total 4 drwxr-xr-x 3 root root 4096 Jun 5 12:21 mediacfg.d/ etc/urpmi/mediacfg.d: total 4 drwxr-xr-x 2 root root 4096 Jun 5 12:21 Official-5-x86_64/ etc/urpmi/mediacfg.d/Official-5-x86_64: total 16 -rw-r--r-- 1 root root 10252 May 31 2015 media.cfg -rw-r--r-- 1 root root 11 Jun 5 12:21 url home: total 0 lost+found: total 0 mnt: total 0 proc: total 0 root: total 8 drwx------ 2 root root 4096 Jun 5 12:21 drakx/ drwx------ 2 root root 4096 Jun 5 12:21 tmp/ root/drakx: total 20 -rw-r--r-- 1 root root 2626 Jun 5 12:21 auto_inst.cfg.pl -rw-r--r-- 1 root root 13827 Jun 5 12:21 ddebug.log root/tmp: total 0 run: total 0 sys: total 0 tmp: total 0 var: total 12 drwxr-xr-x 3 root root 4096 Jun 5 12:21 cache/ drwxr-xr-x 4 root root 4096 Jun 5 12:21 lib/ drwxr-xr-x 2 root root 4096 Jun 5 12:21 tmp/ var/cache: total 4 drwxr-xr-x 4 root root 4096 Jun 5 12:21 urpmi/ var/cache/urpmi: total 8 drwxr-xr-x 2 root root 4096 Jun 5 12:21 partial/ drwxr-xr-x 2 root root 4096 Jun 5 12:21 rpms/ var/cache/urpmi/partial: total 0 var/cache/urpmi/rpms: total 0 var/lib: total 8 drwxr-xr-x 2 root root 4096 Jun 5 12:21 rpm/ drwxr-xr-x 2 root root 4096 Jun 5 12:21 urpmi/ var/lib/rpm: total 112 -rw-r--r-- 1 root root 8192 Jun 5 12:21 Basenames -rw-r--r-- 1 root root 8192 Jun 5 12:21 Conflictname -rw-r--r-- 1 root root 8192 Jun 5 12:21 Dirnames -rw-r--r-- 1 root root 8192 Jun 5 12:21 Group -rw-r--r-- 1 root root 8192 Jun 5 12:21 Installtid -rw-r--r-- 1 root root 8192 Jun 5 12:21 Name -rw-r--r-- 1 root root 8192 Jun 5 12:21 Obsoletename -rw-r--r-- 1 root root 16384 Jun 5 12:21 Packages -rw-r--r-- 1 root root 8192 Jun 5 12:21 Providename -rw-r--r-- 1 root root 8192 Jun 5 12:21 Requirename -rw-r--r-- 1 root root 8192 Jun 5 12:21 Sha1header -rw-r--r-- 1 root root 8192 Jun 5 12:21 Sigmd5 -rw-r--r-- 1 root root 8192 Jun 5 12:21 Triggername var/lib/urpmi: total 2160 -rw-r--r-- 1 root root 1 May 13 11:17 descriptions.Core Updates -rw-r--r-- 1 root root 576 Jun 15 2015 MD5SUM.Core Release -rw-r--r-- 1 root root 576 Jun 2 21:39 MD5SUM.Core Updates -rw-r--r-- 1 root root 1881908 Jun 15 2015 synthesis.hdlist.Core Release.cz -rw-r--r-- 1 root root 311504 Jun 2 21:39 synthesis.hdlist.Core Updates.cz var/tmp: total 0
Attachment 4000 is obsolete: 0 => 1
Attachment 4119 is obsolete: 0 => 1
(In reply to Pierre Fortin from comment #18) > Created attachment 7919 [details] > log up to failure wanting 32bit on 64bit install in virgin VBox VM > > Does no-one even bother to try this? That sounds as if we have plenty of time. We're just volunteers, who don't find time to care about the garden and about many other things, because most of our free time goes to Mageia. Anyway, thx for replying and for attaching the ddebug.log :-)
Keywords: NEEDINFO => (none)Status: RESOLVED => REOPENEDResolution: INVALID => (none)Assignee: bugsquad => thierry.vignaud
This bug has been open for just over 3 years now, spanning mga3 to mga5, and it all boils down the question in Comment 2: >Surely, we shouldn't need to also download the 32-bit core to do a 64-bit install...? Users don't all have [time] to report everything we find either; but I for one, do my best... In the few hours since this report was closed: - installed VirtualBox, configured it, resolved USB & mouse issues - started mga5 install in VBpx - figured out how to get files out of .vdi disk images - ... If the devs don't have time to turn off the 32bit stuff, maybe they have time to point me to the source and I'll do my best to provide a fix...
Adding 32bit core to 64it installs is not a bug, it's a design choice. There is still packages/apps that needs 32bit libs in order to work on 64 bit installs, and we decided to add them to make it easier for endusers to get them Anyway, we should probably add support for media management to simply ignore missing 32bit media on 64bit installs...
CC: (none) => tmb
That would help. Went ahead with VBox install after unchecking 32bit media, and other than the usual Flash failure, installed/works just fine.
FYI: Running mag5 on VirtualBox 5.0.20 causes udisksd problems whereby mounts silently fail and not all mountable drives are visible. See https://www.virtualbox.org/ticket/15487 Installing mga5 on new Dell Inspiron 3000 fails because Core32 is enabled.
Created attachment 8658 [details] mga6-rc fresh install still wants 32-bit Testing on VirtualBox: 1. mirror mga6 64-bit repo only 2. try fresh install of 64-bit only 3. fails wanting 32-bit....
Opening new, more concise report. *** This bug has been marked as a duplicate of bug 19913 ***
Status: REOPENED => RESOLVEDResolution: (none) => DUPLICATE