Bug 5725 - 'urpmi error: 9' causes installation loop
Summary: 'urpmi error: 9' causes installation loop
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: i586 Linux
Priority: Normal major
Target Milestone: ---
Assignee: Thierry Vignaud
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-02 23:45 CEST by Felix Miata
Modified: 2012-05-04 14:00 CEST (History)
2 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments
report.bug from HTTP installation attempt minutes ago (152.11 KB, text/plain)
2012-05-02 23:45 CEST, Felix Miata
Details
fix displaying fatal error messages (720 bytes, patch)
2012-05-03 18:51 CEST, Thierry Vignaud
Details | Diff

Description Felix Miata 2012-05-02 23:45:01 CEST
Created attachment 2162 [details]
report.bug from HTTP installation attempt minutes ago

I queried this here and on both Mageia-dev mailing list and IRC mageia-dev and got 0 response in each case. I tried readonly=1 installation on both m2b3 586 DVD and HTTP cauldron with same failure every time: the subject message displays (only the "9" part, the urpmi part is in the logging only), then after clicking OK the screen goes back to partitioning step, whereupon proceeding as necessary always produces same result. Error follows OK on the step that follows OK on format partition selection, where I selected to format nothing, having pre-formatted to my requirements including disk LABEL. CPU is ancient 2000MHz Sempron on nForce2 chipset, radeon rv200 video, and PATA HD with 36 partitions of 0x types 1, 5, 6, a, 12, 17, 82 & 83.
Comment 1 Thomas Backlund 2012-05-03 18:20:47 CEST
Thierry, what it urpmi error 9 ?

CC: (none) => tmb
Assignee: bugsquad => thierry.vignaud

Comment 2 Thierry Vignaud 2012-05-03 18:46:58 CEST
man urpmi => "9.  Unable to open rpmdb"
Comment 3 Thomas Backlund 2012-05-03 18:51:48 CEST
Doh, I never noticed the error codes in urpmi manual :/
Comment 4 Thierry Vignaud 2012-05-03 18:51:58 CEST
Created attachment 2168 [details]
fix displaying fatal error messages
Comment 5 Thierry Vignaud 2012-05-03 18:53:33 CEST
There was an issue in the installer about reporting fatal errors, which that patch fixes.
Here the error is either "unable to open rpmdb" or "chroot directory doesn't exist" (which I doubt since /mnt always exists in the installer).

I'll commit the error message fix in about 1 hour
Comment 6 Felix Miata 2012-05-04 06:58:10 CEST
Several hours after comment 5 I tried again on the same system. I got past the reported problem only to encounter a rash of repo access errors, so I waited another hour and tried again. That succeeded in a complete install with no apparent errors, so likely I won't be able to replicate this any more.
Comment 7 Dave Hodgins 2012-05-04 08:57:21 CEST
Most likely you were trying to install while updates were being pushed.

In cauldron, unlike a real release, when updates get pushed, the old
version of a package gets deleted.  If you start an install, and it
builds a list of packages to download, but by time it tries to download
the package, the package has been updated (with the old version deleted),
the installation of that package, and all packages included in the same
transaction will fail, which depending on how early it is in the upgrade,
can cause other packages to fail to install/upgrade too.

The workaround, anytime you see this type of error, is to wait a few hours,
and restart the upgrade.

That's one of the things that must be taken into account when upgrading
to cauldron.  I'll go ahead and close this but as invalid, as I'm pretty
sure that was the cause.  Feel free to reopen, if you disagree.

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

Comment 8 Felix Miata 2012-05-04 11:50:20 CEST
(In reply to comment #7)
> The workaround, anytime you see this type of error, is to wait a few hours,
> and restart the upgrade.
 
> That's one of the things that must be taken into account when upgrading
> to cauldron.  I'll go ahead and close this but as invalid, as I'm pretty
> sure that was the cause.  Feel free to reopen, if you disagree.

To be clear, there was no attempt to upgrade anything, as these were all attempts to install on an empty partition.

The pre-comment 6 installation attempts were spread over a period whose length I can no longer recall, but the result was always exactly the same. So to that point, unstable mirror state doesn't look like a likely cause of the problem. Comment 6 was obviously caused by unstable mirror state, but really didn't even apply to the problem reported.

This bug did report a problem (misreported error) that was apparently fixed by Thierry Vignaud's attached patch, making INVALID an incongruous resolution.

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

Comment 9 Felix Miata 2012-05-04 12:03:02 CEST
re comment 4/5 -> comment 8 -> fixed seems better resolution

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

Comment 10 Thierry Vignaud 2012-05-04 14:00:39 CEST
There was only a minor problem, the error code was right, we were just not displaying the useful error message.
There was an issue with your rpm db.
Note that you say you didn't tried an upgrade but an install but yet logs show you didn't acknowledge formatting the root partition. Maybe there was a remaining bogus rpm db on it.
If you ask for install but don't check in formatting, the files still present on the partition _will_ be used.

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