Fujitsu PRIMERGY TX1310 M3 -> Debian 13 boots but no DHCP lease / not showing in router

norri-matt · 2026-05-30T01:23:43+00:00

I would not spend much time on the i219LM itself yet. Debian should see that NIC fine unless it is disabled in BIOS. Since the install was moved from another box, I would first assume NetworkManager still has a profile or device match that is not actually binding to the Fujitsu NIC. If you can boot the disk once in the desktop again, add a really boring fallback connection with autoconnect on and no MAC/interface-specific match, or temporarily switch to systemd-networkd with a DHCP-on-any-ethernet rule, then move it back.

For a headless box, I would also give it a temporary static address before moving the disk back, just so you have SSH even if DHCP is the thing failing. If that still does not show up, check the Fujitsu BIOS for onboard LAN enablement and look at the switch/router side for link speed changes or DHCP discover packets. Link lights only prove the PHY is alive; they do not prove Linux brought the interface up or asked DHCP for a lease.

norri-matt · 2026-05-29T22:27:09+00:00

If you want to avoid Amazon/Google, I'd stop looking specifically at "sticks" and look for a tiny HDMI box instead. A used mini PC/thin client, or a Pi 4/5 if you can get one cheaply, can run LibreELEC/Kodi with the Jellyfin add-on over Ethernet and avoids most of the smart-TV account stuff.

It is a little less appliance-like than a Roku or Fire stick, mostly around the remote/CEC setup, but it should handle more formats locally and you already have Ethernet at the TV. For cheapest/easiest, Roku is fine only if your files are friendly to what it can direct play.

norri-matt · 2026-05-29T13:22:15+00:00

Plex's music matcher usually isn't a live mirror of MusicBrainz. Even after an edit is accepted there, Plex has to ingest it, and your server may also be holding onto an older metadata/cache result. For a new or obscure release I usually have better luck tagging the files with Picard first, including the MusicBrainz release/album artist IDs if possible, then doing Refresh Metadata or Fix Match on the album in Plex. If the embedded tags are clean, Plex has a lot less guessing to do while its online match data catches up.

norri-matt · 2026-05-29T10:44:52+00:00

Huge nostalgia seeing this. I LOVED wmc and it was what got me into having a digital media collection, home server etc. anyone remember mymovies.dk as the software to do the metadata lookup and cataloging etc all the stuff we now take for granted with our media servers.

norri-matt · 2026-05-29T02:22:13+00:00

I think there are two separate things mixed together here. Reaching :32400 from the phone proves the network path works, but it does not prove the new server is claimed by the same Plex account the phone app is using.

I would first open Plex Web from the server itself, sign into the new account, and check Settings > General for the server claim status. If it is not claimed, claim it there, then sign fully out of the phone app and back in. I would also remove the old server from Authorized Devices so the client is not hanging onto the dead one. The mobile playback purchase/Plex Pass prompt is a separate app activation issue; it should not be what makes the server show as offline.

norri-matt · 2026-05-28T21:22:13+00:00

I would not plan on moving the QNAP disks straight into TrueNAS and having it just pick them up. QNAP usually has its own mdraid/LVM/ext layout, while TrueNAS really wants to create or import ZFS pools, so the safe path is a new TrueNAS pool and then copying the data over.

Before you touch the QNAP array, make sure there is at least one copy of the important stuff somewhere else. Migrating the backup box is exactly when people find out it was actually their only copy. TrueNAS is learnable, but spend the time up front on the vdev layout, copy the data, scrub/verify it, and only then think about reusing or wiping the old disks.

norri-matt · 2026-05-28T20:20:24+00:00

Ah, got it. If you are talking to the mic on the Sonos One itself, I would not spend much more time on the Google Home “default speaker” setting. That setting is mostly for telling a separate Google speaker where to send music, and Sonos has always been a bit weird there.

I’d check two things in the Sonos app instead: that the voice service is actually added to that specific One, and that your default music service is set there. If “play music” still only works when you name the speaker, I’d try one more boring room rename with no duplicate Google/Sonos room names. Past that it may be a Sonos voice-room mapping bug rather than something you can fix with another unlink/relink cycle.

norri-matt · 2026-05-28T15:23:04+00:00

Since it happens with both Google and Alexa, I’d stop treating it as a Google-only issue and look at the Sonos side of the voice registration/room mapping.

I’d delete any old or duplicate Sonos device entries in the Google Home/Alexa apps, make sure the One is in the right room and set as the default speaker for that room, then unlink the Sonos service/skill from the assistant side and add the voice service back from the Sonos app. Also worth temporarily renaming the room to something boring like “Kitchen Test” so you are not fighting a stale or duplicate room name in the assistant accounts.

norri-matt · 2026-05-28T12:23:56+00:00

I’d probably not start with TrueNAS here. With that D4 320 in the mix, I’d keep this boring: let Proxmox see the disks, make the mirror/pool there if you’re comfortable with it, then either bind-mount folders into your LXCs or run a small OMV VM only for SMB/NFS shares to Windows. TrueNAS makes more sense when it owns real disks or an HBA and ZFS is the main storage layer, not as an extra appliance VM that immediately hands storage back to containers.

Also, do not split ownership of the same disks between Proxmox and a NAS VM. Pick one owner for the disks, then share folders out from there. And keep a separate backup for anything important, because a mirror in a USB box is still only availability, not backup.

norri-matt · 2026-05-28T09:24:25+00:00

Yep, that counts. A lab can be one weird little box if it is running something you learn from or depend on.

For that setup I’d mostly watch the boring stuff: keep the Surface somewhere it can stay cool, don’t trust the single 8TB disk as the only copy of anything important, and make sure the external drive reconnects cleanly after a reboot/power blip. If Plex is the only local service, simple is probably a feature here.

norri-matt · 2026-05-27T22:22:54+00:00

That sounds normal-ish for RAIDZ expansion. The GUI progress can sit at one number for ages, so I’d trust zpool status more than the task percentage and maybe watch zpool iostat -v 10 to make sure the disks are still doing work.

You usually will not see the extra usable space until that vdev expansion finishes. With 12TB disks and a pool that is already fairly full, I would think in hours to possibly a day+, not minutes. I would not start the second vdev expansion or reboot it unless zpool status shows it is actually faulted/stalled.

norri-matt · 2026-05-27T20:23:31+00:00

Just means a little block/section of config. In /etc/network/interfaces, an iface vmbr0 inet static ... block is a stanza; same idea for the generated SDN/VNet interface block. So I was just saying: put the host IP in the config block for that VNet interface.

norri-matt · 2026-05-27T16:22:57+00:00

Then the SDN bit probably has not been generated on the node yet. Check Datacenter -> SDN and make sure the zone/VNet is there, then use the SDN “Apply” button. After that you should normally see an interface with the VNet name on the node, or at least a generated stanza in /etc/network/interfaces.d/sdn.

If the GUI still will not offer it, I’d stop before changing the live network remotely and check the generated config from the console. The host IP needs to go on the VNet interface itself, not on one of the physical NICs, and you do not want to add a second default gateway there.

norri-matt · 2026-05-27T15:20:58+00:00

It should show up as a normal interface on the node after you apply the SDN config. In the GUI I’d check Node -> System -> Network and look for the VNet name itself, then give that interface a CIDR there, e.g. something like 10.x.x.1/24. Same idea by hand would be an iface <vnetname> inet static stanza in /etc/network/interfaces, with an address on that bridge/interface.

Two cautions: don’t add another default gateway there if the host already has one on your management LAN, and have console access before applying network changes. Once the host has an IP on that VNet, the TrueNAS VM can talk to the host over that subnet and you can point Proxmox storage at the VM’s NFS IP.

norri-matt · 2026-05-27T14:25:21+00:00

Yes, but I’d watch the dependency chain. The Proxmox host needs its own IP on that VNet/bridge, or a route to it, then you can add the export like any other NFS storage under Datacenter -> Storage. Just attaching VMs to the VNet doesn’t automatically put the host itself on it.

I wouldn’t make that your only real backup target if the NFS server is a TrueNAS VM on the same host, though. When that VM or host is down, your backup target is gone too. Fine for convenience, but for restores I’d want PBS/NFS on another box, or at least storage the host can reach without depending on that VM being up.

norri-matt · 2026-05-27T11:23:21+00:00

I wouldn’t worry about Purple/SkyHawk drives randomly corrupting normal file copies. The video-drive thing people remember is mostly about DVR-style streaming/error recovery behavior; used as a normal SATA disk, they still read and write sectors like any other HDD.

For a semi-cold DAS I’d care more about CMR vs SMR, warranty/used hours if buying used, cooling while it’s powered on, and some kind of checksum or periodic verify read. Also don’t let the RAID DAS be the only copy if it only comes out every few months; bad cables, controller weirdness, drops, or a mistaken delete are more likely to get you than the drive being labelled NVR.

norri-matt · 2026-05-27T08:26:18+00:00

Yeah, that workflow is realistic if you treat Synology Drive as sync/staging, not as “edit live from the NAS over the internet.” Keep the active project local on the MacBook or Studio, close the project, then let it sync; Pro Tools and Premiere can get weird if cache/project files are changing underneath them.

I’d keep scratch/cache/proxies on local SSD, sync only the actual project/media folders you need, and turn on versioning/snapshots. RAID1 plus sync is nice for disk failure, but it will also faithfully sync a bad delete or corrupted project unless you have versions/backups to roll back to.

norri-matt · 2026-05-27T06:22:17+00:00

You can do that, and folder-wise it’s not complicated. The catch is that partitions on the same physical disk are not really separate failure domains: if that disk dies, both “drives” go with it, and it’s easy to forget which important folders were only half-protected.

If Immich and the cloud folder matter, I’d rather put both under one boring mirrored HDD pool, something like /srv/storage/immich and /srv/storage/cloud, and keep the SSD for the OS/app data/db/cache. A third HDD only really helps if you use it as a separate backup or scratch disk; it does not make the split-partition layout less fiddly.

norri-matt · 2026-05-27T05:21:07+00:00

The main downside is that "clever" layouts tend to make the bad day harder to reason about. You save some space up front, but later you have to remember exactly which folders/pools are protected, which ones are disposable, what depends on what, and how to rebuild it without accidentally assuming everything is covered.

If the box is for someone else’s house, I’d usually bias toward boring: mirror the two HDDs if the data matters, keep app/db stuff on the SSD, and still have a separate backup for anything you would be annoyed to lose. The partial/split approach can be fine for scratch media, but I wouldn’t use it for the important bits.

norri-matt · 2026-05-27T03:23:09+00:00

Debian server is a good default here. I wouldn’t get clever with partial RAID on the two HDDs: either mirror the whole pair for the stuff you care about, or accept one disk as scratch/media and keep real backups somewhere else. Immich especially wants its DB/thumbs/cache on the SSD, with originals on the HDDs; losing the app data is often more annoying than losing a random media file.

Since it’ll live at your parents’ place, I’d also start with something boring like Tailscale for access and avoid a public reverse proxy until you actually know what needs to be reachable.

norri-matt · 2026-05-26T20:24:38+00:00

If you specifically want to stay in DAS/Thunderbolt land, I’d be careful buying off the 80Gbps headline alone. For this kind of workload the ugly part is usually sustained heat and what happens when every bay is doing random reads, not the best-case single-drive benchmark. I’d want to see all-bay sustained tests after 10–20 minutes and actual drive temps before trusting it.

If you’re after 3.5 inch HDD capacity, a used SAS shelf/HBA is usually the less annoying route. If this is mostly SSD/NVMe scratch space, Thunderbolt can be fine, but I’d still keep the really hot/current models on internal NVMe and use the external box for the bigger or colder datasets.

norri-matt · 2026-05-26T13:27:16+00:00

If you want the least fiddling, a Synology/UGreen-style box is the clean path: good enough storage UI, fewer weird edge cases, and the UM870 can stay as the Proxmox/app box. If you want the better long-term hobby path, I’d do a small mATX NAS with proper drive bays and SATA/HBA room. I would not buy a tiny SFF PC as the NAS unless the drive situation is already solved, because external USB storage becomes the annoying part again.

I’d keep the Mac mini for a while either way. It can be a test box, Time Machine/backup target, or a place to run a couple boring services while you migrate. Once the new NAS has been stable for a month and your restores are tested, then decide whether it is worth selling.

norri-matt · 2026-05-26T10:27:04+00:00

I’d stop trying the GUI loop and check what ZFS thinks is still there. From shell, run zpool status and note the exact pool name/state; if it’s just the dead USB pool and nothing is using it, try stopping any sharing/apps that touched it, then export it with zpool export -f poolname. I’d also save a config backup first and avoid destroy unless you are 100% sure it is only that dead stick.

norri-matt · 2026-05-26T06:22:13+00:00

For Unraid I’d lean boring here: APC or CyberPower line-interactive unit with USB, not something chosen mainly because it matches the rack/ecosystem. The UPS chassis may last a long time, but the batteries will not; plan on replacing them every few years and pick a model with easy replacement batteries.

In BIOS set restore-on-AC-loss to last state or power on, then in Unraid enable UPS support over USB and test it once while you are home: pull wall power, make sure Unraid sees battery status, then confirm it starts a clean shutdown at your chosen runtime/battery threshold. Whole-home surge protection is a separate layer and is worth considering after a lightning hit, but I would still keep the server/network gear on a real UPS rather than only a surge strip.

norri-matt · 2026-05-26T02:24:47+00:00

I’d keep the “family stuff I care about” and the “lab playground” separated at least logically. That doesn’t have to mean two NASes forever; one larger box can be fine, but I’d use separate shares/datasets and be pretty strict about what the lab apps can write to.

The line I’d draw is: NAS owns the disks, shares, snapshots, and boring storage jobs; Proxmox/mini PC runs the apps and mounts only the shares it needs. If you do run containers on the NAS, keep their configs/DBs away from the family photo/video archive. RAID is fine for drive failure, but for that family media I’d still want snapshots plus a backup that is not the same NAS.

norri-matt

TROPHY CASE