Commodore: Boot struts replaced

After watching someone with a fancy minivan wave their hand in front of the tailgate and have it magically rise on it’s own, Sabriena said that she’d like something like that on our next car. Why? Because since she hurt her back, she’s found opening the boot of our VE Commodore difficult and at times painful.

It’s hopefully going to be ages before we replace our car, but I figured that it was probably possible to adjust the spring on the boot to make it not so heavy. So when we got home, I looked it up, and no - there are no springs on the boot on this model at all. In fact, they’re just a pair of gas struts that handle the soft-close and weight offset functions, and apparently when they go out you get the exact situation we’re seeing: a heavy boot lid.

Looking it up, they’re not expensive - there are two, and most places had them for about A$40 each. SuperCheap Auto has them, “Ezilift” EL2071 are the ones for the boot on a VE sedan, and they were about A$75 for the pair. That’s cheap enough to gamble on the old ones still being fine, so we picked some up this morning, and when we got home after our errands I set about changing them.

Swapping them out is pretty easy: open the boot all the way, pop off the little metal retention clip (it slides down towards the tip, doesn’t need to come all the way off) on each end, and pop the strut out, and then clean the dusty grease off the nipples the strut sits on. Replacing the new one in took me a bit of figuring out, because I did not read about this beforehand. The strut is ever so slightly too long, and compressing the strut by hand is basically a non-starter.

But what you can do is close the boot lid slightly, and then there’s a plastic bump stop on each side that you can pop off to open it a tiny bit further. Do that, and the struts pop on with a tiny bit of effort. Push the clips back down, close the boot lid slightly and put the bump stops back on, and then test.

And the result? Both Sabriena and I nearly smacked ourselves in the chin with the spoiler when we opened it the first time. So yeah, I would say the old ones were buggered. You now trivially open the boot one handed - and you only lift it an inch or two and it opens itself.

I should have done this years ago, they were likely wore out when we bought it. I’m now side-eyeing the ones on the bonnet as well.

Horsham, VIC, Australia fwaggle

Published:


Modified:


Filed under:


Location:

Horsham, VIC, Australia

Navigation: Older Entry

Imaging a laptop to VirtualBox

My old laptop is looking a little worse for wear. Its battery has decided life is not worth living, and it’s stuck with a developer preview of Windows 10 on it, which means it will never see another update. Microsoft offers no migration path for this, I’m supposed to reinstall Windows freshly, but there is software on there for ODB2 purposes which has an utterly bullshit license which states that I cannot reinstall it without purchasing the software again.

Out of spite, my plan is to reverse engineer it and put all the Holden-specific stuff into my own, open source software, but unfortunately energy and time and motivation all conspire against me and that hasn’t happened for some years now.

But I also want the SSD it’s on out of that laptop for the Longhorn cluster. I was going to just buy another one, but because Sam Altman is a fucking shithead, that’s not reasonably going to happen any time soon.

So I decided to dd the disk to an image on my desktop, which is unfortunately Windows again. However this works fine:

dd bs=4096 if="\\.\physicaldrive2" of="d:\laptop.dsk"

It was ridiculously slow. I don’t know if a 4KB blocksize is optimal, maybe it would have gone faster, but I think the issue was my 4TB beyblade that I dropped the 480GB image on to because my NVME drive doesn’t have that much space on it. It may also have been the fact that I was using a USB 3.0 SATA dock, but I feel like it should be faster than this. Anyway, it took about 3 hours at an average of about 50MB/sec.

I was rooting around for a hard drive I could write the image back to, when an idea occurred to me that I could just use VirtualBox and not have to run it on real hardware. After some Googling, I learned that yeah, it’s pretty easy to convert a disk image to a VBox image:

'C:\Program Files\Oracle\VirtualBox\VBoxManage.exe' convertfromraw D:\laptop.dsk d:\laptop.vdi

More waiting, but it eventually finished, and after I gave it sufficient RAM + CPU the VM booted fine, so I’m content. I still cannot reduce the primary partition below 250GB for some reason (I will almost guarantee that as it’s almost exactly half the size of the original partition that there is some magic block there which cannot be moved and thus prevents the shrink), but the resulting VBox image is a dynamic/sparse image anyway so the whole thing only weighs less than 100GB anyway, so maybe I don’t care any more?

Horsham, VIC, Australia fwaggle

Published:


Modified:


Filed under:


Location:

Horsham, VIC, Australia

Navigation: Older Entry Newer Entry

More time server goofing

After dicking around with the time server last week, I noticed that AliExpress were having a “sale” and they had “marine style” GPS antennae for about $12 shipped, which sounded good enough to gamble on. The package arrived today, so after work I set about figuring out how to get it on the roof.

I’d originally intended to put it on the post that old FoxTel dish used to live on (the dish removed because it cast a shadow on the solar panels at certain times of the day), however doing so would likely necessitate some sort of lightning protection. Instead, by tucking it under the TV antenna next to the evaporative tower for our air conditioning, I can negate the risk of that significantly.

That’s farther than 5 meters though, and I don’t know how good the “active” part of this $12 GPS antenna is to push the signal adequately down an extension cable, so I resolved to move the GPS into the house rack instead of the garage, run the cable through the penetration into the ceiling void and up to the roof. A cursory test shows that signal is significantly improved with it just laying on the roof. Why, I don’t think I once saw less than 7 satellites that met the filters, a far cry over the “three or four but sometimes two” (and definitely no hope of SouthPAN reception whatsoever) of the puck on a west-facing window.

The antenna mounts by what’s allegedly a 1"-14 TPI thread, so I started trying to find something to mount it with. Absolutely nothing in Australia that I can find, and the only thing I could find mail ordering was small plate-mount things that I’d have to screw into my roof. No thanks. Jaycar had bullbar mounts for a UHF antenna, but even that wasn’t really right as I’d still need some sort of bolt in the right thread, and I’d need a way to enlarge the hole in it.

Off to Hammer Barn (twice, as the first time I neglected to bring the antenna with me to test fit anything, and guessed wrong on the threads and thus had to return one), and it turns out 20mm x 3/4" valve take-off adapter (Holman PVVA2020) fits the thread on the bottom of the antenna just well enough. You’d not want to swing off it or anything, and it’s certainly not water-tight, but it pulls up tight enough without jumping a thread to keep the antenna in place. A couple of 45 degree elbows and a short length of the appropriate sized pipe, and then some glue to stick it all together and I have a reasonably nice looking little mount. A couple of antenna clamps to squeeze it to the TV mast, snake the cable back in to the rack and we’re away. Ironically, because of the clamps, the mounting solution cost more than the antenna did.

Interestingly though, once I let it sit with the SouthPAN test-mode signal enabled for a while, precision was really good for location, but my time signal with Chrony was absolutely dogshit. Bad enough it threw out my PPS signal as a falseticker and switched to an NTP source instead. Inspecting it, and I learned why: for some reason when the test mode signal is on (even if it’s not got a clear enough signal to get a DGNSS fix), it periodically clobbers the GPS->UTC offset, which is currently 18 seconds, to zero. Whichever NMEA message contains the offset (almanac?) would come in and set it back to 18 seconds, and back and forth they’d go, at roughly 7 minute intervals.

So that means that periodically, the NMEA clock the PPS uses for a reference is out by 18 seconds. No wonder Chrony was throwing it out.

I spent a little while faffing about with u-center trying to figure out what I had configured wrong, before I gave up and just figured the receiver is too old to do it properly. But what I can do is crank the position-hold settings, let it sit in DGNSS mode until the survey-in period is done (I picked an hour at 1.5M, it came up with a standard deviation on the position it picked of 0.4M, which I think is good?). I then turned off test mode in the SBAS configuration, did a warm start, and let it go.

I’ll see how accurate it is over the next week, but hopefully it’s an improvement… at least I’m not out too much money if not.

Update: 2026-01-18: It’s sat pretty rock-solid with a nice flat graph of skew since the installation. CloudFlare’s dances around either side of it but it’s fairly consistently below a microsecond out too. Of course with something like this it’s hard to tell which is correct. I have found the performance of CloudFlare’s time server to be pretty stellar compared to most of the others in the pool, but the point is they’re in agreement a lot more of the time than the previous solution, so I’m happy.

Horsham, VIC, Australia fwaggle

Published:


Modified:


Filed under:


Location:

Horsham, VIC, Australia

Navigation: Older Entry Newer Entry

Bushfire!

Today was the third day in a row of our local heatwave - we had 44, 42, and 44 today, but today was forecast to have very strong winds as well, making conditions less than ideal for people who don’t enjoy bushfires. Alas, that’s how it came to be with apparently more than 60 fires across the state today. We had one turn up just to the west of us, out near Natimuk, I think it started around 3pm.

That’s not great for the people there, but not great for us either - the wind was coming from the north-west blowing it down through Natimuk, but when the wind swung around to coming from the south-west it looked like it’d blow the entire fire front straight at us.

We had all our shit ready to go, but took encouragement from the fact that they were still evacuating people to Horsham, so it felt slightly unlikely we’d have to leave. But still, we were ready if need be. There was a soft recommendation for people in our area (the west side of Horsham, near the grasslands) to move east of Bennett road, but we opted to stay put and just be ready to leave town completely if it looked like we’d have to.

The weather was absolute arse though, the swamp cooler kept up until it reached the point where it was blowing smoke into the house, so we switched it off. Almost immediately though the house became unbearable, but I realized that we had - despite the clouds of smoke - copious amounts of solar capacity free, so we fired up the two old split systems and let them have a go. This kept the house quite comfortable until well into the evening, when we started to look like we’d be dipping into buying electricity… I figured I don’t need to be contributing to any demand surge issues, and the smoke had cleared out a bit so we switched back to the evaporative cooler.

We never lost power, and the next day there were several news articles about the power from solar+wind helping the state cruise through the heatwave event with very few demand issues at all.

At about 8pm or so they downgraded us from dark orange to light orange, with the fire apparently only making it as far as Vectis, so we were able to relax a bit, but it was a bit of a worrisome day. It remains to be seen what sort of damage was done to Natimuk though.

Horsham, VIC, Australia fwaggle

Published:


Modified:


Filed under:


Location:

Horsham, VIC, Australia

Navigation: Older Entry Newer Entry

Arch Linux, Serial Console; Garbled messages

A couple of years ago now I scored a serial console, specifically a Link MC-3 which is a rebadged Wyse 60 (or thereabouts) which is itself a knock-off VT-220. I love it to death, and relish any opportunity to drag it out and do something with it.

So the other day I was going to use it to reinstall FreeBSD on my time server, but couldn’t find a cable for it, so I built a new one… and in the process of testing that, I found that when I enabled getty (well, the systemd equivalent of it anyway, and in case future me is looking at this post going “what did you know?!”, the command to do this is systemctl start serial-getty@ttyUSB0.service if the serial device is /dev/ttyUSB0) on my Linux machine, I get some weird messages that look somewhat reminiscent of auditd style messages:

3008;start=<some uuid>;user=root;hostname=fwaggle-laptop;machineid=<some uuid>;bootid=<some uuid>;pid=1234;type=command;cwd=/home/fwaggle

There’s a bunch of these, before and after every command, before and during a login, everywhere. I put up with them and ended up doing something else, and today during lunch I happened to take another look, and managed to turn up a handful of GitHub issues about it, leading to the culprit: systemd itself!

They’re OSC “context” messages, with the idea being your shell will quietly eat them and be able to do all sorts of things at the presentation level, like showing which commands ran as root, and one of the more interesting example uses is being able to right click on a command’s output and kill the process that generated it. As it’s in-band signalling, it does bring up interesting ideas about how one could spoof it for interesting tricks, but I am not aware of anything just yet that uses it.

I find it pretty obvious that the argument that any VT-100 or ANSI-capable terminal will ignore these messages doesn’t hold water, but it was comforting to see that I wasn’t alone, why someone else had the same issue just three weeks ago!

The solution is pretty easy to do, though not exactly elegant. First, run systemctl edit serial-getty\@.service, which will spawn your editor (hope your $EDITOR or $VISUAL is set correctly). I add this to the file:

[Service]
Environment=TERM=dumb

This tells systemd your terminal is “dumb”, and does not support all the OSC messages. Upon running systemctl restart serial-getty@ttyUSB0.service the problem has gone away! Unfortunately so has a bunch of other shit, like the ability for the shell to clear the screen, move the cursor, and so on. Baby, bathwater, bye. Purists may argue this relegates you back to the proper early terminal days, but I have VT-220 capability I would like to use it, thank you very much.

I haven’t found an acceptable solution to this. You can run export TERM=vt220 in your shell after login, but I would like a way to automate it.

Apparently a more permanent fix is to remove /etc/profile.d/80-systemd-osc-context.sh and create an empty /etc/tmpfiles.d/20-systemd-osc-context.conf file to stop the former being recreated, but I’m not sure what else that will break in the future and this is rather rare an occurrence for me.

Horsham, VIC, Australia fwaggle

Published:


Modified:


Filed under:


Location:

Horsham, VIC, Australia

Navigation: Older Entry Newer Entry