-   Linux - Software (
-   -   Mandriva - Software Won't Install (

des_a 06-28-2017 11:02 PM

Mandriva - Software Won't Install
1 Attachment(s)
After having created a few working servers, I'm having a problem with Mandriva again. I've seen this problem before, but don't know the solution. While trying to install software on the machine, the software won't install. What I thought was the solution, is not, because the vmain server is working just fine. vweb won't do the same thing as vmain did, however. I'm following almost the same procedure as I did with vmain. Here was the previous thread:

I downloaded the files from the mirror, years ago. I used wget to mirror them. I forgot which mirror I got them from. Then from the applicable directories I'd ran genhdlist2. This basically created a local copy of the distribution source. The files are accessible from my ftp server. I also have smb enabled on the share. It is done using an NAS. It is on my urpmi share. For these type of Linuxes, this is my standard procedure, created some time ago.

I know I have the correct path to the files, and the correct username and password. I know the files are there. I know they are in the database, because I just had recreated the database with genhdlist2 again, thinking that would fix the problem. I know it's finding the file in the database. But for some reason, it's complaining that it can't find the file.

Updating the database has no effect. I can use wget manually using the file it refers to to download it. I bet I could download it manually and use urpmi or rpm to install it. But for some reason, it's not working the way it's really supposed to work. Please help.

des_a 06-29-2017 06:40 PM

I could always try a new fresh install, even though this is a new fresh install. Maybe this is some sort of "bug" that happens only sometimes when you do a fresh install. If that's the case, a fresh install will probably fix it again. How to just go about fixing it though? I don't really know what's causing it, so how to fix it? I didn't have the same problem with the vmain server, which is another virtual machine running on the same system. Therefore I can conclude, that even like I thought before, that it would only occur with Mandriva on Mandriva, is wrong. I could have tried again with another install, and perhaps, it would work. Unless it is a bug in virtual box or something. In that case, it could be that Mandriva on Mandriva really does not work, and that one virtual machine on Windows 10 will be okay, but two or more will not with that OS. I don't know until I really were to try repeatedly re-installing it freshly always getting the same result of it not working.

This is a fresh install, but won't let me install the software, yet the other machine, as I said before, would work okay. And by this point, I'm sure it wasn't the software database getting corrupted.

This is indeed a bit strange...

des_a 07-01-2017 08:33 PM

So I tried a fresh install of the OS. I was paying close attention to any technical problems I had along the way.

Everything worked smoothly except for the following:

* The first time I tried my test of installing software, it froze the system. I was trying to install the software from the command line in a terminal in LXDE. I believe it's the default terminal that the system uses, because I didn't change it or anything. LXTerminal is it's name.

* To fix it, I had to power off the virtual machine from the menu, and restart it. Then during my second test, since I didn't really need the GUI at this point, I logged onto a console tty2. I logged on with the root account.

* I had to remount my software share, which has the scripts I will be using to install the software in general. However for this test, I was only setting up the media sources and testing the first package to be installed. I again used verbose mode for this test. (If I ran the entire script, it would take forever to tell me what I need to know - whether or not the software installation works. I really do want the package I'm trying to install, and the script calls for it, so by testing and then running the script, it will later cause part of the script to fail. But that's okay.)

* This time it worked okay and told me what I needed to know. The answer is it doesn't work and gives the same error and output as before.

So this still doesn't work, even with a fresh install. The only thing that I saw was a bit damaged from the shutoff was /tmp. That shouldn't matter too much. I will try to rebuild the database one more time, but I'm pretty certain by this point, that that won't make a difference.

That leaves me to troubleshoot the system in it's entirety. The problem may not be the actual machine, but what it's running on.


des_a 07-01-2017 08:46 PM

The machine it's running on is actual hardware, running Windows 10. It is running in virtualBox, the propriatory version, I believe. It is running the latest version, as of starting the virtual machine's build. I can look up the version, if you need it.

On virtualbox, at the time of running the virtual machine and setting it up, there are these other virtual machines running:


vmain - The virtual main server - Mandriva Linux 2010.1
vwinxpsrv - The virtual Windows XP server server - Windows XP Proffesional
vwinxp - The virtual Windows XP server - Windows XP Proffessional

Now I'm trying to create vweb


vweb - The virtual web server - Mandriva Linux 2010.1
However, vweb won't let me install software in the proper mannor.

Is there for some reason some limitation about how many copies of Mandriva Linux 2010.1 you may run at a time? Let's now go over the legal perspectives as well, assuming that the software you run is mostly GPL, is there anything in the Mandriva Liscense I'm overlooking that says you can't do this? Assuming you conform to the rest of the GPL as well, of course. I didn't download the whole system twice, but was using the exact same copy to do this, the same copy of the software packages, and the same copy of the boot CD with it's same software. Is this perhaps why it will not work?

Each time I have ran into this problem, I was trying to use more than one copy at a time. The first, was when main1 was made of this software, and then I forget which server it was I tried to run on top, but it was the same one. The second now, is Windows 10 is underneath, but now there was one copy that worked okay, but now this one - the second, does not. It runs into this problem. Each time, there were two copies I was trying to run on the same machine at once. Is this why it fails? I know it's not exactly like Windows for the liscensing, and I'm not trying to do anything illegal on purpose.

I freely downloaded it free of charge when I did. I think it might even be all GPL software, but I'm not quite sure. I certainly didn't download from other third party sites or anything. I do not believe I'm really using anything from the non-free portion of the software at this point, but I do have the source enabled.

des_a 07-01-2017 08:46 PM

Please help me troubleshoot. This is indeed a strange problem...

AwesomeMachine 07-01-2017 10:27 PM

Normally when you add a source to the package manager, it is a hyperlink to some mirror. Are you telling me there is some program in Mandriva to build a local mirror? It must be urpmi specific. If it's not, it won't work.

The mirrors for different distros are different. A script that works on Debian to build a local mirror will not build a local mirror with any other distro. It sounds like the problem is within the local mirror and the way urpmi handles it.

I wouldn't worry too much about Mandriva's antipiracy measures. I'm sure there are none. It would only cause problems.

But I would worry about using Windows as a host OS for Linux-based virtual machines. No one really knows what Windows is actually doing!

des_a 07-01-2017 11:33 PM

I'm testing to see if it is a problem with the local mirror. It "shouldn't" be by this point. But I did have some technical issues while trying to rebuild the local mirror. So maybe that was the problem. Yes, there is a program made by Mandriva and also on Mageia to build local mirrors. It is called genhdlist2. There used to be one used called genhdlist, but that was depreciated sometime in the past. So now you use genhdlist2. That is the list of "hyperlinks" to the files in the mirror. There is also a program gendistrib, but I really don't know how to use that, and genhdlist2 is enough to make it work. Check out the man pages if you want to know more. It's installed with urpmi, I believe and is definitely part of it. I believe there is a program with the same name for debian based distributions, but it is appearently different under the hood. The problem is not the concept of what I'm doing, because it is a proven concept. But the problem may have been that the files that genhdlist2 makes got corrupted again. Like I said, I'm trying again to rebuild them, this time with the most verbosity possible, which I just learned how to do. We'll see if that works or not.

des_a 07-01-2017 11:41 PM

P.S. - I'd put Windows under it, when it had the same problem I'm having now before when Mandriva was on Mandriva.

des_a 07-02-2017 03:27 AM

I rebuilt the mirror again. Still the same problem. I wonder if bits that you use to build the mirror matter? I was rebuilding the mirror this time, with a 32-bit machine, and using it on a 64-bit machine. The verbosity told me that it was keeping every file it had, and then it finished and exited with a normal code and everything. But when I went to use it, it told me the same thing.

So it's possible, that bits do matter. But, I'm going to go ahead and remove the files for the source, and rebuild from scratch using the same machine I just did to build them, and rebuild them again. Then I'll see what happens. If that doesn't work, I could always build another 64-bit machine to do it with, since it keeps crashing to use the one I'm trying to install software on, at times (probably a RAM problem). Then I can try to do it again. I guess that's the only way I'd know if bits matter or not.

But if it doesn't work either of those two times, I'm out of ideas at that point, at what could be wrong, except for somehow going back to the virtual machine being the problem or something. If we know that before, Mandriva wasn't the problem, either time I've had the problem. Then the problem must be the virtual machine. The next question would be, what is the problem? Is it preventing me from running two copies of the same software or what?

des_a 07-02-2017 03:37 AM

Doing a google search:, I've found no other complaints at this time.

des_a 07-02-2017 12:29 PM

When I rebuilt the mirror with the 32-bit version, first deleting the other files, no difference.

des_a 07-02-2017 01:19 PM

I didn't test it with the rebuilt mirror for 64-bit yet, but I did test to see whether software would install on the 64-bit machine I created or not. It works. So it works on one machine on virtualbox on Windows 10, but not on the other machine on virtualbox on Windows 10. This isn't a RAM problem, is it? I did have to reduce both machine's RAM, but they seem to function okay. I believe I reduced the RAM to 256MB. But it could have been 128MB. If you want me to double check, I will. It seems to run okay as far as I can tell though. The underlying machine has 2GB RAM, I believe.

des_a 07-02-2017 07:37 PM

It's not the RAM. Both machines had 256MB of RAM. I tried to go up to the original 512MB I was giving the machine before (my host only has enough RAM to give one 512MB at a time, and when I get to 3 running, probably can't give any 512MB). I confirmed that the host machine has 2GB RAM. What else could be the problem?

des_a 07-02-2017 07:39 PM

P.S. - When both machines have 512MB RAM, and are both running with the other servers, the whole host machine is way too slow. I'm assuming that everything is actually OK, but it sure seems to swap a lot and therefore freezes.

des_a 07-02-2017 09:34 PM

This is my idea for fixing the problem:

des_a 07-07-2017 12:08 AM

I think my idea will work. But I'm stuck on something. I need a script that will use rpm, to get the filenames of packages required by a package. It should be done using the most primitive tools possible available to sh. Tools that I can depend on being installed on a primitive system. Nothing like grep or anything. That may not be installed for some reason.

The script should be called:


This should be it's usage statement, if the user does NOT give it a package file name:


softir {package}
(the space is significant and can be produced by echo without parameters)

With a package name, it should print to standard output, the filenames of the packages required by the package file name given. There should be no trailing lines before the output. There should be one blank line after the output.

Please help me come up with this script, and then I can tie it all together and see if this solution actually solves my problem or not.

astrogeek 07-07-2017 01:21 AM


Originally Posted by des_a (Post 5731760)
I think my idea will work. But I'm stuck on something. I need a script that will use rpm, to get the filenames of packages required by a package. It should be done using the most primitive tools possible available to sh. Tools that I can depend on being installed on a primitive system. Nothing like grep or anything. That may not be installed for some reason.

Please, again, read the LQ posting guidelines. While members are usually willing to put forth much effort to help, asking for others to write a script to meet your requirements is frowned upon.

In this case, you should be able to get the information you seek directly from rpm, no need for further scripting.


rpm -qp package-name.rpm --requires
That will give you the required package names and versions, the exact filenames may vary by source, version and maintainer.

Mandriva urpmi would provide similar query commands, but I do not have a Mandriva system to test on at this time, so I refer you to the rpm and urpmi man pages for details.

des_a 07-07-2017 01:15 PM


While members are usually willing to put forth much effort to help, asking for others to write a script to meet your requirements is frowned upon.
Sorry again. Sometimes it's hard to understand those guidelines in a certain situation.

Anyway, I'd gotten that far. Where I was stuck was making a file name out of it's output. Or at least being able to parse it in some meaningful way that would lead to a filename. The other choice is to be able to get a package name from a filename and use that to install it and for some internal stuff. But I don't know how to do that either right now.

des_a 07-07-2017 01:15 PM

I'll check out the man pages again though for the later, and come back if I'm still stuck and don't have a solution yet.

des_a 07-20-2017 07:27 PM

I got so far. But now it doesn't seem to have the dependencies figured out well enough. It told me on a particular package that it doesn't depend on anything. In reality it did, so when I tried to install the package, it failed. Should I make it so that packages have to have their dependencies managed manually? Or should I continue this route and fix it somehow? This route this is what is supposed to happen: All the dependencies and subdependencies are automatically calculated, and automatically installed, unless it's not available. If it's not available, print an error message of some sort. Please give me advice. If you think I should continue this route, I'll need to post all the current code for you.

des_a 07-20-2017 07:29 PM

P.S. - I think that when I am done I will have a working solution, and will not have to start again. I took care of the downloading and everything myself. I think that it is in the detecting of what can be downloaded or something like that that it was going wrong. It is probably indeed a bug in urpmi, and probably continues to this day, I'd guess.

des_a 07-20-2017 07:29 PM


des_a 07-23-2017 07:01 PM

I am thinking that this "bug" will only show up in virtual machines, so it could be the virtual machine's fault, possibly. However, my solution seems to work okay so far. I am on the "real" script to install the software now. I have to manually manage dependencies for now, so I need to run the script with each package, a line at a time, and find all the dependencies to include in them. I had bugs when installing from remote sources, for some reason, but I think I fixed all of those critical bugs now. But it wasn't the same bug or anything showing up that showed up origionally. The problem is definitely somewhere in the urpmi set of tools. Since "softi.p2f" doesn't completely work, I am using a number of ways to get the package name's file names. For now, that will work. When I get softi working, I will post a version here for you guys. I don't yet know of the legal ways to put things under the GPL or anything, or this would be a canidate. So consider it a development version for now, to be used anywhere to solve this same problem, but for no other uses. Modify it if necessary to solve this problem, but that's all. Use and/or modify it, but don't repost it or anything for this development version. But you can use it anywhere to solve this problem. Hopefully I've got the general idea right...

Anyway, I will post it for just such purposes. I will use it for it's "real" uses anywhere it helps in the scope of my network or expanding places, such as for friends and family who run into the same problem.

Just one more proper script to go and then if that works, and everything is installed, it works!

des_a 07-26-2017 02:39 PM

1 Attachment(s)
There are way too many dependencies to manually install them all. And since p2f doesn't completely work, I have to use other methods that require a human in order to find which package belongs to which file. And the requires output doesn't seem to be computer readable. Please help or provide another solution to this underlying problem.

Here is the code for softi.

des_a 07-26-2017 08:09 PM

A new version of Mageia just came out. I probably don't want to start over on the vmain server right now, but I may want to start over on vweb and try to use this new version. I will download it, and see if it has the same problem as version 5.1 had with it's GUI. Although, I may or may not actually want a GUI on this server. If I do, I will want a "light" one. I'd prefer to stick with LXDE for this. If it works, I'll rethink my structure and maybe keep the vmain server, but create a vmain2 server with Mageia Linux. Then I'd continue to create vweb. But maybe I don't need vmain2 right now at this time...

Anyway, vweb, I need for sure, so if Mageia 6 fixes this problem, I could use it. But I'll have to see if it does or not. I'll have to see if it even installs properly or not. Mageia 5.1 had a BIG GUI error, which I now see documented as a bug. It meant that it was a NO GO for me, as far as time to switch or not. If 6 doesn't have the bug, I can re-evaluate whether or not to use it. If the technology is good, I can use it, otherwise I can't.

By "technology", I mean from a user's point of view, in the configuration and use of the servers, having the servers I'm looking for and want to enable. I heard that some protocols were discontinued. Unfortunately, unless there is simply a reason NOT to do it, I really needed those enabled on my server. For vweb it should work just fine of course.

It's come a long way since I first tried out Mageia, that's for sure! But keep trying to work on a solution here, it may be the solution I need. I'm not sure one way or the other for sure...

des_a 07-26-2017 08:12 PM

By the way, the failure is in the download of the packages. As long as I download them myself, installing them should be a snap. I don't have the space to mirror the whole distribution locally, or I would. I need it to be done via ftp protocol. The problem I've been having, as I mentioned before, is the packages dependencies.

This is indeed a strange problem...

des_a 07-28-2017 08:00 PM

I tried the newest version of Mageia, and this is the first canidate that might work for me as a client. I'll hold off on working on it, until I get the servers finished and stuff, however.

I tried to simply "mount" the filesystem share onto /mnt/urpmi. Then I adjusted the /etc/fsab file to make it mount automatically. I then fixed the script to add media sources, to add local media sources.

I think I have had success, because it appears like I can now install sofware with urpmi. To be sure, I will have to reinstall the OS, and try to install from a fresh installation, by copying my solution. If that works, I solved the problem.

This is indeed a strange problem...

des_a 07-28-2017 08:01 PM

P.S. - I can't believe I didn't think to go this route before...

des_a 07-30-2017 05:02 AM

Indeed I had success. I ran into a RAM problem, that I fixed by kludging it... Anyway, the vweb server is now born and up and running!

See this link for the website on vweb (which is the main purpose of having vweb): See here for a GUI (click and point) to get there:

I now have it up and running! Yeah!

I am onto the web development portion now. The main work is done. No self-sign up at this point, but really at this point, that's OK. Appearently a site that is self sign up takes quite a bit of explaining to understand how to do. Perhaps there are premade packages you can aquire for this, but I don't want to go that route right now. The way I have done it is fine for now.

There is a note that running this OS in today's world CAN BE a security risk, but that's OK with me for now. My Google accounts had been hacked before and I fixed the problem. Google is a big target, and it was probably some random attack on Google. However, my network has not had such attacks before. Not that it couldn't happen, it's just probably too small a target. I expect it to get to be a bigger target over time, which is why I'll continue to learn about security.

But by the time I am such a target, I will probably know what I need to know about security. I just CAN'T completely secure older OSs, and I NEED older OSs to make it work, but I just have to have a good back up plan and security detection plan to cope with these type of attacks. Now if it happened every day at some point, I'd have to rethink my whole plan for being more independent. But it shouldn't happen until there are ways to cope with it, if you know what I mean. Perhaps the older technology will also become obsolete on my network as well by that time...

Certainly, I can "almost" upgrade to Mageia and redo all my Mandriva servers (the latest version of Mageia). However, the keyword is "almost". It's only "almost" ready for that. It has to do with it's changing technology and the fact that I need older technology to do what I want as far as servers are concerned, because less is possible with newer technology in this type of field. As far as I am capable of doing it, anyway.

For example: It appears that talk has been depreciated, and swat as well. I need those two for now to make it work. If I could "easily" get and configure these two and there would be no stability problems in the system, it "almost" might be worth a try. Why still almost? Because I really need to get to version "a" of my network. I haven't had such a complete version happen yet. But I've got a good roadmap to it at this point.

The issue is solved by using smb as the remote protocol and mounting it within the filesystem using fstab. Then you add local media sources for urpmi. softi was not needed after all, but wasn't a waste of time either. If someone could work on it with me, that'd be great, but we'll have to find somewhere else appropriate to work on it and it's low priority for me now. Not worth opening what would "now" be an appropriate programming thread for it.

I thought that it was appropriate before, but I guess I was wrong. However, please point me if you can to where I could appropriately ask questions about the LQ guidelines. A new thread or something like that would be a good way to go, unless there's some general thread already out there... But I don't want to purposely or accidently violate the guidelines by posting a new thread where "I" think is appropriate.

This "bug" appears to only be in virtual machines and only be in more than one machine running on the physical machine whether both are virtual or only one is. I don't think it's by design on Mandriva's part. I don't think I have violated the license by running the same copy more than once that I would need to try to fix. I would never intentionally violate it. I don't think I managed to violate virtual boxes license either. But perhaps virtual box was over zealous with it's protection against violating licenses? Beware for Mageia users, because I bet whatever issue it was, was NOT fixed yet. But unless I tried to test it, I couldn't be sure. But since there is no other documentation out there yet about this... So hopefully it helps others too. I do not think I'm violating any package's licenses, even if here and there I'm using a few non-free packages. They all give free re-distribution rights, which I believe is basically what I am doing by running multiple copies. No windows software was used via wine or anything... At least they present their licenses right out in front of you though. Something Linux is not very good at at this point. No wonder so many Linux users just try to stick to GPL or related licenses!

Thanks for all your help here, marking as solved. So if you want to reply more, do it now so it doesn't close on you. I can always re-open it if there are lots of replies, at least temporarily, but if it's closed, the best I can do is link to it, short of asking for administrative help. Anyway, thanks again!

This is a standard part of what to do when I get "stuck" on something, before I go to other things. Thanks again!

des_a 07-30-2017 05:06 AM

By the way, I'll say it one last time. The problem occurs when you download the files, and has to do with the way that's done. Download them yourself, and it works. Avoid downloading them with Internet protocols (FTP anyway), and it works just fine too.

This was indeed a strange problem, that almost appears like an unnecessary anti-piracy stunt...

All times are GMT -5. The time now is 09:38 PM.