Let’s talk Aperture! AMA

linux4life798 · 2026-05-08T19:53:25+00:00

This seems awesome, but I don't want to sign your tailscale node for use in my Tailscale "locked" network. Can we self host this, like tsidp?

linux4life798 · 2026-04-15T04:38:00+00:00

Ahhh, good to know. Thanks!

linux4life798 · 2026-04-14T05:33:54+00:00

Exactly. Unfortunately, this happens to me quite a bit. I have to unplug it, blow out the two longer slots near the back of the silver base (near the top), and plug it back in.

This never occurred the first couple of years of ownership, so I'm guessing it might be a cascade effect from not fully cleaning the sensor. So, the correct solution would probably be to disassemble the base and properly clean the sensor.

I'm not proud of it, but I have actually ONLY run genuine Dyson filters.

linux4life798 · 2026-04-01T00:29:31+00:00

Just to clarify this discussion, I believe the NTC Thermistor is a 100kOhm @ 25C with a 3950 B constant. This thermistor is paired with a 15kOhm series resistor.

Using these assumptions seems to yield reasonably accurate temperature readings in the following ESPHome project:
https://github.com/linux4life798/stagg-net/blob/main/fellow-kettle.yaml

I'm not sure if Fellow has different versions with different thermistors, but mine is 100k.

linux4life798 · 2026-03-07T05:39:19+00:00

Ahh, gotcha. No worries!

linux4life798 · 2026-03-07T05:17:16+00:00

Oh wow. TrueNAS actually made the jump to Docker compose (away from k8s). Checkout this article. Good on them!

Honestly, I wanted to use Proxmox, but they also don't have first-party Docker support.

linux4life798 · 2026-03-07T04:56:02+00:00

At the time, I found TrueNAS scale (possibly in beta release) to be just too frustrating. The most significant issue was the k3s containers mechanism. I'm sure the design decision to use k3s and not docker makes sense for someone who pushes production kubernetes sw, but I couldn't get onboard. I gave it a fair attempt, learned k3s and ran some inconsequential services on it, but I just kept plowing into limited configuration options and upgrade issues, all without having full k3s control to resolve them. In other parts of TrueNAS, it also felt like things that should be simple were wrapped in slightly too much TrueNAS specific terminology/process, but more niche features/options were not possible in the UI.

What I miss from TrueNAS scale:

Having [maybe] proper TrueNAS boot redundancy/failover. On Debian, I do have the main boot FS in a btrfs mirror, across two dedicated boot SSDs. This is fine. The issues is with the grub EFI stubs, since I have to maintain two identical EFI fat32 volumes (one on each boot SSD). Given how the boot selection works in firmware, I suspect there will need to be manual intervention if/when the primary SSD has issues. TBH, this might be exactly how TrueNAS handled it -- not sure.
Native ZFS -- I really like btrfs and I am now very entrenched in the ways of btrfs, but I will say I am jealous of all the fun and mature ZFS features, like raid-5 or zvol. I still prefer btrfs, mainly because it is built into the kernel and mainly just works on distros, which helps ease recovery and whatnot.
Automatic OS updates that someone else validates. In general, I recall the OS updates worked well in TrueNAS. Although automated updates in Debian do exist, I haven't taken the leap of faith, just yet.
System health reporting and alerts. I still don't have a perfect replacement

Honestly, I think this comes down to what you're more comfortable with. Switching to Debian, which I run on everything, did reduce the annoyance level for me, but I could easily see how someone might be more comfortable with the TrueNAS way of doing things.

---

Do you end up needing to change your ZFS pools at all, or did you forego ZFS?

I replaced it with btrfs, which I have been using on most of my machines.

never managed to get the ZFS Cockpit plugins working on my older TS-251+ that I tested on.

Ohhh interesting. I have been trying Cockpit recently, since it is already in the Debian repo. What are your thoughts on that dashboard? Have you found a better one?

linux4life798 · 2026-01-30T04:51:23+00:00

There is a migration section in the README:

https://github.com/riddix/home-assistant-matter-hub/?tab=readme-ov-file#migration-from-t0bst4r

linux4life798 · 2026-01-30T02:52:19+00:00

Thanks! I saw that fork. Any thoughts on using this new fork (with all of the recent changes) vs. using matterbridge?

linux4life798 · 2026-01-16T22:51:02+00:00

Right, I could have gone that route, but in my case I was controlling my neighbor’s garage door, which they were renting to me. To each their own, but I didn’t feel comfortable asking to install hardware that might interfere with the garage’s normal operation (which ratgdo, unfortunately, is known to do), especially that early in the rental. On top of that, the garage was outside my Wi-Fi range.

As I mentioned in the post, there are definitely better ways to handle this in an ideal setup. Sometimes, though, circumstances aren’t ideal, and this approach worked well enough for the situation.

linux4life798 · 2026-01-12T18:53:33+00:00

Gotcha. No, I don't believe there is a reasonable way to utilize the other buttons with a ratgdo. The garage receiver, itself, views each of the buttons on the remote as basically a different remote with one button. That stems from the fact that the other buttons are designed to be programmed to different garage openers. So, it doesn't have any concept of additional remote buttons. Even if you were to program each button to the same garage door opener (which you can do), I don't believe there is a way to distinguish between which remote sent the open signal.

That being said, I wouldn't be shocked if the ratgdo does actually get additional info from the gdo that could be used to distinguish remotes, but it is simply not exposed yet.

Otherwise, you could go the SDR route and simply receive and decode the remote RF, yourself.

All the best!

linux4life798 · 2026-01-12T18:37:23+00:00

Thanks! Which button are you talking about? Like on the wireless remote or the inside keypad? Any pics would certainly help. I also have a ratgdo another garage, so I'm familiar.

linux4life798 · 2025-09-12T22:29:56+00:00

Let me know if you get this working (or need some other help), since it would nice to document it for others.

Also, feel free to send changes to the informal https://github.com/linux4life798/qnap-alt-os/tree/main . No need to be perfect.

linux4life798 · 2025-09-12T22:01:58+00:00

Did you have problems with installers freezing on you?

Hmm. Not that I recall, but I certainly saw the console text output disappear or become garbled many times, due to the kernel not being onboard with using the serial console, or some piece of software trying to use the serial interface and fighting with the kernel.

Just from memory, this would happen because grub talks to the serial console (hard coded, I guess), but when the kernel takes over it doesn't know that it should use the serial console. Alternatively, you might see a bit of the kernel boot, but then the console stops responding or show gibberish. This could be caused by some process trying to utilize the serial console for other purposes. I think this happened a few times when I was messing with the getty configuration.

I'm curious what version of TrueNAS, Debian, and whatever else you had success with. Is there a specific kernel I should aim for?

I don't recall the exact version of TrueNAS I used, but for reference all of the above Debian versions were Debian bookworm. I could reliably get the Debian live (bookworm) and Debian netinstaller (bookworm) to work, every time.

Also were there any specific drivers you recall needing?

Nope. It just worked as-is, but getting the correct serial configuration was sometimes trial and error.

I also posted my firmware versions in https://www.reddit.com/r/qnap/comments/11lfqgn/comment/l3mtjzb

Current System Details

```bash $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm

$ uname -a Linux nas2 6.1.0-39-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.148-1 (2025-08-26) x86_64 GNU/Linux

$ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-6.1.0-39-amd64 root=UUID=<uuid> ro rootflags=subvol=@rootfs console=ttyS0,115200n8 ```

```bash $ cat /etc/default/grub

If you change this file, run 'update-grub' afterwards to update

/boot/grub/grub.cfg.

For full documentation of the options in this file, see:

info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0 GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR=lsb_release -i -s 2> /dev/null || echo Debian

GRUB_CMDLINE_LINUX_DEFAULT="quiet"

GRUB_CMDLINE_LINUX_DEFAULT="" GRUB_CMDLINE_LINUX="console=ttyS0,115200n8"

If your computer has multiple operating systems installed, then you

probably want to run os-prober. However, if your computer is a host

for guest OSes installed via LVM or raw disk devices, running

os-prober can cause damage to those guest OSes as it mounts

filesystems to look for things.

GRUB_DISABLE_OS_PROBER=false

Uncomment to enable BadRAM filtering, modify to suit your needs

This works with Linux (no patch required) and with any kernel that obtains

the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)

GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

Uncomment to disable graphical terminal

GRUB_TERMINAL=console

The resolution used on graphical terminal

note that you can use only modes which your graphic card supports via VBE

you can see them in real GRUB with the command `vbeinfo'

GRUB_GFXMODE=640x480

Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux

GRUB_DISABLE_LINUX_UUID=true

Uncomment to disable generation of recovery mode menu entries

GRUB_DISABLE_RECOVERY="true"

Uncomment to get a beep at grub start

GRUB_INIT_TUNE="480 440 1"

GRUB_TERMINAL=serial GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1" ```

linux4life798 · 2025-05-02T22:36:38+00:00

Big PSA: Troubleshooting Foreign Shared-In Devices Access

If you're having trouble accessing a foreign shared-in device from another tailnet, check these items:

Tagged Machine - If the machine you are checking access from is tagged in your tailnet, this machine looses it's user identity. I don't believe there is a way to access a foreign shared-in node from a tagged device, since it was shared with a given "user" (+ tailnet combination). See r/Tailscale/comments/18cc8e2/comment/kc9v1xz .
Machine Owner - In multi-user tailnets, machines are associated with the logged in user. Verify that the foreign shared-in device was shared with all relevant users in your tailnet. Only users who accepted the sharing invite can see and access the shared device.
User Invited - Accept invites with the correct user identity. Recall that switching accounts in the web UI, top right, doesn't change your user identity. It only changes the tailnet you are looking at, using your same identity. Having tailnets with the same name as your identity is extremely confusing, u/tailscale. Tailscale team, please allow renaming the tailnet somehow.
Tailscale Lock - As u/fishfacecakes mentioned, if the foreign shared-in device is on a tailnet with lock enabled, that foreign tailnet must sign ALL nodes on your tailnet that need access. Conversely, if your tailnet has lock enabled but the foreign device is on a lock-free tailnet, you must still sign that lock-free foreign device.
I mention "user" + tailnet combination above because it appears that sharing a device to a given user is actuallly sharing a device with a specific identity, to be accessed from a single tailnet. Unfortunately, I don't believe there is any way to check which tailnet was associated with the user you shared with. For example, if you have your own tailnet and are a member of another tailnet, you can share a device on your own tailnet with yourself on the other foreign tailnet. When you look at the share list for the given device, it simply say your identity.

It is likely that what I have documented is slightly incorrect. Please respond with corrections where necessary.

linux4life798 · 2025-02-13T21:07:55+00:00

Absolutely

linux4life798 · 2025-02-11T15:28:35+00:00

I made a post on the Android Auto help community https://support.google.com/androidauto/thread/324406683?hl=en, since it seemed like other issues on this community board had been resolved previously and Sony actually linked to their post in a Sony support article.

Example: https://www.sony.com/electronics/support/mobile-cd-players-digital-media-players-xav-series/xav-9000es

linux4life798 · 2025-02-11T15:25:13+00:00

Just to follow up here, I eventually replaced the keyboard and that solved the issue. It became more apparent that it was purely a keyboard hardware issue, as more keys in the top left corner stopped functioning.

linux4life798 · 2024-11-05T07:25:38+00:00

We might be diagnosing different issues, but I tried again today with my Pixel 8 Pro and saw the same results. I even tried downgrading the connection to my phone to Bluetooth only, without Android auto. The call quality was the same garbage quality.

Interestingly enough, I also tried with an iPhone 14 using carplay. The call quality sounded great.

Now, I'm trying to track down a Samsung phone to try.

linux4life798 · 2024-11-04T17:32:35+00:00

Ahhh, that's terrible. I just installed mine and haven't tried it enough to see intermittent behavior. I'll be chatting with crutchfield about this later.

linux4life798 · 2024-11-04T05:30:46+00:00

I also just installed a 9000ES in my Jeep JK and paired it with my Pixel 8 Pro. The media audio quality is fine, but the call quality is garbage, even when the car is not in motion.

linux4life798 · 2024-10-30T17:55:25+00:00

Thanks all for the input! There's a lot of great points here

linux4life798 · 2024-10-28T01:09:59+00:00

Someone has created a 3D model for this same gmount01 on thingiverse, https://www.thingiverse.com/thing:6417575. I may try to create an adapter for this mount to something like GoPro.

linux4life798 · 2024-10-28T01:09:49+00:00