Chameth.com - posts like debugging-beyond-the-debugger, docker-automatic-nginx-proxy, g15-ram-upgrade, tailscale-docker-gotcha but not modern-css-is-fun, why-you-should-be-using-https

An interesting Tailscale + Docker gotcha

2026-01-29T00:00:00Z

As I’ve written about before, I use Tailscale for a lot of things. I thought I had it set up in a reasonably secure manner, but I recently noticed a problem.

I use Tailscale’s ACLs to limit what each node can access, based on the tags I apply to it. So an app node can’t access anything via Tailscale, while an integration or server node can access things tagged with either app or integration. This is expressed pretty simply in the Tailscale ACL JSON:

{
	"tagOwners": {
		// Servers that can be SSH'd into
		"tag:server": [],
		// Applications that are exposed on tailscale but never connect out
		"tag:app": [],
		// Things which talk to other services over tailscale (connecting to apps etc)
		"tag:integration": [],
	},
	"grants": [
		{
			// Users can access everything
			"src": ["autogroup:member"],
			"dst": ["*"],
			"ip":  ["*"],
		},
		{
			// Servers and integrations can access integrations and apps
			"src": ["tag:server", "tag:integration"],
			"dst": ["tag:integration", "tag:app"],
			"ip":  ["*"],
		},
	],
}

Over the past week I’ve been setting up a private Forgejo instance behind Tailscale, complete with an actions runner that runs things using a docker-in-docker container. I didn’t want the runner knowing anything about Tailscale, so I had it configured to speak to Forgejo direct over HTTP (forgejo:3000) instead of using full Tailscale HTTPS URL that I use when accessing it (http://git.example-net.ts.net/)¹.

Everything was going fine, until I forgot to do that translation… and it worked. My Forgejo action runners could access anything on my tailnet. I run several things on Tailscale that just have authentication turned off, on the basis that only authorised devices can access them. Things like the admin interface for this website. I definitely didn’t intend for any workflow I run on my git server to have access to edit my website!

This wasn’t just limited to Forgejo, either. Any docker container I was running could access the tailnet. In hindsight it’s fairly obvious why: the host is running Tailscale, connected as a node tagged with my server tag. That creates a tailscale0 interface, and automagically sets up iptables rules to route Tailscale traffic over the interface. Docker also automagically sets up iptables rules to bridge traffic, and apparently these two sets of rules interact in such a way that traffic from Docker containers is allowed to route via the tailscale0 interface.

I say it’s fairly obvious in hindsight — there’s no reason why Docker would special case any particular host interface after all — but it still feels pretty surprising. Because both bits of software inject their own iptables rules, I never really had a good mental model for how they interact. The host Tailscale node was a completely separate building block to Docker. It would be a pain to use either of them if they didn’t do these rules, but it’s also one of the reasons I don’t really like “magical” things².

There are lots of ways to fix this, but none of them feel particularly great. You can configure both Tailscale and Docker to not automatically fiddle with iptables and handle the rules yourself, but I really hate dealing with iptables³. As a stopgap I did hold my nose and add some iptables rules to drop traffic to the tailscale0 interface if it originated from the IP ranges that Docker was configured to use:

iptables -I DOCKER-USER -s 192.168.0.0/16 -o tailscale0 -j DROP
iptables -I DOCKER-USER -s 172.17.0.0/12 -o tailscale0 -j DROP

The DOCKER-USER chain is a nice little escape hatch; it comes before the main auto-generated DOCKER chain, and Docker leaves the rules in it alone.

So I added these rules, and felt pretty good about myself, and then… everything started breaking in weird ways. After some debugging I realised the problem was DNS⁴. The server’s DNS resolver is 100.100.100.100, a special Tailscale address. This is so that it can resolve tailnet hostnames via MagicDNS (and so I don’t have to configure my custom DNS servers manually on each device; Tailscale does it for me). My new iptables rules inadvertently dropped all the DNS packets coming from docker containers. D’oh.

Obviously the solution here is to double down and add MORE iptables rules:

iptables -I DOCKER-USER -s 192.168.0.0/16 -d 100.100.100.100 -o tailscale0 -j ACCEPT
iptables -I DOCKER-USER -s 172.17.0.0/12 -d 100.100.100.100 -o tailscale0 -j ACCEPT

This got DNS working again, but it all feels a bit gross. Not least because to actually make these persist you need to use iptables-save, and then you also get all the rules that both Docker and Tailscale have inserted. I came across a script to filter out the Docker ones, but… yuck⁵.

I realised a cleaner idea might just be to lock down what server tagged nodes could access within Tailscale itself. That way I can avoid touching iptables at all. It’s handy to be able to curl services from the host when debugging, but it’s not really necessary. So I removed that access, and… stuff broke again. I’m using my Forgejo instance as a registry for some of the docker images I run, so the docker daemon needs to be able to reach it. I ended up making a new tag for infrastructure, which can be accessed from server devices. This does still allow all the docker containers to reach Forgejo, but I already have it set up with appropriate access controls and public/private repository splits. Forgejo is a service designed to run publicly, so this seems a reasonable trade-off for convenience. I used the tests feature of Tailscale’s ACL config to make sure I’d got the rules right:

{
	"tests": [
		{
			// Servers can only access infrastructure
			"src":   "tag:server",
			"proto": "tcp",
			"allow": [
				"tag:infrastructure:8080",
			],
			"deny": [
				"100.84.16.43:8080",
				"me@example.com:8080",
				"tag:server:8080",
				"tag:app:8080",
				"tag:integration:8080",
			],
		},
	],
}

The whole situation still feels a bit messy. If I ever get around to switching to nftables I might loop back and manually craft some rules for routing traffic, instead of leaving Tailscale and Docker to do their own thing.

I discovered later on that logging into the container registry at forgejo:3000 actually issued a redirect to https://git.example-net.ts.net/ so this was all basically for naught… ↩︎
I didn’t use Tailscale’s MagicDNS for a long time just because the word “magic” put me off. Only when I eventually got around to learning how it worked, and seeing that it wasn’t really that magical under the hood, did I change my mind. ↩︎
nftables seems far better in lots of ways, but I can’t really be bothered migrating. Maybe next time I reimage the server for whatever reason… ↩︎
It’s always DNS… ↩︎
Again, nftables would almost certainly help here. It actually has (gasp) configuration files. But again, I really didn’t want to spend the time migrating. ↩︎

Exposing game servers over Tailscale

2025-12-07T00:00:00Z

I’ve recently been playing a lot of Factorio with a friend. I’ve been hosting, but my desktop computer is behind far too many layers of NAT, and I can’t be bothered dealing with setting up port forwards. Up until today we made do with Steam’s networking support, which in our case ended up relaying the connection via one of their servers. This is amazing as a free, no-hassle service, but the performance was so-so. We’d get random lag spikes, or the initial map download would crawl along at about 1/100th of the speed we should be able to get. We’re both fans of Tailscale though, so maybe there’s an easy solution there?

Tailscale even have an article on sharing a Factorio server but it’s a ten minute long video¹, and focused on setting up an actual dedicated server in Docker rather than just clicking the convenient “Host” button in the game client. What we did instead was:

I shared my desktop’s Tailscale node with my friend, by creating a sharing link in the Admin console
My friend accepted the link, and could then see my machine in their admin panel
I used tailscale lock to sign my friend’s desktop’s node key, as I have tailnet lock enabled
I added a grant to my tailnet’s ACL to permit access from my friend to the specific IP/port on my tailnet:

		{
			"src": ["friend@example.com"],
			"dst": ["100.0.0.42", "fd7a::42"],
			"ip":  ["udp:34197"],
		}

After this, my friend could connect to Factorio by entering the Tailscale IP address, or the Tailscale hostname (as they use MagicDNS). Running tailscale status shows that Tailscale managed to establish a direct connection despite the many layers of NAT involved, and the performance improvements were significant and immediate.

We did a bit of testing, and confirmed that no other services on my machine are accessible. And sharing a machine by default only allows it to accept incoming connections, so I can’t get unwanted access to anything on my friend’s Tailnet, either.

I’ve written before about all the different ways I use Tailscale; this is yet another new way it’s solved a problem for me.

I’m not a fan of video tutorials at the best of times, but especially not when I want to do something as quickly as possible so I can get back to ~~my addiction~~ growing the factory. ↩︎

Avoiding the Consequences of Dumb Laws with Tailscale

2025-09-30T00:00:00Z

More and more sites are implementing privacy-invading age checks or just completely blocking the UK thanks to the Online Safety Act.

Protecting kids from some content online is certainly a noble goal, but the asinine guidance from Ofcom, threats of absolutely disproportionate fines, and the stupidly broad categories of content have resulted in companies just giving up or going through a tick-box exercise that offers very little protection but lots of inconvenience and a complete invasion of privacy.

Instead of uploading my ID to some third party company, I’ve taken to proxying my traffic through to a country that doesn’t have such stupid laws. Thankfully, Tailscale makes this really easy. I’ve discussed how I use Tailscale before, but not really covered app connectors. I find Tailscale’s description of these pretty confusing, but they basically amount to automatic, DNS-based subnet routing configurations (or, to put it another way, a per-website exit node). You can safely ignore all references to ‘SaaS apps’ in their docs.

I create a custom app connector, and give it the domains to be included:

App configuration in the Tailscale admin console

Tailscale then magically resolves those domains, and has the ‘connector’ advertise routes for them. Any client that accepts routes will start sending requests to the connector, which passes them onto the Internet at large. Any other traffic is left alone, unlike when you use an exit node.

The special bit here is how you can specify wildcard domains. Tailscale proxies the DNS requests from clients (so it can inject responses for nodes on your tailnet), which means it can dynamically update the routes as you resolve new domains. I tried to set this up more manually, and quickly came unstuck: despite using the same DNS servers, my server and my desktop would get different responses for the same query as it varied by geography. Trying to get the full set of IPs (and keeping them updated) would have been a nightmare. Tailscale expanding the wildcards nicely sidesteps all of that.

At first I was just proxying the traffic to one of my servers, but just today I added a new connector for Imgur and found I was still blocked, just for different reasons. They not only block my entire country but also a load of known datacenter IP ranges. Hmph. I fixed this by hacking up a new side project: tsv. It’s a simple Go app that accepts traffic from the tailnet (advertising itself as both an app connector and an exit node), and passes it on to another VPN.

There are lots of other ways you could accomplish this, but this makes it so all my devices can still access services without any additional configuration. As long as Tailscale is installed, the Internet will still work as it’s meant to, without all the nonsense. If I come across a site that doesn’t work, adding it is trivial: I just make a new app connector in Tailscale.

Obvious disclaimer: the laws in the UK are binding on the service providers, not the end user. Doing this sort of thing in other countries might be illegal. I don’t know; do your own research! Also all of this is a workaround for something that should be fixed at a legislative level, but I’m not holding my breath.

How I use Tailscale

2025-06-25T00:00:00Z

The Tailscale logo

I’ve been using Tailscale for around four years to connect my disparate devices, servers and apps together. I wanted to talk a bit about how I use it, some cool features you might not know about, and some stumbling blocks I encountered.

I’m not sure Tailscale needs an introduction for the likely audience of this blog, but I’ll give one anyway. Tailscale is basically a WireGuard¹ orchestration service, with lots of nice features sprinkled on top. It’s a subscription product, but it has an insanely generous free tier that covers basically anything you’d ever want to do as an individual. They also open source all their client software, and there’s a third party control server implementation called Headscale if you want to avoid the hosted system entirely.

Basic connectivity

At its core, Tailscale lets you easily connect from one device to another, even if they’re not directly exposed to the Internet. You install the Tailscale client wherever you like (on your phone, computer, servers, Raspberry Pi, etc), authenticate the machine with the control server, and it can then talk to all the other machines on the tailnet using their private Tailscale IP addresses.

That isn’t anything revolutionary: it’s the basic premise behind VPNs. But Tailscale makes it so easy. You don’t have to bother with any networking configuration. You don’t have to distribute keys. You just install the client², and login.

For example, my home automation service runs on a Raspberry Pi that sits behind two different routers. I installed Tailscale on it³, logged in, and immediately I could SSH into it from my computer or my phone even when they’re on different networks.

Speaking of SSH, Tailscale has special support for it whereby it handles any incoming connection to port 22 from the Tailscale network, and deals with authentication itself. No public keys or passwords: if you’re logged into Tailscale you can be logged into the machine. This is particularly handy when you SSH from a phone, as proper credential management is a bit of a nightmare there.

Exposing entire machines is just the start, though. If you run multiple services on the machine you need to remember which port they’re all on. Yuck. Instead, you can expose individual services as their own node on a tailnet. There are lots of options for doing so: there’s an official Docker image, a Go library, and many third-party tools (such as my own Centauri and tsp).

Not just a VPN

Exposing individual services wouldn’t be much use if you still had to remember their IP addresses. For a long time I manually added DNS entries for Tailscale nodes, allowing me to connect to http://grafana/ instead of http://100.73.190.100. Recently I switched to Tailscale’s MagicDNS, though, which takes care of that for you. Every machine on the tailnet gets an automatic DNS entry based on its name.

I initially shied off of this because it changes the DNS resolver on every machine it’s installed on, and it all seemed a bit too “magic” for me⁴. I got fed up with manually adding DNS entries though, so I spent a bit of time learning about it and got over my knee-jerk “what on earth is going on?!” reaction. The DNS controls also let you force a specific upstream DNS server. I use NextDNS everywhere, so having Tailscale automatically configure this for me on all my devices was a bonus⁵.

As well as the short names, you can resolve nodes on the tailnet using a slightly longer form: machine.your-tailnet.ts.net. The “your-tailnet” bit is randomly generated, and you can reroll it in the control panel to find a fun one. But why waste time say lot word, when few word do trick? Because Tailscale can make these addresses globally routable, and issue TLS certs for them too.

Say you’re developing something on your local machine, and want to get feedback from someone. You can use Tailscale’s “funnel” feature to expose it publicly:

tailscale funnel 127.0.0.1:8080

With no other options, this will expose the service over HTTPS on port 443. You can then invite people to visit https://machine.your-tailnet.ts.net and they’ll connect through to port 8080 on your machine. They don’t even need Tailscale installed. I don’t use this terribly often, but it’s a great quality-of-life improvement on the occasions I do want to share something.

Tailscale also has a “serve” command, which does much the same but only exposes it over your tailnet. This is how you’d use the Tailscale Docker image to expose a normal service onto your tailnet, but it’s also useful for similar development scenarios. Occasionally I’ll want to test something on my phone, and rather than make sure it’s connected to the right Wi-Fi network, recompiling the app to not bind to localhost, figuring out my machine’s IP, and so on, and so forth, I just run tailscale serve and access it over Tailscale.

Authentication, two ways

One of my minor frustrations with Tailscale was how cumbersome the authentication process was. I logged in using GitHub, and every time I tried to login to Tailscale, I had to bounce through the GitHub OAuth flow and then select which organisation I wanted to use. Even if I was logged in to GitHub, it still shows the permission page every time. It’s not a dealbreaker, but it’s definitely not smooth. This is what it looks like:

Logging in to Tailscale with a GitHub account

Tailscale have since added the ability to sign in with a custom OIDC provider, so I set up a KeyCloak instance, and my login flow now looks like this:

Logging in to Tailscale with KeyCloak as an OIDC provider

It’s a significantly shorter flow, and because KeyCloak is entirely under my control I can configure how long I stay logged in for. It also reduces my reliance on third parties: if GitHub goes down, or decides to ban my account⁶ or something, I can still access Tailscale.

That’s how you log in to Tailscale, but Tailscale can also assist with logging in to other services. If you connect to a HTTP service over Tailscale, it will add in the following headers:

Tailscale-User-Login: alice@example.com
Tailscale-User-Name: Alice Smith
Tailscale-User-Profile-Pic: https://example.com/photo.jpg

A lot of software has support for accepting login credentials provided by a reverse proxy, which is basically what’s happening here. For example, I run a Grafana instance that’s only exposed over Tailscale. Its config (set in environment variables) is:

GF_USERS_AUTO_ASSIGN_ORG: "true"
GF_USERS_AUTO_ASSIGN_ORG_ROLE: "Admin"
GF_AUTH_PROXY_ENABLED: "true"
GF_AUTH_PROXY_HEADER_NAME: "Tailscale-User-Login"
GF_AUTH_PROXY_HEADER_PROPERTY: "email"
GF_AUTH_PROXY_AUTO_SIGN_UP: "true"

So anyone who presents a Tailscale-User-Login header gets an admin account created with that as their e-mail address. It’s super convenient, but obviously make sure it’s only exposed via Tailscale if you do that!

Other services I run that support this include Miniflux (an RSS reader), Jelu (a book tracker), Linkding (a bookmark manager), and Seafile (a file storage system). If you’re hosting something yourself, look out for “proxy auth” or “remote users” in the documentation or configuration. It’s amazingly convenient to be able to access things without entering credentials.

ACLs, tags and mistakes

For a long time I didn’t bother with any kind of ACLs within my Tailscale network. Every machine could access every other machine. Then one day a thought hit me. The default Tailscale SSH config re-prompts you for user authentication, but I’d disabled that by tweaking the config… That means anyone with access to any of my machines (or who managed to get Tailscale credentials out of one of my apps) would be able to SSH into anywhere else on my network. Even as root! Compromising a small bit of my network would immediately lead to a complete take-over. What’s the point in defence-in-depth if you roll out a red carpet over the drawbridge for any attackers?

The first and most obvious fix for this was to restrict root access over SSH. I changed my Tailscale ACL to prompt for reauthentication for root access, but still allow regular SSH unprompted:

{
  "ssh": [
    {
      "action": "accept",
      "src":    ["autogroup:member"],
      "dst":    ["autogroup:self"],
      "users":  ["autogroup:nonroot"],
    },
    {
      "action": "check",
      "src":    ["autogroup:member"],
      "dst":    ["autogroup:self"],
      "users":  ["root"],
    },
  ],
}

This still didn’t sit right with me, though. Why should a random webserver be able to (theoretically) SSH into my desktop computer unchallenged? Tailscale allows you to do more advanced ACLs by applying tags to devices. I dutifully created a bunch of tags, and went through and tagged every device: user, server, app, container, and so on. This, it turns out, was a mistake. I could no longer SSH to anywhere. If I’d read the docs properly, I might have noticed how they describe tags:

Tailscale tags are how you authenticate and identify non-user devices, such as servers and ephemeral nodes. They serve two primary purposes: to provide an identity to non-user devices and to let you manage access control policies based on purpose.

By applying a nice user tag to all of my devices (computer, phone, tablet and so on), I’d effectively removed my own identity from them. They no longer counted for the autogroup:member source in the SSH config. Whoops. And it’s not easy to fix either:

You cannot remove all tags from a device. A device with a tag-based identity must have at least one tag.

So I’d have to remove all the affected devices, then re-add them. At the time I wanted to roll back all the tags, which would mean reconnecting dozens of nodes to the Tailnet. I did end up doing that, but I also took it as an opportunity to switch to KeyCloak as I mentioned earlier. Setting everything up again was a bit less painful when it wasn’t just correcting a dumb mistake.

I now have a much more sensible tag setup: servers are tagged server, apps are tagged app, and a few special apps are tagged integration. I then use Tailscale’s grants to limit access within the tailnet:

{
  "grants": [
    {
      // Users can access everything
      "src": ["autogroup:member"],
      "dst": ["*"],
      "ip":  ["*"],
    },
    {
      // Servers and integrations can access integrations and apps
      "src": ["tag:server", "tag:integration"],
      "dst": ["tag:integration", "tag:app"],
      "ip":  ["*"],
    },
  ],
}

This stops anyone but a user device from accessing servers, and stops plain apps from accessing anything at all. So for example my Grafana instance is tagged as an app; it doesn’t connect out over Tailscale for anything, it only exposes its interface over Tailscale. My home automation software is tagged as an integration, as it reaches out to other services over Tailscale (e.g., to push metrics it receives from devices).

You could go even further and limit which specific machines talk to which others, but I think this tier system sets reasonable boundaries for my use without getting too much in the way.

Even more

There are lots of other cool features offered by Tailscale that I’ve not covered: exit nodes (allowing you to route normal Internet traffic over Tailscale; very handy when you’re behind a router you don’t trust, or if you want to appear as being in another country for totally legitimate reasons); Tailscale lock (a system where existing nodes have to verify any new ones, guarding against both unauthorised access and Tailscale themselves inserting nodes into your network); file sharing, and more I’ve probably forgotten.

As I mentioned before, an awful lot is available on the free personal plan. It’s definitely worth checking out if you manage servers, or self-host anything. I can’t imagine going back to managing servers and private apps without Tailscale, and I’m excited to see what else they do going forward.

If you’re not familiar with it, WireGuard is a modern VPN included in the Linux kernel. It’s basically the only VPN that isn’t terrible. ↩︎
They have installation instructions and packaged versions of the client for just about every device you can imagine: Windows, Mac, every major Linux distribution, iOS, Android, etc, etc ↩︎
They even have an apt repository specifically for raspbian builds, so it’s super easy. ↩︎
Lots of people seem to treat “magic” as a good thing in software. I think it’s the absolutely opposite. I want to know how something works, not for it to be inscrutable! ↩︎
This is entirely optional, of course, you can just let each device do their own thing as well. ↩︎
I don’t think this is likely, but it’s one of my biggest concerns about using “social” logins. More-or-less all of these services can arbitrarily ban you with no recourse; why would you trust them as keyholders to other things? ↩︎

Upgrading the RAM in a Dell G15 laptop

2023-07-29T00:00:00Z

The Dell G15

I currently use a Dell G15 laptop for work. It has served me well for a little over a year, but recently it has been struggling a little with my day-to-day workload. It came with 32GB of RAM — the highest possible specification at the time¹ — but that is apparently no longer enough for me.

For a recent project, I was working on a Rust library used in an Android app. That meant running the usual glut of Android tools (Android Studio, an emulator and at least one Gradle daemon) alongside a normal IDE (IntelliJ IDEA). Throw in a web browser and a couple of electron apps, and I often managed to use all 32GB.

When you start swapping memory out to an encrypted disk — even an SSD — it doesn’t make for great performance. At first, I tried to work around this by enabling the Linux out-of-memory (OOM) killer, but it turns out that it’s not too good with Electron apps: it will kill the large browser process, but then the small Electron wrapper will just respawn it.

Can it be upgraded or not?

The obvious solution to not having enough RAM is to add more RAM. A quick look in the manual showed this might not be possible, though. The manual includes the following “Memory specifications” table:

Description	Values
Memory slots	Two SODIMM slots
Memory type	DDR5
Memory speed	4800
Maximum memory configuration	32GB
Minimum memory configuration	8GB
Memory size per slot	8GB or 16GB
Memory configurations supported	8 GB, 1 x 8 GB, DDR5, 4800 MHz 16 GB, 1 x 16 GB, DDR5, 4800 MHz 16 GB, 2 x 8 GB, DDR5, 4800 MHz, dual-channel 32 GB, 2 x 16 GB, DDR5, 4800 MHz, dual-channel

That unambiguously says that an upgrade from 32GB is not possible. I gave up.

Later though, I was complaining about memory issues to a friend, and he pointed out a Dell forum thread where a couple of people claim to have successfully installed dual-channel 32GB modules. Since the alternative was getting an entire new PC after only a year, I decided to give it a go.

The upgrade attempt

I ordered a pair of Crucial 32GB DDR5-4800 SODIMMs, and after they turned up dismantled the laptop. The G15 comes apart pretty normally: there are uncovered screws on the bottom holding the lower part of the case on. With those removed and some gentle prying, it pops off, and you get access to the battery, GPU and motherboard.

The first thing I saw was this:

The G15 motherboard adamantly proclaiming that it doesn’t want 32GB SODIMMs

Not one but two labels that indicate it will only accept 8GB or 16GB modules. Oh well, what’s the worst that can happen?

Oops?

I dutifully installed the new modules, reconnected the battery and put the case back together. I pressed the power button, and… nothing. None of the usual garish lights that immediately come on, no screen output, just a dead laptop. After reading some more of the user manual, I found that there is a tiny status LED on the side next to the ethernet port. Forcing the laptop to power off and back on again, the status LED blinked a distress code at me: 2 amber blinks, 4 white blinks. The manual says that is — unsurprisingly — a memory fault.

I figured at this point that the manual and labels on the motherboard were probably right. I took the laptop apart again, reinstalled the original 2x16GB modules, reassembled it, and pressed the power button. It didn’t boot. I don’t spend a lot of time fiddling inside computers, but I’ve done it enough that I’m reasonably confident I can’t entirely break a computer while swapping some RAM modules. I took to Googling², and found an interesting article that said Dell laptops don’t like to boot after RAM changes unless you clear the CMOS by popping out the battery for 15 minutes.

I opened the laptop up, and looked around for the CMOS battery. There wasn’t one. Turns out they don’t exist any more. I left the main battery disconnected for a while to see if it would help, and it didn’t.

Unexpected success

I started to get worried: if I couldn’t fix this, I wouldn’t be able to work until I got a new PC, and that wasn’t really in my budget at the minute. I sat reading old forum threads and help guides³, none of which were actually useful. Out of nowhere, though, the laptop booted up.

Naturally, I immediately shut the laptop down again, opened it up, and switched back to the new RAM modules. Then I turned it on again and sat waiting. After about 15 minutes of it looking totally dead, it turned on and showed a BIOS warning about the hardware configuration being changed. It then booted perfectly normally, and all 64GB of RAM was visible and usable.

My theory is that the forum threads were right: Dell laptops are funny about RAM upgrades. But somehow in removing the physical CMOS battery, they’ve kept the same “you have to wait 15 minutes” behaviour just without any indication that’s what’s happening. Regardless, I now have enough RAM even for the greediest of IDEs and Electron apps.

Bizarrely, the maximum spec has decreased to 16GB since then. ↩︎
In the generic sense. I use Kagi these days. ↩︎
On my phone because, y’know, the laptop was busted. ↩︎