I’m a little teapot 🫖

  • 0 Posts
  • 72 Comments
Joined 1 year ago
cake
Cake day: September 27th, 2023

help-circle
  • Ruckus APs and Opnsense have been solidly reliable for me for 5y now. No random fucking with unifi bugs (like having my WPA enterprise SSID punting users out onto the management vlan at random instead of the Kerberos assigned VLAN for that user, thanks unifi) and fantastic wireless coverage has me completely satisfied with my infra choices. Also, Ruckus unleashed handles controller duty on the primary AP rather than requiring a management container, that’s also a plus.


  • I wrote snapshot hooks for Arch that fire before installing or upgrading packages and I have a simple shell alias that I can use to fire off a manual snapshot any time I need one. If a package breaks in an inconvenient way and can’t just be dowgraded back to function or I have some other time pressure I can just point my root partition at a clone of my most recent snapshot and reboot to roll back. I don’t usually bother rebooting into a cloned snapshot to test changes as I can just perform the same steps to roll back and the automated rolling snapshots mean I don’t need to baby anything to have the same protection.











  • Because you’re relying on compatibility between older Debian software (systemd, etc) and newer versions installed in the chroot. Things get weird quickly.

    Consider a nested privileged container instead (LXC or similar) and cross your fingers that Debian systemd and Arch systemd play nice.

    If the above fails just make a VM and pass through the GPU with GVT-g (otherwise pass through the entire GPU.)

    If all of that fails install Arch to a USB attached SSD or something.


  • If you’re using an Intel chip look into GVT-g and consider running Arch from a VM, that’ll be the closest thing to native.

    The unfortunate thing about running an Arch container from a Debian host is that you’re relying on an older kernel and an older systemd host side and I’ve found that often causes compatibility problems inside the Arch container. If you are very, very lucky Arch will just work inside the container, but IME that’s fairly rare as systemd often has breaking changes over several releases (and Arch tends to be at least several releases ahead of Debian.)



  • Btrfs, ZFS and ext4. My servers use ZFS, my client machines mostly use btrfs and I have a sprinkling of ext4 partitions for specific workloads. I’m all in on CoW filesystems for snapshots, send receive, transparent compression and reflinks. I like btrfs on client machines and SBCs because it’s easily available (baked into the kernel) and doesn’t require maintaining dkms or holding kernel versions until ZFS supports them and because snapshot handling and other filesystem admin tasks are simple and straightforward. I run ZFS wherever data integrity is important, eg: storage servers and backup targets, but largely prefer working with btrfs.