Stuart Longland (VK4MSL)

Back-up account for Stuart Longland (VK4MSL) (npub12n5…9dex) in case my server goes down. If I follow you here, I will probably follow you on my home server as well.

Posts made here expire after 2 months.

Public Key

npub12h9s2ds73gxsjmewpdf0z66q0elhx4xk6tww4w98d32p7u9kp60qyvts7y

NIP-05 Address

[email protected]

Profile Code

nprofile1qqs9tjc9xc0g5rgfduhqk5h3ddq8ulmn2ntd9h82hznkc4qlwzmqa8sprpmhxue69uhhyetvv9ujumt0d4hhxarj9ecxjmnt4rck8n

Publishing to

relay.momostr.pink

Author Public Key

npub12h9s2ds73gxsjmewpdf0z66q0elhx4xk6tww4w98d32p7u9kp60qyvts7y

Show more details

Last Notes

2026-04-13 10:45:15 UTC

- reply

So, I've mounted my snapshot from the 11th read-only.
I've re-formatted the volume XFS and have it mounted read-write.
`rsync` is copying the files. I see there's remnants of the old "combined" PostgreSQL + Mastodon system + redis + backups directories there (as btrfs subvolumes).
Some time ago I split it out to separate RBD volumes for performance reasons. So only the back-ups remained on the disk. Not quite sure why that brought the machine down, but we might get through this unscathed.
`rsync` of course is complaining about I/O errors transferring some of the back-up files, but whatever… the other volumes are good, I can recover from this. Back-ups will be on XFS from now on.
I've done a `fsck` of the other volumes, they're okay, but I've snapshotted them just in case. I can migrate those to XFS later. We'll let this run overnight and see how things are tomorrow.

2026-04-13 10:14:54 UTC

- reply

eff it… we're going XFS.

2026-04-13 10:05:51 UTC

- reply

```
tree extent[30474240, 16384] parent 78826651648 has no backref item in extent tree
backpointer mismatch on [30474240 16384]
adding new tree backref on start 30474240 len 16384 parent 78826651648 root 78826651648
Repaired extent references for 30474240
bad full backref, on [30490624]
ERROR: commit_root already set when starting transaction
ERROR: failed to start transaction: Invalid argument
failed to repair damaged filesystem, aborting
beryllium:~#
```
… bugger!

2026-04-13 04:23:23 UTC

- reply

Still going this afternoon, at extent #170752147456… I note the pace has quickened quite a bit, so maybe that's a good thing?

2026-04-12 20:43:21 UTC

- reply

I wake up to the server fiddling extents at extent #128730550272. The hardest bit is knowing what the progress is… the number alone is meaningless unless I know what the total number of extents is.
Some might suggest at this point I hit ^C, reformat the volume and restore from a back-up. If I have to do that, I think I'll be re-formatting XFS not BTRFS.

2026-04-12 08:30:33 UTC

- reply

Well, no such luck… still going. Somewhere around extent 107335499776 now.
Not sure what the uptime stats are for my server. I don't actually measure uptimes, but I first noticed it offline yesterday morning around 6AM.
Last stretch of downtime was on the 28th March for about 10 minutes.
This is now about 36 hours. Assuming no downtime between those points, I'm at about 89.8% uptime availability.
That puts me just a smidge above Github: https://mrshu.github.io/github-statuses/

2026-04-11 21:17:08 UTC

- reply

As some might've guessed… that `fsck` is still grinding away.
24+ hours. I thought large EXT2 volumes took a long time to check, but it seems BTRFS can be just as bad.
```
ref mismatch on [77402689536 8192] extent item 1, found 0
data extent[77402689536, 8192] bytenr mimsmatch, extent item bytenr 77402689536 file item bytenr 0
data extent[77402689536, 8192] referencer count mismatch (root 256 owner 227855 offset 33595392) wanted 1 have 0
backpointer mismatch on [77402689536 8192]
owner ref check failed [77402689536 8192]
repair deleting extent record: key [77402689536,168,8192]
Repaired extent references for 77402689536
```
Not sure what number that's expected to climb to. Maybe with some luck I might be "back home" this afternoon, but at this rate, who knows?

2026-04-11 10:50:06 UTC

- reply

And no, I don't know what a "mimsmatch" is either…

2026-04-11 10:48:37 UTC

- reply

Still going… seeing a lot of messages like this:
```
ref mismatch on [35132342272 8192] extent item 1, found 0
data extent[35132342272, 8192] bytenr mimsmatch, extent item bytenr 35132342272 file item bytenr 0
data extent[35132342272, 8192] referencer count mismatch (root 256 owner 227508 offset 149012480) wanted 1 have 0
backpointer mismatch on [35132342272 8192]
owner ref check failed [35132342272 8192]
repair deleting extent record: key [35132342272,168,8192]
Repaired extent references for 35132342272
ref mismatch on [35132350464 8192] extent item 1, found 0
data extent[35132350464, 8192] bytenr mimsmatch, extent item bytenr 35132350464 file item bytenr 0
data extent[35132350464, 8192] referencer count mismatch (root 256 owner 227508 offset 149020672) wanted 1 have 0
backpointer mismatch on [35132350464 8192]
owner ref check failed [35132350464 8192]
repair deleting extent record: key [35132350464,168,8192]
Repaired extent references for 35132350464
```

2026-04-11 05:53:33 UTC

- reply

Whatever `btrfs` did, it did a proper job of it.
10 hours later and `btrfsck --repair` still grinding away. Yes I took a snapshot of the disk before making changes.

2026-04-10 20:59:01 UTC

Over here for a bit, because right now my Mastodon server is busy undergoing a `btrfsck --repair` on a key volume.

2026-03-28 10:34:59 UTC

Swapping over here as I jump the home server from Mastodon 4.5.5 to 4.5.8.

2026-02-06 22:12:04 UTC

- reply

Let's see if we can force-recompile the offender. Guessing here, but let's try:
```
mastodon@mastodon:~/live$ env RAILS_ENV=production bundle install --force
```

2026-02-06 22:09:57 UTC

Ohh wonderful, so `apt-get dist-upgrade` has managed to break the custom Ruby build that runs Mastodon. Or rather, one of its "gems".
```
==> /var/log/syslog <==
2026-02-07T08:08:31.370873+10:00 mastodon bundle[9097]: There was an error while trying to load the gem 'charlock_holmes'.
2026-02-07T08:08:31.371202+10:00 mastodon bundle[9097]: Gem Load Error is: libicudata.so.72: cannot open shared object file: No such file or directory - /home/mastodon/live/vendor/bundle/ruby/3.4.0/gems/charlock_holmes-0.7.9/lib/charlock_holmes/charlock_holmes.so
```
#MastoAdmin

2026-01-20 20:57:33 UTC

- reply

Oookay… booting back up.

2026-01-20 20:51:47 UTC

- reply

I notice `pg_dump` is still complaining about the collation:
```
WARNING: database "mastodon_production" has a collation version mismatch
DETAIL: The database was created using collation version 2.36, but the operating system provides version 2.41.
HINT: Rebuild all objects in this database that use the default collation and run ALTER DATABASE mastodon_production REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.
```
… but it seems to be running okay. I don't feel like doing a `DROP DATABASE` and restore at this time to rebuild the objects, unless there's some simpler way to do a rebuild.
Anyway, the build is started, we should be back soonish.

2026-01-20 20:45:55 UTC

- reply

Swapping over here during the update.

2026-01-08 02:32:27 UTC

- reply

Are we back yet? Let's see.

2026-01-08 02:30:06 UTC

- reply

Oookay, Mastodon rebuild done, updates applied… another reboot.

2026-01-08 02:26:09 UTC

- reply

This would explain it, I forgot about `/etc/apt/sources.list.d` … so another update pass.

2026-01-08 02:24:36 UTC

- reply

Pulled latest stable Mastodon, and I'm currently building that.
I notice this message:
```
WARNING: database "mastodon_production" has a collation version mismatch
DETAIL: The database was created using collation version 2.36, but the operating system provides version 2.41.
HINT: Rebuild all objects in this database that use the default collation and run ALTER DATABASE mastodon_production REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.
```

2026-01-08 02:18:37 UTC

- reply

Oookay, `reboot` time… at last.

2026-01-08 02:14:37 UTC

- reply

Did an `apt-get --fix-broken install` which succeeded, and re-ran `apt-get dist-upgrade -y`.
It seems to be installing without incident, and most crucially, without this `sse4.2-support`. So clearly it wasn't needed, makes me wonder why it was picked up as an update in the first place.

2026-01-08 01:48:31 UTC

- reply

```
Preparing to unpack .../0-sse4.2-support_27_amd64.deb ...
This machine doesn't support SSE4.2, sorry.
Aborting.
dpkg: error processing archive /tmp/apt-dpkg-install-e5FGqW/0-sse4.2-support_27_amd64.deb (--unpack):
new sse4.2-support package pre-installation script subprocess returned error exit status 2
```
Not a promising message. The CPUs in the VM report themselves as "QEMU Virtual CPU version 2.5+", the physical CPU is a Intel Atom C2000 series.

2026-01-08 00:34:29 UTC

- reply

Download is finished and database back-ups taken. The packages are being installed now.
After that, I'll reboot (to activate the new kernel and `glibc`), then I can tackle Mastodon's update to 4.5.4.

2026-01-08 00:19:59 UTC

- reply

I'll swap over here for the moment.

2025-12-12 03:05:44 UTC

- reply

```
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----
1: 0xe38a0e node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/usr/bin/node]
2: 0x120a5a0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/usr/bin/node]
3: 0x120a877 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/usr/bin/node]
4: 0x1438155 [/usr/bin/node]
5: 0x14519e9 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/bin/node]
6: 0x1426098 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/bin/node]
7: 0x1426fc5 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/bin/node]
8: 0x13ffc9e v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/usr/bin/node]
9: 0x18612fc v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/usr/bin/node]
10: 0x1dbf476 [/usr/bin/node]
pid 1614196 exit 1
Build with Vite failed! ❌
```
!@#$ JavaScript!

2025-11-07 00:06:20 UTC

- reply

Starting up…

2025-11-07 00:04:29 UTC

- reply

Failed a second time, apparently it now works _without_ that option set.
It used to be it'd fail to build unless I did set the "max old space size". This is a VM with 8GB of RAM… it did get an upgrade when the Atom C2000 issue was resolved on a couple of old boards meant I gained some extra compute capacity… but yeah… JavaScript drives me nuts.
Anyway, managed to get the assets compiled… onward with database migration.

2025-11-06 23:31:12 UTC

- reply

Trying again with `--max-old-space-size=512`.

2025-11-06 23:29:55 UTC

- reply

```
<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----
1: 0xe38a0e node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/usr/bin/node]
2: 0x120a5a0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/usr/bin/node]
3: 0x120a877 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/usr/bin/node]
4: 0x1438155 [/usr/bin/node]
5: 0x14519e9 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/bin/node]
6: 0x1426098 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/bin/node]
7: 0x1426fc5 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/bin/node]
8: 0x13ffc9e v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/usr/bin/node]
9: 0x18612fc v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/usr/bin/node]
10: 0x1dbf476 [/usr/bin/node]
pid 2154020 exit 1
Build with Vite failed! ❌
```
… I f'ing hate #JavaScript.

2025-11-06 23:23:10 UTC

- reply

```
root@mastodon:~# nodejs --version
v22.21.0
```
…let's try that assets compile step again!

2025-11-06 23:22:24 UTC

- reply

So the issue was `liburing1` not being available on Debian 12… and also `/etc/apt/sources.list.d/postgresql.list` still referencing Debian 11 repositories.
Not so much I'm "holding" broken packages, just the distribution has moved on. Now PostgreSQL v18 is installed and it'll attempt an update of the cluster (from v17). I've got a full database dump.

2025-11-06 23:18:48 UTC

- reply

```
root@mastodon:~# apt-get install -y postgresql
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
postgresql-18 : Depends: liburing1 (>= 0.7) but it is not installable
Recommends: postgresql-18-jit but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
```
…excuse me, *I* have held broken packages? *I*? You're operating in Australia, we're presumed innocent until found guilty by a jury here… Evidence please!

2025-11-06 23:17:10 UTC

- reply

In the midst of picking apart NodeSource's `setup_22.x` script so I can manually apply the changes without running a script as `root`… I see this:
```
The following packages have been kept back:
postgresql
```
I hate it when Debian does things without explaining what's going on.

2025-11-06 23:07:06 UTC

- reply

```
Building with Vite ⚡
You are using Node.js 20.5.1. Vite requires Node.js version 20.19+ or 22.12+. Please upgrade your Node.js version.
failed to load config from /home/mastodon/live/vite.config.mts
error during build:
TypeError: crypto.hash is not a function
at file:///home/mastodon/live/node_modules/@vitejs/plugin-legacy/dist/index.js:584:21
at Array.map (<anonymous>)
at file:///home/mastodon/live/node_modules/@vitejs/plugin-legacy/dist/index.js:584:3
at ModuleJob.run (node:internal/modules/esm/module_job:192:25)
at async DefaultModuleLoader.import (node:internal/modules/esm/loader:228:24)
at async loadConfigFromBundledFile (file:///home/mastodon/live/node_modules/vite/dist/node/chunks/config.js:36128:12)
at async bundleAndLoadConfigFile (file:///home/mastodon/live/node_modules/vite/dist/node/chunks/config.js:36014:17)
at async loadConfigFromFile (file:///home/mastodon/live/node_modules/vite/dist/node/chunks/config.js:35981:42)
at async resolveConfig (file:///home/mastodon/live/node_modules/vite/dist/node/chunks/config.js:35632:22)
at async createBuilder (file:///home/mastodon/live/node_modules/vite/dist/node/chunks/config.js:34104:19)
pid 2145854 exit 1
Build with Vite failed! ❌
```
… bugger.

2025-11-06 23:06:17 UTC

- reply

`NODE_OPTIONS="--max-old-space-size=768" RAILS_ENV=production bundle exec rails assets:precompile`
The `--max-old-space-size=768` is needed here because `nodejs`' heap management sucks, it just `malloc`s until it hits `ENOMEM` then dies.

2025-11-06 22:51:33 UTC

- reply

Oookay… onto the next step. `bundle install && yarn install --immutable`

2025-11-06 22:23:22 UTC

- reply

To be fair, I saw the `rbenv install` and missed the other bit, due to the way the text wrapped.
https://mediacdn.aus.social/media_attachments/files/115/505/089/838/600/968/original/61fd67bec45e60bb.png

2025-11-06 22:21:16 UTC

- reply

Crap, forgot `RUBY_CONFIGURE_OPTS=--with-jemalloc`…

2025-11-06 22:19:13 UTC

- reply

```
mastodon@mastodon:~/live$ rbenv install
==> Downloading ruby-3.4.7.tar.gz...
-> curl -q -fL -o ruby-3.4.7.tar.gz https://cache.ruby-lang.org/pub/ruby/3.4/ruby-3.4.7.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 22.1M 100 22.1M 0 0 2503k 0 0:00:09 0:00:09 --:--:-- 3143k
==> Installing ruby-3.4.7...
-> ./configure "--prefix=$HOME/.rbenv/versions/3.4.7" --enable-shared --with-ext=openssl,psych,+
-> make -j 4
-> make install
```
… took its time as usual… but we should soon be moving on to the next phase.

2025-11-06 22:04:44 UTC

- reply

Errm, the original Pi is ARMv6: `armhf` architecture.
`armel` is the software floating-point ABI.
`armhf` is the hardware floating-point ABI.
`armhf` isn't going anywhere for a little while yet, your Pi v1s are still good for now

2025-11-06 21:53:27 UTC

- reply

There are times I wonder why I run Debian for a Mastodon host… I compile that much of it from source I might as well be running Gentoo.

2025-11-06 21:52:45 UTC

- reply

Ahh, `rbenv` my nemesis, we meet again… time to pull v3.4.7 (from v3.2.3).

2025-11-06 21:40:42 UTC

Oookay… I'll swap over here for a bit while I get my instance updated.

2025-10-24 02:44:17 UTC

Swapping over here for a bit… my server's behind a few versions so I better bump Mastodon up to the latest on the 4.4 branch ahead of a move to 4.5 when it's finally released. #MastoAdmin

2025-09-28 00:40:46 UTC

- reply

```
✓ built in 9m 52s
PWA v1.0.0
Building mastodon/service_worker/sw.js service worker ("es" format)...
vite v6.3.6 building for production...
transforming...
✓ 73 modules transformed.
rendering chunks...
computing gzip size...
../../public/packs/sw.mjs 188.78 kB │ gzip: 60.27 kB │ map: 1,065.79 kB
✓ built in 11.28s
Build with Vite complete: /home/mastodon/live/public/packs
mastodon@mastodon:~/live$
```
…restarting.

2025-09-28 00:38:57 UTC

- reply

```
✓ 1940 modules transformed.
rendering chunks...
```
… nearly there.

2025-09-28 00:36:38 UTC

While I'm fine with quote posts in general, can't say I'm excited by the "boost" button essentially being a menu button. Ohh, and I'll have to whitelist quote-posts for @npub1s35…d4qd. #QuotePost #Mastodon #mastodon45
https://mediacdn.aus.social/media_attachments/files/115/279/117/747/468/307/original/d553fe417c4bae05.png

2025-09-28 00:31:56 UTC

- reply

```
I, [2025-09-28T10:29:20.664134 #3384849] INFO -- : [dotenv] Loaded .env.production
Building with Vite ⚡
vite v6.3.6 building for production...
transforming...
```

2025-09-28 00:30:00 UTC

Little bit of downtime on my home server while I update to Mastodon 4.4.5. #MastoAdmin

2025-08-31 03:44:40 UTC

- reply

WICEN OwnCloud also got knocked out… seemingly couldn't run `e2fsck` (it seems to be using EXT4). A map of the RBD and a manual run has sorted that one out.

2025-08-31 03:40:18 UTC

- reply

Actually it's taken out 3 of the 4 VMs with filesystem corruption… so much for btrfs being self-healing.

2025-08-31 03:38:22 UTC

- reply

…and of course the Mastodon host running there has just crapped itself. btrfs is failing to mount the filesystem and Debian + systemd is incapable of dropping to a root shell when things go pear shaped.

2025-08-31 03:29:24 UTC

Yaaay, machine check exception bringing a node down… what fun!

2025-08-30 08:50:19 UTC

- reply

```
✓ built in 18.20s
Build with Vite complete: /home/mastodon/live/public/packs
```
…ya huh, that was a long 18.2 seconds.

2025-08-30 08:48:50 UTC

- reply

```
Building with Vite ⚡
vite v6.3.5 building for production...
transforming...
✓ 1940 modules transformed.
rendering chunks...
```
…don't rush yourself…

2025-08-30 08:41:37 UTC

- reply

Waiting for `vite` to weave its magic… then we should be able to re-start.

2025-08-30 08:35:12 UTC

Quick update of the server to Mastodon 4.4.3… since I notice 4.4.2 isn't sending email notifications and can't show videos full-screen. (It'll open the video then immediately close it.)

2025-07-09 03:45:59 UTC

- reply

Migrations done… let's see if she'll start up.

2025-07-09 03:08:53 UTC

- reply

```
bin/rails aborted!
LoadError: Could not open library 'vips.so.42': vips.so.42: cannot open shared object file: No such file or directory. (LoadError)
Could not open library 'libvips.so.42': libvips.so.42: cannot open shared object file: No such file or directory.
```
`apt-get install -y libvips` duh! Forgot that.

2025-07-09 02:36:02 UTC

- reply

```
==> Installed ruby-3.4.4 to /home/mastodon/.rbenv/versions/3.4.4
```
First hurdle cleared. Now for the next steps…
```
env NODE_OPTIONS="--max-old-space-size=768" RAILS_ENV=production sh -c 'bundle install && yarn install --immutable && bundle exec rails assets:precompile' && SKIP_POST_DEPLOYMENT_MIGRATIONS=true RAILS_ENV=production bundle exec rails db:migrate
```

2025-07-09 02:16:07 UTC

Hi ho hi ho, it's Mastodon update time I go… you'll find me over here in the interim.
https://mastodon.social/@Mastodon/114818205314251502
#MastoAdmin

2025-06-30 22:45:43 UTC

- reply

8 of the 10 OSDs have updated their metadata… waiting on the last two which are taking a while.
In the meantime, the RBD volume that runs PostgreSQL is blocked… so I'll hang around on here for a hour or two.

2025-04-05 06:50:59 UTC

- reply

Enough power to be annoying, but not useful.
https://mediacdn.aus.social/media_attachments/files/114/284/026/375/533/388/original/2ea988f2b1d520d7.mp4

2025-04-05 06:42:38 UTC

- reply

https://mediacdn.aus.social/media_attachments/files/114/283/993/261/796/919/original/377212f762bf2e5e.mp4

2025-04-05 06:26:23 UTC

Brilliant, power outage. Just what I need.
https://mediacdn.aus.social/media_attachments/files/114/283/926/970/029/808/original/6303c6eebbc34bdc.png

2025-03-28 08:55:37 UTC

- reply

Managed to get my firewall to fail over to 4G… but geez…
Friday evening habit is to stream a 50s and 60s radio show… well… with my shitty line-of-sight to the Telstra towers, that just ain't happening.
Glitching left, right and centre… and no wonder… look at the ping time:
```
--- 8.8.8.8 ping statistics ---
50 packets transmitted, 43 received, 14% packet loss, time 49504ms
rtt min/avg/max/mdev = 161.328/762.185/1152.049/286.621 ms, pipe 2
```

2025-03-12 22:37:37 UTC

- reply

…and down she goes again.
Seriously, the HFC network around here really is terrible just now.
A Brunswick street bird's underpants stay up longer!

2025-03-12 20:03:47 UTC

- reply

> A woman takes a selfie as she walks along flooded Edmondstone Street in the suburb of Newmarket.
Bloody hell, lots would see that and think "only in America", but that photo was taken a couple of suburbs over from where I am.

2025-03-10 10:52:50 UTC

- reply

```
2025-03-10T09:23:01Z>2025-03-10T10:41:01Z PADI=17 PADR=0 STATUS="no carrier">"active"
2025-03-10T10:41:01Z>2025-03-10T10:42:01Z PADI=18 PADR=0 STATUS="active">"no carrier"
```
NBNco, you taunt me so.

2025-03-10 09:26:08 UTC

- reply

…and down it goes again…
```
2025-03-10T09:14:01Z>2025-03-10T09:23:01Z PADI=49 PADR=0 STATUS="active">"no carrier"
```

2025-03-10 08:55:29 UTC

- reply

```
2025-02-17T15:54:01Z>2025-03-08T13:46:01Z PADI=73 PADR=0 STATUS="active">"no carrier"
```
Now that I'm home… I can see exactly down to the second, when the Internet link last went down.
I might manually grab the emails from the VPS, pull those down, then feed them into the server here to see what people have been sending me.

2025-03-10 04:19:47 UTC

- reply

Not certain, but it *might* have peaked.
http://www.bom.gov.au/fwo/IDQ65389/IDQ65389.540604.plt.shtml
#CycloneAlfred
https://mediacdn.aus.social/media_attachments/files/114/136/185/872/524/424/original/9f22f3b1c53df07a.png

2025-03-10 02:10:56 UTC

- reply

Alert is back a few pages now. https://www.theguardian.com/australia-news/live/2025/mar/10/australia-live-news-ex-tropical-cyclone-alfred-flood-evacuation-queensland-nsw-lismore-brisbane-wa-election-roger-cook-anthony-albanese-peter-dutton-ntwnfb?CMP=share_btn_url&page=with%3Ablock-67cdf9c18f08d2770c97ddd6#block-67cdf9c18f08d2770c97ddd6

2025-03-09 00:28:11 UTC

Some tree carniage in our street already. Thankfully only a little one. #CycloneAlfred
https://mediacdn.aus.social/media_attachments/files/114/129/625/523/897/209/original/c06143bbac0e7158.jpg

2025-03-08 23:43:31 UTC

NBN outage confirmed, I just had this message in from Internode. No doubt a legacy of #CycloneAlfred
*.longlandclan.id.au
*.vk4msl.id.au
and *.vk4msl.com are going to have major outages for a little while.
https://mediacdn.aus.social/media_attachments/files/114/129/428/679/688/669/original/163f977423ea7c11.png

2025-03-05 07:37:32 UTC

- reply

Getting closer now… #CycloneAlfred
https://mediacdn.aus.social/media_attachments/files/114/108/676/528/315/956/original/608d88e41bb88223.png

2025-03-05 03:33:14 UTC

- reply

The updated forecast map. #CycloneAlfred
https://mediacdn.aus.social/media_attachments/files/114/107/697/324/639/234/original/ea50dc02b41d2177.png

2025-03-05 01:54:39 UTC

- reply

Well hello #CycloneAlfred … we've been expecting you!
https://mediacdn.aus.social/media_attachments/files/114/107/318/544/883/714/original/711bf66a03e11a82.png

2025-03-05 00:49:38 UTC

- reply

Another forecast… as #CycloneAlfred wobbles itself to the coast.
https://mediacdn.aus.social/media_attachments/files/114/107/040/627/746/477/original/bf2aa1334cd22bf2.png

2025-03-04 23:15:51 UTC

- reply

For those in the Northern Rivers NSW region (and those living close to the Queensland border… maybe one of these is closer to you):
The following SES evacuation centres will open as of 4pm this afternoon, according to Chris Minns.
Terranorra Public School — 650 Terranora Rd, Terranora
Tyalgum Hall — Coolman St, Tyalgum
Mullumbimby RSL — 58 Dalley St, Mullumbimby
Kingscliff TAFE — 806 Cudgen Road, Kingscliff
Murwillumbah TAFE — 146 Murwillumbah Street, Murwillumbah
Ocean Shores Country Club —113A Orana Road, Ocean Shores
Coraki Pubic School — 48-52 Adams Street, Coraki
Kyogle Memorial Hall — Stratheden Street, Kyogle
Southern Cross University — Military Road, East Lismore
Evans Head RSL — 11-13 McDonald Place, Evans Head
Burringar Sports Club — Fourth Ave, Burringbar
Uki Hall — 1462 Kyogle Rd, Uki
https://www.abc.net.au/news/2025-03-05/tropical-cyclone-alfred-brisbane-forecast-queensland-nsw-live/105010498?utm_campaign=abc_news_web&utm_content=link&utm_medium=content_shared&utm_source=abc_news_web#live-blog-post-156886
#CycloneAlfred

2025-03-04 23:06:26 UTC

- reply

Forecast updates are coming through thick and fast … and of course it has to happen while my server is busy running the JavaScript build tools that build Mastodon's UI.
#CycloneAlfred has a definite kink in the predicted path as it crosses the coast.
Seriously Alfred, go home, you're drunk!
https://mediacdn.aus.social/media_attachments/files/114/106/642/386/798/701/original/418109ae08a740fc.png