Oh I’m aware, I just wanted to add to the trivial list of issues. But I think there might still be issues with some Snapdragon CPUs.

It could also be that some students have ARM laptops, and they’ve got an x86 version of Debian.

You can customise your console login with /etc/issue too!

When it happens, try pressing Alt + SysRq(/PrtSc) + o. If that turns off your computer, then the kernel is still running and something is preventing shutdown; if it doesn’t, either SysRq is disabled, or ACPI is broken.

My Mikrotik routers and switches also reboot in seconds (even for upgrades), which I’ve never seen consumer gear do!

Even my Ubiquiti switches seem to take a minute or so to start forwarding traffic after a reboot; whilst my Mikrotik switches reboot faster than any of my unmanaged switches start up.

Maybe look into using the pstore, it can store kernel panics in ACPI or UEFI variables to be read by the next boot. Usually this is accessible at /sys/fs/pstore, but if systemd-pstore is installed then it should be in the journal, but it can also be here: /var/lib/systemd/pstore.

Cloudflare usually blocks ‘unknown’ bots, which are basically bots that aren’t search crawlers. Also I’ve got Cloudflare setup to challenge requests for .zip, .tar.gz, or .bundle files, so that it doesn’t affect anyone unless they download from their browser.

There’s also probably a way to configure something similar in Anubis, if you don’t like a middleman snooping your requests.

I just used a bot to read it: https://web.archive.org/web/20250901133211/https://cheapskatesguide.org/articles/debian-netinstall-waf.html

It shouldn’t be because you’re not actually the owner of the IP address. If any user could get a cert, they could impersonate any other.

They’re ‘shortlived’ 7 day certs, verified using a HTTP challenge. It doesn’t matter who owns the IP, it’s just a matter of who holds the IP.

It doesn’t look like the normal boot log for Linux (or FreeBSD), so I’m not sure what it is either.

Not really, but once you’ve patched the driver, run dkms status and dkms build <id from status> (e.g. dkms build nvidia/580.76.05) to rebuild the driver for your current kernel.

When you get it working, it’ll be a good idea to write a little guide here for other people to follow.

Oh no worries!

Also hdparam/nvme-cli will let the drive erase itself, and should be faster than operating through a computer. Like it can take seconds on some SSDs since it wipes the chips in parallel, and some drives are self encrypting, so it just deletes the key, leaving the scrambled data. But those usually won’t work on USB drives.

The official driver already uses DKMS (at least in the newer drivers), so you should be able to patch the code in /usr/src/nvidia-470* and have it apply automatically every kernel update.

Ah that sucks.

If it’s an external SSD, I like to format my drives as f2fs, which is a filesystem designed for flash memory, so it might be a bit faster and last longer than ext4. But that’s just personal preference and ext4 should always work fine.

one parallel port (DB25)

You might even be able to use the parallel port as basic GPIO, especially if it’s on the I/O bus and not some sort of PCI adapter.

Don’t Python scripts need python at the beginning of the command that summons them?

Not if the script has a python shebang (e.g. #!/usr/bin/env python3), then it will run like any other script.

Perhaps there was an easier lighter-weight way of doing this?

Yeah, SSH tunneling. What I would do (and have done in the past) is something like:

ssh -L 8080:192.168.0.1:80 myserver

That will forward port 8080 on your host to port 80 on 192.168.0.1, so you can access your router’s web UI with http://localhost:8080/ in your own web browser.

You can also setup full tunneling with SSH, but that requires messing around with SOCKS and I usually can’t be bothered.

I believe the main contributor for drm_panic wants to add one eventually. Here’s what it might look like:

https://gitlab.com/kdj0c/panic_report/-/issues/1

Link if you can’t scan

Also it looks like the colours are configurable at compile time (with white on black default).