Bug 19913 - x86_64 install | upgrade fails -- looking for 32-bit core
Summary: x86_64 install | upgrade fails -- looking for 32-bit core
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia tools maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
: 10162 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-12-08 15:48 CET by Pierre Fortin
Modified: 2021-07-08 20:20 CEST (History)
2 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments
stacked screen shots (113.79 KB, image/jpeg)
2016-12-08 15:49 CET, Pierre Fortin
Details

Description Pierre Fortin 2016-12-08 15:48:10 CET
Description of problem:  Using ***FULL*** 64-bit (x86_64) sources ONLY from repos (not DVD/ISO); installation fails wanting 32-bit sources.


Version-Release number of selected component (if applicable): MGA3 through Cauldron(6)


How reproducible:  always. I first reported this against MGA3 May 20, 2013 (bug 10612)


Steps to Reproduce:
1. Using FULL 64-bit repo ONLY
2. Boot with its boot.iso 
3. Select Install or Upgrade
4. Proceed with install using defaults
5. Install fails wanting 32-bit sources  <===
6. Uncheck 32-bit sources
7. Install proceeds as expected.
Comment 1 Pierre Fortin 2016-12-08 15:49:00 CET
Created attachment 8741 [details]
stacked screen shots
Comment 2 Pierre Fortin 2016-12-08 15:50:20 CET
*** Bug 10162 has been marked as a duplicate of this bug. ***
Marja Van Waes 2016-12-09 00:03:17 CET

CC: (none) => marja11
Assignee: bugsquad => mageiatools

Comment 3 Marja Van Waes 2017-03-29 07:49:31 CEST
@ 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

Comment 4 Pierre Fortin 2017-03-29 18:19:03 CEST
@ 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?
Comment 5 Dave Hodgins 2017-03-30 22:33:50 CEST
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

Comment 6 Dave Hodgins 2017-03-30 22:39:58 CEST
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.
Comment 7 Pierre Fortin 2017-03-31 17:36:52 CEST
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..?
Comment 8 Pierre Fortin 2021-07-08 20:20:31 CEST
Closing as OLD

Resolution: (none) => OLD
Status: NEW => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.