This a native machine code execution that crashed in your system. Could be an instruction that your CPU doesn’t understand (because the instruction is newer than your CPU, example: AVX512), or because your hardware returns an error when this instruction is executed (RAM issues?). Too difficult for me to understand this ASM crash.
I don’t think it’s some cpu issue because I used arch for sometime on my another laptop which is poorer in terms of hardware and cpu than current one. But again I might be wrong, will try to understand if this happens again.
Used to use TeamViewer as I supported it for a company and was familiar with it but I got tired of the 2 hour session limit. Found Rustdesk through some Google searching and now I run my own install of it. Absolutely love it for my use case and I’m glad they’re able to keep putting out updates!
I think pcr 7+8 (for grub) or pcr 7+12 (for systemd-boot) should be okay. The more pcr you add, the higher likelihood you need to re-enroll after updates.
The reason why using your own keys can be a problem is if you exclude the Microsoft certificates, then oproms from graphics cards stop working. You have to add the Microsoft certs after using your own key for the top level platform key.
For Debian, if you use out of kernel modules like Nvidia, you have create signing keys and edit a config file so dkms to sign those modules for those modules to work with Secure Boot. Instructions are on the Debian wiki.
That just means the TPM will not auto unlock the encrypted disk. You would have to unlock with whatever LUKS password (or key file) you set for that drive. There is optionally a TPM master key you can export that similar to the Microsoft Bitlocker password (40 digit number iirc), that Lennart mentioned in his blog. If you deleted any other pass slots and do not have that TPM master key, you will not be able to unlock the LUKS drive.
If you look at that freedesktop manpage I linked, it states some of the PCR values and what each one measures. When you enroll a PCR, that value is stored in the TPM. If anything differs between the system and the TPM, the TPM will refuse to unlock that encrypted drive.
For example, PCR 0 measures your mother UEFI firmware. If you update the firmware, the TPM will not unlock your LUKS drive until you re-enroll the drive once again. Is is a personal choice, but enrolling certain PCR into the TPM can be more inconvenient.
It’s good history, I don’t think it really has any bearing today though.
Novell purchased SuSE Linux AG. Novell signed the agreements, and they were very controversial at the time. Novell was much more involved in the day to day than IBM is at Red Hat, SUSE was not an independent business they were a big part of Novell (the SuSE founder left at one point because of how they ran things, he did eventually return). Novell was later purchased by Attachmate, which made SUSE an independent business unit, both were acquired by Micro Focus. It was sold to EQT Partners in 2018 and operates as an independent business today.
Novell and today’s company are not the same, they’ve gone through significant changes multiple times, which is maybe a better reason to at least put in some thought.
Personally, I don’t mind this sort of telemetry so long as they’re open about it - which looks to be the plan, at least for the moment.
IMO the FOSS/Linux space has an odd relationship with telemetry that I think should change. I’d like to point out the gnome-info-collect debacle:
GNOME users: "GNOME devs don’t understand what we want!"
GNOME devs: “Hey, we want to get some data on how people use GNOME. If you’d like to help, install and run this one-off tool. Source code is here, and we collect XYZ metrics (all anonymized, of course.)”
(Some) GNOME users: screeching incoherently about data harvesting and telemetry
Yeap! That’s most of the reasons why, IMO, we didn’t see the adoption of SUSE like we did with RedHat based stuff.
I’ve been a huge supporter of RH over the years. After IBM bought them I was cautious but believed that RH would continue mostly the same. Then they killed CentOS. I understood the reasons and the arguments that Stream made sense for them. I was highly annoyed and disappointed with that decision but Rocky showed up and it was okay.
This final round of fuckery really shows me that the RH we all supported is gone. They burned down nearly all the good will they built up. Locking the source behind a paywall was just the final insult as far as I’m concerned.
I don’t know how much this will hit their bottom line but I suspect it’s going to have some kind of financial impact just from the number of people like me who used CentOS/Rocky as a gateway to RHEL in prod. I suspect they know and just don’t care.
With that being said I’m looking at how they react to over the next year or so. If they’re going to be more of an asshat then I’ll start retooling for another distribution. I here nix is pretty good these days…
The scariest thing about this entire situation is how cold and calculated everything is, they’re taking it step by step, justifying each action, waiting a while, then proceeding with the next stage, carefully, very carefully attempting to avoid a massive community backlash.
Exactly, IBM is counting on little bits of outage over a long period of time. Once they started firing community members working on various outreach projects I realized that unless things drastically changed RH was done and it’s just IBM 😞
Thanks for this! Also have been unhappy with the Linux music player selections – at the moment I’m using the Foobar2000 snap, but I hate snap and don’t want it on my system. Trying this later today.
I’ve always stuck to Thinkpads for Linux – especially the T series is incredibly solid. That said, you really shouldn’t have an issue with a 2015 MacBook.
I have an issue that clipboard content is application dependent.
So many times, I will open a program to find some text, Ctrl+C to add it to the clipboard, close that program because I’m done with it, switch to the second program, push Ctrl+V, nothing happens because closing the first program cleared the clipboard’s content when closed.
Is this inherent to Linux, or could using something other than KDE fix it?
At this point, I’d like to see better regulation about usage of user data for training before this gets approached by the FOSS community. Ideally we should see a regulatory bloodbath where AI training data is concerned (using other people’s data or creation without explicit consent, and ultimately regurgitating that data, as LLMs do).
*I don’t think we’ll ever see sufficient regulation at all – but we should. Use of data in the way needed and quantities needed clearly call for it, in my view
linux
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.