set up a second efi boot partition
This may or may not work. Recognizing a second ESP on the same disk is not required in the EFI standard. So it’s down to your board’s implementation if it works or just stops the moment it finds the first one.
right dicks
in more than one way
Just for informational reason, because yes, it’s bullshit you don’t need to think about even without the insanity of the people involved:
It’s basically just an installer for archlinux and a management tool for configuration and dot files. And on top of it it’s all vibe coded with claude…
The alt right <-> social media recruiting pipeline is alive, running well and always expanding
It could disappear…
Nice how the sentence and the general statement work for omarchy and claude.
Nazis… “kind of dicks”… yeah, totally the same thing.
Do right-wing morons ever do something else than projecting their cultish mindset when talking about how the left is pushing ideology, virtual signaling (whatever the flavor of the month is…) and brigading?
(I would give him bonus points however for managing to cram the top3 of “tHe LeFt”-brain rot into a single statement. That’s actual dedication… or better training.)
maybe people with similar political views tend to agree on certain topics
For people those people treating politics as a team sport and uncondtionally cheering for everything their team does, all while not actually having any independent views and opinions beyond the latest narratives their favorite talking heads are spreading that day, this must feel like a completely alien concept.
That’s the probably most unhelpful and stupid thing I saw in quite some time. The AI or Not Quiz right at the beginning in particular regularly links the exact same things to human or to AI (404 links are a sign or AI hallucination or just natural link decay that show it’s from a human; wonky grammar is a sign for AI unless the text is human-written where it’s just bad english that LLMs would not produce intentionally…).
Yes, spotting AI by clear attributes isn’t easy. If it was those points would be changed first in training of AI. But lengthily discussing tell–tale signs then interpreting them in contrary ways depending on source is absolute bullshit.
No, you said these videos show common mistakes on purpose because real users would make them. Which is okay…
But it doesn’t matter if it was an honest mistake or one made on purpose because it’s a common thing.
Ignoring the chat telling him the problem (and that he caused it himself) and also not mentioning the problem’s origin anymore later was not an accident. Given the fact that he later made some offhand comment about “yeah, shader thing again” he understood the problem yet intentionally chose to not include the explanation in the video but leave it at “on Linux there are random freezes I don’t understand”.
I would at least pretend to learn from my mistakes. So when I skip the shader compilation, then experience freezes while shaders get loaded and the whole f***ing chat mentions it, letting them compile first and then seeing if that fixes the issue would be in fact the first thing I would try…
So no, this is not honest “showing common mistakes other people will experience” or “struggling with basics”. Because if it was honest there would be any mention of the underlying issue once he understood it. And he obviously did, judging by a later offhand comment about “yeah, shader issues…”
When using the systemd hooks for your initramfs (and using rd.luks.name=<UUID>=<name> instead of cryptdevice=UUID=<UUID>:<name> in the kernel parameters) it will try to decrypt all listed drives with the first password typed in, and only ask for additional passwords if that fails. Unlike the “traditional” busybox hooks that will ask for a password for each device. Doesn’t matter what you actually do with the drives themselves.
So yes, you can for example have partitions/devices /dev/sda1, /dev/sda2, /dev/sdb1 all encrypted with the same password, format sda1 as your classic swap partition, sda2 as the first half of your btrfs raid0 root device and sdb1 as the second half (let’s give them fitting names when decrypting, so /dev/mapper/cryptswap, /dev/mapper/root-a and /dev/mapper/root-b), with rd.luks.name=<UUID>=cryptswap rd.luks.name=<UUID>=root-a rd.luks.name=<UUID>=root-b in your kernel parameters.
And at boot you will be asked for the password only once, which will unlock all three encrypted partitions. (Unless you mistype. They it will fall back to the default behavior of asking for 3 passwords, one for each.)
The epitome of modern AI/LLM: It only needs to do, not actual make sense or be right.
You are probably also one of those insane ideologues that refuse to hammer in a screw for some reason, although you know how well that hammer worked on nails… 😂
It’s a tool, use it where it works and don’t where it doesn’t.
But that doesn’t work with the people creating AI as they are totally dependent on the believe that AI can do absolutely everything (and an artificial general intelligence is just moments away…) to justify they insane investments. So they will make up a million stupid narratives why some people are “actually” not using AI as it obviously can’t be because of AI shortcomings…
Your best options when you are already doing a fresh new install:
But that’s not related to BTRFS at all and can be done with any file system
If you can do this is mostly depending on the specific installer (I would assume only the first option works by default…). It’s definitely possible in general but “I’m not technical enough” doesn’t go well with all the details you have to figure out yourself when the installer doesn’t do all the work.
If they have the same password you can just unlog them at boot with one password. They SystemD hook for unlocking LUKS drives automatically tries the first provided password on all encrypted drives it’s supposed to unlock. Only if that fails it will ask for additional passwords.
I don’t know if Fedora (or plasma) do things differently but the normal default is that you need sudo to reboot/shutdown/etc.
Then on basically all distros using systemd this behavior is modified via logind session and polkit. So the first thing to look at would be if a shutdown rule exists in /etc/polkit-1/rules.d/ that allow users in a certain group to shutdown/reboot in the first place.
Mine looks like this:
/etc/polkit-1/rules.d/50-shutdown.rules
polkit.addRule(function(action, subject) {
if ((action.id == "shutdown" ||
action.id == "reboot") &&
subject.isInGroup("wheel"))
{
return polkit.Result.YES;
}
});
So every user in the wheel group can do it without password prompt. Without this UI elements for shutdown/reboot will try assuming they have the right but simply fail.
People actually thought about that… so snapshots are read-only by design
Honestly I have no clue how many EFI implementations actually fail there. Maybe it’s indeed a minor fraction. But I have personally seen two different ones (out of about a dozen -mostly laptops a few years old- systems where I tried it) and that’s enough to consider it a problem. (PS: Probably not conicidently one of those also had a broken SecureBoot implementation that rejected all key changes and only worked with the pre-installed MS ones. Maybe I’m simply good at finding the trashy ones.)