Bug 14101

Summary: basesystem packages unavailable during fresh install
Product: Mageia Reporter: Frank Griffin <ftg>
Component: InstallerAssignee: Thomas Backlund <tmb>
Status: RESOLVED FIXED QA Contact:
Severity: critical    
Priority: Normal CC: paiiou, thierry.vignaud
Version: Cauldron   
Target Milestone: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Source RPM: CVE:
Status comment:

Description Frank Griffin 2014-09-16 15:34:25 CEST
During a fresh install today, package installation failed with a slew of errors starting with:
       /bin/sh is needed by p11-kit-0.20.6-1.mga5.x86_64
and going on to complain about filesystem, libc, ld-linux, and various other staples.

urpmi --auto-update seems happy on my other cauldron systems, so this appears to be limited to something in the installer.

To reproduce, do a fresh install selecting all package selection checkboxes.

Unfortunately, "bug" seems to be broken, giving the error:
      ask_from_list: empty list
      interactive::ask_from_listf_raw() called from /usr/lib/libDrakX/interactive.pm:284
      interactive::ask_from_listf() called from /usr/lib/libDrakX/install/commands.pm:404
      instal::commands::bug() called from /usr/bin/bug:16
      (eval)() called from /usr/bin/bug:14

Reproducible: 

Steps to Reproduce:
Comment 1 David Walser 2014-09-16 19:10:12 CEST
Is this resolved yet?  I saw Thomas working on a similar issue.

Assignee: bugsquad => tmb

Comment 2 Frank Griffin 2014-09-16 21:42:17 CEST
The mirrors are boiling at the moment with the mass rebuild.  As soon as they settle down, I'll try again.
Comment 3 Frank Griffin 2014-09-17 17:43:52 CEST
Same error still.

It alternates with the installer crashing after the "Installing" window appears with "Time Remaining (estimating)" displayed but before any detail line appears.  The install terminates and flips back to tty1 indicating that something ended with status 4 (or perhaps -4).

The only unusual thing I noticed is that when (having clicked "Details") the package count is shown, it is significantly larger than the last time I did an install.  It used to float around 2900-3000 and now it's 3500+.  Is it possible that some internal limit is now being exceeded if every package category is checked ?
Georges Eckenschwiller 2014-10-09 21:17:46 CEST

CC: (none) => paiiou

Comment 4 Frank Griffin 2014-10-10 00:13:46 CEST
This has morphed into a kernel crash at the start of package installation.  tty4 shows a kernel trap message for invalid opcode.

Install has been running well on the machine forever.  Did we change compile options for the install kernel recently ?
Comment 5 Thomas Backlund 2014-10-10 08:41:02 CEST
What hw ?

tv also caught a invalid opcode during stage2 debugging.

can you paste the trap info from the logs

We haven't changed anything (besides disabling lock-elision in glibc, but that only affected Haswell class hw with new firmwares we dont yet ship)
Comment 6 Thierry Vignaud 2014-10-10 14:09:08 CEST
Fixed.
The invalid opcode bug will be followed in bug #14172

Status: NEW => RESOLVED
CC: (none) => thierry.vignaud
Resolution: (none) => FIXED

Comment 7 Frank Griffin 2014-10-22 13:34:27 CEST
This is still a problem, similar but possibly not identical.

Now that bug#14172 finally has a workaround, I was able to try a fresh install with every package category checked again, and it aborts with a huge display of package install errors, including lots of KDE and PHP stuff.

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

Comment 8 Manuel Hiebel 2014-10-22 19:11:35 CEST
which isn't same error as here, no ?
Comment 9 Frank Griffin 2014-10-22 19:36:44 CEST
It's a bit hard to tell, as there are so many packages that fail install.  Originally, basesystem ones were listed first.  Now others are, but I can't swear that basesystem packages aren't somewhere in the large error window.

Anyway, the basic problem is the same: the install fails because critical packages fail install.
Comment 10 Thierry Vignaud 2014-10-23 01:37:00 CEST
This particular issue has been fixed.
Please open a _NEW_ bug report and attach the /root/drakx/report.bug.xz from a failed install to it

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