Right. With the pandemic and all none of us are going to travel much but still…
About a year ago I purchased myself an OpenWRT router to use on the plane and in hotels.
And so far I really like both the device and the Hong Kong based brand (launching new and updated products, and releasing relatively regular updates for older products). Pick a device that fits your needs (USB powered? LTE? Small form factor?).
The GL-AR750S aka Slate is fully customizable but runs a few nice things out of the box: WireGuard (with a physical button to turn it on or off), OpenVPN, shell access, Tor (requires the latest firmware), IPv6, DoH (Cloudflare only for now), multiple SSIDs (i.e. Guest WiFi), and more.
Oh and I specifically picked this version (compared to other or cheaper ones) because it had both 2.4Ghz and 5Ghz, as well as 3 Gbit ports (1x WAN, 2x LAN).
Pick whatever works for you…
I use the device on flights, where I connect to the network once in the air, purchase WiFi or use iPass “for one device” and then connect to the interwebs behind my NAT-router from my iPad, phone(s), laptop(s), and even Shan‘s devices if she is travelling with me.
In hotels, I either connect it to the wired ethernet, if still available (tends to be more stable), or connect it to the guest WiFi and then connect my devices to the router: saves me from connecting to a new network and typing the room number and login/password/family name on every device. And once again hides the true number of connected devices; quite handy trick for those pesky hotels providing free access only to two devices.
Sure it takes a bit of setup every time: find a working USB port, sign in to the web interface, search for new networks if this is a new hotel or I haven’t travelled on this airline, connect to said network, sign in with iPass, and optionally enable VPN)…
And once in a while some fiddling with VPN or DNS that’s borking up or being blocked by overzealous firewalls.
Also, some in-flight entertainment USB ports don’t provide enough power (and/or are often broken — looking at you Lufthansa in economy) so be sure to carry a couple of these (US-plug works best) — I’ve already forgotten one on my last flight from MUC-SIN on LH, but luckily I have pretty easy access to these.
All right. With the release of the new RPi4 with 8Gb of RAM I had to get myself one to see if it was already a viable desktop replacement for surfing and emails.
While a SD card works fine for certain tasks (things that don’t require a lot of IO) — for a desktop that’s a no-go… It’s just too slow.
I still had an old Macbook Pro 13″ (2o15?) SSD lying around that was collecting dust. Why not use that one to use as root for the RPi?
This article will focus on making it work on Raspbian first. Technically this should all work on other distros as well, but YMMV seeing all this is still beta.
I use Raspbian Lite: I like to work with minimalstic systems and install just what I need. But technically this should work with any flavour.
But first, let’s prep the device.
Case
I already have a RPi4 (4Gb) at home running mostly Docker containers (nginx proxy and a few personal things and Smokeping).
And one of the ‘best’ purchases I made for the RPi4 was the “Raspberry Pi 4 Model B Aluminium Case” (Lazada, AliExpress). This case is passive and dissipates enough heat (even in a closed cabinet in Singapore where it’s 30°) for the CPU never to throttle back when overclocked at 2Ghz (see below).
Do note that this case (which is pretty much just a massive heat sink) gets pretty hot if the RPi is running at max performance for long periods of time.
USB-SSD
Get one that fits your SSD and that ideally has Linux support. As Apple uses custom SSD connectors (prior to being soldered onto the motherboard) I had to get a converter from China. It was a bit of Russian Roulette to see if it would work or be supported on Linux. I got myself this one (chipset: Netchip Technology). As I didn’t remember what type of Macbook Pro this came from, using this site to compare serial/model was useful. This USB-to-SSD converted also works on Mac and Windows by the way.
The SSD with the PCB that provides the USB interface.
In my case, the RPi also did not provider enough power to the USB-SSD converter (although… it really should but whatevs), so be sure to use the provided power cable and plug it into a USB power source. Not doing so will cause the SSD to heat up and show a bunch of disconnects/errors in dmesg.
raspbian ~ # fdisk -l /dev/sda1
Disk /dev/sda1: 233.8 GiB, 250999127552 bytes, 490232671 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
raspbian ~ # lsusb
Bus 002 Device 002: ID 0525:622b Netchip Technology, Inc.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
raspbian ~ # lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
|__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
Raspberry Pi 4 with USB SSD connected
eeprom update
Disconnect the USB-SSD for now.
At the time of writing we need to update the eeprom to boot from USB. I’m using the latest eeprom available to me. Note that the USB-boot eeprom is about to hit stable so you might not need to do this anymore.
There are two methods for updating. We can do it manually:
rpi-update
cd /lib/firmware/raspberrypi/bootloader/beta
rpi-eeprom-update -d -f ./pieeprom-2020-06-15.bin
# BCM2711 detected
# VL805 firmware in bootloader EEPROM
# BOOTFS /boot
# *** INSTALLING ./pieeprom-2020-06-15.bin ***
# BOOTFS /boot
# EEPROM update pending. Please reboot to apply the update.
reboot
# RPi should come back online after a reboot
Or we use rpi-eeprom-update (see article, at the bottom):
nano -w /etc/default/rpi-eeprom-update
# edit critical to stable
rpi-eeprom-update
rpi-eeprom-update -a
The good thing is that, even if you boot from a Raspbian that does not have /etc/default/rpi-eeprom-update edited to use stable instead of critical, it will not downgrade your eeprom.
Now you can plug in the SD card in an USB-SD card reader, and test if the RPi boots from USB. Note that the SD card might be slower.
RPi booting the SD card from USB (/dev/sda)
All right — so everything is working. I am keeping this SD card to update the eeprom again at a later stage (as the one we flashed is beta). If we use Archlinux or Ubuntu the eeprom update tools won’t be included.
Next step is to flash Raspbian to the USB-SSD.
This screenshot shows Ubuntu, but for the sake of this article, we’ll use Raspbian still. I’m using Etcher to flash.
Boot-up from the USB-SSD.
Errors
In case you are getting an error similar to start4.elf: is not compatible you’ll need to copy paste /boot/start4.elf from a Raspbian that ran rpi-update (i.e. the one from the SD card, or see below).
If you are booting (a fresh) Raspbian, it might complain about cma: Failed to reserve 256 MiB (and several other errors). The solution is running rpi-update.
Boot from the working Raspbian (using the SD card):
# check which drive is your USB-SSD (i.e. using fdisk -l or dmesg).
# In my case I booted from USB-SD (/dev/sda) and we'll update the new/clean Raspbian on the SSD (/dev/sdb).
#
# First resize the partition, if the system never booted it'll be 1.5Gb and thus not big enough:
# Device Boot Start End Sectors Size Id Type
# /dev/sdb1 8192 532479 524288 256M c W95 FAT32 (LBA)
# /dev/sdb2 532480 3620863 3088384 1.5G 83 Linux
fdisk /dev/sdb
# Type the following:
# p (and visually check it all makes sense)
# d
# 2
# n
# Select (default p): p
# Partition number (2-4, default 2): <enter>
# First sector (2048-490234751, default 2048): 532480 (or whichever is the same "start" from the 2nd partition)
# Last sector, +/-sectors or +/-size{K,M,G,T,P} (532480-490234751, default 490234751): <enter>
# Created a new partition 2 of type 'Linux' and of size 233.5 GiB.
# Partition #2 contains a ext4 signature.
# Do you want to remove the signature? [Y]es/[N]o: n
# p (visually check once again it makes sense, if not you can cancel/quit by typing q)
# w (if it makes sense)
# The last command will write the changes to the partition table and sync all changes.
# Then we need to check and resize the filesystem:
e2fsck -f /dev/sdb2
resize2fs /dev/sdb2
# If all that worked we can start mounting everything
mkdir /tmp/ssd
mount /dev/sdb2 /tmp/ssd/
mount /dev/sdb1 /tmp/ssd/boot/
mount /proc/ /tmp/ssd/proc/ -t proc
mount --rbind /sys/ /tmp/ssd/sys/
mount --rbind /dev/ /tmp/ssd/dev/
# Once everything is mounted, we're chrooting into the fresh Raspbian running on the SSD
chroot /tmp/ssd/ /bin/bash
# you can double confirm the partition size using:
df -h
# And we update the system. Again, if all this hits stable it might not be needed.
rpi-update
# say "y" when it's asking you to.
# exit the chroot and turn off the device, remove the USB-SD and leave USB-SSD connected.
exit
halt
My first reboot the boot process threw errors about failing to mount the root fs.
We’ll need to update /etc/fstab with the correct partuuid.
# Boot from the (USB-)SD card again
# In my case sdb became sda and vice versa, so double check
lsblk
# be sure to select the right disk (the SSD, no the SD)!
mkdir /tmp/ssd
mount /dev/sda2 /tmp/ssd/
# And find the SSD here as well.
# look for the last column, partuuid, something like
"6f6cc2fb-01"
blkid
nano -w /tmp/ssd/etc/fstab
# edit the existing partuuid's with the ones from blkid
# you'll need to edit both /boot (-01) and / (root, -02).
halt
# When rebooting from the SSD it'll go through a fsck. In my case for some reason it failed and dropped to a shell. I did a manual check and everything was fine. Rebooted and it booted normally... *shrug*
Booting
At this stage booting from the USB-SSD should work just fine. You have a working system booting from USB.
It’s working! Now I can configure my system.
Overclocking
Last thing I’d recommend is getting a bit more juice out of your four cores.
You can quite easily overclock the RPi4 to 2Ghz (per core). It’s a pretty nice boost (~25%) and worth going for. I haven’t seen any heat issues leading to underclocking (throttling back), and everything runs stable. Note that under real circumstances you are unlikely to be running at 100% for extended period of times.
This guide explains how to overclock Raspbian (but the same applies for Ubuntu RPi — I’ll eventually be using Ubuntu as the OS due to its 64 bit support; at the moment Raspbian only supports a 64 bit kernel (beta) and the userland still runs 32 bit. But that’ll be a follow-up article.
The gist of the article is to edit /boot/config.txt and add:
over_voltage=6
arm_freq=2000
Save the file, reboot and monitor temp (echo $((cat /sys/class/thermal/thermal_zone0/temp/1000))) and core frequency (watch -n 1 vcgencmd measure_clock arm) while running stress -c 4 to make sure the cores are running at 100%.
Raspberry Pi 4 running at 2Ghz. It never throttled back after running for ~30 minutes.
Resilio Sync released an update last week and on Synology these package don’t auto update. Time to manually update the packages again.
On my DS1515 (more RAM, more CPU) the manual update goes by fine (stop service, manual update, browse for file, upload, start service) but my DS216j, not so much.
Attempting to upload the file instantly fails with the useful error “Operation Failed”.
I tried to re-download the file (was it corrupt)… Nop. Did I select the right architecture? Yep. Decided to give it a go via via the command line. Perhaps a reboot? Nop.
First, make sure SSH is enabled and you can SSH. Oh and pro tip: add your SSH key.
Something along these lines should get you started:
# Transfer the file to the NAS
scp *.spk NAS-IP:
# Connect to the device
ssh [email protected]
# Install it as root using sudo. It'll ask for your psw
sudo synopkg install *.spk
[password]
# resiliosync_armada38x_DSM6_2.7.0.1366-1.spk install successfully
# All good? Then remove the installer
rm *.spk
Somehow this worked… 🤷♂️ Not sure what caused the error in the first place. I am guessing the device is a bit low on RAM.
I live in Singapore. And haze is a thing. Thanks Indonesia and burning rain forests to create palm plantations. Needless to say, so far 2019 and 2020 haven’t been great.
Anyhow I got myself a Novita air purifier ~2 years ago, and I stole received a Xiaomi purifier from Liyun.
The Novita is pretty dumb (the PM sensor goes randomly nuts and it needs to be quite polluted before it really kicks in. It also needs to be turned off/on again every so often for it to keep on standby — if not it goes into some sleep mode).
The manual says you should consider cleaning (aka remove dust and cat hair) every 3 or so months, and replace the filter every 6 months. It’ll show a warning when the timer hits zero.
Selling new filters is how they make money I guess.
Buy a new filter (or don’t and use the same filter), reset the timer and things are back to normal.
For the Xiaomi it’s a bit harder. The “smart filter” is really just a HEPA filter with an NFC tag. It’ll calculate how often the purifier runs and calculate a % based on that. I’ve now hit 0% left on my filter after a haze season (September 2019) and ~8 months of normal usage (as it’s in the bedroom, it starts filtering around 21h00, and then runs in the quiet night mode until 9am next morning and then shuts off).
While the purifier still runs at 0%, it gives a big red warning both in the app and on the device itself and urges you to replace the filter.
You can tape off the NFC tag with some tinfoil, but that’ll just change the big red warning from “used and old filter, please replace” to “fake filter, please replace”.
Now I am not against replacing HEPA filters when they are used and are not actually filtering the air anymore. But I am also against uselessly replacing things for the sake of handing money to $BigCorp and ruining the planet with it.
Running a few tests with a relatively precise PM sensor (use this assembled kit if you are not into DIY) shows that for both my purifiers, the exhuast air is 0 PM1.0, 0 PM2.5 and 0 PM10. So that shows me that both are still working and cleaning the air just fine (further away in the room, the PM heads up to 10-20 on haze-free days).
Am I missing something here? Why throw away something that still works?
The Resilio Sync package that’s provided on a Synology NAS’ Packager Center is out of date (2.6.2) and has a bug that causes big files to fail to sync (and that causes a loop of endless retries).
The solution is to manually update the package from 2.6.2 to 2.6.4. Find your NAS architecture and then download (bottom of the page) the right binary and manually install it.
Note that you need to stop the Resilio Sync service running (manually stop it via Package Center) before uploading the package and installing it.
Once done, don’t forget to manually start the service again.
Resilio Sync GUI will be at <NAS IP>:28888/gui/.
The howto guide to manually update the package can be found here.
