| Summary: | x86_64 install | upgrade fails -- looking for 32-bit core | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Pierre Fortin <pf> |
| Component: | RPM Packages | Assignee: | Mageia tools maintainers <mageiatools> |
| Status: | RESOLVED OLD | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | davidwhodgins, marja11 |
| Version: | Cauldron | Keywords: | FOR_ERRATA6 |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Attachments: | stacked screen shots | ||
|
Description
Pierre Fortin
2016-12-08 15:48:10 CET
Created attachment 8741 [details]
stacked screen shots
*** Bug 10162 has been marked as a duplicate of this bug. ***
Marja Van Waes
2016-12-09 00:03:17 CET
CC:
(none) =>
marja11 @ Pierre Would you manage to write an errata entry about this issue, with a link in it to this bug report? https://wiki.mageia.org/en/Mageia_5_Errata#Classic_Installer_DVDs Please say _no_ if you don't have time to figure out how to do that. Keywords:
(none) =>
FOR_ERRATA6 @ Marja 1. I *never* install/update via CD/DVD/ISO. I always use a local repo; so I can't confirm this issue exists in those installs; though it makes sense it would. 2. this problem exists in 5.1 and 6sta2. 3. I haven't had a chance to report release-blocker issues when installing on a new SSD: 5.1 suffers a kdmgreet crash loop which prevents any attempt to login; even via a vty. 6sta2 suffers a different crash loop, also denying logins. I haven't had time to debug these to determine if they occur only on an SSD... Any objection if I open placeholder issues? Lastly, WHY are the 32-bit sources even enabled on a 64-bit install? Since the workaround is to simply uncheck these sources, it would seem that disabling them should be extremely simple... or is there a technical/political reason for not doing so? There are several packages (skype is the only one that I can think of without checking, but there are others) that only have 32 bit versions available. Because of this, the installer expects (insists?) the mirror to have all of the repos available, including the 32 bit ones. If the local mirror doesn't have the 32 bit repos, that is likely the cause of the problems. If the problems can be recreated using a mirror with all of the repos available, then it's worth reporting as a severe errors. If it only happens when the 32 bit repos are not available, then the bugs should be set as enhancement requests, to try and get things working without the 32 bit repos. It may also be a problem of when the local mirror was last synced, as well as when the mirror, that's synced from, was last synced. With cauldron especially, checking https://pkgsubmit.mageia.org/ before syncing is a good idea. If anything large like the kernels have been updated, local syncing should hold up until those updates have been synced to the mirror being synced from. See http://mirrors.mageia.org/status too. Most mirrors will sync a large update like the kernels within a couple of hours. Some mirrors can take a day or more. We don't have any control on when or how often the mirrors choose to sync. CC:
(none) =>
davidwhodgins On a Mageia 5 x86_64 virtualbox install I have (without skype), the following
32 bit packages are installed ...
# rpm -qa --qf %{NAME}.%{ARCH}\\n|grep 586|sort
libalsa2.i586
libalsa-plugins-pulseaudio.i586
libasyncns0.i586
libdbus1_3.i586
libflac8.i586
libgcrypt11.i586
libgpg-error0.i586
libjson2.i586
liblzma5.i586
libogg0.i586
libpth20.i586
libpulseaudio0.i586
libpulsecommon5.0.i586
libpython2.7.i586
libsndfile1.i586
libsystemd0.i586
libvorbis0.i586
libvorbisenc2.i586
libwrap0.i586
libxau6.i586
libxcb1.i586
libxdmcp6.i586
Each of the packages that require those libs would need to be modified to use only 64 bit versions, it that's possible. There may be reasons the 32 bit versions must be used.
I get that 32-bit apps can be installed on a 64-bit system; BUT... that is done AFTER an *install*. The install process does not install any 32-bit apps. I'll concede that 32-bit apps may be part of an *update*; but why involve 32-bit sources on a basic install? Answering myself: To allow a user to manually select what to install... <sigh> How about checking for the availability of 32-bit sources *before* preselecting them only to then complain they don't exist..? Closing as OLD Resolution:
(none) =>
OLD |