Raspbian Root on a Windows Share

[ejolson]

Since the 1980's it has been possible to boot diskless Unix workstations with their root directories mounted using a network file system. Linux has maintained that capability and the Raspbian operating system which runs on the Raspberry Pi is a type of Linux. This thread describes how to set up a Pi Zero to network boot without an SD card and mount its root filesystem from a standard Microsoft Windows CIFS/SMB share using the USB Ethernet gadget. Similar instructions could be used to boot any Pi from a minimal SD card and then mount root from a Windows share over regular Ethernet.

These instructions were tested using the version of Raspbian Lite released October 2018 and Microsoft Windows Vista Home. It is expected that a similar technique will work with other versions of Windows.

Log into Windows and create a subdirectory called Pi.

C:\Users\XXXXXXX>mkdir Pi

Download the files linux-cdc-acm.inf and linux.inf from

https://www.kernel.org/doc/Documentation/usb/

and place them in the Pi directory. These two information files are needed for some versions of Windows to properly configure the Linux USB Ethernet and Serial gadgets.

In preparation for logging in to the Pi Zero later, download and install the putty secure shell program from

https://www.chiark.greenend.org.uk/~sgt ... atest.html

Internet connection sharing ICS defaults to different local addresses with different versions of Windows. Set the local IP number for ICS NAT to 192.168.5.1 by running regedit and clicking

->HKEY_LOCAL_MACHINE
->SYSTEM
->CurrentControlSet
->Services
->SharedAccess
->Parameters

Then change

ScopeAddress 192.168.5.1
ScopeAddressBackup 192.168.5.1

Next, download the Raspbian image from

https://www.raspberrypi.org/downloads/raspbian/

and write it to an SD card.

Now, configure the FAT-formatted boot partition of the SD card as follows. To the end of config.txt add

dtoverlay=dwc2

Further change cmdline.txt to

dwc_otg.lpm_enable=0 dwc_otg.speed=2 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait modules-load=dwc2,g_ether g_ether.host_addr=02:47:c0:a8:0d:02 g_ether.dev_addr=02:47:c0:a8:0d:01 quiet init=/usr/lib/raspi-config/init_resize.sh

Note that cmdline.txt is a single line. The changes load the Ethernet gadget, force USB2 mode and assign local MAC addresses to each side of the USB network. We also explicitly specify the root directory to be partition 2 of the SD card.

Finally, create an empty file in /boot called ssh to enable secure login, unmount the SD card from the Windows computer and place it in the Pi Zero.

Boot the Pi Zero by connecting it to the Windows PC using a USB cable. After some time the Windows PC should recognize new hardware. It may also pop up a display saying it needs an RNDIS driver. If this happens you can tell Windows to look in the Pi directory where you copied the linux-cdc-acm.inf and linux.inf files earlier. Since the appropriate drivers are already included with Windows, only the information files are needed for the Linux gadgets.

Once the Ethernet gadget is recognized there will be two network devices present on the Windows computer and you need to enable ICS so the DHCP client in Raspbian running on the Zero gets an IP number. Click on

->Control Panel
->Network and Internet
->Network and Sharing Center
->Manage network connections

then right click on the upstream network device and click

->Properties
->Sharing

Check the "Allow other network users to connect through this computer's Internet connection" check box and click

->OK

This will enable ICS which then starts a DHCP and DNS server with NAT for the USB Ethernet gadget. If everything goes well, you should now be able to connect to the Raspberry Pi and login using a command such as

C:\Users\XXXXXXX>putty raspberrypi.mshome.net

with username pi and password raspberry. Here mshome.net is the domain used by the DNS built into Windows ICS.

Before proceding it is worth highlighting that the method just described includes a few items that are different or missing from other posts about attaching a Pi Zero to a Windows computer. First, this post details how to download the missing linux-cdc-acm.inf and linux.inf files if Windows can't find an RNDIS driver. Second, this post uses ICS to setup NAT, DNS and DHCP on the Windows computer. Not only does this allow us to reach the Pi from the Windows computer as raspberrypi.mshome.net but it also allows the Zero to connect to the Internet. Third, the only additional software installed on Windows is the secure shell client putty. In particular, the Bonjour protocol is not needed nor will any NFS or iSCSI servers be required for the sequel.

The next post will discuss how to create a Windows share with an ext4 image file containing a Raspbian root filesystem. If you are following along and discover any errors or have questions please post them here.

[ejolson]

In this post we create a boot script that will allow the initial RAM filesystem to mount an ext4 image hosted on a Samba share as the Raspbian root filesystem and then copy all the necessary files to the Windows machine in preparation for booting the Pi Zero with the root filesystem as a Windows share without an SD card.

First, let's configure Microsoft Windows sharing and check that it's possible to mount the share on the Pi Zero. On the Windows machine click on

->Control Panel
->Network and Internet
->Network and Sharing Center
->Password protected sharing
->Turn on password protected shared
->Apply
->Continue

Also disable Windows Firewall by clicking

->Control Panel
->Windows Firewall
->Change settings
->Off (not recommended)
->Apply
->OK

Now login to the Pi and type the following while replacing XXXXXXX by your Windows username.

Code: Select all

$ sudo bash
# apt-get update
# apt-get install smbclient
# exit
$ smbclient -UXXXXXXX //192.168.5.1/Users
Enter XXXXXXX's password:
smb: \> pwd
Current directory is \\192.168.5.1\Users\
smb: \> cd XXXXXXX/Pi
smb: \XXXXXXX\Pi\> ls
  .                                   D        0  Fri Nov  2 22:10:31 2018
  ..                                  D        0  Fri Nov  2 22:10:31 2018
  linux-cdc-acm.inf                   A     3357  Tue Jan  3 18:31:30 2006
  linux.inf                           A     2259  Tue Jan  3 22:00:50 2006

smb: \XXXXXXX\Pi\> quit

If apt-get update fails, then please fix Windows Internet connection sharing ICS as described in the previous post before proceeding. If you can not connect to your Windows share with smbclient and list the contents of the the Pi directory, then please fix your Windows sharing configuration.

We shall now create a custom boot script for the initial RAM filesystem that mounts an ext4 image as Raspbian root. This will be done by modifying the NFS boot script. First copy the nfs boot script into a file named samba by typing

$ sudo bash
# cd /usr/share/initramfs-tools/scripts
# cp nfs samba

Now edit the file samba to make the following changes

Around line 72 make the change

Code: Select all

    #nfsmount -o nolock ${roflag} ${NFSOPTS} ${NFSROOT} ${rootmnt}
    SAMBAROOT=//${NFSROOT%%:*}${NFSROOT#*:}
    echo mount -t cifs $NFSOPTS $SAMBAROOT /run/samba
    mount -t cifs $NFSOPTS $SAMBAROOT /run/samba
    echo ls /run/samba
    ls /run/samba

Around line 95 make the change

Code: Select all

    # Default delay is around 180s
    delay=${ROOTDELAY:-180}
    echo mkdir /run/samba
    mkdir /run/samba

Around line 108 make the change

Code: Select all

        nfs_retry_count=$(( ${nfs_retry_count} + 1 ))
        [ "$quiet" != "y" ] && log_end_msg
    done
    echo losetup /dev/loop0 /run/samba/raspbian.ext4
    losetup /dev/loop0 /run/samba/raspbian.ext4
    echo mount -t ext4 /dev/loop0 ${rootmnt}
    mount -t ext4 /dev/loop0 ${rootmnt}
    echo ls ${rootmnt}
    ls ${rootmnt}

Before proceeding, you may want to make one more change to the scripts used on the initial RAM filesystem. This change shouldn't be necessary; however, the timeouts used for the DHCP client on the initial RAM filesystem are in my opinion too short to reliably obtain a lease from the ICS local DHCP server. While the default script employs an exponential back off each time a timeout occurs, it appears that quickly repeated lease requests cause ICS to ignore subsequent requests. This results in a not infrequent failure to boot.

A fix for this problem is described in this post below. Unfortunately, even with this additional change, the Zero doesn't always receive a DHCP lease. The Pi is sometimes recognized as a different network device after it reboots. There may also be a race between various components of the Windows Vista networking stack which lead to a scrambled configuration when network devices disappear and reappear too quickly. While one could use static IP numbers, I'm usually able to get the Pi to boot with DHCP by unpluging it and waiting a few minutes before trying again. Disabling, waiting and then enabling ICS and the upstream network device also seems to help.

After following the instructions in the above mentioned link, edit /etc/initramfs-tools/modules and add the lines

Code: Select all

g_ether
libcomposite
u_ether
udc-core
usb_f_ecm
usb_f_rndis
arc4
ecb
md4
md5
hmac
nls_utf8
cifs
ccm

These modules are needed to load the Ethernet gadget and mount the Windows share from the initial RAM filesystem.

It now time to make the initial RAM filesystem. Do this by typing the following commands on the Pi Zero.

Code: Select all

# uname -r
4.14.71+
# update-initramfs -c -k 4.14.71+

The next step is to copy the boot and root filesystems to the Windows share. This is done by mounting the share, creating a boot subdirectory then recursively copying the boot directory. Then a file called raspbian.ext4 shall be made and formatted with an ext4 directory. Then mounted over loopback. Note that in the example below an 8GB image will be created. This is fine for Raspbian Lite; however, if you decided to use a full version of Raspbian instead, it would be better to specify seek=16384 in what follows to create a 16GB image. These steps may be performed by typing the commands

Code: Select all

# cd
# mkdir pi newroot
# mount -t cifs -o username=XXXXXXX,vers=1.0 //192.168.5.1/Users/XXXXXXX/Pi pi
Password for XXXXXXX@//192.168.5.1/Users/XXXXXXX/Pi:
# cd pi
# cp -r /boot .
# touch raspbian.ext4
# dd bs=1024K seek=8192 count=0 if=/dev/zero of=raspbian.ext4
# losetup /dev/loop1 raspbian.ext4
# mke2fs -t ext4 -L ROOT /dev/loop1
mke2fs 1.43.4 (31-Jan-2017)
Creating filesystem with 2097152 4k blocks and 524288 inodes
Filesystem UUID: 2bc38869-428e-4e89-9db5-f749ee23829b
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done

# losetup -d /dev/loop1

While vers=1.0 is compatible with all versions of Windows, if you are using newer versions of Windows you may prefer to specify either vers=2.0, vers=2.1 or vers=3.0 or omit this option entirely from the mount command because the older protocol versions are slower and less secure than the newer ones. In the case of Windows Vista vers=2.0 is actually the best choice and will be used in the next post which describes how to change cmdline.txt for network boot.

Note that the mke2fs command above may take a few minutes, especially if a 16GB image is being made. You can monitor the activity from Windows by clicking on

->Task Manager
->Resource Monitor

Although the Ethernet gadget is not included in the Network graph the Disk graph will indicate activity as the image file is formatted. My system averaged between 20MB/sec and 40MB/sec while this operation was being performed.

Next, mount the raspbian.ext4 disk image and use rsync to copy the contents of the running root filesystem to the image.

Code: Select all

# cd
# mount -o loop pi/raspbian.ext4 newroot
# rsync -glopqrtxDH --numeric-ids --delete / newroot

The rsync command runs considerably slower than formatting the image and averaged about 5MB/sec on my system. Even with Raspbian Lite that provides plenty of time to do something else. The next post will describe how to install rpiboot.exe on Windows and use it to boot the Pi Zero without an SD card.

[ejolson]

Having created a suitable initial RAM filesystem, it is now easy to boot the Pi Zero without an SD card using rpiboot.exe. This is the same program used to flash the eMMC on a compute module. A convenient Windows installer called rpiboot_setup.exe can be downloaded from the page

https://www.raspberrypi.org/documentati ... lashing.md

Download, run the installer and choose the defaults. The rpiboot.exe program will then be installed in C:\Program Files\Raspberry Pi. Create a file called bootpi.bat in the C:\Users\XXXXXXX\Pi directory containing the single line

"\Program Files\Raspberry Pi\rpiboot.exe" -d \Users\XXXXXXX\Pi\boot

This batch command runs the rpiboot.exe program with the boot directory that we copied from the Pi Zero in the previous post. Before doing that, we need to edit cmdline.txt and config.txt so they load the initial RAM filesystem and run our newly created samba boot script as well as make a minor change to /etc/fstab on the Raspbian root filesystem image so it doesn't try to mount the SD card later.

The editing of the files in the boot directory can be done either from Windows with a suitable text editor or from the Raspberry Pi, however, editing files on the root directory must be done with the Pi since Windows can't read the ext4 filesystem image. In this discussion, all editing will be done from the Pi for simplicity.

If you have already rebooted the Pi or unmounted the Windows share and root filesystem image, you can remount everything by typing the following commands on the Pi Zero:

# cd
# mount -t cifs -o username=XXXXXXX,vers=2.0 //192.168.5.1/Users/XXXXXXX/Pi pi
# mount -o loop pi/raspbian.ext4 newroot

Now edit pi/boot/cmdline.txt so that it appears as

boot=samba dwc_otg.lpm_enable=0 dwc_otg.speed=2 console=serial0,115200 console=tty1 elevator=deadline fsck.repair=yes rootwait modules-load=dwc2,g_ether g_ether.host_addr=02:47:c0:a8:0d:02 g_ether.dev_addr=02:47:c0:a8:0d:01 nfsroot=192.168.5.1:/Users/XXXXXXX/Pi,username=XXXXXXX,vers=2.0,password=YYYYYYY ip=::::raspberrypi:usb0:dhcp

Here XXXXXXX is your login name under Microsoft Windows and YYYYYYY is the corresponding password. It is important that the password not contain any spaces or tabs. Please change it before continuing if it does. Also note that I have specified vers=2.0 in the options of cmdline.txt for the Windows share that will hold the root filesystem. For best performance and security, please use the most up-to-date level supported by the particular version of Windows you are using.

Then, edit pi/boot/config.txt so the following lines appear at the end

dtoverlay=dwc2
kernel=kernel.img
initramfs initrd.img-4.14.71+

Finally edit the file newroot/etc/fstab so that it reads as

Code: Select all

proc /proc proc defaults 0 0
/dev/loop0 / ext4 defaults,noatime 0 1

Be sure to edit the version of fstab that is on the filesystem image copied to the Windows share and not the one on the SD card. After these changes, we are now ready to boot the Pi without an SD card. Before removing the SD card, unmount the root filesystem image and the Samba share and then power the Pi down with the commands

# cd
# umount newroot
# umount pi
# poweroff

Wait for the green light to flash four times, wait a little more and then remove the USB plug from the Windows computer. After the power has been disconnected remove the SD card and then plug the USB cable back in.

Once power has been reapplied the Zero will wait for rpiboot.exe to send it the kernel and initial RAM filesystem. This can be done using the batch script made earlier by typing

C:\Users\XXXXXXX\Pi> cd \Users\XXXXXXX\Pi
C:\Users\XXXXXXX\Pi> bootpi.bat
Waiting for BCM2835/6/7
Sending bootcode.bin
Successful read 4 bytes
Waiting for BCM2835/6/7
Second stage boot server
File read: config.txt
File read: start.elf
File read: fixup.dat
File read: config.txt
File read: config.txt
File read: cmdline.txt
File read: kernel.img
File read: initrd.img-4.14.71+
File read: bcm2708-rpi-b-plus.dtb
File read: config.txt
File read: overlays/dwc2.dtbo
Second stage boot server done
C:\Users\XXXXXXX\Pi>

At this point the Pi should begin booting. Wait sometime for it to finish and then try connecting using putty.

C:\Users\XXXXXXX\Pi> putty raspberrypi.mshome.net

If things don't work, please review the above steps or further diagnose the problem by connecting a monitor to the Zero to watch it boot. Note for any version of Raspbian running without an SD card, kworker will continuously consume about 10% of the available CPU checking to see if a card has been inserted yet. The SD card slot may be disabled entirely to prevent kworker from using so much CPU by adding an additional option to config.txt if desired.

Please let me know if you follow the above instructions, whether they work and whether you needed to make any changes for different versions of Windows.

Good luck!

[ejolson]

In this post I do a little tidying up.

First, fix the timezone on the Pi using raspi-config. Since Windows is set to local time, it is important for the Pi to be set to the same timezone as the Windows machine. Otherwise, there will be time synchronization issues between the Windows share and the Pi.

Presently the boot directory is mounted under /run/samba/boot and the actual boot directory mount point is empty. We fix this by making a symbolic link as

$ sudo bash
# cd /
# rmdir boot
# ln -s /run/samba/boot .

If needed, one can update the initial RAM filesystem using

# update-initramfs -u -t
update-initramfs: Generating /boot/initrd.img-4.14.71+

Note that the -t option may be necessary due to the lack of accurate time synchronization between the Windows machine and the Raspberry Pi. If not, then you are lucky.

Occasionally apt-get upgrade will update the Raspbian kernel with a new version. When this happens one should make sure the initial RAM filesystem is properly updated. This may not always happen because of the time synchronization problem previously mentioned. To make sure, it might be a good idea to run

# update-initramfs -c -t -k ZZZZZZZ

where ZZZZZZZ is the version of the new kernel just installed. Note that the -u option may be needed in place of the -c option, in case there is already an initial RAM filesystem for the specified kernel.

For kworker to use 10% of the CPU is a significant load since the Pi Zero only has one core. To avoid this edit /boot/config.txt so that the last lines read as

dtparam=audio=on
dtoverlay=sdtweak,poll_once
dtoverlay=dwc2
kernel=kernel.img
initramfs initrd.img-4.14.71+

For the poll_once option to take effect, it is necessary to reboot the kernel. To do this type

# /sbin/reboot

then return to the Windows machine and type

C:\Users\XXXXXXX\Pi>bootpi.bat

It often takes a couple minutes for ICS to provide a lease when the Zero is booting. If after a couple minutes it is not possible to log in, then one might assume that the DHCP client in the initial RAM filesystem has timed out. If this happens then remove the USB cord, plug it back in and again return to the Windows machine and type bootpi.bat.

[ejolson]

Now that kworker is not taking up so much CPU, it is reasonable to perform a few performance tests. We will test network bandwidth using iperf3 and then test how well the loopback mounted ext4 filesystem performs using bonnie++. To install these programs type

# apt-get install iperf3 bonnie++

There is a Linux x86 computer on the local network upstream from the Pi Zero and Windows machine. On that computer I started iperf3 in server mode using the -s option. Then on the Pi Zero I typed

$ iperf3 -c X86HOST

where X86HOST is the Linux computer where the iperf3 server is running. The results were

Code: Select all

Connecting to host X86HOST, port 5201
[  4] local 192.168.5.105 port 37128 connected to 192.168.174.132 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.03   sec  10.0 MBytes  81.3 Mbits/sec    0   26.9 KBytes
[  4]   1.03-2.08   sec  10.0 MBytes  80.0 Mbits/sec    0   26.9 KBytes
[  4]   2.08-3.05   sec  9.06 MBytes  78.6 Mbits/sec    0   41.0 KBytes
[  4]   3.05-4.08   sec  10.0 MBytes  81.0 Mbits/sec    0   41.0 KBytes
[  4]   4.08-5.06   sec  9.32 MBytes  80.3 Mbits/sec    0   41.0 KBytes
[  4]   5.06-6.10   sec  10.0 MBytes  80.5 Mbits/sec    0   72.1 KBytes
[  4]   6.10-7.01   sec  8.75 MBytes  80.1 Mbits/sec    0   72.1 KBytes
[  4]   7.01-8.05   sec  10.0 MBytes  80.7 Mbits/sec    0   72.1 KBytes
[  4]   8.05-9.09   sec  10.0 MBytes  80.7 Mbits/sec    0   72.1 KBytes
[  4]   9.09-10.00  sec  8.75 MBytes  80.6 Mbits/sec    0   72.1 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  95.9 MBytes  80.4 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  95.9 MBytes  80.4 Mbits/sec                  receiver

iperf Done.

which indicates a network speed from the Pi Zero through the NAT of the Windows ICS that is comparable with 100 mbit Ethernet. This is not surprising, as the local network here is exactly that.

I originally wanted to test the speed of the overlay mounted ext4 filesystem image against writing directly to the mounted Windows share. Unfortunately, bonnie++ could not perform the tests directly on the Windows share because it aborted with the error

Code: Select all

Create files in sequential order...done.
Stat files in sequential order...Can't stat file 0000000000vm9l94I9pGr
Cleaning up test directory after error.

The test was repeated twice with similar results each time. Note that the sequential and random read and write tests completed fine, but because of the error in the later file creation tests, bonnie++ did not print its summary page nor any of the results.

Fortunately, bonnie++ ran fine though somewhat slowly on the loopback-mounted ext4 filesystem image with the following results for two independent runs:

Code: Select all

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
raspberrypi      1G    34  98  3691  20  1706   3   357  92  3261   3 304.3  42
Latency               531ms   13353ms    9702ms   57808us     386ms     148ms
Version  1.97       ------Sequential Create------ --------Random Create--------
raspberrypi         -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  1956  60 +++++ +++  2473  62  2044  62 +++++ +++  2307  61
Latency               229ms    3738us   10819us     175ms   14631us   13107us
1.97,1.97,raspberrypi,1,1541400355,1G,,34,98,3691,20,1706,3,357,92,3261,3,304.3,42,16,,,,,1956,60,+++++,+++,2473,62,2044,62,+++++,+++,2307,61,531ms,13353ms,9702ms,57808us,386ms,148ms,229ms,3738us,10819us,175ms,14631us,13107us

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
raspberrypi      1G    34  97  3550  16  1662   3   414  90  3220   3 292.4  42
Latency               550ms   13873ms    9973ms   51278us     403ms     400ms
Version  1.97       ------Sequential Create------ --------Random Create--------
raspberrypi         -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  1995  61 +++++ +++  2435  60  1967  60 +++++ +++  2014  54
Latency               254ms    3614us   10674us     201ms     226us   10755us
1.97,1.97,raspberrypi,1,1541403765,1G,,34,97,3550,16,1662,3,414,90,3220,3,292.4,42,16,,,,,1995,61,+++++,+++,2435,60,1967,60,+++++,+++,2014,54,550ms,13873ms,9973ms,51278us,403ms,400ms,254ms,3614us,10674us,201ms,226us,10755us

It is worth noting during the above test that the loop0 worker consumed from 10 to 30 percent of the CPU while the cifs worker did likewise. In particular, the Zero ran with about 80 percent CPU with the remaining 20 percent in IO wait. Thus, the %CP numbers reported by bonnie++ underestimate the total CPU used.

[ejolson]

When booting sometimes the DHCP client in the initial RAM filesystem fails to receive a lease before timing out. It appears that ICS local DHCP server gets confused when the Ethernet gadget disappears and reappears when the Pi Zero reboots. On Windows one can check what IP number the ICS local DNS server currently thinks is assigned to the Pi by typing

C:\Users\XXXXXXX\Pi>ping raspberrypi.mshome.net

This will return an IP number immediately and the ping round trip time if things have been setup correctly. If there is an error, disable and then enable network sharing in hopes that this will cause the ICS local DHCP server to start working again.

If after waiting for some time the Pi doesn't boot, this means that the Windows share and Raspbian root filesystem was never mounted. In this case there is no danger in removing the USB cord, reinserting it and then running the bootpi.bat script again. It would be interesting to know whether the unreliability just discussed also occurs when using versions of Windows more recent than Vista. Note that the changes discussed in the next post mitigate the just-mentioned booting problem by introducing longer timeouts when requesting a lease in the initial RAM filesystem.

Since both the boot and root filesystems for the Pi are stored on the Windows computer, this provides an easy way to make backups. Log into the Pi and shut it down with the command

# /sbin/reboot

After the green light turns off the Pi returns to a state where it is waiting for rpiboot.exe to feed it a kernel and initial RAM filesystem. Before doing that we can make a copy of raspbian.ext4 file called backup.ext4 and further copy the contents of the boot directory to a directory called backup-boot. On my system it took about 5 minutes to copy the 8GB file that contains the root filesystem.

After making the backups, reboot the Pi using the bootpi.bat script.

Any insight why the Pi Zero sometimes doesn't receive a IP lease from the ICS local DHCP server when booting would be appreciated. As this reliability issue and the above mentioned work around is a bit tedious, I hope someone can come up with something better.

[ejolson]

I've been having the trouble that Microsoft ICS stops working when the Pi Zero reboots. Restarting ICS at the right time is made difficult by the fact that the DHCP client on the initial RAM filesystem only tries to obtain a lease for about a minute before timing out. Moreover, there is no visual feedback to indicate that the Pi is requesting the lease when no monitor is connected. This post disables the timeout and causes the green LED to blink once every 30 seconds when the Zero requesting a DHCP lease. The fact that the initial timeouts are much longer also appears to increase reliability.

First edit /usr/share/initramfs-tools/scripts/functions so that around line 230 it reads as

Code: Select all

        # Documentation/frv/booting.txt

        while true; do
                ROUNDTTT=29
                echo 255 >/sys/class/leds/led0/brightness
                sleep 1
                echo 0 >/sys/class/leds/led0/brightness
#       for ROUNDTTT in 2 3 4 6 9 16 25 36 64 100; do

Then change to the /boot directory and type

$ sudo bash
# update-initramfs -u -k 4.14.17+ -t
# sync
# sync
# sync
# /sbin/reboot

to update the initial RAM filesystem and reboot. Return to the Windows system and type

C:\Users\XXXXXXX\Pi> bootpi.bat

to load the kernel and initial RAM filesystem. After the kernel boots the green light will turn on. After some time it will turn off for a second and then turn back on. This is the indication that the Zero is waiting for a DHCP lease. The green light will continue to blink once every 30 seconds until a lease is obtained. If the blinking continues for some time, this is an indication that ICS is not working.

To enable it, click on the upstream network device as indicated in the previous post and turn it off, wait for some time and then turn it on again. In less than a minute the ICS local DHCP server should wake up enough to give a new lease to the booting Pi Zero.

Sometimes it I found it necessary to start over by unplugging the USB cable connected to the Zero, waiting for some time, plugging it back in and then rerunning bootpi.bat.

Another way to work around the unreliable ICS local DHCP server is to give the Pi Zero a static IP number so that it can finish booting even without a lease. After the Pi is booted one can then check if the local NAT firewall is working and reset ICS if necessary. While this seems to solve reliability problem with booting, static IP numbers have the disadvantage that the ICS local DNS server will not be updated with the hostname. Thus, you must use the numeric IP number instead of raspberrypi.mshome.net when logging in.

[ejolson]

Windows ICS allows one to perform port forwarding from the upstream network connection to the Pi Zero. In this post we enable ICS port forwarding so that upstream machines can use ssh to connect to the Pi.

First, click on

->Control Panel
->Network and Internet
->Network and Sharing Center
->Manage network connections

Then right-click on the upstream network device and click

->Properties
->Continue
->Sharing
->Settings...
->Add

Fill out the form so it reads

Description of service: SSH server
Name or IP address of the computer hosting
this service on your network: rasperrypi
External Port number for this service: 22
Internal Port number for this service: 22

Finally click the TCP radio button and and then click

->OK
->OK
->OK

Note, do not include mshome.net in the name of the computer hosting this service but only raspberrypi in the above form. At this point it should be possible to connect to the Pi Zero from any computer upstream by specifying the address of the Windows computer as the secure shell host.

[ejolson]

At this point the Pi Zero is booting Raspbian without an SD card through a USB cable attached to a Windows computer. Aside from the occasional unreliability of not receiving a DHCP lease upon rebooting, which can be resolved using static IP numbers, this project is done. One question remains, however, and that is why? What is this good for?

There are a number of different directions one could take at this point. For example,

1. One could embark upon a GPIO project. Note that since the Zero is tethered to the PC any project which relies on its small size is inaccessible. One could, however, build a Raspberry Pi controlled electronic stapler with object recognition that only staples pages printed on company letterhead and never fingers.

2. Another use could be to offload computationally intensive tasks from the Windows computer. This is natural because both machines are tethered together. One idea is to use the Pi to render POV-Ray scenes. Alternatively one could transcode interlaced AVCHD video downloaded from a camcorder to VC4 hardware-encoded progressive H264 video correctly sized for web viewing. In general it would not be too difficult to create a script that looked for any type of work to do in a subdirectory of the Windows share and then deposited the finished results in a separate subdirectory.

3. One could also use the Zero as a sandbox in which to run security sensitive desktop applications such as web browsers, banking, email clients and office tools. Note that Microsoft ended mainstream support for Windows 7 on January 13, 2015, but extended support won't end until January 14, 2020. My computer is actually running Vista. In this case Xrdp with Xorgrdp could be installed on the Pi so that such applications can run using Remote Desktop without installing additional software on the Windows computer.

4. One could set up network services on the Zero that are not easily provided under Windows. Such services range from LDAP and Kerberos to a full LAMP-stack web server with a blog or forum like this one hosted on top of that. Game servers for lpMUD, netrek or Minecraft are also possible. One could keep these services local for development and testing purposes or use Windows port forwarding to make the services available to upstream computers and even the Internet if desired.

What's interesting for me is that, except for the stapler project, all the above ideas can be implemented with only a 5$ Pi and a USB cable. Details describing other ideas and uses are welcome.

[ejolson]

I now have a Windows 10 computer to test whether the procedure outlined above needs modifications. I'm hoping the ICS local DHCP server is more reliable and the occasional problems of obtaining a lease upon boot go away.

It has also been brought to my attention that Pi A and A+ models work with rpiboot the same way as a Pi Zero or Zero W--they only need a different USB cable. However, as detailed in this thread the Pi 3A+ does not work with rpiboot. Even so, the Pi 3A+ can still switch to gadget mode after loading the kernel and initial RAM filesystem from an SD card. In this way a 3A+ could mount the Raspbian root filesystem over USB from a Windows computer using a configuration similar to the one described above.