Net-tools Linux ((FREE)) Download
Jerry Bradley
I've always like using rarp, ifconfig, arp, iptunnel ectera for managing my network. I found out that these packages are available in Arch by installing the "net-tools" package. So I used pacman to install it, and typed "ifconfig" in bash and there appeared the expected outputed information about my network device.
At first, I figured it was a problem with ifconfig, so I navigated to /usr/bin/ then used rm to remove ifconfig, and used pacman to install net-tools again, which is supposed to include ifconfig. But what I don't understand is why after manually deleting a package included in net-tools such as I did with ifconfig, it would no longer be included when I installed net-tools again using pacman.
But oddly, even before deleting or reinstalling any packages/programs, I also found that every single program included in net-tools would accept no arguments, and display no output when I attempted to run them, however as I mentioned before, ifconfig and others did fucntion before I rebooted. Maybe I goofed when I deleted ifconfig, or used the wrong pacman arguments, but I don't understand why these programs simply stopped fuctioning completely.
pacman now also tells me when I run "sudo pacman -R net-tools" or "sudo pacman -Rs net-tools" or if I use any other removal arugments, that it cannot find that package. This baffles me because the bash output I pasted earlier in the post clearly says "no packages were upgraded" and upraded implies the modifiication of an existing package on my system, not one that is newly installed.
Basically, funtioning, then mysteriously non-functioning package after reboot, and the inabillity to uninstall or properly reinstall this package again using pacman. Also, running "pacman -Sg net-tools" returns nothing, therefore it's not a group and I cannot select any individual elements.
I have a 2 theories, that I'm not using the correct pacman arugments to install/unintall a problematic package completely, and that the reason net-tools isn't working correctly is that my system is running another conflicting program/programs to manage my connections and network harware, and that's the reason something like ifconfig wasn't working. But even still, I can't seem to get ifconfig and friends back on my system at all! Maybe I could find a mirror that has the lone packages such as "ifconfig" and "arp" that I want, but I still want to understand why pacman wouldn't install any of part of net-tools that I manually deleted. I'm sure it's a simple and silly mistake I've made.
Anyway, I went ahead and manually deleted all but one of the binaries included in net-tools, as well as the .gz files located in /usr/share/man/man8 and /usr/share/man5, which according to the source is where all the files associated with that package reside or should reside. I'll explain why I left a single file behind later on.
I made sure of two things, that net-tools is not present in either of pacman's databases. net-tools is part of the core repository, and I verified net-tools wasn't in either the sync, nor the local database where pacman stores metadata about packages that have been installed. I didn't delete anything, there was simply nothing pertaining to net-tools in either database.
However, it did not write any files to the file system at all, because it found a single conlict. Most strikingly, the output from pacman didn't even mention the other files in the package. Yes, pacman doesn't replace conflicting files in packages by design, and it's reccomended that you simply delete a conflicting file, yet later on I will show that what pacman found as a file conflict in one instance, it did not in another, regarding two completely null (thus identical) binaries.The documentation didn't mention anything about also not writing files that are not conflicting simply because of a single and completely separate file conflict. It didn't explain why the other binaries and archives weren't written to the file system. It doesn't make any sense, because pacman still returned "Error: no new packages upgraded, yet still claimed no package called "net-tools" was present when I tried removing it using -R with pacman, which essentially says this package exists on the system, but I couldn't upgrade it because of a problem, but also then when asked to remove that package, it supposedly does not exist on the system. One output implies it exists, as upgrade impiles a modification of an existing thing, the other claims it doesn't exist at all, all outputed from the same program.
When I looked at the binary I purposely left behind, it was 0 bytes. Null. I think this is what caused the problem, that for some strange reason, all the net-tools binaries became corrupted, and all the files left completely null, which would really be only explanation of the lack of any output, not even an error when I tried to run them.
The only conclusion I can come to is that because pacman's metadata and database entries for the packages existed, while the files themselves were null, (who knows why it happened) and when I ran "sudo pacman -R net-tools" the first time, those database entries and metadata was removed, but since the files to be deleted were essentially null, I originally thought maybe that pacman would detect a null file as a conflict if it was referenced by the same name and sym/hard link, but that's not the case; because I used
It also didn't hesitate to remove a null binary file of a different package using "pacman -R" but in the case of net-tools, accroding to the database, net-tools wasn't on the system and therefore could not be deleted. But this still does not explain why even if all the net-tools files were corrupt, or null, that pacman didn't remove them the first time using the -R argument.
I think what happened is that some elements of symbolic link structure of the package was preserved by that single file that I didn't delete, (as an experiment to get to the bottom of this problem) which led pacman to try to upgrade it, but it didn't know how to interpret the conflicting information. The database said net-tools wasn't there, but something else said it was, but it didn't return a file conflict error for all but one file, and no other errors for that matter beyond the one conflict, and most importantly pacman didn't try to write those missing files. pacman should have either found an error pertaining to those specific files it chose not to write, or written them to the file system. One thing I'm pretty certain of, is that there isn't an exeption in pacman's logic to handle what happened. pacman only gave a reason for choosing not to write only one of the files in my experiment, not any others.
However, it did not write any files to the file system at all, because it found a single conlict. Most strikingly, the output from pacman didn't even mention the other files in the package. Yes, pacman doesn't replace conflicting files in packages by design, and it's reccomended that you simply delete a conflicting file, yet later on I will show that what pacman found as a file conflict in one instance, it did not in another, regarding two completely null (thus identical) binaries.The documentation didn't mention anything about also not writing files that are not conflicting simply because of a single and completely separate file conflict. It didn't explain why the other binaries and archives weren't written to the file system. It doesn't make any sense, because pacman still returned "Error: no new packages upgraded, yet still claimed no package called "net-tools" was present when I tried removing it using -R with pacman, which essentially says this package exists on the system, but I couldn't upgrade it because of a problem, but also then when asked to remove that package, it supposedly does not exist on the system. One output implies it exists, as upgrade impiles a modification of an existing thing, the other claims it doesn't exist at all, all outputed from the same program.
However, if you have really installed net-tools with pacman in the first place, then the only explanation that makes sense to us would be a corruption in the pacman database (i.e. pacman didn't consider the net-tools package to be installed, even though it should have). And in that case, WorMzy's theory of a database/disk/I/O issue is the only valid one I can see. I can see no system misbehaviour in the rest.
df19127ead