[Solved] "net-tools" installation issues

AxisPraxis · 2016-09-18 22:47:22

Hi everyone, this is my first post here on the forums.

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.

I then did a proper reboot later that day, and typed ifconfig in bash, only this time, there was no output at all.

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.

So, if I went over to /usr/bin/ and deleted "arp" which is a part of net-tools, it would not reappear after running "sudo pacman -S net-tools"

For example, below is the output in bash after running "sudo pacman -S net-tools"

resolving dependencies...
looking for conflicting packages...

Packages (1) net-tools-1.60.20160710git-1

Total Installed Size:  0.46 MiB

:: Proceed with installation? [Y/n] y
(1/1) checking keys in keyring                     [######################] 100%
(1/1) checking package integrity                   [######################] 100%
(1/1) loading package files                        [######################] 100%
(1/1) checking for file conflicts                  [######################] 100%
error: failed to commit transaction (conflicting files)
net-tools: /usr/bin/ipmaddr exists in filesystem
net-tools: /usr/bin/iptunnel exists in filesystem
net-tools: /usr/bin/mii-tool exists in filesystem
net-tools: /usr/bin/nameif exists in filesystem
net-tools: /usr/bin/netstat exists in filesystem
net-tools: /usr/bin/plipconfig exists in filesystem
net-tools: /usr/bin/rarp exists in filesystem
net-tools: /usr/bin/route exists in filesystem
net-tools: /usr/bin/slattach exists in filesystem
net-tools: /usr/share/man/man5/ethers.5.gz exists in filesystem
net-tools: /usr/share/man/man8/arp.8.gz exists in filesystem
net-tools: /usr/share/man/man8/mii-tool.8.gz exists in filesystem
net-tools: /usr/share/man/man8/nameif.8.gz exists in filesystem
net-tools: /usr/share/man/man8/netstat.8.gz exists in filesystem
net-tools: /usr/share/man/man8/plipconfig.8.gz exists in filesystem
net-tools: /usr/share/man/man8/rarp.8.gz exists in filesystem
net-tools: /usr/share/man/man8/route.8.gz exists in filesystem
net-tools: /usr/share/man/man8/slattach.8.gz exists in filesystem
Errors occurred, no packages were upgraded.

It simply finds elements of net-tools that already exist in the filesystem, tells me no packages were upgraded, and does not install those that are missing, such as the "ifconfig" I deleted manually

pacman also wrote .gz archives to the filesystem of all the individual programs like so:

net-tools: /usr/share/man/man5/ethers.5.gz exists in filesystem

I get an unexpected end of file error when I tried to open the ifconfig .gz file, or any other .gz that was included with the installation of net-tools.

If I delete either the .gz file, or as I mentioned before, the program itself, it will not appear in my filesystem again if I use pacman to install net-tools.

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.

Any advice is appreaciated!

Last edited by AxisPraxis (2016-09-19 17:26:05)

WorMzy · 2016-09-18 22:57:33

Sounds like filesystem corruption to me. What filesystem are you using? Have you run fsck/check/scrub on it recently?

AxisPraxis · 2016-09-18 23:01:10

Using EXT4.

This is a fairly new installation.

I will run fsck/check/scrub and report back.

Last edited by AxisPraxis (2016-09-18 23:03:01)

WorMzy · 2016-09-18 23:46:56

You only need fsck; the other two are for different filesystems.

You should probably check the state of the disk too using smartctl.

AxisPraxis · 2016-09-18 23:56:55

WorMzy wrote:

Sounds like filesystem corruption to me. What filesystem are you using? Have you run fsck/check/scrub on it recently?

I think you're onto something...

Here is the output of running fsck on my current hard drive (sda1):

[root@arch]# fsck -t ext4  /dev/sda1/
fsck from util-linux 2.28
e2fsck 1.43.1 (08-Jun-2016)
fsck.ext4: Not a directory while trying to open /dev/sda1/

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

Not looking good... corruption might definely explain the issue.

I'll use DBAN and wipe it clean. The drive itself was taken from a surveillance system, and given to me for free, so I can't complain. I'll also take a look at the S.M.A.R.T. data (if it has it) on the drive to see if it's on its last leg.

Last edited by AxisPraxis (2016-09-19 00:30:02)

WorMzy · 2016-09-19 00:07:52

You've got an extra slash at the end of the device name. Try '/dev/sda1'.

Please also use code tags when posting terminal output, it makes it easier to read.

AxisPraxis · 2016-09-19 00:17:37

What a rookie mistake...

Don't need that extra slash there becase it isn't a directory, it's a device.

Anyway.

I ran the test with smartctl, and it passed the overall-health self-assessment.

Here is the right output from fsck, and it appears to come back without error.

[root@archbang ablive]# fsck -t ext4 /dev/sda1
fsck from util-linux 2.28
e2fsck 1.43.1 (08-Jun-2016)
/dev/sda1: clean, 86184/30531584 files, 2498204/122096390 blocks

WorMzy · 2016-09-19 00:31:36

fsck looks good, but I would try it again with the -f flag to force it to check the filesystem.

Another set of eyes looking over the smartctl output may help spot something you may have missed.

Is this an archbang install?

jasonwryan · 2016-09-19 00:38:12

AxisPraxis wrote:

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.

For the same reason that if you manually install a program with `make`, pacman knows nothing about it. Manually deleting the package doesn't update pacman's database, as far as pacman is concerned, the binary is still there.

AxisPraxis · 2016-09-19 00:45:18

I'm running these tests on an Archbang live CD, but the installation on the drive is Arch linux.

Here is the output from the smartctl test and fsck again using the -f and -t ext4 aruguments:

[root@archbang ablive]# sudo smartctl /dev/sda1
smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.6.4-1-ARCH] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

ATA device successfully opened

Use 'smartctl -a' (or '-x') to print SMART (and more) information

[root@archbang ablive]# smartctl --smart=on /dev/sda1
smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.6.4-1-ARCH] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF ENABLE/DISABLE COMMANDS SECTION ===
SMART Enabled.

[root@archbang ablive]# sudo smartctl -t short /dev/sda1
smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.6.4-1-ARCH] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Short self-test routine immediately in off-line mode".
Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 2 minutes for test to complete.
Test will complete after Sun Sep 18 06:11:09 2016

Use smartctl -X to abort test.

[root@archbang ablive]# sudo smartctl -H  /dev/sda1
smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.6.4-1-ARCH] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

[root@archbang ablive]# fsck -f -t ext4 /dev/sda1
fsck from util-linux 2.28
e2fsck 1.43.1 (08-Jun-2016)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda1: 86184/30531584 files (0.1% non-contiguous), 2498204/122096390 blocks
[root@archbang ablive]#

Last edited by AxisPraxis (2016-09-19 00:47:22)

WorMzy · 2016-09-19 01:02:00

The 'smartctl -a' output would be more useful, but it looks like the disk and filesystem are healthy.

On the install proper, can you check whether /var/lib/pacman/local/net-tools-1.60.20160710git-1 exists and if so, does it contain anything? (it should be a directory)

If it contains files, please run 'file /var/lib/pacman/local/net-tools-1.60.20160710git-1/*' and post the output.

AxisPraxis · 2016-09-19 04:36:10

jasonwryan wrote:

AxisPraxis wrote:
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.
For the same reason that if you manually install a program with `make`, pacman knows nothing about it. Manually deleting the package doesn't update pacman's database, as far as pacman is concerned, the binary is still there.

I didn't use the correct term. By package, I was actually referring to the various binaries included in that package(net-tools), such as rarp, ifconfig, iptunnel and so on. Sorry, that's my mistake.

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.

I've figured out a few things. After verifying all but one of the package's files had been manually deleted, and that there were no remaining database files that could cause problems, explicitly according to this site's pacman wiki page regarding installation errors, I ran

sudo pacman -S net-tools

and pacman found a single conflicting file, the one I purposely didn't delete.
Looks like:

packages (1) net-tools-1.60.20160710git-1

Total Installed Size:  0.46 MiB

:: Proceed with installation? [Y/n] y
(1/1) checking keys in keyring                     [######################] 100%
(1/1) checking package integrity                   [######################] 100%
(1/1) loading package files                        [######################] 100%
(1/1) checking for file conflicts                  [######################] 100%
error: failed to commit transaction (conflicting files)
net-tools: /usr/bin/ipmaddr exists in filesystem
Errors occurred, no packages were upgraded.

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

truncate -s 0 filename

to wipe the contents of a binary in another separate package, yet pacman didn't hesititate to write to that null file, returning it to its normal state when I ran

sudo pacman -S packagename

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.

After I deleted that last file, and installed net-tools again, all the binaries run as they should.

Yes, simply deleting all the files would have solved my problem and I could have immediately moved on, but I wanted to get to the bottom of this.

To prove something funny was going on here, I recreated the dysfuntional conditions on my now working installation of net-tools.

I ouright deleted the binary ifconfig, and used

truncate -s 0 impaddr

to make the binary impaddr completely null, and don't forget that a null impaddr binary file is the exact same file pacman previous claimed was conflicting. I then ran

pacman -S net-tools

and both binaries were restored to their working state, without a single error. Yet before, I had that single null binary file, zero bytes, called "impaddr" which is the sole one I left undeleted, and yet pacman detected it as a conflict, and also refused to write any other files without giving any reason, when in both instances both of the files were of the same name, and exact same value, null, zero bytes. That is what makes me think it was some sort of a symlink or hard link issue between files. Anyway now not only did it write the missing file from the package, it wrote the correct information the null binary file that I wiped clean. Pretty funky stuff if you ask me.

Anyway, that's my theory. Most importantly, my problem is fixed!

Last edited by AxisPraxis (2016-09-19 04:41:08)

Mr Green · 2016-09-19 06:21:43

Random idea

pacman -Qo /usr/bin/ipmaddr

ayekat · 2016-09-19 06:54:35

AxisPraxis wrote:

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.

No, this all makes sense, 100%. If any file conflicts, pacman will not install the package. "Conflict" means: the file in question already exists in the file system (regardless of whether the file is equal, or null, or whatever). Pacman doesn't care whether it's 1 or 100 files, because you wouldn't want pacman to "half-install" a package.

The real issue is that we don't know how the binaries have been installed in the first place (i.e. before you created this thread). The behaviour you have described matches consistently what would happen if you installed something without pacman.

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.

Also, tip: you can use -Qi to check whether a package is installed, you don't need to -R it :-)

WorMzy · 2016-09-19 10:05:32

The only other way I can see this sort of situation arising is if the PC lost power before the buffers were flushed to the disk. This could've been due to a power cut, or a hard-shutdown. The 'smartctl -a' output still would be good to see.

Anyway, please remember to mark your thread as solved by editing your first post and amending the topic title.

AxisPraxis · 2016-09-19 19:59:23

ayekat wrote:

AxisPraxis wrote:
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.
No, this all makes sense, 100%. If any file conflicts, pacman will not install the package. "Conflict" means: the file in question already exists in the file system (regardless of whether the file is equal, or null, or whatever). Pacman doesn't care whether it's 1 or 100 files, because you wouldn't want pacman to "half-install" a package.
The real issue is that we don't know how the binaries have been installed in the first place (i.e. before you created this thread). The behaviour you have described matches consistently what would happen if you installed something without pacman.
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.
Also, tip: you can use -Qi to check whether a package is installed, you don't need to -R it :-)

I definitely agree that at the end of the day, the real cause was most likely a disk issue that corrupted the binaries and .gz files in the package, and maybe pacman's database as well.

I should also say all this is just my attempt to fully and completely understand what pacman does, how it works, and the nature of this problem. After glancing throught the documentation on pacman, I became aware very quickly that deleting all the files would undoutedly solve the problem. But I wanted to investigate.

I used pacman to install the package originally. I really don't think the install was not problematic, some other independent thing happend, corrupting all the files of the package.

I think I'm starting to understand how pacman works, but I still have a few questions

As I mentioned in the post you quoted, In my little experiment I verified that there were no net-tools entires in either of pacman's databases, so corruption in the database would have played a role at that point, as there wasn't anything regarding the package in either database.

Yes, pacman finding a conflicting file, and refusing to overwrite is a design feature.

But:

AxisPraxis wrote:

To prove something funny was going on here, I recreated the dysfuntional conditions on my now working installation of net-tools.
I ouright deleted the binary ifconfig, and used
truncate -s 0 impaddr
to make the binary impaddr completely null, and don't forget that a null impaddr binary file is the exact same file pacman previous claimed was conflicting. I then ran
pacman -S net-tools
and both binaries were restored to their working state, without a single error. Yet before, I had that single null binary file, zero bytes, called "impaddr" which is the sole one I left undeleted, and pacman detected it as a conflict, and also refused to write any other files without giving any reason, when in both instances both of the files were of the same name, and exact same value, null, zero bytes. That is what makes me think it was some sort of a symlink or hard link issue between files. Anyway now not only did it write the missing file from the package, it wrote the correct information the null binary file that I wiped clean.

As I mentioned in the above quote, not only did pacman replace the file I purposely deleted, it wrote the correct information to the binary I wiped clean.

Here is my question, why did pacman determine one of two identical files as a conflict? It found one null "impaddr' binary to be in conflict, and in my second test it decided to "fix" it, and write the other missing binary to the file system.

sudo pacman -S net-tools, then something like:

A)
first binary file missing (pacman does nothing)
second binary file missing (pacman does nothing)
third binary file (the null impaddr binary) (pacman finds a conflict and refuses to install)
B)
first binary file exists (Not sure whether pacman leaves it untouched, or decides to reinstall it regardless, either way the end result leaves a funtioning binary file)
second binary does not exist (pacman installs it)
third binary (impaddr) exists, but was made null by my bash command (pacman still reinstalls it)

The third binary file in both examples A and B were identical, but pacman decided one of them was a file conflict. Why? If the package exists in the database, pacman might attempt to reinstall it, as in example B. But, if there were no database files present in the case of example A, why would the end error be a failure to update? Maybe it's just how the term is used, compared to the actual context of what the program is actually doing that has me confused.

Like so:

net-tools: /usr/bin/ipmaddr exists in filesystem
Errors occurred, no packages were upgraded.

As I said, no net-tools database files were present at that time, so I'm guessing something outside that database told pacman this package exists on the system, therefore I will try to upgrade it. I make the argument that pacman thought it was installed only on the basis of the existence of what it thought was a conflicting file (Remeber later it also said a completely indentical file was not in conflict) but because the database didn't reflect any installed package called "net-tools," it did not have the same result as example B.

I guess that's just the way pacman works. I think now that my problem is solved, it's on me figure out how pacman works more fundamentally.

TheChickenMan · 2016-09-19 23:37:01

Before pacman unpacks a package it checks to see what's in there and if it will conflict with anything that are already in those locations on the filesystem. If there are any conflicts it aborts the install. If these files come from a package correctly installed by pacman then they will be listed in pacman's watched files database and pacman will know which package installed owns the files. It will not let another package overwrite the files but it will let a package of the same name install over the files, else upgrades and reinstalls would not be possible.

ayekat · 2016-09-20 07:06:30

I feel like there is still some confusion about what "installed" means (although, there is quite a wall of text there, so maybe I just got it wrong):

"Installed" means: the package is marked as "Installed" in the pacman database. The files in the file system do not matter. If /usr/bin/ifconfig exists (no matter in what state), this doesn't tell us anything about the state of the package.
In your description, it is often not clear to me whether you are acting on an installed or not installed package, because that difference is important:

Installing packages

If package xyz is installed, and you modify/delete a file in the filesystem that belongs to xyz, running `pacman -S xyz` will overwrite/recreate the file.
If package xyz is not installed, and you create a file in the filesystem (no matter whether empty or not) that would belong to xyz, running `pacman -S xyz` will detect a conflict and abort.

Removing packages

If package xyz is installed, running `pacman -R xyz` will uninstall the package and delete all its files in the filesystem, regardless of whether some have been modified or deleted.
If package xyz is not installed, running `pacman -R xyz` will not do anything.

Arch Linux

#1 2016-09-18 22:47:22

[Solved] "net-tools" installation issues

#2 2016-09-18 22:57:33

Re: [Solved] "net-tools" installation issues

#3 2016-09-18 23:01:10

Re: [Solved] "net-tools" installation issues

#4 2016-09-18 23:46:56

Re: [Solved] "net-tools" installation issues

#5 2016-09-18 23:56:55

Re: [Solved] "net-tools" installation issues

#6 2016-09-19 00:07:52

Re: [Solved] "net-tools" installation issues

#7 2016-09-19 00:17:37

Re: [Solved] "net-tools" installation issues

#8 2016-09-19 00:31:36

Re: [Solved] "net-tools" installation issues

#9 2016-09-19 00:38:12

Re: [Solved] "net-tools" installation issues

#10 2016-09-19 00:45:18

Re: [Solved] "net-tools" installation issues

#11 2016-09-19 01:02:00

Re: [Solved] "net-tools" installation issues

#12 2016-09-19 04:36:10

Re: [Solved] "net-tools" installation issues

#13 2016-09-19 06:21:43

Re: [Solved] "net-tools" installation issues

#14 2016-09-19 06:54:35

Re: [Solved] "net-tools" installation issues

#15 2016-09-19 10:05:32

Re: [Solved] "net-tools" installation issues

#16 2016-09-19 19:59:23

Re: [Solved] "net-tools" installation issues

#17 2016-09-19 23:37:01

Re: [Solved] "net-tools" installation issues

#18 2016-09-20 07:06:30

Re: [Solved] "net-tools" installation issues

Board footer