| Summary: | 'urpmi error: 9' causes installation loop | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Felix Miata <mrmazda> |
| Component: | Installer | Assignee: | Thierry Vignaud <thierry.vignaud> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | Normal | CC: | davidwhodgins, tmb |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Attachments: |
report.bug from HTTP installation attempt minutes ago
fix displaying fatal error messages |
||
Thierry, what it urpmi error 9 ? CC:
(none) =>
tmb man urpmi => "9. Unable to open rpmdb" Doh, I never noticed the error codes in urpmi manual :/ Created attachment 2168 [details]
fix displaying fatal error messages
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 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. 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 (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 re comment 4/5 -> comment 8 -> fixed seems better resolution Status:
REOPENED =>
RESOLVED 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. |
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.