Finding device base address to communicate via inb() and outb() - linux-device-driver

I am trying to communicate with a disk drive using inb(), inw(), outb() and outw() commands so I can find specific information about the drive. However, to use these commands, I need the correct I/O ports for the device. When I have the correct I/O ports, I can find the information I am looking for very easily, however, I do not know a way to find the base address of a device's I/O ports in Linux.
In DOS, I am able to use Hdat2 to find the device's base address, however, I am trying to find the address in Linux. Is there a way to find which device maps to which I/O port in Linux?
There is a file in /proc called ioports that contains some information but I don't how to associate this information with specific devices.
Any help would be greatly appreciated. Thanks!

So I did find something, although it isn't the most elegant solution and it definitely doesn't work everywhere, it has worked on my hardware so I figured I would share.
First, you have to get the address of the SATA Controller from the lspci command like Nikolai showed (the -D just shows the full domain numbers):
# lspci -D
...
0000:00:1f.2 SATA controller: Intel Corporation 82801IR 6 port SATA AHCI Controller
...
Now with this address (0000:00:1f.2) you can go into /sys.
In /sys/bus/pci/devices, your device should be listed:
# ls -l /sys/bus/pci/devices
...
lrwxrwxrwx 1 root root 0 Jan 14 12:35 0000:00:1f.2 -> ../../../devices/pci0000:00/0000:00:1f.2
Now in this directory there will be several hostX directories.
# ls -l /sys/bus/pci/devices/0000\:00\:1f.2/
...
drwxr-xr-x 4 root root 0 Jan 13 12:40 host0
drwxr-xr-x 4 root root 0 Jan 13 12:40 host1
drwxr-xr-x 3 root root 0 Jan 13 12:40 host2
drwxr-xr-x 3 root root 0 Jan 13 12:40 host3
drwxr-xr-x 3 root root 0 Jan 13 12:40 host4
drwxr-xr-x 4 root root 0 Jan 14 08:21 host5
...
In one of these hostX directories, there will be a targetX:X:X directory. This targetX:X:X directory will then have a directory called X:X:X:X (the X's are numbers that can vary).
# ls -R /sys/bus/pci/devices/0000\:00\:1f.2/host0
/sys/bus/pci/devices/0000:00:1f.2/host0:
power scsi_host:host0 target0:0:0 uevent
/sys/bus/pci/devices/0000:00:1f.2/host0/target0:0:0:
0:0:0:0 power uevent
...
In the X:X:X:X directory, there is a link named "block:sdX" (where X is a letter). This sdX is the name of the drive that this directory corresponds to.
# ls -l /sys/bus/pci/devices/0000\:00\:1f.2/host0/target0\:0\:0/0\:0\:0\:0/
lrwxrwxrwx 1 root root 0 Jan 14 15:01 block:sda -> ../../../../../../block/sda
So /dev/sda corresponds to host 0 on the SATA Controller at 0000:00:1f.2. Now to find the address that we can use to talk to /dev/sda through inb() and outb() commands, we look in the file named "resource" in /sys/bus/pci/devices/0000:00:1f.2/.
# cat /sys/bus/pci/devices/0000\:00\:1f.2/resource
0x000000000000fe00 0x000000000000fe07 0x0000000000000101
0x000000000000fe10 0x000000000000fe13 0x0000000000000101
0x000000000000fe20 0x000000000000fe27 0x0000000000000101
0x000000000000fe30 0x000000000000fe33 0x0000000000000101
0x000000000000fec0 0x000000000000fedf 0x0000000000000101
0x00000000ff970000 0x00000000ff9707ff 0x0000000000000200
0x0000000000000000 0x0000000000000000 0x0000000000000000
The address we are looking for is fe00, which is on the first line. We want the first line because it is host 0, if it were host 1, we would look on the second line, and host 2 the third line, and so on. The host number was given by the hostX directory that we found earlier. Each line in the resource file is separated into 3 columns:
Column 1 = beginning address
Column 2 = end address
Column 3 = flags
So this is how I get from /dev/sda to 0xfe00 in order to send commands to the device.
If anybody know any better way to do this, I am all ears...

The device is most probably hanging off of the PCI bus, so lspci(8) is the first to look at. Then figure out where under /sys the controller is described. Here, for example, I have:
~$ lspci
...
03:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04)
...
~$ ll /sys/bus/pci/devices/0000\:03\:00.0/
total 0
drwxr-xr-x 4 root root 0 Dec 16 11:57 ./
drwxr-xr-x 6 root root 0 Dec 16 11:57 ../
-rw-r--r-- 1 root root 4096 Dec 16 11:57 broken_parity_status
lrwxrwxrwx 1 root root 0 Dec 16 11:57 bus -> ../../../../bus/pci/
-r--r--r-- 1 root root 4096 Dec 16 11:57 class
-rw-r--r-- 1 root root 4096 Dec 16 11:57 config
-r--r--r-- 1 root root 4096 Dec 16 11:57 device
lrwxrwxrwx 1 root root 0 Dec 16 11:57 driver -> ../../../../bus/pci/drivers/megaraid_sas/
-rw------- 1 root root 4096 Dec 16 11:57 enable
drwxr-xr-x 5 root root 0 Dec 16 11:57 host0/
-r--r--r-- 1 root root 4096 Dec 16 11:57 irq
-r--r--r-- 1 root root 4096 Dec 16 11:57 local_cpus
-r--r--r-- 1 root root 4096 Dec 16 11:57 modalias
-r--r--r-- 1 root root 4096 Dec 16 11:57 pools
drwxr-xr-x 2 root root 0 Dec 16 11:57 power/
-r--r--r-- 1 root root 4096 Dec 16 11:57 resource
-rw------- 1 root root 262144 Dec 16 11:57 resource0
-rw------- 1 root root 256 Dec 16 11:57 resource2
-rw------- 1 root root 262144 Dec 16 11:57 resource3
-r-------- 1 root root 32768 Dec 16 11:57 rom
lrwxrwxrwx 1 root root 0 Dec 16 11:57 subsystem -> ../../../../bus/pci/
-r--r--r-- 1 root root 4096 Dec 16 11:57 subsystem_device
-r--r--r-- 1 root root 4096 Dec 16 11:57 subsystem_vendor
--w------- 1 root root 4096 Dec 16 11:57 uevent
-r--r--r-- 1 root root 4096 Dec 16 11:57 vendor
This shows controller's PCI configuration space. See the details in Linux Device Drivers, Third Edition. Chapter 12: PCI Drivers.
Edit:
Take a look into this partition and mass-storage naming howto for help on Linux drive naming.

Are you accessing hardware from a userspace program or from a kernel module?
If you're doing it from userspace, the reason it's hard to find physical address information is that nobody accesses hardware that way; anything that needs to touch raw hardware lives in the kernel.
If you're writing a kernel module, you get address information from in-kernel structures, not by accessing /sys/...

The path seems have chanced in kernel 3.10, this is how I find the corresponding device node:
$ ls -l /sys/bus/pci/devices/0000\:00\:1f.2/ata1/host0/target0\:0\:0/0\:0\:0\:0/block/
total 0
drwxr-xr-x 10 root root 0 Oct 17 08:35 sda
$ ls -l /sys/bus/pci/devices/0000\:00\:1f.2/ata2/host1/target1\:0\:0/1\:0\:0\:0/block/
total 0
drwxr-xr-x 9 root root 0 Oct 17 08:35 sdb

Related

`mkdir` returns successfully but doesn't work in kubernetes (minikube) shared volume

I am trying to set up a shared volume in a minikube Kubernetes cluster to allow multiple pods to communicate with each other. What is configured is:
A PVC using the nfs-server-provisioner dynamic provisioner
Multiple Pods (some are jobs) that mount the PVC
The goal is to have an init container in each pod that creates a directory on startup using the Pod's name as the directory name, and have a job scan that directory and do some stuff.
I have this configured, and no errors are thrown, but the directory isn't created.
When trying to do this manually I see some strange behavior; mkdir returns a non-error code but doesn't do anything:
< ssh into pod >
user#802542b3ccb195b001258094dc543606-1601299620-zcszs:~$ ls -al /output/
total 8
drwxrwxrwx 2 user users 4096 Sep 28 13:28 .
drwxr-xr-x 1 root root 4096 Sep 28 13:27 ..
user#802542b3ccb195b001258094dc543606-1601299620-zcszs:~$ mkdir /output/test
user#802542b3ccb195b001258094dc543606-1601299620-zcszs:~$ echo $#
0
user#802542b3ccb195b001258094dc543606-1601299620-zcszs:~$ ls -al /output/
total 8
drwxrwxrwx 2 user users 4096 Sep 28 13:28 .
drwxr-xr-x 1 root root 4096 Sep 28 13:27 ..
user#802542b3ccb195b001258094dc543606-1601299620-zcszs:~$
I am able to touch files:
user#802542b3ccb195b001258094dc543606-1601299740-bw2hj:~$ ls -al /output/
total 8
drwxrwxrwx 2 user users 4096 Sep 28 13:29 .
drwxr-xr-x 1 root root 4096 Sep 28 13:29 ..
user#802542b3ccb195b001258094dc543606-1601299740-bw2hj:~$ touch /output/test
user#802542b3ccb195b001258094dc543606-1601299740-bw2hj:~$ ls -al /output/
total 8
drwxrwxrwx 2 user users 4096 Sep 28 13:29 .
drwxr-xr-x 1 root root 4096 Sep 28 13:29 ..
-rw-r--r-- 1 user users 0 Sep 28 13:29 test
user#802542b3ccb195b001258094dc543606-1601299740-bw2hj:~$
Here is the nfs mount:
Filesystem Size Used Avail Use% Mounted on
10.110.46.205:/export/pvc-2e433dc6-018d-11eb-be1a-0242766f1f7c 252G 134G 107G 56% /output
The same behavior is observed when using regular volumes. I am using the Docker driver but also observed this with the virtualbox driver. Is this a minikube issue? I would expect mkdir to error out if it can't complete.
minikube version: v1.13.1
commit: 1fd1f67f338cbab4b3e5a6e4c71c551f522ca138-dirty

Why do I see different files in Visual Studio Code terminal and Linux terminal?

I noticed that a lot of commands were missing when using VSCode terminal. So I tried a ls -l / on both my distro's and VSCode's terminals.
Linux Mint Xfce Terminal:
livy#linux-mint:~$ ls -l /
total 2097252
drwxr-xr-x 2 root root 4096 Aug 13 15:13 bin
drwxr-xr-x 4 root root 4096 Aug 13 15:15 boot
drwxr-xr-x 2 root root 4096 Aug 13 15:06 cdrom
drwxr-xr-x 20 root root 4260 Aug 15 08:40 dev
drwxr-xr-x 147 root root 12288 Aug 13 16:46 etc
drwxr-xr-x 4 root root 4096 Aug 13 15:06 home
lrwxrwxrwx 1 root root 33 Aug 13 15:07 initrd.img -> boot/initrd.img-4.15.0-54-generic
lrwxrwxrwx 1 root root 33 Aug 13 15:04 initrd.img.old -> boot/initrd.img-4.15.0-54-generic
drwxr-xr-x 23 root root 4096 Aug 13 15:07 lib
drwxr-xr-x 2 root root 4096 Jul 29 19:15 lib64
drwx------ 2 root root 16384 Aug 13 14:59 lost+found
drwxr-xr-x 2 root root 4096 Jul 29 19:14 media
drwxr-xr-x 2 root root 4096 Jul 29 19:14 mnt
drwxr-xr-x 3 root root 4096 Aug 13 15:18 opt
dr-xr-xr-x 214 root root 0 Aug 15 08:40 proc
drwx------ 4 root root 4096 Aug 13 15:07 root
drwxr-xr-x 32 root root 940 Aug 15 08:41 run
drwxr-xr-x 2 root root 12288 Aug 13 15:14 sbin
drwxr-xr-x 2 root root 4096 Jul 29 19:14 srv
-rw------- 1 root root 2147483648 Aug 15 08:40 swapfile
dr-xr-xr-x 13 root root 0 Aug 15 09:31 sys
drwxrwxrwt 15 root root 4096 Aug 15 08:53 tmp
drwxr-xr-x 11 root root 4096 Jul 29 19:14 usr
drwxr-xr-x 11 root root 4096 Jul 29 19:50 var
lrwxrwxrwx 1 root root 30 Aug 13 15:07 vmlinuz -> boot/vmlinuz-4.15.0-54-generic
And here is the result from VSCode terminal:
livy#linux-mint:~$ ls -l /
total 2097204
drwxr-xr-x 6 nfsnobody nfsnobody 4096 Aug 13 16:00 app
lrwxrwxrwx 1 livy livy 7 Aug 15 09:13 bin -> usr/bin
drwxr-xr-x 2 livy livy 80 Aug 15 09:13 boot
drwxr-xr-x 2 nfsnobody nfsnobody 4096 Aug 13 15:06 cdrom
drwxr-xr-x 5 livy livy 340 Aug 15 09:13 dev
drwxr-xr-x 15 livy livy 860 Aug 15 09:13 etc
drwxr-xr-x 4 nfsnobody nfsnobody 4096 Aug 13 15:06 home
lrwxrwxrwx 1 livy livy 33 Aug 15 09:13 initrd.img -> boot/initrd.img-4.15.0-54-generic
lrwxrwxrwx 1 livy livy 33 Aug 15 09:13 initrd.img.old -> boot/initrd.img-4.15.0-54-generic
lrwxrwxrwx 1 livy livy 7 Aug 15 09:13 lib -> usr/lib
lrwxrwxrwx 1 livy livy 9 Aug 15 09:13 lib64 -> usr/lib64
drwx------ 2 nfsnobody nfsnobody 16384 Aug 13 14:59 lost+found
drwxr-xr-x 2 nfsnobody nfsnobody 4096 Jul 29 19:14 media
drwxr-xr-x 2 nfsnobody nfsnobody 4096 Jul 29 19:14 mnt
drwxr-xr-x 3 nfsnobody nfsnobody 4096 Aug 13 15:18 opt
dr-xr-xr-x 209 nfsnobody nfsnobody 0 Aug 15 09:13 proc
drwxr-xr-x 6 livy livy 160 Aug 15 09:13 run
lrwxrwxrwx 1 livy livy 8 Aug 15 09:13 sbin -> usr/sbin
drwxr-xr-x 2 nfsnobody nfsnobody 4096 Jul 29 19:14 srv
-rw------- 1 nfsnobody nfsnobody 2147483648 Aug 15 08:40 swapfile
drwxr-xr-x 7 livy livy 140 Aug 15 09:13 sys
drwxr-xr-x 4 livy livy 80 Aug 15 09:13 tmp
drwxr-xr-x 12 nfsnobody nfsnobody 4096 Aug 13 16:00 usr
drwxr-xr-x 7 livy livy 160 Aug 15 09:13 var
lrwxrwxrwx 1 livy livy 30 Aug 15 09:13 vmlinuz -> boot/vmlinuz-4.15.0-54-generic
From the file owners, permissions, and modification date... it looks like they are working on different file systems. VSCode's /bin even points to /usr/bin, while it is not the case in Xfce terminal. The strange thing is that I can still use VSCode's terminal to navigate my home directory (/home/livy) and make changes to files. It even sources the content of my ~/.bashrc file.
What I am missing here?
I was having this exact same issue and discovered that the cause was that VSCode was installed as a Flatpak package. Uninstall it (be it a snap or a Flatpak package) and install the .deb file distributed by Microsoft.

How to upgrade zookeeper from from 3.4.8 to 3.4.13?

I am trying to upgrade zookeeper from 3.4.8 to 3.4.13.
Before upgrade the content of /usr/lib/zookeeper
drwxr-xr-x 5 root root 4.0K Aug 23 08:39 .
drwxr-xr-x 77 root root 12K Aug 23 08:50 ..
drwxr-xr-x 2 root root 4.0K Aug 23 08:39 bin
lrwxrwxrwx 1 root root 19 May 24 11:25 conf -> /etc/zookeeper/conf
drwxr-xr-x 2 root root 4.0K Aug 23 08:39 lib
-rw-r--r-- 1 root root 12K May 24 11:25 LICENSE.txt
-rw-r--r-- 1 root root 170 May 24 11:25 NOTICE.txt
-rw-r--r-- 1 root root 1.3M Aug 23 08:39 zookeeper-3.4.8.jar
lrwxrwxrwx 1 root root 38 Aug 23 08:39 zookeeper.jar -> /usr/lib/zookeeper/zookeeper-3.4.8.jar
As mentioned in answer I have downloaded the zookeeper from this link and placed the zookeeper-3.4.13.jar in /usr/lib/zookeeper and pointed the symbolic link like below
lrwxrwxrwx 1 root root 39 Aug 30 03:19 zookeeper.jar -> /usr/lib/zookeeper/zookeeper-3.4.13.jar
But on checking the status after resarting zookeeper it is still pointing to 3.4.8
ubuntu#vrni-platform:/etc/zookeeper/conf$ telnet localhost 2181
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
status
Zookeeper version: 3.4.8--1, built on 02/06/2016 03:18 GMT
It appears this is because of the way the jars are loaded from /usr/lib/zookeeper/bin/zkEnv.sh
#release tarball format
for i in "$ZOOBINDIR"/../zookeeper-*.jar
do
CLASSPATH="$i:$CLASSPATH"
done
Can someone let me know is this some known issue is zkEnv.sh? Is this expected?
This has been answered in zookeeper mailing list. We should not have multiple zookeeper-<version>.jar in the CLASSPATH.

WAL-E: Cannot restart postgresql after backup-fetch

This is on Ubuntu 14.04 LTS
EDIT:
WAL-E installed using pip, with secret keys managed by envdir, according to the instructions https://gist.github.com/elithrar/8682235 and https://github.com/wal-e/wal-e#dependencies.
I am trying to restore a database using WAL-E, and everything appears to go well initially, as I have Postgres installed and running, and can easily create or restore a database and access it locally and remotely via pgadmin. Where it goes bad is when I try to perform a restore from an S3 backup using wal-e fetch-backup. It appears to go well up until the point of starting the postgres.
There are a number of errors that come up, appearing to be either missing packages or permissions issues, like the following:
* Starting PostgreSQL 9.3 database server
* The PostgreSQL server failed to start. Please check the log output:
2015-07-11 00:41:11 EDT LOG: database system was interrupted; last known up at 2015-06-30 05:00:02 EDT
2015-07-11 00:41:11 EDT LOG: starting archive recovery
Traceback (most recent call last):
File "/usr/local/bin/wal-e", line 5, in <module>
from pkg_resources import load_entry_point
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3084, in <module>
#_call_aside
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3070, in _call_aside
f(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3097, in _initialize_master_working_set
working_set = WorkingSet._build_master()
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 651, in _build_master
ws.require(__requires__)
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 952, in require
needed = self.resolve(parse_requirements(requirements))
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 847, in resolve
new_requirements = dist.requires(req.extras)[::-1]
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2602, in requires
dm = self._dep_map
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2803, in _dep_map
self.__dep_map = self._compute_dependencies()
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2825, in _compute_dependencies
for req in self._parsed_pkg_info.get_all('Requires-Dist') or []:
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2794, in _parsed_pkg_info
metadata = self.get_metadata(self.PKG_INFO)
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 1617, in get_metadata
return self._get(self._fn(self.egg_info, name))
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 1728, in _get
with open(path, 'rb') as stream:
IOError: [Errno 13] Permission denied: '/usr/local/lib/python2.7/dist-packages/six-1.9.0.dist-info/METADATA'
2015-07-11 00:41:11 EDT LOG: invalid checkpoint record
2015-07-11 00:41:11 EDT FATAL: could not locate required checkpoint record
2015-07-11 00:41:11 EDT HINT: If you are not restoring from a backup, try removing the file "/var/lib/postgresql/9.3/main/backup_label".
2015-07-11 00:41:11 EDT LOG: startup process (PID 1693) exited with exit code 1
2015-07-11 00:41:11 EDT LOG: aborting startup due to startup process failure
I had several of these and was able to resolve them by changing the group and modifying the permissions on the noted files to match others in the directory, but I suspect the problem has more to do with how and/or where these packages were installed. After resolving the above issue, postgres still fails to start up, returning the following:
* Starting PostgreSQL 9.3 database server
* The PostgreSQL server failed to start. Please check the log output:
2015-07-11 00:30:04 EDT LOG: database system was interrupted; last known up at 2015-06-30 05:00:02 EDT
2015-07-11 00:30:04 EDT LOG: starting archive recovery
Traceback (most recent call last):
File "/usr/local/bin/wal-e", line 5, in <module>
from pkg_resources import load_entry_point
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3084, in <module>
#_call_aside
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3070, in _call_aside
f(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3097, in _initialize_master_working_set
working_set = WorkingSet._build_master()
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 651, in _build_master
ws.require(__requires__)
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 952, in require
needed = self.resolve(parse_requirements(requirements))
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 839, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'wal-e==0.8.1' distribution was not found and is required by the application
2015-07-11 00:30:04 EDT LOG: invalid checkpoint record
2015-07-11 00:30:04 EDT FATAL: could not locate required checkpoint record
2015-07-11 00:30:04 EDT HINT: If you are not restoring from a backup, try removing the file "/var/lib/postgresql/9.3/main/backup_label".
2015-07-11 00:30:04 EDT LOG: startup process (PID 1495) exited with exit code 1
2015-07-11 00:30:04 EDT LOG: aborting startup due to startup process failure
It is complaining about the 'wal-e==0.8.1' distribution was not found..., but it is clearly installed and executable:
ls -l /usr/local/lib/python2.7/dist-packages
total 608
drwxr-sr-x 2 root staff 4096 Jul 10 20:14 argparse-1.3.0.dist-info
-rw-r--r-- 1 root staff 88400 Jul 10 20:14 argparse.py
-rw-r--r-- 1 root staff 65659 Jul 10 20:14 argparse.pyc
drwxr-sr-x 6 root staff 4096 Jul 9 22:36 azure
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 azure-0.11.1.egg-info
drwxr-sr-x 5 root staff 4096 Jul 9 22:36 babel
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 Babel-1.3.egg-info
drwxr-sr-x 57 root staff 4096 Jul 9 22:36 boto
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 boto-2.38.0.dist-info
drwxr-sr-x 3 root staff 4096 Jul 9 22:36 concurrent
drwxr-sr-x 3 root staff 4096 Jul 9 22:36 dateutil
drwxr-sr-x 3 root staff 4096 Jul 9 22:36 debtcollector
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 debtcollector-0.5.0.dist-info
-rw-r--r-- 1 root staff 207 Jul 10 20:10 easy-install.pth
-rw-r--r-- 1 root staff 126 Jul 10 20:33 easy_install.py
-rw-r--r-- 1 root staff 315 Jul 10 20:33 easy_install.pyc
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 futures-3.0.3.dist-info
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 gevent
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 gevent-1.0.2.egg-info
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 greenlet-0.4.7.egg-info
-rwxr-xr-x 1 root staff 82869 Jul 9 22:36 greenlet.so
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 iso8601
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 iso8601-0.1.10.egg-info
drwxr-sr-x 15 root staff 4096 Jul 9 22:36 keystoneclient
drwxr-sr-x 2 root staff 4096 Jul 10 20:33 _markerlib
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 msgpack
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 msgpack_python-0.4.6.egg-info
drwxr-sr-x 5 root staff 4096 Jul 9 22:36 netaddr
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 netaddr-0.7.15.dist-info
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 netifaces-0.10.4.egg-info
-rwxr-xr-x 1 root staff 58386 Jul 9 22:36 netifaces.so
drwxr-sr-x 4 root staff 4096 Jul 9 22:36 oslo
drwxr-sr-x 3 root staff 4096 Jul 9 22:36 oslo_config
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 oslo.config-1.14.0.dist-info
-rw-r--r-- 1 root root 299 Jul 9 22:35 oslo.config-1.14.0-py2.7-nspkg.pth
drwxr-sr-x 3 root staff 4096 Jul 9 22:36 oslo_i18n
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 oslo.i18n-2.1.0.dist-info
drwxr-sr-x 3 root staff 4096 Jul 9 22:36 oslo_serialization
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 oslo.serialization-1.7.0.dist-info
drwxr-sr-x 3 root staff 4096 Jul 9 22:36 oslo_utils
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 oslo.utils-1.8.0.dist-info
-rw-r--r-- 1 root root 299 Jul 9 22:35 oslo.utils-1.8.0-py2.7-nspkg.pth
drwxr-sr-x 5 root staff 4096 Jul 10 20:14 pbr
drwxr-sr-x 2 root staff 4096 Jul 10 20:14 pbr-1.3.0.dist-info
drwxr-sr-x 4 root staff 4096 Jul 10 20:10 pip-7.1.0-py2.7.egg
drwxr-sr-x 3 root staff 4096 Jul 10 20:33 pkg_resources
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 python_dateutil-2.4.2.dist-info
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 python_keystoneclient-1.6.0.dist-info
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 python_swiftclient-2.4.0.dist-info
drwxr-sr-x 3 root staff 4096 Jul 9 22:36 pytz
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 pytz-2015.4.dist-info
drwxr-sr-- 3 root staff 4096 Jul 9 23:25 requests
drwxr-sr-- 2 root staff 4096 Jul 9 23:25 requests-2.7.0.dist-info
drwxr-sr-x 3 root staff 4096 Jul 10 20:33 setuptools
drwxr-sr-x 2 root staff 4096 Jul 10 20:33 setuptools-18.0.1.dist-info
drwxr-sr-x 3 root staff 4096 Jul 9 22:36 simplejson
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 simplejson-3.7.3.egg-info
drwxr-sr-- 2 root staff 4096 Jul 9 23:26 six-1.9.0.dist-info
-rw-r--r-- 1 root root 29664 Jul 9 23:26 six.py
-rw-r--r-- 1 root root 29006 Jul 9 23:26 six.pyc
drwxr-sr-x 4 root staff 4096 Jul 9 22:36 stevedore
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 stevedore-1.6.0.dist-info
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 swiftclient
drwxr-sr-x 7 root staff 4096 Jul 9 22:35 wal_e
drwxr-sr-x 2 root staff 4096 Jul 9 22:35 wal_e-0.8.1.egg-info
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 wrapt
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 wrapt-1.10.5.egg-info
I have done quite a bit of searching, but haven't found anything that helps. Any suggestions or points in the right direction are appreciated.
Additionally, it would be of great interest to solve this to ensure that my primary installation will behave in the event that a restoration is necessary. Backing up is pointless if I can't restore it.
I am not entirely sure what resolved the The 'wal-e==0.8.1' distribution was not found errro, but on rebooting I never saw that again.
Aside from that, fixing this was rather straightforward.
The executable bit on a number of python distributions was not set.
Chowning these fixed the error:
chmod o+x /usr/local/lib/python2.7/dist-packages/requests-2.7.0.dist-info/
chmod o+x /usr/local/lib/python2.7/dist-packages/requests
...
Reason backup_label is not created properly
Run the below command in your Master
su postgres
psql -c "select pg_start_backup('initial_backup');"
rsync -cva --inplace --exclude=pg_xlog
/var/lib/postgresql/9.1/main/
slave_IP_address:/var/lib/postgresql/9.1/main/
psql -c "select pg_stop_backup();"
cd /var/lib/postgresql/9.1/main
create file name recovery.conf add the below lines
standby_mode = 'on'
primary_conninfo = 'host=master_IP_address
port=5432 user=rep password=yourpassword' trigger_file =
'/tmp/postgresql.trigger.5432'
service postgresql restart

How to start 'mongos' route server (MongoDB 2.1.1) on Raspbian?

So i used THIS Tutorial from Eugene Ch'ng for setting up a MongoDB Shard-Cluster. Following all his steps works perfect.
My cluster contains 4 raspberry-pi (b+) and my MacBook.
After setting up my Config-Server (only one for now, due to hardware shortage), i came to the point where i should start the "mongos" instance. But there is none.
/opt/mongo/bin contains:
pi#pi01 /opt/mongo/bin $ ls -l
total 48536
-rwxr-xr-x 1 root root 4986476 May 28 20:16 bsondump
drwxr-xr-x 2 root root 4096 Jun 1 08:24 cfg0
-rw-r--r-- 1 root root 2376 May 29 10:34 log.cfg0
-rwxr-xr-x 1 root root 2734964 May 28 20:28 mongo
-rwxr-xr-x 1 root root 6942152 May 28 20:28 mongod
-rwxr-xr-x 1 root root 5006660 May 28 20:32 mongodump
-rwxr-xr-x 1 root root 4990416 May 28 20:36 mongoexport
-rwxr-xr-x 1 root root 5018040 May 28 20:39 mongofiles
-rwxr-xr-x 1 root root 5007712 May 28 20:43 mongoimport
-rwxr-xr-x 1 root root 4977940 May 28 20:47 mongooplog
-rwxr-xr-x 1 root root 4990044 May 28 20:50 mongoperf
-rwxr-xr-x 1 root root 5013980 May 28 20:54 mongorestore
Even this wasn't helping me:
sudo find / -name 'mongos'
Where can i find the 'mongos' process to start the mongodb route-server?
Thank you for your help in advance.