

You know, GNOME does some stupid stuff, but I can respect them for this.
“Life forms. You precious little lifeforms. You tiny little lifeforms. Where are you?”
- Lt. Cmdr Data, Star Trek: Generations


You know, GNOME does some stupid stuff, but I can respect them for this.
I’d just recommend checking hard drive SMART scores and stuff like that. Maybe run a memory test as well.


If you scroll down in journalctl, it can go later in time. Also, you can check different boots by changing the b parameter, with -b 0 being the current boot, -b -1 being the previous boot, b -2 being the boot before that, etcetera.
For UFW, I’d just try unblocking the Proton ports if it says they’re blocked in Proton settings. Also, check to make sure you don’t have two firewalls installed; while this once again shouldn’t crash the system, my PC did some very weird things when both UFW and firewalld were installed.


Alright then. That probably eliminates the lp thing. Can I ask: what journalctl command (or logging command in general, if not journalctl) did you use? I’d recommend giving the results of journalctl -b -1 -p 3 and dmesg.
Also, it’d probably be a good idea to tell us what ports are getting blocked; that shouldn’t be personally identifying in any way. After doing research on what those ports are and what ProtonVPN requires, try experimenting with unblocking some of them if you can; a blocked port shouldn’t crash your system, but it’s worth a shot.
I might also recommend looking at a task manager, just to make sure some application isn’t taking up all your memory and causing the system to freeze.
Finally, take a look at your CPU temps in case this is some kind of cooling failure.


I don’t think it’s ProtonVPN, at least not directly, as those happened over 20 minutes before the crash (I’m assuming it happened somewhere around 9:32:30)
That last one looks really odd, and I’m wondering what that kernel module is used for. I’m looking around real quick.
EDIT: Looks like it’s for line printers. I’m trying to think why your kernel would randomly load that. Can we see the contents of the following?:
/etc/modules-load.d/modules.conf/usr/lib/modules-load.d/modules.conf/usr/local/lib/modules-load.d/modules.conf (if it exists)/run/modules-load.d/modules.conf (if it exists)Also, can you give us more information about your hardware, just to be sure?


Interesting project, but not pulling me off XFCE terminal.
The name sounds like a Romulan senator, though.


At least they provide an official Flatpak now.
Also, this isn’t an official repository, but https://github.com/palfrey/discord-apt works pretty good for me. If you look at the source code for the fetching script and the Github Workflows, you can see that they just pull directly from the Discord website, and comparing file hashes further confirms it. I no longer use it since the official Flatpak is an option now, but it’s still useful.


I was talking less install a bootkit and giving it back to be and more just straight-up stealing the laptop and seeing if they can get any personal info they can sell before formatting it and eBaying it.
Still, your points are totally valid.


I would ditch Discord, but the TMBW server is just so darn good and I can’t leave that behind. Maybe I could convince them to set up a Matrix bridge (they already self-host MediaWiki), but then they’d probably end up basically doing this just for me.
My university’s Linux User’s Group is on Discord, but they have it bridged with a Matrix server; due to the current state of things in the US, they only allow political discussion in certain encrypted channels that are exclusive to the Matrix server.


The password thing is pretty based, honestly. What you say is probably not possible, as the NT kernel would have to support LUKS, I’m pretty sure, which it doesn’t.


Precisely. I just use probably as a catch all.


Me waiting for Star Trek Lower Decks Volume 2, or at least a repressing of volume 1:



It really shouldn’t matter. I know what they’re talking about and it’s true.


It’s not malicious or “ransomware”, and this is perfectly normal, default behavior for most devices - both macOS and Windows implement full disk encryption in a default install these days, and your key is almost always in your Microsoft Account on the Microsoft website. While Microsoft does a lot of crap wrong, in this case, Windows’s failure to decrypt under GRUB is security features actually kind of doing their job. Basically, trying to boot Windows through GRUB confuses the TPM, causing it to not want to give the keys in case the Windows boot partition has been tampered with by bad actors. Thus, you have to boot directly through Windows Boot Manager, not GRUB
Also, secure boot and TPM aren’t just some conspiracy by Microsoft to block Linux; they are attempts at implementing legitimately necessary security features. Full disk encryption supported by correctly implemented secure boot and an encryption chip are essential to having modern security. Linux is not blocked by TPM and Secure Boot; it is certainly possible for Linux distributions to take advantage of them to enhance their own security. I have implemented automatic LUKS full disk encryption that similarly fails to unlock if the partition has been tampered with on my Debian install. In theory, they can actually be used to help improve your security.
That is not to say I think TPM and secure boot are good, though. The really obnoxious thing about secure boot is that all the certificates are controlled by Microsoft rather than a standards body or a group of certificate authorities. While so far, Microsoft has kept it relatively open by providing the third party CA and the shim binary in order to avoid having its neck snapped by the FTC, considering the current administration, we don’t know how much longer they’ll keep it up, and they could actualize the much-feared blocking of Linux.
The other big problem with TPMs and secure boot is that often, there are so many different implementations and frequently major security flaws in their implementations that weaken their protection. A typical petty thief stealing your laptop still probably won’t be able to decrypt your drive, but a nation state can probably find a way. It doesn’t help that Windows doesn’t encrypt communication between the CPU and the TPM (luckily, the Linux kernel does that by default). Despite these issues, I’d say TPM and Secure Boot is better than nothing for most devices; not using them (EDIT: or a non-M$-controlled alternative, like a memorized drive password AND/OR FIDO keys, which may be better) at least in part means your device is more vulnerable to physical access and bootkit attacks than even most Windows laptops, and they are often the only tools at your defense
EDIT: An addendum: Now the really smart thing I’ve heard people do is to keep the boot partition on a flash drive (possibly with a keypad or biometrics) that you keep with you at all times.


I also recommend dd on a live USB, but with some advice.
First off - and I’m really surprised nobody’s warned you - be EXTREMELY CAREFUL with dd; it is a very powerful tool, but with great potential for data loss. Check your command over and over again to make sure it’s doing what you want before running it, and make sure you have a backup beforehand; it will happily mow over any disk you tell it. Also, do it when you’re fully awake, not at 1 AM or something.
I would call myself an experienced dd user, and even I messed up once recently; I was trying to create a bootable USB when I was really tired. Instead, I overwrote a drive. Luckily, it wasn’t my root drive, and I had a full backup of its contents, so I was able to reformat the drive and restore from backup.
Also, don’t run a bare minumum dd command like dd if=/dev/whateverdevice1 of=/dev/whateverdevice2; it’s going to be an absolute pain in the rear.
dd bs=1M oflag=sync status=progress if=/dev/whateverdevice1 of=/dev/whateverdevice2
bs=1M: The size of block it tries to copy at a time. Play with this a bit, as different drives have different optimal block sizes.oflag=sync: Basically, most operating systems don’t actually write data to the drive right away, but store it in a buffer in RAM to be written later. This is usually fine, but sometimes, you want to be certain that data has actually been written to a drive; this flag turns off that buffering so that when dd is done, the data will for sure actually be on the drive. In lieu of this, you could also just run the sync command afterwards, which forces it to write the current buffer to disk, but I prefer the dd way. It should also do it automatically during shutdown, but I have had cases where a system hangs during shutdown and I’m not certain if syncing is done or not.if is input drive, of is output drive. I prefer lsblk for looking at the list of drivers.You’ll usually need to run dd with sudo.
Once you do a successful copy, you’ll need to extend your BTRFS partition using GParted or similar. If you have a partition after your main one, like swap, you’ll need to delete the swap partition before extending, then recreate the swap partition and update fstab accordingly.


Cool. Probably still not using it. If I want to run an out-of-tree COW filesystem, I might as well be using ZFS - stable and with less drama.


They did do something with the butt bugs in the IDW comics recently…


It’s nice that they still put out Trek physical media.
It’s just really weird that SNW stuff seem to be the franchise’s only 4K Blu-Ray releases (besides film remasters and Kelvin timeline, of course) - everything else with a decent resolution has only been released in 1080p. Like, objectively, I can hardly complain about 1080p, and any more than that for LD and PRO is probably pointless, but it’s really weird that PIC and DIS don’t have it for the seasons that were filmed for 4K.
Also, if they’re not going to renew PRO, can they at least give it the dignity of a complete series set, or at the very least a season 1 Blu-Ray so I don’t have to buy episodes 1-10 and 11-20 separately?!
From what I can tell, you wouldn’t use it instead of Ansible or another automation system, but rather just support for a config file you can plot in to make setting up automation with any automation system easier by allowing you to put it into a file rather than a gigantic Flatpak install command.