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:
Is this resolved yet? I saw Thomas working on a similar issue.
Assignee: bugsquad => tmb
The mirrors are boiling at the moment with the mass rebuild. As soon as they settle down, I'll try again.
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 ?
CC: (none) => paiiou
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 ?
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)
Fixed. The invalid opcode bug will be followed in bug #14172
Status: NEW => RESOLVEDCC: (none) => thierry.vignaudResolution: (none) => FIXED
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 => REOPENEDResolution: FIXED => (none)
which isn't same error as here, no ?
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.
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 => RESOLVEDResolution: (none) => FIXED