Archive for category Software
The picture also shows a defunct Sandisk Extreme Plus killed by continuous video recording in my Fly6 bike camera. I later replaced the EVO with a video-rated Samsung card which has been running fine ever since, albeit with the occasional crash-and-reformat expected with “action” cameras.
With that as background, a different Samsung EVO card from the same batch has been running the MPCNC’s Raspberry Pi for about a year. Over the course of a few days last week, the RPi went from an occasional stall to a complete lockup, although waiting for minutes to hours would sometimes resolve the problem. As I’ve learned by now, it’s not a software crash, it’s the controller inside the card suffering from write amplification while trying to move data from failing sectors.
f3write to the card shows the problem:
The write speed started out absurdly high as the card’s write cache fills, then slowed to to the flash memory’s ability to absorb data, and eventually ran out of steam during the last few files.
But, as you might not expect,
f3read reported the data was fine:
sudo f3read /mnt/part F3 read 7.0 Copyright (C) 2010 Digirati Internet LTDA. This is free software; see the source for copying conditions. SECTORS ok/corrupted/changed/overwritten Validating file 1.h2w ... 2097152/ 0/ 0/ 0 Validating file 2.h2w ... 2097152/ 0/ 0/ 0 Validating file 3.h2w ... 2097152/ 0/ 0/ 0 Validating file 4.h2w ... 2097152/ 0/ 0/ 0 Validating file 5.h2w ... 2097152/ 0/ 0/ 0 Validating file 6.h2w ... 2097152/ 0/ 0/ 0 Validating file 7.h2w ... 2097152/ 0/ 0/ 0 Validating file 8.h2w ... 2097152/ 0/ 0/ 0 Validating file 9.h2w ... 2097152/ 0/ 0/ 0 Validating file 10.h2w ... 2097152/ 0/ 0/ 0 Validating file 11.h2w ... 2097152/ 0/ 0/ 0 Validating file 12.h2w ... 2097152/ 0/ 0/ 0 Validating file 13.h2w ... 2097152/ 0/ 0/ 0 Validating file 14.h2w ... 2097152/ 0/ 0/ 0 Validating file 15.h2w ... 2097152/ 0/ 0/ 0 Validating file 16.h2w ... 2097152/ 0/ 0/ 0 Validating file 17.h2w ... 2097152/ 0/ 0/ 0 Validating file 18.h2w ... 2097152/ 0/ 0/ 0 Validating file 19.h2w ... 2097152/ 0/ 0/ 0 Validating file 20.h2w ... 2097152/ 0/ 0/ 0 Validating file 21.h2w ... 1322894/ 0/ 0/ 0 Data OK: 20.63 GB (43265934 sectors) Data LOST: 0.00 Byte (0 sectors) Corrupted: 0.00 Byte (0 sectors) Slightly changed: 0.00 Byte (0 sectors) Overwritten: 0.00 Byte (0 sectors) Average reading speed: 43.04 MB/s
Obviously, the card’s read speed isn’t affected by the write problems.
Assuming the actual data & programs on the card were still good, I slurped the partitions:
sudo partimage save /dev/sdf1 mpcnc_boot.gz sudo partimage save /dev/sdf2 mpcnc_partition.gz
And wrote them back:
sudo partimage restmbr mpcnc_boot.gz.000 sudo partimage restore /dev/sdf1 mpcnc_boot.gz.000 sudo partimage restore /dev/sdf2 mpcnc_partition.gz.000
Unshown: a finger fumble requiring MBR restoration.
Having forced the card controller to reallocate all the failed sectors, the card works now fine and runs at full speed again. This won’t last long, but it’ll be interesting to see how it plays out.
While I was at it, I wrote the partitions to a new-ish / unused Samsung EVO Plus card, now tucked under the MPCNC’s monitor in case of emergency.
An old SFF Optiplex with an SSD may be a better fallback.
It turns out the Spirograph patterns I’d been using to wring out the MPCNC are also known as Guilloché, perhaps after the guy who invented a lathe-turning machine to engrave them. Sounds pretentious, but they still look nice:
With the ballpoint pen / knife collet holder in mind, I stripped the tool changes out of the Spirograph generator GCMC source code, set the “paper size” to a convenient 100 mm square, and tidied up the code a bit.
As with Spirograph patterns, changing the random number seed produces entirely different results. A collection differing in the last digit, previewed online:
Seed = 213478836:
Seed = 213478837:
Seed = 213478838:
Seed = 213478839:
They’re such unique snowflakes …
The Bash script now accepts a single parameter to force the PRNG seed to a value you presumably want to plot again, rather than just accept whatever the Gods of Cosmic Jest will pick for you.
The GCMC source code and Bash (or whatever) script feeding it as a GitHub Gist:
A trio of Cutter Cutting Plotter Blade Holders arrived:
Despite the name, they’re not well-suited for drag knife blades, because they’re collets gripping a 2 mm shaft. The blade doesn’t rotate unless the plotter / cutter rotates the entire holder, which is actually a thing.
I got ’em because the snout of a common ball-point pen refill measures about 2 mm:
The glob around the tip comes from plotting too fast for conditions; about 1500 mm/min works better for continuous lines and 250 mm/min improves text.
The stock MPCNC adapter has a single recess suited for Genuine Plotter Pens, but the knurled lock ring on these cheapies sticks out far enough to make them wobbly. This being an inconvenience up with which I need not put, a few lines of OpenSCAD tweak the stock STL:
The original STL is ivory, new cuts are cyan, and additions are reddish.
The two support beams are now 1.6 mm = four thread widths, for improved slicing with a 0.35 mm nozzle and a higher spring constant.
It’s by-and-large indistinguishable from the old adapter:
Which I was using upside-down, because the flange fit better.
The MPCNC works reasonably well as a pen plotter with a genuine ballpoint pen:
The OpenSCAD source code as a GitHub Gist:
With none other than Troy Hunt recommending Pi-Hole, I got a Round Tuit:
unzip 2018-06-27-raspbian-stretch-lite.zip -d /tmp sudo dcfldd status=progress bs=1M of=/dev/sde if=/tmp/2018-06-27-raspbian-stretch-lite.img
Raspbian now arrives with
ssh disabled, so the first boot requires a keyboard and display:
Then do some configuration required to get a fresh Raspberry Pi ready for remote access:
sudo apt-get update sudo apt-get upgrade sudo apt-get install screen iotop sudo raspi-config # enable ssh ssh-keygen -t rsa cd ~/.ssh cp -a /my/public/key authorized_keys chmod go-rwx authorized_keys cd sudo nano /etc/ssh/sshd_config # unusual port, no root login, etc sudo service ssh restart
As the good folks at Pi-Hole say, “Piping to bash is controversial, as it prevents you from reading code that is about to run on your system.” I took a look, it’s beyond my comprehension, so just get it done:
curl -sSL https://install.pi-hole.net | bash
- Static IP: 192.168.1.2/24
- DNS using, say, Cloudflare’s 18.104.22.168
- DHCP turned off, which is the default
Configure the router’s DHCP to hand out the Pi-Hole’s IP, with, say, 22.214.171.124 as a backup.
Boot a few random PCs and whatnot to verify it works as expected, which it did the second time around, thus this particular post.
mkdir Downloads cd Downloads/ wget https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-arm.tgz tar zxvf cloudflared-stable-linux-arm.tgz sudo mkdir /opt/cloudflare sudo cp cloudflared /opt/cloudflare/
Start the daemon from within a
screen session, also as suggested:
sudo /opt/cloudflare/cloudflared proxy-dns --port 54 --upstream https://126.96.36.199/.well-known/dns-query --upstream https://188.8.131.52/.well-known/dns-query INFO Adding DNS upstream url="https://184.108.40.206/.well-known/dns-query" INFO Adding DNS upstream url="https://220.127.116.11/.well-known/dns-query" INFO Starting metrics server addr="127.0.0.1:37777" INFO Starting DNS over HTTPS proxy server addr="dns://localhost:54"
Contrary to the suggestions, you can configure Pi-Hole to use the DoH tunnel (or whatever it’s called) by tweaking its upstream DNS configuration:
Then set up
systemd to start the daemon automagically:
sudo nano /etc/systemd/system/dnsproxy.service
Because I put the daemon in
/opt/cloudflare, that file differs slightly from the suggestion:
[Unit] Description=CloudFlare DNS over HTTPS Proxy Wants=network-online.target After=network.target network-online.target [Service] ExecStart=/opt/cloudflare/cloudflared proxy-dns --port 54 --upstream https://18.104.22.168/.well-known/dns-query --upstream https://22.214.171.124/.well-$ Restart=on-abort [Install] WantedBy=multi-user.target
And then It Just Worked.
Controversies over the ethics of ad and tracker blocking will go nowhere here, as I’ve cleaned out enough Windows machines to have absolutely no sympathy with the unholy spawn of adtech (not just the company, which I didn’t know existed until just now, but, yeah, them too).
One of the scanners glowed brightly in the rack just inside the Stop and Shop:
A closer look:
If I understand this correctly,
CCRestart just crashed, so you must restart
CCRestart. The entrance of a deep rabbit hole looms behind the
The file extension and the overall UI make it reasonable to assume the scanners run Window CE, just like some voting machines.
To the best of my knowledge, the screen isn’t touch-sensitive. I passed up the opportunity to poke the buttons below the screen …
The Wyze Cam is a surprisingly inexpensive camera firmly lashed to the Wyze app, with no provision for ordinary IP camera streaming. It seems to be a generic camera with custom firmware and, unsurprisingly, one can commandeer the bootloader with different firmware from a MicroSD card, thereby adding missing functions and suppressing undesired actions.
Oddly, buying a genuine Wyze Cam directly from Wyze isn’t significantly more expensive than a generic from the usual eBay / Amazon sellers. Bonus: the legit camera arrives next week rather than in a month or two.
I found one of my few remaining 2 GB MicroSD cards, formatted it with a 512 MB (!) FAT32 partition (per the suggestions), set up the “custom firmware” bootloader, and installed it with no issues.
Installing the new firmware requires copying a directory tree, configuring the WiFi SSID and password in the usual
wpa_supplicant, and rebooting. Works fine and, yeah, the camera now runs Linux.
I told the router to assign a known IP address to the camera’s MAC address, set up port forwarding for port 8554 to that IP address, put the camera against the storm window in the kitchen, and rebooted everything to get it working:
Unfortunately, while it works more-or-less well with browsers on the local network, it’s apparently inaccessible from outside. The router manages a DDNS name-to-IP mapping to make itself findable, the port is open, the forwarding seems correct, no image data arrives to browsers outside, and they eventually time out.
Changing to port 8080 doesn’t help, nor does using MJPEG instead of H264 encoding.
Even more unfortunately, the router doesn’t do hairpin connections (inside to outside to inside), so I can’t debug this mess from the Comfy Chair.
This is a placeholder for what I’ve done while I accumulate more knowledge …
So this happened:
As far as I can tell, the Crucial M5500 SSD in that PC (an off-lease Dell Optiplex 760) stopped being a SATA hard drive, although it seems to work OK when jammed in a USB adapter.
So I picked up a new-to-me Optiplex 9020 with Windows 8.1 on an SSD, shrank the partition, tried to install Xubuntu 18.04, fat-fingered the UEFI password dance, reinstalled Windows from the SSD’s recovery partition, and got this display after a while (clicky for more dots):
After letting it stew in its own juices during supper, I forced it off (pushed the power button until it died), restarted, got through the UEFI dance, and it now seems All Good. I made recovery DVDs (remember DVDs?), both before and after the fumbled Xubuntu installation, but didn’t need them.
I expect we’ll never boot Windows 8.1 again, but it’s there Just In Case.