-   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:

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