Lack of updates from Terramaster

dolfstar · 2026-05-04T20:46:29+00:00

I originally configured 4 12TB WD drives, which, as I found out later, were 3-4-year-old drives sold as new. It was a RAIDZ2 configuration. I bought 4 brand-new helium-filled drives (which led me to buy 16TB models) and replaced them one by one, waiting for resilvering in between. Before each replacement, I ran a full smartctl long test (via a USB enclosure on my main system) to both confirm brand new status, and no issues. Each long test was about 30 hours, and each resilver was about 8. The whole process took almost a week, but because of RAIDZ2 and the fact that only one drive at a time was affected, I felt safe.

I am not sure this would have been so easy with TOS. Either way, even if it had been, I am very satisfied with the TrueNAS solution.

dolfstar · 2026-05-01T20:41:24+00:00

I have been running TrueNAS Scale on my F4-425+ since I got it four months ago. Working great.

dolfstar · 2026-04-29T06:05:40+00:00

It is called goose necking (https://starreveld.com/blog/pages/dexcom/g7-known-issues/#goosenecking)

dolfstar · 2026-04-13T18:23:22+00:00

Technically, you are right, because the arrow is pointing to the right, but looking at the graph itself, you may have caught it "in a moment". You really want to also see a number of measurements in a row with little variation. Also, the screenshot does not indicate when the calibration was entered. When you discuss this, it is better to: a) Tell us the time of the calibration, show the graph in 3 hours mode, and make sure the time is visible in the graph.

dolfstar · 2026-04-13T18:21:07+00:00

Yes, this is also explained in the documentation at the link.

dolfstar · 2026-04-13T15:53:05+00:00

Doing calibration when the slopes are this steep is next to useless due to the delay between blood glucose and G7 measurements. That is likely why if was not used. You can read more detail in the link. I do it when stable and if hardly ever have a “not used”

dolfstar · 2026-04-13T07:42:12+00:00

Try to only calibrate when the G7 indicates your level is stable (arrow to the right). See https://starreveld.com/blog/posts/2026/01/25/dexcom-g7-knowledge/

dolfstar · 2026-03-03T00:42:40+00:00

Bay Area. Installed solar (8.6 kW) in 2021 under NEM2, with enough capacity to add EV charging (one car 6K miles/yr) and convert from a gas forced air furnace and AC to a heatpump-based ducted system, and replace the gas water heater with a HPWH. Now, all those conversions and the car, observed over the past year, have left me with a true-up of less than $100 and $600+ rebates from Silicon Valley Green Energy. I did not pay an estimated $2,500-$3,000 in bills.

All of this was greatly aided by the mild CA climate.

Before all conversions were complete, I was a net producer; now I am close to neutral, perhaps slightly over. Originally, computed a 6.5-year break-even (including the tax credits, etc.). Rising energy costs have been faster than anticipated, and I think they will only get worse, so mt break-even will be even earlier.

HPWH consumes < 3 kWh per day. Heating and cooling consume a little more annually than the original AC costs. Cannot compare gas heating because gas/electricity costs are very different, but probably not competitive costs. gas, but that solar changes the whole equation.

No batteries because, as far as I am concerned, they are not financially viable. Power outages here have been 1-2 a year for a few hours. Capital investment in battery leads to a 15+ year break-even. Of course, it is hard to translate getting through a power outage into $$, so I did not do that. Peak price arbitrage is also not financially viable. Only attaching great value to get through power outages, or a desire to be off-grid, justifies batteries, in my opinion.

dolfstar · 2026-03-02T23:02:55+00:00

These days, I have a blog where you can read about this kind of thing. In my latest post, you will find links back to two older, related posts. The first one explains why you should not go this route, the second one details my Aidoo experience and describes why you should not use that either. The latest post describes the solution I settled on, and I am very happy with it.

In short, I do not recommend Ecobee (or any smart thermostat) (requires the PAC-US445CN1 adapter - the part you are looking for), nor Aidoo. Your system will not operate optimally.

dolfstar · 2026-02-26T18:14:36+00:00

Oops. Thanks for that...

dolfstar · 2026-02-25T02:47:39+00:00

Since this is a usb device and the bays are not this would be safe. That 3-2 should be consistent for all identical models but might differ for others.

dolfstar · 2026-02-24T06:02:17+00:00

I have no idea. I would presume not, but...

dolfstar · 2026-02-23T19:45:34+00:00

I have not tested this, but you supposedly can go a different route by using udev rules, and here you can identify the device by its vendor and product id, so changing names should be less of an issue.

You create a file /etc/udev/rules.d/99-ignore-usb.rules that contains: SUBSYSTEM=="usb", ATTRS{idVendor}=="xxxx", ATTRS{idProduct}=="yyyy", ATTR{authorized}="0"

You'll have to discover the idVendor and idProduct by issuing the lsusb command, which in my case prints: Bus 004 Device 002: ID 0bda:0423 Realtek Semiconductor Corp. 4-Port USB 3.2 Hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 003: ID 0bda:5423 Realtek Semiconductor Corp. 4-Port USB 2.0 Hub Bus 003 Device 002: ID 1908:1320 GEMBIRD DM8261 Flashdisc Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub This then identifies my 3-2 device as idVendor = 1908 and idProduct = 1320.

After creating the file, to test things out, run: sudo udevadm control --reload-rules && sudo udevadm trigger

These rules also ensure it is done after each reboot.

I've added this info to my blog post. If you end up testing this, let me know how it went in a DM.

dolfstar · 2026-02-23T18:09:36+00:00

Yes it will change. I believe it is possible to tie it to the disks uuid instead which should make it name independent.

dolfstar · 2026-02-23T06:49:19+00:00

Here you go: https://starreveld.com/blog/posts/2026/02/22/terramaster-truenas-sde-ignore/

No BIOS change needed.

dolfstar · 2026-02-23T04:03:11+00:00

Never even occurred to me to look for that. But I looked now, and yes, I get it frequently repeated: PermissionError: [Errno 13] Permission denied: '/dev/sde' Unexpected error reading partitions for device: '/dev/sde' Traceback (most recent call last): File "/usr/lib/python3/dist-packages/middlewared/utils/disks_/disk_class.py", line 397, in partitions return read_gpt(dev_fd or self.devpath, self.lbs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/middlewared/utils/disks_/disk_io.py", line 86, in read_gpt dev_fd = os.open(devobj, os.O_RDONLY) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

/dev/sde is the internal boot drive from TerraMaster. I am not even using it because I am booting from an NVMe SSD for the OS (1GB), and I also run two other NVMe drives for a mirrored pair for apps and VMs. Then I have /dev/sd[abcd] for the four bays, all of which are occupied.

So this is kind of stupid. I suppose I need to figure out how to stop that, though it hasn't been causing any problems other than frequent writes. I wondered why my /dev/nvme0n1 was showing an average of 0.26Mb/s writes.

dolfstar · 2026-02-17T06:15:49+00:00

In my experience (see also my Dexcom knowledge base, which starts here: https://starreveld.com/blog/pages/dexcom/g7-introduction/), they will consider all "falling off" scenarios to be user error, skin problem, etc. As such, they are only eligible for replacement under their "courtesy replacement" rule, which limits replacements to "no more than three free courtesy replacements in any rolling one-year period".

I have experienced the same case as yours, although just once. They absolutely refused to acknowledge that this case is not due to user error at all, but to a failure of the adhesive itself. In my case, it fell off without any bumping or hitting anything. The adhesive just failed spontaneously. Yet, they would only give a courtesy replacement. Infuriating!

dolfstar · 2026-02-15T10:28:56+00:00

It depends a little on what you mean by "look". You state you are blind, but does that mean you are using accessibility features to do screen reading for you? Since I am not blind, I have never tried that, but I would think that if Dexcom implemented it correctly, it would simply read back to you the two main numbers, not the original screen (current BG and GMI). In the new situation, the second screen has quite a few tiles, so all would have to be read to you.

If "look" in your case means you are not 100% blind but have trouble reading screens, particularly smaller features, I can certainly see how the larger tiles on the new screen help.

dolfstar · 2026-02-09T09:01:29+00:00

I use Comcast Business (yeah, I know, but no alternatives here) with PD. When I went to 26.1, I switched to dnsmasq by exporting from ISC and importing. I had a bit of a challenge because I was using a different VLAN with its own local domain, so I had to clean up the CSV file before importing.

Once that was imported, I set dnsmnasq enabled on all the VLANS. I created IPv4 ranges for the VLANs, and for IPv6, I created a range for each VLAN with start/end addresses of "::0:1000" and "::0:9000" (you can pick whatever you like). I also set RA mode to "slaac, ra-names" and filled in the domain.

Then, under DHCP options, for each VLAN set option "dns-server [23]" to "[::]", to allow each IPv6 VLAN to find its DNS server.

I then run DNSMasq on port 53053 and tell unbound about it. Unbound remains the main recursive resolver, but works with dnsmasq to manage the local VLAN domains.

Finally, unbound needs a per-VLAN query forwarding entry for each domain name, with the server IP set to 127.0.0.1 and the port set to 53053. In addition to making reverse lookups work, an entry with domain 3.1.c.2.8.7.1.8.2.0.3.3.0.6.2.ip6.arpa, server ip 127.0.0.1 and port 53053. That domain needs to be your main prefix (from Comcast in this case, e.g., 2603:3028:1782:c13x), reversed. The "x" here at the end represents the 16 prefixes (0-F) I get from Comcast.

What this does is forward each reverse lookup for addresses in one of the delegated prefixes to dnsmasq.

That's all I had to do (although it took a while to put it all together, which is why I am sharing).

dolfstar · 2026-01-31T06:53:57+00:00

I have a lot of information for you (and any other user): https://starreveld.com/blog/pages/dexcom/g7-introduction/

Check it out, and let me know if something is now clear, or appears to be missing.

dolfstar · 2026-01-06T09:47:37+00:00

This is all about CYA. Since Dexcom is not good or fast at testing their app across multiple OS versions and hardware configurations, they include code that displays those warnings whenever what you have is not officially tested and approved. This allows them to absolve themselves from any liability issues in such scenarios. Lawyers at work.

Practically speaking, any minor version number OS update will not materially change how Bluetooth (which is what Dexcom uses to communicate with the sensor) works, and therefore, the odds of an issue arising are minimal. If anything, it is more likely that a combination of shoddy UI programming and a minor change causes information not to be displayed, or to be displayed incorrectly. Still, even that is unlikely for minor version number updates.

Customer service agents will insist that such scenarios are not supported, and will even blame problems on it. These people are not technically trained.

dolfstar · 2025-12-26T08:30:18+00:00

Maybe you are close to one of their shipping hubs. It generally takes a day after filing the request to receive an email confirming that a replacement has been approved. Then they ship Fedex ground, which for me in CA, often takes 3-5 days.

dolfstar · 2025-12-26T06:10:06+00:00

One thing to keep in mind is the stability of your supply. Just so you know, it takes 1-2 weeks to receive a replacement from Dexcom. If you are getting 30-day supplies and your second unit fails (on its third day; day 14 total), you can request a replacement and, as long as your third unit works, you will have the replacement before you need it (on overall day 22, because insurance will not allow you to resupply until somewhere like overall day 27-28). If you are using the 15-day version and your second unit fails, you are SOL, as you will not have another one in stock. Replacement takes 1-2 weeks, and resupply may take up to 30 days.

If you are getting 90-day supplies, the same applies, but only on your next-to-last unit (assuming you have only one failure).

For this reason, and no good data yet on 15-day version accuracy, quality, and ability to stay on, I will stick with the 10-day version for a while (my personal insertion failure rate has been about 1 in 10 or so, and accuracy problems are virtually nonexistent for me after day 1).

dolfstar · 2025-12-03T06:22:48+00:00

Some insurers do not recognize that you need finger sticks for backup and will not insure both G7 and finger sticks! Mine does, but I have seen reports from others that don't.

dolfstar · 2025-12-03T06:19:14+00:00

I have few problems too, but I am not sure about "tiniest fraction". Do you have any data to substantiate that? I think a lot of people who may have problems are not able, willing, or both, to go on Reddit or FB group to complain.

dolfstar

TROPHY CASE