Bug 19036 - 6RC classic iso upgrade from mga5 stalls on package installation after some 300 packages
Summary: 6RC classic iso upgrade from mga5 stalls on package installation after some 3...
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: Release (media or process) (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal major
Target Milestone: ---
Assignee: Thierry Vignaud
QA Contact:
URL:
Whiteboard:
Keywords: 6sta1.5
Depends on:
Blocks:
 
Reported: 2016-07-23 19:25 CEST by Len Lawrence
Modified: 2019-02-28 16:05 CET (History)
4 users (show)

See Also:
Source RPM: Not sure; could be dracut or drakx11 installer
CVE:
Status comment:


Attachments
report.bug for mga5 to 6RC round 3 upgrade (214.28 KB, application/octet-stream)
2016-07-24 02:28 CEST, Len Lawrence
Details
report.bug for mga5 to 6RC round 3 upgrade (49.17 KB, application/octet-stream)
2016-07-24 10:04 CEST, Len Lawrence
Details
Latest 6RC report.bug, part 1 (914.36 KB, application/octet-stream)
2016-07-24 15:49 CEST, Len Lawrence
Details
Second part of report.bug for mga5 -> 6RC upgrade (797.93 KB, application/gzip)
2016-07-24 15:51 CEST, Len Lawrence
Details
Install log for mga5 upgrade -> 6RC (297.54 KB, application/gzip)
2016-07-24 15:55 CEST, Len Lawrence
Details

Description Len Lawrence 2016-07-23 19:25:50 CEST
Description of problem:
Chose upgrade for UEFI installation from USB stick.
The installation sequence started with more than 1100 packages but ground to a halt after 102 packages failed to install.  That left 1055.  resumed the operation; stopped at 92 packages failed to install.  Resumed with 960 to go.  The interruptions occurred ten times with the outstanding packages whittled down to 759 with 75 failures.

At this point the system appeared to be hung but on tty1 there were a series of error messages of this form:

Cannot open Requirename index using db5 - Too many open files (24)
Other index names occurred, like Providename, Obsoletename and Conflictname.
There was another message in the middle of all this:

Glib critical : Source ID 19723 was not found when attempting to remove it at /usr/lib/libDrakX/interactive/gtk.pm line 924

In the end I forced a reboot and installed Plasma5 from the same iso.  That went very smoothly.

Version-Release number of selected component (if applicable):
Mageia-6-RC-x86_64-DVD (July 22)

How reproducible:
Tried it once

Steps to Reproduce:
1. Boot the iso from USB
2. Choose upgrade from mga5
3. Resume the installation every time it stops
4. When it appears to be hung, check what is happening via tty1
Comment 1 Len Lawrence 2016-07-23 19:29:44 CEST
Should have said that the system started as a mixed desktop system,  probably up-to-date.
Len Lawrence 2016-07-23 19:32:58 CEST

Keywords: (none) => 6RC

Comment 2 Charles Edwards 2016-07-23 22:13:17 CEST
Mixed system or not this is an issue that any user doing a 5 to 6 upgrade using
either of the dvd iso may face.
The dvd's contain only a "fixed" selection of rpms whereas the system being upgrade
could contain numerous other pkgs which also need to be upgraded to prevent failed dependency errors.


Possible solutions:

Re-add the ability to add online media at the beginning of the install.

Except for a selected number of core pkgs disregard "failed install" errors and allow the installation to complete.


Work arounds:

When the upgrade fails reboot the system with the Mga5 kernel, add Mga6 sources,
and complete the upgrade using urpmi.

Strongly recommend that the dvd.iso be used Only for installs Not for upgrades.

CC: (none) => cae

Comment 3 Manuel Hiebel 2016-07-23 22:35:49 CEST
Could you provide the file /root/drakx/report.bug.xz if you have it as an attachment ?

Keywords: (none) => NEEDINFO

Comment 4 Len Lawrence 2016-07-23 23:48:39 CEST
Sorry Manuel.  I was looking elsewhere for logs.  Installed Plasma right after that.  I could roll back I guess and dump the report if you really need it.  Problem is lack of time just now, seriously.
Comment 5 Len Lawrence 2016-07-24 01:59:15 CEST
@Manuel 
Started again but see no /root/drakx.  While the upgrading is going on all /root contains is non-chrooted-marker.DrakX.  There is a /mnt/root/drakx which does contain the report.debug.xz and report.debug which has a later timestamp.  I am guessing that report.debug is compressed at intervals.
Comment 6 Len Lawrence 2016-07-24 02:11:13 CEST
report.debug contains all the hardware checks and a list of unknown packages.
Been watching this for two hours now and it has installed only 250 of 1175 packages.  I am going to have to dump the file and shut down.
Comment 7 Len Lawrence 2016-07-24 02:28:48 CEST
Created attachment 8244 [details]
report.bug for mga5 to 6RC round 3 upgrade

This was obtained from /mnt/run/drakx about two hours into the upgrade.  The timestamp indicated that it was generated right at the beginning of the process.
Upgrade abandoned.
Comment 8 Len Lawrence 2016-07-24 02:49:25 CEST
Charles suggestion about ignoring the failed components seems like a good idea providing the system is not compromised by doing that, as he points out.
Comment 9 Len Lawrence 2016-07-24 02:56:19 CEST
g/debug/bug/  It is the middle of the night!
Comment 10 Marja Van Waes 2016-07-24 08:57:26 CEST
(In reply to Len Lawrence from comment #7)
> Created attachment 8244 [details]
> report.bug for mga5 to 6RC round 3 upgrade
> 
> This was obtained from /mnt/run/drakx about two hours into the upgrade.  The
> timestamp indicated that it was generated right at the beginning of the
> process.
> Upgrade abandoned.

I think you attached a different one, this one contains

* second stage install running (DrakX v16.105)

That should be DrakX v17.52 now.

Besides, instead of abandoning, you completely finished it:

* starting step `exitInstall'

It was a report.bug.xz that you attached, report.bug.xz is neither deleted nor overwritten when upgrading.

The file you need is report.bug (and, yes, it is likely that you need to compress it, so you might want to rename report.bug.xz to report.bug.xzOLD or so, first)

CC: (none) => marja11, thierry.vignaud

Comment 11 Len Lawrence 2016-07-24 09:39:55 CEST
@marja
Luckily I did dump report.bug as well before shutting down having noted the difference in timestamps.  It is not much bigger than the compressed file.
Comment 12 Len Lawrence 2016-07-24 10:04:12 CEST
Created attachment 8246 [details]
report.bug for mga5 to 6RC round 3 upgrade

Attachment 8244 is obsolete: 0 => 1

Comment 13 Marja Van Waes 2016-07-24 10:12:48 CEST
That's very weird, that also has

* second stage install running (DrakX v16.105)

:-(

Are you sure you were using an 6RC iso?

What is the time stamp of the iso, and were the checksums ok?
Comment 14 Marja Van Waes 2016-07-24 10:14:31 CEST
Ah, no, you reached the exitInstall step, so this is just old again, sorry :-(
Comment 15 Len Lawrence 2016-07-24 12:02:53 CEST
[lcl@belexeuli Mageia-6-RC-x86_64-DVD]$ checksums
Current directory is /data/isos/mageia6-RC/Mageia-6-RC-x86_64-DVD
Fri Jul 22 23:00:00 CEST 2016
md5 sumcheck
ba559aeb2402969de56badcfaeaaf81d  Mageia-6-RC-x86_64-DVD.iso
ba559aeb2402969de56badcfaeaaf81d  Mageia-6-RC-x86_64-DVD.iso
sha1 sumcheck
c2adc675072d4527b208301e7d0eb062afd458ae  Mageia-6-RC-x86_64-DVD.iso
c2adc675072d4527b208301e7d0eb062afd458ae  Mageia-6-RC-x86_64-DVD.iso
sha512 sumcheck
cce5def2ba186b93eafed465d30a565451f95054765574c53747ee5fc60fe2227f6fdbb25237239311c026479b4225ae5559688141eca679ecd688ac819fc00d  Mageia-6-RC-x86_64-DVD.iso
cce5def2ba186b93eafed465d30a565451f95054765574c53747ee5fc60fe2227f6fdbb25237239311c026479b4225ae5559688141eca679ecd688ac819fc00d  Mageia-6-RC-x86_64-DVD.iso

And this is what the USB drive holds:
[lcl@belexeuli Mageia-6-RC-x86_64]$ ls -l
total 19
-r--r--r-- 1 lcl lcl    80 May 27  2011 autorun.inf
-r--r--r-- 1 lcl lcl  2048 Jul 22 21:21 boot.catalog
dr-xr-xr-x 1 lcl lcl  2048 May 27  2011 dosutils
dr-xr-xr-x 1 lcl lcl  2048 Jan 29  2015 EFI
dr-xr-xr-x 1 lcl lcl 10240 Jul  9 00:00 isolinux
dr-xr-xr-x 1 lcl lcl  2048 Jul 22 21:21 x86_64

The preceding Plasma install would have wiped the root partition and left a report.bug.xz, the one with the earlier timestamp, dated yesterday evening.  The uncompressed report file was dated just before midnight, the time when the second attempt at upgrading started.  So I have no idea what is going on here.

This is isolinux/x86_64
$ ls -l
total 79925
-r--r--r-- 1 lcl lcl 48932376 Jul 22 21:11 all-nonfree.rdz
-r--r--r-- 1 lcl lcl 28268288 Jul 22 21:11 all.rdz
-r--r--r-- 1 lcl lcl  4641232 Jul 22 21:11 vmlinuz

$ cat x86_64/VERSION
Mageia Mageia vanda 20160722 20:21

As I said earlier, I am out of time now.  Probably off the grid for weeks but shall
probe a bit more when I can.  Real life cannot be avoided.  Sorry the report did not help.
Comment 16 Marja Van Waes 2016-07-24 12:43:24 CEST
no problem, thanks for the great job you're doing here :)

i'll set this report to unconfirmed for now.

if you're away for holidays, then: enjoy them!

if not: good luck with whatever takes your time.

Status: NEW => UNCONFIRMED
Ever confirmed: 1 => 0

Comment 17 Len Lawrence 2016-07-24 13:10:03 CEST
Thanks Marja.  Not holidays - I wish.  Entertaining kid sister (70) from New Zealand and things like that.

Resumed the upgrade.  Looked at mnt/root/drakx/ddebug.log:

install stage2 running DrakX v17.52

That confirms that the report.bug files are stale.
No later reports available.  When is report.bug supposed to be started or is it created at the the finish?  Any other logs useful?  The hardware side will probably not change much from one report to another.  install.log and ddebug.log are the only files  concurrent with this latest run.
Comment 18 Marja Van Waes 2016-07-24 13:31:03 CEST
(In reply to Len Lawrence from comment #17)
> Thanks Marja.  Not holidays - I wish.  Entertaining kid sister (70) from New
> Zealand and things like that.

Nice :-)
> 
> Resumed the upgrade.  Looked at mnt/root/drakx/ddebug.log:
> 
> install stage2 running DrakX v17.52

That's good.... please attach that file, then
> 
> That confirms that the report.bug files are stale.
> No later reports available.  When is report.bug supposed to be started or is
> it created at the the finish? 

Come to think of it, it is probably created when issuing the "bug" command in tty2 during installation, and else at the end of install.

> Any other logs useful?  The hardware side
> will probably not change much from one report to another.  install.log and
> ddebug.log are the only files  concurrent with this latest run.

 ddebug.log with DrakX v17.52 is fine, thanks for having checked!
Comment 19 Len Lawrence 2016-07-24 15:19:02 CEST
OK, this is my final tilt at this particular windmill.  The upgrade eventually ran into the open file limit.  Each failure entails user input and the time between entering the install stage and the next failure, which may be one or two packages later, is several minutes long.  So what is going on in that period?  No timeout needs to be that long. 

The only log files available are ddebug.log and install.log so please find these attached.  And thanks Marja for your constant presence.
Comment 20 Marja Van Waes 2016-07-24 15:49:27 CEST
(In reply to Len Lawrence from comment #19)

> 
> The only log files available are ddebug.log and install.log so please find
> these attached. 

Maybe bugzilla played a trick on you? I don't see a new attachment.
Comment 21 Len Lawrence 2016-07-24 15:49:48 CEST
Created attachment 8249 [details]
Latest 6RC report.bug, part 1

Thanks marja for the gentle reminder.  Ran bug /dev/sde1, so this time it should be current.  Had to split the file in two (169291 lines).
Comment 22 Len Lawrence 2016-07-24 15:51:41 CEST
Created attachment 8250 [details]
Second part of report.bug for mga5 -> 6RC upgrade

Attachment 8246 is obsolete: 0 => 1

Comment 23 Len Lawrence 2016-07-24 15:55:00 CEST
Created attachment 8251 [details]
Install log for mga5 upgrade -> 6RC
Comment 24 Len Lawrence 2016-07-24 15:57:59 CEST
The install log may be redundant now.  Holding ddebug.log for now because it too needs to be split and may also be redundant.
Comment 25 Marja Van Waes 2016-07-24 16:08:30 CEST
Near the end of attachment 8250 [details], there are many lines about:

cannot open [Obsolete|Conflict|Provide|Requiere]name index using db5 - Too many open files (24)

@ tv

That means nothing to me, guessing it's for you

Keywords: NEEDINFO => (none)
Status: UNCONFIRMED => NEW
Assignee: bugsquad => thierry.vignaud
Ever confirmed: 0 => 1

Comment 26 Thierry Vignaud 2016-07-24 16:23:26 CEST
(In reply to Len Lawrence from comment #21)
> Had to split the file in two (169291 lines).

It's better to just compress it next time...
Comment 27 Thierry Vignaud 2016-07-24 16:24:12 CEST
(In reply to Marja van Waes from comment #25)
It means rpm is failing to open its rpmdb in /var/lib/rpm...
(really /mnt/var/lib/rpm when chrooted in the installer)
Comment 28 Len Lawrence 2016-07-24 16:48:21 CEST
@marja re comment 20.  No trick, just me being slow aka interrupted.
Comment 29 Len Lawrence 2016-07-24 16:50:53 CEST
In reply to Thierry Vignaud in comment 26

The compressed file exceeded the 1 MB limit so I had to split it and compress the two halves.
Comment 30 Marja Van Waes 2016-07-24 17:49:01 CEST
(In reply to Len Lawrence from comment #29)
> In reply to Thierry Vignaud in comment 26
> 
> The compressed file exceeded the 1 MB limit so I had to split it and
> compress the two halves.

I considered telling you about compressing with xz, bug wasn't sure how much better it compresses.

Now I know, I copied an old report.bug to report.bug2 and report.bug3, and then I ran "gzip report.bug3" and "xz report.bug2", here are my results:

-rw-r--r--  1 marja marja 2354075 apr 27 13:17 report.bug
-rw-r--r--  1 marja marja  179920 jul 24 17:43 report.bug2.xz
-rw-r--r--  1 marja marja  347409 jul 24 17:45 report.bug3.gz

so xz compresses almost twice as much as gzip
Comment 31 Marja Van Waes 2016-07-24 17:50:06 CEST
lol, I should have renamed tham to report2.bug and report3.bug ;-)
Comment 32 Len Lawrence 2016-07-24 19:26:18 CEST
Good to know.  xz from now on.
Comment 33 Len Lawrence 2019-02-28 16:05:45 CET
This applied to an old release and is certainly not relevant anymore.

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


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