Bug 16209 - mga5 update/install fail + no wireless
Summary: mga5 update/install fail + no wireless
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: Release (media or process) (show other bugs)
Version: 5
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords: NEEDINFO
Depends on:
Blocks:
 
Reported: 2015-06-25 15:45 CEST by Pierre Fortin
Modified: 2015-07-04 18:32 CEST (History)
2 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments
currently installed i586 packages (4.13 KB, text/plain)
2015-06-25 19:18 CEST, Pierre Fortin
Details

Description Pierre Fortin 2015-06-25 15:45:09 CEST
Description of problem: currently running mga4 up-to-date on Dell M6800 i7 (8-thread) 32GB memory, 750GB with Intel 7260 wireless.

Backed up / and began update from local x86_64 repo; unchecked 32-bit stuff and started update which did over 3200 packages. It then failed and I had no network.  Was able to uncheck 32-bit and get a few more packages updated; but this got to a point where no more updates could be applied; only failures.

Next, tried a full install which again had 32-bit checked - unchecked these. It proceeded up to about where networking would be installed.  Again, no networking, so I didn't bother with "bug" or "F2"... 

Why are 32-bit packages enabled for 64-bit machines? What 32-bit packages are needed?  See bug 10162

Version-Release number of selected component (if applicable):


How reproducible: Looks like I have to get the i586 repo to find out... :P restored mga4 partition and will try again and update this issue when I get the 32-bit stuff...


Steps to Reproduce:
1.
2.
3.


Reproducible: 

Steps to Reproduce:
Comment 1 Pierre Fortin 2015-06-25 15:52:40 CEST
My mirroring script avoids lots of packages (other languages mainly); but I'll probably have to download many GB to retest...  :P

A list of needed 32-bit packages would be appreciated.  Better, why aren't needed 32-bit packages, if any, part of the 64-bit distro??
Comment 2 Sander Lepik 2015-06-25 17:49:26 CEST
There are applications that are 32-bit only. Skype, Steam and probably some more. Core 32 Release/Updates can be enabled. Also, if you use broken mirror (read: half synced) then don't expect it to work. Try with enabled repos and with those that have all provided files. If it still fails, then reopen.

Status: NEW => RESOLVED
CC: (none) => mageia
Resolution: (none) => INVALID

Comment 3 Pierre Fortin 2015-06-25 19:18:46 CEST
Created attachment 6778 [details]
currently installed i586 packages

Your reason for closing this report is based on 32-bit applications v. my desire to update/install ONLY 64-bit packages.  Re-opening for the following reasons:

0. this has been a problem since at least mga3

1. My point is that if I DISABLE all 32 bit stuff before updating; the update should handle only my 64 bit packages and not fail at a point where it wants 32-bit stuff and networking is not updated, thereby making the system USELESS...

I can deal with 32 bit applications LATER.  

I've attached my list of installed 32-bit packages -- note that they are mainly lib* except for:
  lsb-core-lib-4.1-16.mga4.i586
  lsb-lib-4.1-16.mga4.i586
  wine-gecko-2.21-3.mga4.i586
  wine32-1.6.1-2.mga4.i586
NONE of which are required for a running system.


2. Then, there's the issue of the *fresh* install...  WHY should there be any 32-bit packages required in this case?  I have a 64-bit machine, disabled the 32-bit stuff and expected a 64-bit ONLY install WITHOUT 32-bit stuff (unless I later choose to install some)...
This INSTALL[1] also failed before installing networking...  ??!!!

[1] I did select a number of extra packages; but.... surely no 32-bit packages are presented/selectable if the 32-bit stuff is all disabled.

Sure, I'll eventually get mga5 installed; but having to rely on unnecessary 32-bit packages in a separate repo tree is bad design IMO.
Pierre Fortin 2015-06-25 19:18:59 CEST

Status: RESOLVED => REOPENED
Resolution: INVALID => (none)

Comment 4 Sander Lepik 2015-06-25 19:25:44 CEST
Show some errors you are getting. Currently the bug is quite useless.

Keywords: (none) => NEEDINFO

Comment 5 Sander Lepik 2015-06-25 19:29:11 CEST
Also, for network upgrades it's wise to use --download-all
Comment 6 Pierre Fortin 2015-06-25 19:49:59 CEST
Planning to do that; but without networking after update attempt, I chose to try a fresh install which also failed -- without networking.

My mirroring of i586 has progressed to media/core/release/a* -- [b-z]* still in the queue as I write this...  Doing full mirror to avoid being told I have an incomplete one** when I continue to object to the need to do any 32-bit stuff on a 64-bit update -- updating any 32-bit applications is not the priority; a working 64-bit base system is...

WHY does a 64-bit *fresh* install require ANY 32-bit packages?
Can no-one answer this question in the interim?


** was responding to comment 4 and collided with comment 5, so I was right to do full mirror...
Comment 7 Sander Lepik 2015-06-25 19:57:22 CEST
Can't say w/o seeing errors. I can only guess. But guessing doesn't help..
Comment 8 Pierre Fortin 2015-06-25 20:04:52 CEST
OK.  I take comment 7 to imply that 32-bit packages are required for a 64-bit install.

In order to get errors, I have to redo my efforts which took the better part of an evening; both upgrade and install gave non-networked systems. 

Can you at least specify which file(s) you want? "I can only guess. But guessing doesn't help.."
Comment 9 Sander Lepik 2015-06-25 20:07:11 CEST
I want to see which errors urpmi gives when you try to upgrade. There are probably conflicts that break upgrade. Which packages are conflicting?
Comment 10 Pierre Fortin 2015-06-25 20:24:47 CEST
Repeat:  Can you at least specify which file(s) you want? "I can only guess. But guessing doesn't help.."

> There are probably conflicts that break upgrade. 
Yup; but only after upgrading ~3200 packages before the first error.

> Which packages are conflicting?
Once the errors occurred, I was presented with media sources where I had to uncheck the 32-bit sources again. The upgrade proceeded to install a few more packages, then no more.  When the install process restarts this way, do the error files[1] get over-written, or am I OK to continue the upgrade and then find several (or a complete) log(s)?  This is important because there are several failures with source selections in between...

[1] still don't know where to find them, and won't have network access to get find out during the next attempt.
Comment 11 Sander Lepik 2015-06-25 20:30:09 CEST
Are you using command line or GUI?

I use network upgrade for many years myself, with this command: urpmi --auto-select --download-all --no-recommends

If error occurs, copy it into txt file that you can access later.
Comment 12 Pierre Fortin 2015-06-25 20:58:19 CEST
My network is only 3Mb/s, so I don't want an upgrade/install taking days to complete.  I mirror the packages[1] locally, then do the upgrade/install from HD.

My wget mirror rules process only x86_64 with:

reject = *-af-*,*-ar-*,*-az-*,*-bg-*,*-bn-*,*-br-*,*-bs-*,*-ca-*,*-cs-*,*-cy-*,*-da-*,*-de-*,*-el-*,*-eo-*,*-es-*,*-et-*,*-eu-*,*-fa-*,*-fi-*,*-fr-*,*-ga-*,*-he-*,*-hi-*,*-hr-*,*-hu-*,*-id-*,*-is-*,*-it-*,*-ja-*,*-ka-*,*-ku-*,*-ky-*,*-lt-*,*-lv-*,*-mk-*,*-mn-*,*-ms-*,*-mt-*,*-nl-*,*-no-*,*-pa_IN-*,*-ps-*,*-po-*,*-pt-*,*-pt_BR-*,*-ro-*,*-ru-*,*-sc-*,*-sk-*,*-sl-*,*-sq-*,*-sr-*,*-sv-*,*-ta-*,*-tg-*,*-tl-*,*-tr-*,*-uk-*,*-uz-*,*-vi-*,*-zh_CN-*,*-zh_TW-*,*-debuginfo-*

exclude_directories = 
/mageia/distrib/cauldron/x86_64/dosutils/autorun/de-DE,
/mageia/distrib/cauldron/x86_64/dosutils/autorun/es-ES,
/mageia/distrib/cauldron/x86_64/dosutils/autorun/fr-FR,
/mageia/distrib/cauldron/x86_64/dosutils/autorun/it-IT,
/mageia/distrib/cauldron/x86_64/dosutils/autorun/pt-BR,
/mageia/distrib/cauldron/x86_64/dosutils/autorun/ru-RU,
/mageia/distrib/cauldron/x86_64/dosutils/autorun/zh-CN,
/mageia/distrib/cauldron/x86_64/media/debug*,
/mageia/distrib/cauldron/x86_64/media/*/backports,
/mageia/distrib/cauldron/x86_64/media/*/*testing

So having to also grab i586 is, to me, an unnecessary step that takes MANY hours to complete...   and why I don't want 32-bit sources.  I can install/upgrade 32-bit packages individually later if I need/want them.
Comment 13 Pierre Fortin 2015-06-26 00:22:05 CEST
(In reply to Sander Lepik from comment #11)
> Are you using command line or GUI?

boot.iso on USB stick

> I use network upgrade for many years myself, with this command: urpmi
> --auto-select --download-all --no-recommends

Digging into this...  
 --no-recommends is not documented in 'man urpmi' (2013-11-05) or in 'urpmi -h' (urpmi-7.31-1.mga4). What does this do?
Comment 14 Samuel Verschelde 2015-07-02 10:09:33 CEST
(In reply to Pierre Fortin from comment #13)
> Digging into this...  
>  --no-recommends is not documented in 'man urpmi' (2013-11-05) or in 'urpmi
> -h' (urpmi-7.31-1.mga4). What does this do?

--no-recommends is probably an alias to --no-suggests, which means only install the required dependencies, not the packages that are merely suggested by other packages because, although they are not strictly required, they add useful functionalities.
Comment 15 Pierre Fortin 2015-07-02 17:02:05 CEST
What am I missing?  Since the boot.iso methods failed (above), I finally got the i586 tree mirrored locally and decided to use urpmi to do the update.  However, using --test, it appears to only want to update a few tainted packages...

root@prf /mnt/hd/distros/remote/mageia/distrib/5   <=== current dir
10:22:30 # urpmi --test --auto-select --searchmedia .  <=== "."
trying to select nonexistent medium "."
To satisfy dependencies, the following packages are going to be installed:
(test only, installation will not be actually done)
  Package                        Version      Release       Arch    
(medium "Tainted Release")
  cdrdao                         1.2.3        9.mga4.taint> x86_64  
  gstreamer0.10-plugins-ugly     0.10.19      9.mga4.taint> x86_64  
  gstreamer1.0-soundtouch        1.2.2        1.mga4.taint> x86_64  
  k3b                            2.0.2        12.mga4.tain> x86_64  
  lib64k3bdevice6                2.0.2        12.mga4.tain> x86_64  
  lib64k3blib6                   2.0.2        12.mga4.tain> x86_64  
  lib64opal3.10.10               3.10.10      6.mga4.taint> x86_64  
  lib64opal3.10.10-plugins       3.10.10      6.mga4.taint> x86_64  
  lib64quicktime0                1.2.4        6.mga4.taint> x86_64  
  lib64rtmp0                     2.4          0.git2011122> x86_64  
  lib64xine1                     1.1.21       11.mga4.tain> x86_64  
  xine-plugins                   1.1.21       11.mga4.tain> x86_64  
344KB of additional disk space will be used.
14MB of packages will be retrieved.
Proceed with the installation of the 12 packages? (Y/n) 

#### NOTE that these are mga4 packages...
installing cdrdao-1.2.3-9.mga4.tainted.x86_64.rpm lib64k3bdevice6-2.0.2-12.mga4.tainted.x86_64.rpm lib64xine1-1.1.21-11.mga4.tainted.x86_64.rpm lib64k3blib6-2.0.2-12.mga4.tainted.x86_64.rpm gstreamer0.10-plugins-ugly-0.10.19-9.mga4.tainted.x86_64.rpm k3b-2.0.2-12.mga4.tainted.x86_64.rpm lib64opal3.10.10-3.10.10-6.mga4.tainted.x86_64.rpm xine-plugins-1.1.21-11.mga4.tainted.x86_64.rpm gstreamer1.0-soundtouch-1.2.2-1.mga4.tainted.x86_64.rpm lib64rtmp0-2.4-0.git20111228.5.mga4.tainted.x86_64.rpm lib64opal3.10.10-plugins-3.10.10-6.mga4.tainted.x86_64.rpm lib64quicktime0-1.2.4-6.mga4.tainted.x86_64.rpm from /distros/x86_64/media/tainted/release
Preparing...                     ##########################################################################################################################################
Installation is possible
root@prf /mnt/hd/distros/remote/mageia/distrib/5
10:27:44 # du -s *
41G     i586
4.0K    SRPMS
57G     x86_64
root@prf /mnt/hd/distros/remote/mageia/distrib/5
10:32:25 # du -s ../4/*
48G     ../4/i586
82G     ../4/x86_64
root@prf /mnt/hd/distros/remote/mageia/distrib/5
10:42:07 # tree -dL 3 .
.
âââ 4
â   âââ i586
â   â   âââ doc
â   â   âââ dosutils
â   â   âââ install
â   â   âââ isolinux
â   â   âââ media
â   â   âââ misc
â   âââ x86_64
â       âââ doc
â       âââ dosutils
â       âââ install
â       âââ isolinux
â       âââ media
â       âââ misc
âââ 5               <=== where I issued the urpmi command from...
â   âââ i586
â   â   âââ doc
â   â   âââ dosutils
â   â   âââ install
â   â   âââ isolinux
â   â   âââ media
â   â   âââ misc
â   âââ SRPMS
â   âââ x86_64
â       âââ doc
â       âââ dosutils
â       âââ install
â       âââ isolinux
â       âââ media
â       âââ misc
âââ caldron

32 directories
root@prf /mnt/hd/distros/remote/mageia/distrib
10:55:28 # 

Weird...  the urpmi output appears related to what it found in ../4/... as opposed to ./5/... even though I was in /mnt/hd/distros/remote/mageia/distrib/5 -- just a few mga4 packages to update v. all of mga5...

man urpmi contains:
       --media media1,...,mediaN
           Select specific media to be used, instead of defaulting to all
 available media 
           (or all update media if --update is used).  No rpm will be fetched from other media.
Comment 16 Pierre Fortin 2015-07-02 17:04:45 CEST
Forgot to paste "cd .." just before "tree -dL 3 ."
Comment 17 Pierre Fortin 2015-07-04 18:32:02 CEST
Closing.  Used urpmi method to update which was a bit better; but still failed to setup wireless...  opening different bug.

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


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