systemd-journal-flush and ostree-finalize slowing shutdown
It seems to happen pretty much every time by now, but whenever I go to turn off/reboot my computer, it seems to always halt, generally after unmounting /var/home, with the systemd-journal-flush.service.
I've tried manually flushing before shutting down, to no avail, and the only fix related to it that I found online involved changing the flush configuration to have Storage=persistent, but I can't very well do that here to test it.
Same thing happens with ostree-finalize (earlier than journal-flush but always combined with it).
Even after a rebasing, be it with an update, kernel argument change, or even happened after I just updated grub with ujust, it halts for ups of 5 mins on shutdown until it eventually reaches the timeout and shuts it down.
Solution:Jump to solution
turns out it very well may have been, after all
applying Turtlewit's workaround in #Tuned power manager tunes too low seems to have solved this returning issue for me and and for TheMCNerd2018; haven't had it again since
seems like this is one where "works on my machine" doesn't win :)...
365 Replies
also experiencing this
Exactly the same as you describe it
this seems isolated to bazzite. I rebased to ublue kinoite and it goes away
ublue kinoite? you mean aurora? but yeah, it is weird
just base kinoite ublue-os/kinoite
ohh, alright
but then it probably isn't an upstream issue?
i don't really know but that seems likely
someone fixed this with a manual
rpm-ostree update earlierit didn't update anything, but I'll report back if it does conclusively fix it
well the
ostree-finalize is the final step in an update during shutdown
it removes the oldest deployment and replaces it with the incoming one
anyways i need to head off and get some sleepyeah, I'll be doing that too, Mr Knight of Light
thank you for the help, I did run the rpm-ostree update and I'll see tomorrow if during normal use it happens again
systemd-journal-flush happened again, that didn't change, don't know about how it would affect ostree-finalize, I'll check in case I rebase for any reason
here's a log of my last boot that involved both the sddm black screen (from another issue) as well as the long shutdown time https://paste.centos.org/view/d0ed3e25
as for systemd service logs, @Kyle Gospo asked me for them but I'm not sure what service it should be, so here's
journalctl -u systemd-journal-flush.service I guess https://paste.centos.org/view/fab425edAll that does is write logs to your disk, I need the full log to figure out why that's taking so long
I suspect you have a drive issue
@nickname I'm out but if you can get them that command that'd be very helpful
yeah, I need the command š
:clueless: oh boy
ok hold on
that'd be interesting, given I recently replaced both my nvmes š¤ could be faulty, but hadn't had any issues before
yeah he's probably out doing work stuff
ok
fair enough
give me a minute here
i just got pinged again
no problem
if I can't do it before I have to leave I'll do it later when I get back anyway, so it's all good
probably the wrong command but hey i don't know
send link idk i can take a look at this. also have you updated recently?
I have, like before yesterday or maybe even yesterday, and yesterday, per Hikari's suggetion, even did an rpm-ostree update again (although no updates were available)
ok
here https://paste.centos.org/view/607cb397
was just skimming through and was thinking maybe I should try manually disabling TPM on the bios? if that would make any difference
never touched it and it never did, but idk
can try
and report back
alright
ok, disabling TPM at the very least didn't change the sddm black screen problem, now onto a shutdown
š¤
i know updates can make shut downs slower but if no new updates applied and it takes a long time then it's probably something else
nope, didn't help, halted on journal-flush again
does it ever fully shut down
right, hence the ostree-finalize in this issue as well (although that one is because it would take ups of 5 mins, which seems excessive)
it does, after like 1-3 minutes (it varies) stuck on journal-flush, it moves on and usually shuts down normally after that
and sure, if it were just a minute then it might seem like "c'mon man, it's just a minute, just wait", but given sometimes it takes longer, as the timeout goes from 1:30 to like 3:00 or something, and also given it wasn't happening before, it can be inconvenient
is your setup completely stock?
well
hard to ask that
besides the black screen forcing a reboot to log in and shutdowns taking a while, I can use Bazzite pretty normally when I do log in, it's just that, of course, I'd prefer it didn't do this
if you're referring to packaging, I have only 1 package layered which is nbfc (but I'm pretty sure it was happening even without it being there, can try though) and besides that I have a few flatpaks like Heroic, Floorp (removed Firefox) and an arch container where I do some other stuff, like Vesktop and the like
yeah none of that should be causing this
I have to go now, won't be able to test for a while, but I can try answering any other questions that might help
yeah, I figured
I'll be home in like 20 minutes
nice, maybe you can help them test if needed? seeing as the issue is probably the same
ok keep the thread open, we'll be around later most likely. i was planning to go out too. so the black screen at boot is gone now though?
ever since disabling TPM?
well you left but that's wwhat you said above
They said it didn't change it
oh
and your hardware is all AMD?
that's even more bizarre
at least there was consistency before when nvidia users were the only ones with issues
would it be possible to have images with only certain changes made from 39 to 40 to narrow it down more or are the changes too intertwined for that to be feasible
probably would need a lobotomy first
someone else said +1... to this
ok so AMD users are experiencing this
i already knew you were mervius but now i have another person š
tbh I don't care that much about slow shutdown since boot already takes loke 4 minutes whenever the motherboard loses power due to RAM training.
maybe it's mesa
I have always had TPM disabed even before the issues
yeah it wasn't that
I can try disabling reBAR and above 4G decoding and see if that helps
probably wont but try whatever and report results š«”
there's like 6 others with this issue
I'll give it a go
do you all have a distrobox container installed
in some way
I mean there's the default arch one afaik
eh im thinking that shouldnt cause issues
I don't really use distrobox nor know how
so other than that, no
if it has init system like on, supposedly that may cause issues
you can try removing it with boxbuddy
and seeing if you still have issues
i highly doubt it
question for everyone here thouhg
this happens regardless of a fresh installation?
@mervius you said you reinstalled?
I did a fresh install with a full wipe last night
my computer has not been turned off since
oh ok, well when it's on again
let me know if you experience any issues
or if it's only upgrading from 39 --> 40
even though it shouldn't be happening regardless
tbh the wipe was also to remove any residuals from trying to get virtualisation with gpu passthrough working
No difference
the only thing I changed in my bios was disabling armoury crate and changing IOMMU from auto to enabled
the latter likely not actually doing anything
and i don't think the former does anything on linux either
I'm home but elden ring is updating
Just turned my computer off
and it was quick to turn off
also no black screen when turning it back on
I could do it a few more times
2 for 2
Yes, as of yesterday at least. Haven't tried yet today. I'll test once I have a chance to
3 restarts and no issue so far
I'm thinking it might be the update timer?
I had it after an upgrade but also with a fresh install, which is what I have now
wait, what did you do?
nothing?
literally just the fresh install I have
I have disabled the update timer for now to see if that changes anything
Did that after the reboots, though
but so far, it hasn't happened
huh? so you're saying it just fixed itself?
ĀÆ\_(ć)_/ĀÆ
was it maybe some auto update or something?
should I maybe try to update manually and check myself?
systemd-analyze
Please
Worth doing
one sec
that was the command the whole time š
I tried a few times, I guess I'll do it again
should note some differences in hardware
but, just a moment
you have nvidia
and mervius has AMD
but whatever both have similar issues
though, this command might be more useful when you have the problem occur
yeah, I just booted normally after a reboot due to black screen + force shutdown after long flush
should I do it anyway
What version are you on?
like actual image in rpm-ostree status
what command gets you all of that, mine isn't that long
it's verbose
verbos
ah
this is the short
this is what seems to be slowing down my shutdown
Version: nightly (2024-04-26T17:02:20Z)and apparently I'd forgotten, I do have coolercontrol+liquidctl installed as well
this is the version I'm on
a few mins difference
That is an update finishing. Unless you have this every single shutdown nothing is wrong, or it's a red herring and the next service is the issue
As do I, don't have this issue
right
I didn't think that'd be it, just because earlier I had mentioned I only had nbfc layered
but yeah, not like I thought that was the problem
I ran the update system app before rebooting it said everything was up to date, discover store as well
wish I could do some testing but it seems both issues have just... stopped
:/
I wonder if at this point it's worth just rebasing using the regular download command instead of just attempting repeated updates
just force rebase back to the original image
and see if that helps
That will happen if you have an update queued
I'm sorry, what do you mean by update queued? should that happen on every shutdown?
uhh
if the upate isn't working properly, maybe
but it probably shouldn't
not unless it updates or you rebase like for updating kernel args
basically it should only show up any time you touch the ostree
Queued meaning it updated in the background
And you'll boot into it next reboot
I'm new to linux, I don't know how to update the kernel, I usually just use the system update app or type ujust update in the terminal
so, Kyle, worth a short just rebasing using the command below the download button?
on the bazzite website I mean, basically just rebasing back to original image
and if so, should I get rid of the layered packages or-?
That's fine because you can't update it separate from the image here anyway
Are you not on the original image now?
You can rpm-ostree reset, but I know for a fact those packages aren't the problem
I believe I am, I posted the output of rpm-ostree status above
I did do a fresh install with the ISO straight from the website
so yeah
yeah, bazzite-nvidia;stable
so there's no point in rebasing, it'd do nothing
and yet
right
at this point I really don't know, here's a check-local-overrides for the heck of it https://paste.centos.org/view/09b51960
also unrelated to any of this, any time I attempted to disable watchdog with the ujust script it didn't seem to do anything, it still shows it as disabled (even after reboots and such)
rpm-ostree kargs | fpastefpaste seems unnecessary, here
how are you running configure-watchdog?
ujust configure-watchdog
it has no default action
it shows a selection menu and I can select disable
I do
it doesn't
you're using it backwards
here:
oh?
rpm-ostree kargs --append-if-missing=nowatchdog
and then is your CPU amd or intel?amd
rpm-ostree kargs --append-if-missing=modprobe.blacklist=sp5100_tco
that's itAMD Ryzen 7 4800H
oh, alright
is this one also related to watchdog?
yes
also, wdym I'm using it backwards?
alright
seemed pretty straightforward, I run it, it tells me its current state and then asks me if I want it enabled or disabled
systemd-journal-flush is taking around 1min50s to stop when I shutdown everytime here too. I only use AMD too, but since I'm new to Linux I don't understand much of anything.
yeah, I have this issue as well, seems like there's no fix yet unfortunately
I'm still unable to reproduce this on any hardware
I'd love to help, but I got to be able to see it
If I could get a dump of how long every service took that might help, the service you're saying is taking a minute is writing an 8 MB file to the disk
And then exiting
how can I provide that?
would
systemd-analyze blame be helpful here?
@Kyle Gospo someone mentioned the booting to black screen happens on AMD systems on Kinoite too https://discord.com/channels/1072614816579063828/1233578459113193543/1234187027679809536
so maybe some of this is upstreamI'm extremely positive that's the case @nickname
Yes
https://paste.centos.org/view/be64ea7b
let me know if you can see it, I never used a pastebin service before
I mean it does seem that the problem can also just stop
for seemingly no reason
did you say you disabled the automatic update service on this fresh installation?
I have, but I did that after the problem didn't occur
seeing if that prevents it from developing
so far, it hasn't happened
ok
I suppose it's possible the image I used to make the installation media, the installation media, or the installation process itself broke in just the right way for the problem to not happen anymore
but idk how likely that would be
any updates on this issue?
still happening to me, I fresh installed and it seemed like it wasn't happening, but after tweaking the look and feel and everything it started happening again, don't know if it's a coincidence or not, trying to narrow it down now
still not able to reproduce
still not seeing any useful logs of what's actually happening
how can I provide a log of the shutdown process?
okay, I have a question, @Leigars @mervius @Emi do any of you do anything regarding mount points? trying to check something
for instance, I have a secondary drive with a partition dedicated to my personal folder and files and have it being automounted to a directory
Nothing special. Just whatever the default is. I manually mount my other drives whenever I need to access them because it's not very often
I haven't experienced this issue in the last couple of days though
so you never really touched fstab or partition manager?
hmm
interesting
i've messsed with partitions on other drives but not my main one
and not fstab
right, but even just opening partition manager on bazzite
i've done that
hmmm, alright
not saying it's because of it, I'm just testing things and trying to narrow it down
I have a separate drive with Windows 10 installed, but it's not auto mounting I think
i also have a second drive with win11 on my desktop, and likewise not automounting
I have no other installs currently, 3 drives, one blanked out, bazzite install, and personal files drive
ohhh, I got something interesting, I might've narrowed down what the problem could be, let me check further
okay, follow up question, have any of you touched the power profiles? like making it do something when on battery or on ac and whatnot?
On my laptop I have it set to power saver on battery and performance on AC
and by that you mean you customized the settings to automatically switch profiles, right?
I don't have a battery
I actually can't change the power profile off of "balanced"
it doesn't let me
hmmm
but you stopped having the issue, right?
Well I set it to those in their respective battery states through the KDE menu and it just remembers that setting when I switch
Same on my desktop
Well, it doesn't let me in the power options in the toolbar
right
I have opened partition manager
but not changed anything
can you do me a favor and try to go to the power options and use the Defaults button to reset everything?
to see if Zram is the reason only 125Gib of RAM shows up on my pc
and then reboot maybe twice or thrice
I think it might be
hmm
the zram step is the last step before it stalls on journal-flush
I wonder if there's any relation
I was trying to isolate by changing small things one by one and doing a couple of reboots
since there are about 3 Gib of zram which is pretty close to the 2.5Gib not seen by the system
and the problem arose after I tweaked the power profiles and changed what was displayed on the system tray
hmm
I only touch the system tray power manager to manually block screen locking
then I put the profiles back to default and rebooted, didn't do anything, but then I rebooted again and neither the black screen nor the flush happened
since it can't change profiles
hmm
i should clarify, it wasn't through the settings menu, it was through the tray icon. In the settings everything is still default
humor me, that means the Defaults button is greyed out, right?
yes
could you try to just change something random, apply, and use it to reset to Defaults?
and then perform a couple of reboots and see if anything changes
sure
thank you, I'm really curious if this could somehow be it
in the meantime I'll try and keep re-customizing everything I had and see if it returns
only thing I won't touch is power related
I'm on desktop, power profile is performance
Not sure why but now my laptop won't boot
Just stuck on this screen
how have you achieved this feat
It didn't have any problem shutting down, I didn't see the systemd-journald flush at all
what screen?
interesting
try tapping Esc once
Nothing
huh
so it's really stuck?
Appears so. I tried rebooting too
force shutdown and reboot?
I just changed it to performance when I was disabling suspend lol, but I changed like the day I installed bazzite
oh
In the system toolbar?
It doesn't let me change it off of balanced
Do you have a battery?
system settings > energy saving > switch to power profile. I'm on KDE btw
no
so you really just can't boot at all? can't you even see the logs by pressing esc as soon as the Bazzite logo shows up below ROG's?
I tried that and same thing happened. Nothing failed in the boot sequence from what I can see
could you rollback?
you're on the
-asus image i assume@Leigars and @mervius, if you're okay with it (apparently from the 2 samples we have it goes from fixing the issue to also perhaps making it unbootable), maybe you could humor me and also try just changing something random in the power settings and then going back to the Defaults?
if possible
oh yeah, I didn't consider that
Rollback doesn't help unfortunately. I do have a regular kinoite image pinned so I'll try to boot into that
not what i want
well
do that
but rebase off the asus one
cool so I just ran ujust update
i want to see if the same thing happens
It's the only way I can rebase
yea thats fine
go there first
rebase to the regular image assuming you're not on nvidia or using steam gaming mode
and I'm stuck on Job oatree-finalize-stage.service/stop running
cool
oh, yeah, that's normal
I think
i kno
it takes a while sometimes
when rebasing anyway
manually updated to see if both problems occur when doing so
bit need the reboot to actually finish ):
hmm
idk if the watchdog not stopping is normal
that happened to me a few times, shouldn't be related to any of this
whether it's a bad thing or not besides it
so
development
the manual update broke my system
and the black screen is back
o.o
wait, broke how?
you mean the black screen is the breaking?
and if that's so, can you check if the journal-flush is back too?
it doesn't seem like a coincidence that these seem to appear and disappear together
fuck
the old pinned version is doing it now, too
is this on
:stableagain, by breaking are you referring to just the black screen?
or is something else going on?
i can't boot into my pc so I can't tell you
oh
Same thing for me. I'm rebasing to non-asus bazzite to see if it happens there
well it seems like the play is fresh install and disable updates immediately
cool
and never update ever again
this shouldn't be it though
was this also after having humored me and changing something in the energy options and going back to Defaults?
hmm
I mean I did change it to performance in the energy settings
but that's it
right, but earlier I asked if you could go there, change something random, applying and then pressing the Defaults button to reset it
I'm assuming you didn't do any of that then?
well I need to reinstall again because I can't access anything anymore
is that a yes or no
i dont know what the constant is here anymore
exactly
all of you have different hardware
I'm also confused
My pc was working just fine until ujust update D:
none of the maintainers/contributors can reproduce this and have all upgraded from 39-->40 on their desktop without issue
pain
idk when you last updated
but
literally just now
i mean before now
we have 1 fix with resetting power settings (and hell if I'm too afraid to touch it again), 1 unbootable system (on asus image) and 1 inconclusive that just broke because
After rebasing to non-asus bazzite I'm able to boot @nickname
Never
I disabled the update timer
thank you for letting me know
Thx for the advice
yeah im letting others know in the project to maybe remove the
-asus imagesI think the act of updating is breaking something
GitHub
Commits Ā· ublue-os/bazzite
Bazzite is a custom image built upon Fedora Atomic Desktops that brings the best of Linux gaming to all of your devices - including your favorite handheld. - Commits Ā· ublue-os/bazzite
whether the timer or manual
for the record, I was using the regular Desktop/Laptop image
I have an Acer laptop
Will the Asus stuff be added as a sysext or something?
and had both the issues of journal-flush and black screen, now seemingly gone after resetting power settings (just leaving it noted here in case it helps later)
oh this is what i meant to ask
i guess you lost functionality
ugh
I could layer it I guess
what was it?
im not familiar with asus laptops
asusctl and rog-control-center
the question is why did updating break my previous install
worst case scenario asus image is converted to a ujust script in case it all works out
And in the case of the non-bazzite ublue images, the Asus kernel too
why is ostree:1 broken now, too
i really don't know whats going on at all here
this is also bizarre
wait itbworked this time
Wait is anyone here using gnome? Just wondering if KDE is the common denominator
huh
hmm
also interested
what's the command to go back to ostree:1 again?
yes, KDE here
and keep it permanent
sudo ostree admin pin 1 pins itjust a random idea, maybe we could have more roles that people could attribute to themselves with hardware vendors and images they use?
i suggested hardware roles previously
maybe it wouldn't be too convenient for people with multiple installs, but maybe kt could help
im not a mod/admin here so i cannot change anything
yeah yeah
it's also helpful to see whos on a HTPC or handheld
also maybe DE roles
and that ^
hmm
the problem is the discord is more than bazzite so a lot of the admins and some users use other ublue images
i still agree regardless
Yeah, both are just broken now
well yeah, but then those just wouldn't use those these roles
if there is a significant difference with hardware, maybe they could have their own
systemd-journal-flush seems to be taking a bit but idk how long it should tske
especially when i can't boot into the os
going on a limb, it shouldn't
idk whats going on with your stuff mervius
when I made the "fix" of resetting power, my shutdown is nigh instant now
are you changing anything else radically
It's literally a fresh install with the update timer disabled
and manual update brought the problems back
that's probably not update related per say. it's the fact things worked for you the day the offline ISO released
and now the newest builds of bazzite are causing issues
I think it is with newer builds because I ran 40:testing from as soon as it was available until :stable released and had no issues until a few days ago
Version: nightly (2024-04-26T17:02:20Z)
is the version i have from my installation mediaso something happened specifically with your setup between april 26th and now
well
something happened with bazzite
the version it updated to was from april 27
the last build yea
did anyone mess around
tuned?but at least I can reinstall without a root account, now...
yeah don't enable a root account
we've been discussing for 3 hours now how to fix anaconda
It was enabled in my installation
well don't..
that causes a lot of issues
but since I have to fresh install again
i can leave it off this time
username with a password that has administrative privileges
root off
that's about it
idk if you can run a diff on the two images to see what specifically changed
But it makes no sense thst itbwould persist back to the older version when rolling back in the boot options...
unless it's something in userspace thst breaks?
but it also doesn't persist if that older version is 39 unless you update from 39 to 40 again
for now
im combing over the commits from the time it built last to april 24th
Changed something in power settings and my whole system froze and I had to reboot (couldn't switch into tty), this is the second time today
Try
testing for meexactly, it seems to be related to the power manager, I hadn't messed with tuned but had changed the profiles and brightness and whatnot set to each profile on plasma settings
well i realized this is actually not relevant
I opened tuned
oh?
but didn't change anything
tuned was removed but its not in the latest stable build yet
and it was working fine after opening it
huh
nonetheless, it seems to be power management related
@mervius if you still run into issues
and eventually do a fresh installation
try GNOME
even if that isn't desirable
im curious if the same stuff happens
Im already reinstalling with the installation media I already have
a rebase may break things more
rip
maybe also try redownloading the iso?
really curious if it's only affecting plasma images
just in case?
ofc im on plasma rn
I'm also not deleting it because I know the image It has works as long as you don't update
Or, well, I hope.
most likely if you didn't have issues with april 24th ISO batch
It's possible the installation broke in such a way to cause the issue to not occur... but unlikely
wait, if you got rid of TuneD, what are KDE's power settings tied to? I remember changing on KDE changed it on TuneD as well?
in 39 I mean
PPD, as they are in stock Fedora
ah, right
we'll likely go back to TuneD later, but PPD is slightly ahead in savings right now
yeah, I definitely noticed a difference
they flip-flipped on patch sets lol, TuneD was ahead until a couple weeks ago
would still prefer tlp personally, but I with the current build I did notice quite a difference from 39
so should I enroll MOK or just continue boot
I'm gonna try and get what's on testing to stable here in the next few days
enroll
how tho
password, if asked, is
ublue-osthere's just a view key and continue option
then you already have it enrolled, go ahead and continue
wait, really? the difference from TuneD and ppd/tlp for me was night and day on the 39 build
I didn't do anything tho š¤
enrollment is to your mobo
unless this is your first bazzite install, it's enrolled
no other reason to only have continue and view
I never enrolled it
then you'd need to check your motherboard settings
make sure you have third party keys allowed
Secure boot is set to "other os"
so it should...
@JohnyLPM I tried the power profile to default thing, I only boot to a black screen now
eh
def something going on there
very odd
power prpfiles persist between updates?
and rollbacks?
they do
user config, not part of the immutable image
hmm
that could potentially explain why the issue affected ostree:1 when it previously didn't
it gets to the KDE splash screen but then it's just a black screen
so this power settings stuff
are you all messing around with this:
sure seems like it
I had
if you find
:testing has the problemand it was after resetting that things got fixed
then it's upsteam, testing has PPD and no customizations to power management what so ever
I only changed the thing at the bottom to performance
someone had mentioned it happened on Kinoite as well at some point?
so yeah, must be
but it hadn't caused an issue previously when doing that
also, key point
if you all are setting
performance mode for gaming, don't
on a modern CPU that lowers performance for gamingthat's fun
because you're setting everything to the max clock, and reducing your peak clock for single core workloads
which gaming is full of
tuned def made a difference though
oh I guess I also unchecked dim screen and turn off screen
but that also didn't do anything
and set inactivity to do nothing
I tried all options in the grub, none works anymore
yep
that's why I did a fresh install
I guess it's a fresh install, right?
wild o.o
unable to boot into either branch
*also are you aware thst the portal isn't adding the user to the input group,
fun
the bazzite portal is in the middle of a re-write anyways
there's lots of issues with it currently
the original maintainer stepped away from the project to focus on other stuff
so it does seem the long shut down at least occurs with the black screen boot
maybe not the same issue or cause
butnI haven't had either without having both
Same on my end
So i have a fresh install with no changes except the update timer is off
is there anything I should test, as it doesn't currently occur
Version: main (2024-04-25T06:46:12Z)
hmm
this is different that what I did have before, guess it was previously able to update to Version: nightly (2024-04-26T17:02:20Z) without the issue occuring
which is even stranger
because I was on Version: nightly (2024-04-26T17:02:20Z) the day preior and it was occuring on that version
so maybe something must trigger it that persists in the usser space
instead of being inherent to the image itselfRebasing to :testing and this happened again
wish I could reproduce this even once
definitely not tuned at fault then, though
Maybe tuned for the black screen issue but not this yeah
@Kyle Gospo :testing fixed the freezing when editing power settings, thank you! Maybe it will also fix the blackscreen too?
hope so
also it seems to have fixed the issue i reported a couple days ago about the dGPU not turning off with my asus laptop
I did a fresh install with the GNOME version, so far the shutdowns have been normal
@TheMCNerd2018 nvm found it
Solution
turns out it very well may have been, after all
applying Turtlewit's workaround in #Tuned power manager tunes too low seems to have solved this returning issue for me and and for TheMCNerd2018; haven't had it again since
seems like this is one where "works on my machine" doesn't win :)