Mounting a Raspberry Pi image in Linux

This is quite a useful tip: if you have used Win32DiskImager or similar to clone a Raspberry Pi SD card and you want to mount the resulting .img file in Linux, you need to use the ‘offset’ argument to cater for the .img file including multiple partitions.

Details are here, but the summary would be:
parted [image].img

Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit                                                             
Unit?  [compact]? B                                                       
(parted) print

The output should look something like:

Code:
Model: ATA ST3160815AS (scsi)
Disk /dev/sda: 160041885696B
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start          End            Size           Type     File system     Flags
 1      32256B         10733990399B   10733958144B   primary  ext4
 2      10733990400B   21500881919B   10766891520B   primary  ext3
 3      21500881920B   158961761279B  137460879360B  primary  ext4
 4      158961761280B  160039272959B  1077511680B    primary  linux-swap(v1)

type q to exit from parted.

Now to mount a partition, you have to run something like:

Code:
sudo mount -o loop,offset=32256 picked.img mount/point

 

Advertisements

DHCP re-numbering

A useful tip, if ever having to export and renumber DHCP leases on your Windows Server network, check out this link: https://blogs.technet.microsoft.com/teamdhcp/2012/11/20/bulk-load-dhcp-reservations-using-dhcp-powershell/

Specifically:

If you want to add a large list of reservations, an input text file in CSV format can be used to provide the list of reservations to be configured on the DHCP server. This data can be easily pipelined to Add-DhcpServerv4Reservation cmdlet to add the complete list to the DHCP Server. The input text file (Reservations.csv in the command line used later) containing the reservations should be of the following format –

ScopeId,IPAddress,Name,ClientId,Description

10.10.10.0,10.10.10.10,Computer1,1a-1b-1c-1d-1e-1f,Reserved for Computer1

20.20.20.0,20.20.20.11,Computer2,2a-2b-2c-2d-2e-2f,Reserved for Computer2

30.30.30.0,30.30.30.12,Computer3,3a-3b-3c-3d-3e-3f,Reserved for Computer3

Note that the client id for most clients including Windows computers is the MAC address.

The following command adds all these reservations to the DHCP Server.

Import-Csv Reservations.csv | Add-DhcpServerv4Reservation

 

Multi-room audio with Mopidy and Snapcast

In my quest to continually improve my multi-room audio setup, one thing that has bothered me is getting Spotify to play in multiple rooms. My current solution has been to run a Windows VM with the Spotify client, capture the audio using TuneBlade, and then play it out to the various Raspberry Pi’s on the network that are running shairport-sync so they can receive AirPlay signals.

Works pretty well – but means I need to have that Windows VM working all the time. This isn’t a scalable solution to locations where the VM/Windows machine on-all-the-time isn’t an option.

So, I’m now trialling using Mopidy – an extensible music server written in Python. Mopidy will run on a Raspberry Pi, and has an extension that allows it to connect to Spotify…no Windows machine needed!

To get it up and running, I followed the installation instructions, with a few key call-outs as I was getting this running on a Raspberry Pi as the server as well:

  1. Install raspbian-lite (Jessie) on the Raspberry Pi of choice and get it all set up.
  2. Follow these instructions – specifically:
    wget -q -O - https://apt.mopidy.com/mopidy.gpg | sudo apt-key add -
    sudo wget -q -O /etc/apt/sources.list.d/mopidy.list https://apt.mopidy.com/jessie.list
    sudo apt-get update
    sudo apt-get install mopidy
    
  3. My /etc/mopidy/mopidy.conf file looks like:
    [core]
    cache_dir = /var/cache/mopidy
    config_dir = /etc/mopidy
    data_dir = /var/lib/mopidy
    
    [logging]
    config_file = /etc/mopidy/logging.conf
    debug_file = /var/log/mopidy/mopidy-debug.log
    
    [local]
    enabled = false #Note: this is just because I wasn't setting up local music at this point
    media_dir = /var/lib/mopidy/media
    
    [m3u]
    playlists_dir = /var/lib/mopidy/playlists
    
    [mpd]
    enabled = true
    hostname = ::
    
    
    enabled = true
    username = **** #My Spotify username
    password = **** #My Spotify password
    
    [http]
    enabled = true
    hostname = ::
    port = 6680
    static_dir = ""
    zeroconf = Mopidy HTTP server on $hostname
    
    [websettings]
    enabled = true
    musicbox = false
    config_file = /etc/mopidy/mopidy.conf
    
    
    #output = autoaudiosink
    output = audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! wavenc ! filesink location=/tmp/snapfifo
    
  4. To get Mopidy working as a service, I used sudo systemctl enable mopidy but you can use sudo dpkg-reconfigure mopidy for any Debian-based system.
  5. Then, I needed to install pipbut, it needed to be the Python 2.7 version. To install that, I used apt-get install python-pip2.
  6. Using pip, I could now install the various add-ins for using and supporting Spotify, namely:
    pip2 install Mopidy-Mopify
    pip2 install Mopidy-Moped
    pip2 install Mopidy-WebSettings
    pip2 install Mopidy-Iris
    

To pipe the audio across the network, I needed to install Snapcast server on the same Raspberry Pi, and then Snapclient on the various clients. So, that looks like:

  1. Get the latest compiled release for ARM (RPi) with
    wget https://github.com/badaix/snapcast/releases/download/v0.11.1/snapclient_0.11.1_armhf.deb
    

    on the client and then on the server:

    wget https://github.com/badaix/snapcast/releases/download/v0.11.1/snapserver_0.11.1_armhf.deb
    
  2. Install, with dependencies:
    dpkg -i snapserver_0.11.1_armhf.deb
    sudo apt-get -f install
    

    on the server, and then on the client:

    dpkg -i snapclient_0.11.1_armhf.deb
    sudo apt-get -f install
    
  3. The addition to the mopidy.conf file of the output section will pipe the audio from mopidy to any Snapclient that is listening.
  4. snapclient -l will list the USB devices and other sound cards on the client, and then your /etc/default/snapclient should look something like
    
    # defaults file for snapclient
    
    # start snapclient automatically?
    START_SNAPCLIENT=true
    
    # Allowed options:
    #   --help                          produce help message
    #   -v, --version                   show version number
    #   -h, --host arg                  server hostname or ip address
    #   -p, --port arg (=1704)          server port
    #   -l, --list                      list pcm devices
    #   -s, --soundcard arg (=default)  index or name of the soundcard
    #   -d, --daemon [=arg(=-3)]        daemonize, optional process priority [-20..19]
    #   --user arg                      the user[:group] to run snapclient as when daemonized
    #   --latency arg (=0)              latency of the soundcard
    #   -i, --instance arg (=1)         instance id
    
    USER_OPTS="--user snapclient:audio"
    
    SNAPCLIENT_OPTS="-s 11"
    
    

Building my own Tivo replacement

The Tivo service is coming to an end in my part of the world, so I’m trying to create an equally wife/child-friendly option for recording free-to-air, over-the-air TV and playing it back.

I already have Raspberry Pi’s connected to the various TVs in the house, and I know that Kodi has good support for tvheadend, so I figured I’d give that a go.

I bought a Hauppauge dual tuner USB stick as I thought that it is a good brand, with good Linux support, and I was keen to run the whole thing on an old Raspberry Pi (model B+, 1st generation) if I could.

Good idea, but a bit tricky in the end, because while Raspbian (and LibreElec) detected the card just fine, they would only detect one tuner on the card.

The fine people over in the LibreElec forums helped me out with patching the kernel to allow for dual tuner support.  To do this, I set up a virtual machine running Ubuntu 16.04 and got it ready to act as a cross-compiler for Raspberry Pi.  The instructions to do so are here – just make sure that you remember what kind of Raspberry Pi you are building for!

The summary of steps I took:

  1. I got the toolchain and copied the right (64-bit) bin path into my .bashrc (specifically :/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin)
  2. I then downloaded the 4.9 kernel with git clone --depth 1 -b rpi-4.9.y https://github.com/raspberrypi/linux
  3. I then got patch from a user called Puffin Chunks and followed their instructions
  4. I applied the patch as per instructions (i.e. patch -p1 < ../hauppage_winTV_dualHD_DVB_PuffinChunks_4.9.y.diff)
  5. I then followed the rest of the Raspberry Pi instructions for cross-compiling, paying attention to when to use sudo and when not to!
  6. Because my VM (Hyper-V) won’t do USB pass-through, I put the SD card in a USB card reader and plugged it into another Linux machine on my network. I then mounted it using sshfs, specifically:
    On the machine with the USB card plugged in:
    mount /dev/sdc1 /mnt/fat32/ -o umask=000
    mount /dev/sdc2 /mnt/ext4-2
    bindfs -u -g users /mnt/ext4-2/ /mnt/ext4

    (That last bindfs was due to the fact that ext4 partitions don’t mount with read/write permissions properly.)Then, on the cross-compiling machine:
    sudo sshfs @:/mnt/ext4 mnt/ext4
    sudo sshfs @:/mnt/fat32 mnt/fat32

    This was all in the linux/ folder that I was working within.)
  7. After doing this, the modules install line worked fine:
    sudo make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- INSTALL_MOD_PATH=mnt/ext4 modules_install
  8. Then, making sure that I had put KERNEL=kernel, I copied the kernel across:
    sudo cp mnt/fat32/$KERNEL.img mnt/fat32/$KERNEL-backup.img
    sudo cp arch/arm/boot/zImage mnt/fat32/$KERNEL.img
    sudo cp arch/arm/boot/dts/*.dtb mnt/fat32/
    sudo cp arch/arm/boot/dts/overlays/*.dtb* mnt/fat32/overlays/
    sudo cp arch/arm/boot/dts/overlays/README mnt/fat32/overlays/
    sudo umount mnt/fat32
    sudo umount mnt/ext4
    I actually called the kernel a new name and then added kernel=.img in /boot/config.txt.
  9. Put the card in, booted it up and we were away to the races!  I was now able to boot the RPi, run raspi-config to get things set up, then SSH on and load all the firmwares from the forum into the /lib/firmware/ folder.
  10. Installing tvheadend was pretty simple – instructions are here, but apt-get worked for me after adding deb http://apt.tvheadend.org/unstable/ jessie main to /etc/apt/sources.list

Accessing disks in a VMWare VM

When you have disks sitting in a VMWare vSphere/ESXi box that are formatted NTFS, and you want to access them from inside a VM, you need to look at Raw Device Mapping (RDM).

What it took more than a little time to find out is that for SATA disks (i.e. not in a SAN or RAID config), you need to create “pointers” first.  Great instructions are available here. But, in essence, you’re looking to make a couple of calls like:

vmkfstools -z /vmfs/devices/disks/[long weird name of disk got from ls -l in /dev/disks] /vmfs/volumes/[name of datastore]/[sub folder]/[name of disk].vmdk