Description of problem: In my relatively new Mageia 8 installation on a Dell Latitude E6530, I decided to explore the contents of task-games. This installation ended in failure, with several files failing to verify their characteristics, and many further files failing to find their dependencies, which had just failed to download correctly. At the end of the download process a dialog box appeared, the first line of which stated 9 installation transactions failed. What followed that was 13 pages of error messages (as presented in L.O. Writer) comprised of about 1,450 words of failure details. Needless to say, I did not attempt to run any of the games. I am disappointed that I chose to make a 20GB games installation, only to result in disc territory covered with unusable magnetic patterns. Version-Release number of selected component (if applicable): rpmdrake --version reports 6.32 How reproducible: I have not tried to reproduce this because I do not have another 20GB of drive space in the 50GB partition to use. In fact, I don't know how to get rid of the mess because urpmi --clean command does not appear to be successful. (At least, it does not appear to work long enough to get the job done.) Steps to Reproduce: 1. Check for available hard drive space, which needs to be well-above 20GB. 2. Initiate Add/Remove software. 3. Select task-games, then Apply the command to install. 4. Wait for the process to complete, which is an uninformative time. 5. In the resulting dialog box, select all text, copy it, and paste it into Libre Office Writer. Be amazed at 13 pages of error messages.
Created attachment 13155 [details] LibreOffice Writer document holding text from rpmdrake error messages
I suspect this is a duplicate of bug 24362 After running "urpmi --clean", see if the suggestion in https://bugs.mageia.org/show_bug.cgi?id=24362#c6 works. If it does, this is a duplicate bug.
CC: (none) => davidwhodgins
> only to result in disc territory covered with unusable magnetic patterns Despite things having gone wrong, you should not have a corrupt disc. Packages are downloaded into /var/cache/urpmi/rpms/ and # urpmi --clean as Dave suggests above clears that out. You should not then be short of disc space. [But see later] Additional things you might do to get back to the start are:- # urpme task-games # urpme --auto-orphans One can always test package installation without actually doing it: # urpmi --test <package name(s)> which does actually download the required rpms. If downloading is a problem, this might avoid complications: # urpmi --download-all <package name(s)> "By default, urpmi will download packages when they are needed. This can be problematic when connection failures happen during a big upgrade. When this option is set, urpmi will first download all the needed packages and proceed to install them if it managed to download them all" But beware! I have just done: $ sudo urpmi --test task-games and after a few choices to answer, it said it would need: - *26GB* if free disc space, and download - *17GB* of packages (442).
CC: (none) => lewyssmith
(In reply to Lewis Smith from comment #3) > Additional things you might do to get back to the start are:- > # urpme task-games > # urpme --auto-orphans It is more safe to issue these commands combined: # urpme --auto-orphans task-games So only orphans related to task-games get removed. The other way could also remove "orphans" which are still needed by the system and could render it broken.
I accepted the advice offered by sturmvogel with the following results: [ken@localhost ~]$ su - Password: [root@localhost ~]# urpme --auto-orphans task-games unknown package: task-games [root@localhost ~]# df Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 12K 3.9G 1% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 1.6M 3.9G 1% /run /dev/sda1 50G 20G 28G 43% / tmpfs 3.9G 8.0K 3.9G 1% /tmp /dev/sda6 405G 16G 389G 4% /home tmpfs 787M 152K 787M 1% /run/user/1000 [root@localhost ~]# Then I followed Dave Hodgins' suggestion in Comment 6 of Bug 24362 and selected wget as the download client. I also clicked always for verify RPMs and download XML meta-data. Then I restarted the install task-games process, which told me it had 431 packages comprising 14GB to be retrieved, and which would consume 20GB of additional disk space. The task was started at 11:12 p.m., and it was 11:50 p.m. before control of the machine was returned to me. [ken@localhost ~]$ df Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 12K 3.9G 1% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 1.6M 3.9G 1% /run /dev/sda1 50G 41G 5.8G 88% / tmpfs 3.9G 8.0K 3.9G 1% /tmp /dev/sda6 405G 16G 389G 4% /home tmpfs 787M 164K 787M 1% /run/user/1000 [ken@localhost ~]$ uname -or 5.15.23-desktop-1.mga8 GNU/Linux [ken@localhost ~]$ Arithmetic shows the games consumed 22.2GB, not 20GB The Steam client is installed in both df reports. Ken
(In reply to sturmvogel from comment #4) > It is more safe to issue these commands combined: > # urpme --auto-orphans task-games > > So only orphans related to task-games get removed. The other way could also > remove "orphans" which are still needed by the system and could render it > broken. I did not know that command combination. Useful! :) If you have the time, could you add it to our urpmi wiki page? https://wiki.mageia.org/en/URPMI I see there is no mention of only --auto-orphans by itself either.
CC: (none) => fri
It is already documented. https://wiki.mageia.org/en/URPMI#Advanced_usage points to https://wiki.mageia.org/en/Removing_packages and there we have the chapter https://wiki.mageia.org/en/Removing_packages#Removing_with_dependencies and reference bug from 2011 https://bugs.mageia.org/show_bug.cgi?id=3163#c7
Thanks :) I should have followed the link.
> it had 431 packages comprising 14GB to be retrieved, and which would > consume 20GB of additional disk space. The task was started at 11:12 p.m., > and it was 11:50 p.m. before control of the machine was returned to me. Just 40m for all that?! Thanks Kenneth for the prompt & good feedback. From comment 5, it appears that everything went fine, so closing this.
Status: NEW => RESOLVEDResolution: (none) => FIXED
It hasn't fixed the underlying problem. For some unclear reason, curl is now failing more often. The code hasn't changed, so it may be a change in things like more parts of the internet being overloaded. The default in rpmdrake should still be changed Re-closing as a duplicate of bug 24362. *** This bug has been marked as a duplicate of bug 24362 ***
Resolution: FIXED => DUPLICATE