Categories
Errors Software www

Using Mastodon with Cloudflare

If you’re using Mastodon with Cloudflare CDN/protection and minify turned on, you’ll notice the site may look broken (after a few visits, when hitting Cloudflare cache).

Yeah, that’s not how it’s supposed to look.

And you’ll notice errors in the webdev tools similar to Failed to find a valid digest in the 'integrity' attribute, with computed SHA-256 integrity:

Failed to find a valid digest in the 'integrity' attribute for resource 'https://mastodon.yeri.be/packs/js/common-997d98113e1e433a9a9f.js' with computed SHA-256 integrity 'YgEhHmwjKL88zKfUOMt/qRulYurIuHzhn4SZC9QQ5Mg='. The resource has been blocked.
@yeri:1 Failed to find a valid digest in the 'integrity' attribute for resource 'https://mastodon.yeri.be/packs/js/locale_en-f70344940a5a8f625e92.chunk.js' with computed SHA-256 integrity '1VgpQjY/9w/fgRLw1QH2pfzqr36p3hINvg9ahpBiI2U='. The resource has been blocked.
@yeri:1 Failed to find a valid digest in the 'integrity' attribute for resource 'https://mastodon.yeri.be/packs/js/public-a52a3460655116c9cf18.chunk.js' with computed SHA-256 integrity 'onh6vHxzykkVgJkiww+OCPk0tKC48KMUD9GVJ8/LKJQ='. The resource has been blocked.

Basically, the sha256 hash doesn’t match the js or css static files.

This happens because Cloudflare minifies those files and thus the hash has been changed.

To get it to work correctly, you’ll need to create a Page Rule via Rules > Page Rules > Create Page Rule with the following info:

The page rule created; in this screenshot, the rule is still turned off.
  • URL: YourMastodonURL.com/packs/*
  • Settings: Auto Minify: off (do not select anything)
  • Rocket Loader: slider off
Details on the page rule. Save and deploy.

Don’t forget to purge your cache via the dashboard (for the Mastodon domain) via Caching > Custom Purge > Hostname > YourMastodonURL.com.

Categories
Errors Hardware

Bitflip

Categories
Errors Hardware Misc Software Windows

Screen going black with AutoCAD (LT)

I am not sure what is the problem — I’ve upgraded Shan’s 27″ 2k monitor to a 32″ 4k monitor and AutoCAD LT recently updated from 2021 to 2022. Shan‘s been using a 2017 i5 NUC (NUC7i5BNB) with 32Gb RAM using the onboard GPU. Something that should be plenty for a bit of Windows, Chrome, Photoshop and AutoCAD LT.

For the past few weeks, several times a day her screen would black out for half a second or so and then everything should go back to normal. Sometimes it would happen several times in a row, sometimes it wouldn’t for hours on end.

I tried several things, including getting a 8k 120hz HDMI cable, using a usb-c to DP cable, changing the GPU vRAM minimum from 128Mb to 2048Mb (quite the hack, as it can’t be set in the bios — requires messing around in the registry. Wow.), updating all the drivers, updating the bios, making sure the NUC was properly ventilated and keeping cool (every full moon the NUC shuts down due to overheating in Singapore if I set the fan to ‘balanced’ instead of ‘cool’), and probably more. And because it happened so sporadically it was quite hard to debug (to the point I sometimes didn’t want to believe her as I couldn’t see it blacken out).

Shan was getting frustrated (which in turn means I get frustrated)… and I started looking at getting either an eGPU (I can get a free Nividia M6000, just need the enclosure, but the enclosure would be $$), an AMD Ryzen 5 or 7 NUC (no more Intel in this house, but also $$$), or some other refurb (massive) desktop some friend had lying around (HP z240 or something, zero $, but Shan would kill me for having this massive thing on her desk).

Turns out, the quick fix, was to simply disable hardware acceleration.

Run GRAPHICSCONFIG and uncheck hardware acceleration.

This is probably not ideal in the long run (hopefully it’s an issue with AutoCAD 2022 that is getting fixed, as opposed to the onboard Intel GPU getting messed up with AutoCAD).

When in doubt… Turn off hardware acceleration.

Categories
Apple Errors Software

Apple Watch OS7 stopped showing the date

I’ve been running the Apple WatchOS 7 beta for a while now, and when updating, my watch face lost the “date”: it was no longer showing the date and day of the week (i.e. Fri).

Quite annoying — but it’s a beta after all. I shouldn’t complain. I did what every good beta tester would do: I filed a bug (it’s still unanswered from what I can see).

Beta updates came and went but the date did not come back. Would I be unable to use my watch to figure out the date?! It’s when you lose a feature that you see how often a day you use it.

And then, out of the blue, the big stable release. Apple Watch OS 7 is released to the general public. Surely, I thought, they must’ve fixed it now.

But alas, I was to be disappointed.

I updated Shan‘s watch (that never ran the beta) to see if she had the same issue — but her watch was fine. Sooooo… What was I doing wrong? Why me, Apple Overlord?

I started fiddling around with my language and regional settings (nope, not it), and was contemplating a factory reset (argh, re-adding all my cards to Apple Pay)…

And then…

An epiphany.

They wouldn’t?!?! Would they??

Something only Apple would dare to do.

I deleted the Apple Calendar app (on my iPhone) — as I use the Google Calendar app. Would that somehow be related?

And guess what… Installing the Apple Calendar app via the App Store resolved it:

Check Apple Watch and the option is back!

That’s one way of forcing people to use your apps.

Categories
Errors Google Hardware

Nexus 5: boot loop

I had a Nexus 5 stuck in a boot loop (Android logo/animation in a loop, not actually booting).

This is what I think I’ve done to fix the issue. It seemed that /persist partition was corrupt. I tried a factory reset, flash new stock images, and clear cache, etc before trying the following.

Note that I managed to boot Android 4.4, but nothing else; it did throw a shit load of errors though (Google Play crashes, etc).

First of all, get ADB & Fastboot here. You’ll also need an hex editor (mac).

This will unlock your phone’s OEM mode; and thus potentially voiding warranty and erasing all data (!).

Edit file paths as needed, this is a copy paste of what I can still see on my terminal.

If you know your device’s WiFi MAC & Bluetooth address that’ll be useful for later, as apparently that gets wiped.

Boot into recovery boot by turning off your device and then holding the power + volume down button.

$ ./fastboot-mac oem unlock
... OKAY

Flash openrecovery (TWRP):

./fastboot flash recovery ../openrecovery-twrp-2.8.5.2-hammerhead.img
sending 'recovery' (13918 KB)... OKAY
writing 'recovery'... OKAY

Boot into recovery mode (using volume buttons) from the recovery boot. ADB should work now. This will find a bunch of errors and destroy the partition.

nazgul ~/Android $ ./adb-mac shell

~ # e2fsck /dev/block/platform/msm_sdcc.1/by-name/persist
e2fsck 1.42.9 (28-Dec-2013)
Superblock has an invalid journal (inode 8).
Clear<y>? y
yes
*** ext3 journal has been deleted - filesystem is now ext2 only ***
Superblock has_journal flag is clear, but a journal inode is present.
Clear<y>? yes
/dev/block/platform/msm_sdcc.1/by-name/persist was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Journal inode is not in use, but contains data. Clear<y>?
yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -(75--1098)
Fix<y>?
yes
Free blocks count wrong for group #0 (2972, counted=3996).
Fix<y>?
yes
Free blocks count wrong (2972, counted=3996).
Fix<y>?
yes
Recreate journal<y>?
yes
Creating journal (1024 blocks): Done.
*** journal has been re-created - filesystem is now ext3 again ***
/dev/block/platform/msm_sdcc.1/by-name/persist: ***** FILE SYSTEM WAS MODIFIED *****
/dev/block/platform/msm_sdcc.1/by-name/persist: 30/1024 files (3.3% non-contiguous), 1124/4096 blocks

~ # e2fsck /dev/block/platform/msm_sdcc.1/by-name/persist
e2fsck 1.42.9 (28-Dec-2013)
/dev/block/platform/msm_sdcc.1/by-name/persist: clean, 30/1024 files, 1124/4096 blocks

~ # make_ext4fs /dev/block/platform/msm_sdcc.1/by-name/persist
Creating filesystem with parameters:
Size: 16777216
Block size: 4096
Blocks per group: 32768
Inodes per group: 1024
Inode size: 256
Journal blocks: 1024
Label:
Blocks: 4096
Block groups: 1
Reserved block group size: 7
Created filesystem with 11/1024 inodes and 1102/4096 blocks
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done

So far, so good. Persist partition was corrupt and recreated.

The original howto (see below) said root (su) was needed here; however it worked without root for me (?).

Download this file (kudos to whoever made it) and unrar it. Use your hex editor to edit last 6 digits (“00 00 00”) to a valid hex value, or even better, your actual MAC address if you can remember/find it.

Now upload these two (hidden) files to /sdcard/:

nazgul ~/Android $ ./adb-mac push .bdaddr /sdcard/.bdaddr
0 KB/s (6 bytes in 0.078s)
nazgul ~/Android $ ./adb-mac push .macaddr /sdcard/.macaddr
1 KB/s (6 bytes in 0.004s)

And run these commands:

nazgul ~/Android $ ./adb-mac shell
~ # su
/sbin/sh: su: not found
~ # cd /persist
/persist # ls
/persist # mkdir bluetooth wifi
/persist # chown bluetooth:system ./bluetooth
/persist # chmod 770 ./bluetooth
/persist # ls
bluetooth
wifi
/persist # cp /sdcard/.bdaddr /persist/bluetooth
/persist # chown bluetooth:system ./bluetooth/.bdaddr
/persist # chmod 660 ./bluetooth/.bdaddr
/persist # chown wifi:system ./wifi
/persist # chmod 770 ./wifi
/persist # cp /sdcard/.macaddr /persist/wifi
/persist # chown wifi:system ./wifi/.macaddr
/persist # chmod 660 ./wifi/.macaddr
/persist # rm /sdcard/.bdaddr
/persist # rm /sdcard/.macaddr
/persist # reboot

Go back into recovery boot and flash Android (I flashed 4.4 first, made sure it worked, and then flashed 6.0.1 (latest at this time); but you can probably flash latest version right away. Also unzip the zip file with all the images inside the .tar.gz — we’ll need the files later:

nazgul ~/Downloads/hammerhead-mmb29k.6 $ ./flash-all.sh
sending 'bootloader' (3120 KB)... OKAY
writing 'bootloader'... OKAY
rebooting into bootloader... OKAY
sending 'radio' (45425 KB)... OKAY
writing 'radio'... OKAY
rebooting into bootloader... OKAY
archive does not contain 'boot.sig'
archive does not contain 'recovery.sig'
archive does not contain 'system.sig'
--------------------------------------------
Bootloader Version...: HHZ12k
Baseband Version.....: M8974A-2.0.50.2.28
Serial Number........: 0644c9920b105eb5
--------------------------------------------
checking product... OKAY
checking version-bootloader... OKAY
checking version-baseband... OKAY
sending 'boot' (9154 KB)... OKAY
writing 'boot'... OKAY
sending 'recovery' (10012 KB)... OKAY
writing 'recovery'... OKAY
sending 'system' (1020405 KB)... OKAY
writing 'system'... OKAY
erasing 'userdata'... OKAY
erasing 'cache'... OKAY
rebooting...

Note that it won’t actually boot yet, so go back into recovery boot, and flash userdata and cache (not sure why they go missing or get entirely erased):

nazgul ~/Downloads/hammerhead-mmb29k.6 $ ./fastboot flash userdata image-hammerhead-mmb29k/userdata.img
sending 'userdata' (137318 KB)... OKAY
writing 'userdata'... OKAY
nazgul ~/Downloads/hammerhead-mmb29k.6 $ ./fastboot flash cache image-hammerhead-mmb29k/cache.img
sending 'cache' (13348 KB)... OKAY
writing 'cache'... OKAY

Execute a normal boot now, and wait 5 to 10 minutes.

Android should boot up normally now.

You can also OEM lock your phone again, if you wish (but a sticky bit has been set).

I’ve followed these forum posts.