• 0 Posts
  • 29 Comments
Joined 2 months ago
cake
Cake day: July 6th, 2024

help-circle

  • This would -at least as far as I understand it- limit your swap’s functionality for hibernation etc. Because there your swap needs to be available early. You can still do it in theory, but the key file then would need to be included in you initrams, which kind of defeats the purpose.

    There is however a much more easier option: either use LVM on luks (so the volume is decrypted with the password and then contains both, root and swap) or just use the same password for root and swap while switching over to the systemd hooks (as those encryption hooks try unlokcing everything with the first provided password by default, and only ask for additional password if this fails).

    EDIT: Seeing that you crossposted this from an archlinux-specific community: You can find the guide here. It’s for using a fully enrcypted system with grub as bootloader, but the details (in 8.3 and 8.4) are true for all boot methods. Replace the busybox hooks with their systemd equivalents (in minitcpio.conf for archlinux but again this isn’t limited to that init system), then add “rd.luks.name=<your swap’s uuid=swap” to your kernel parameters and also replace the “cryptdevice=UUID=<your root’s uuid>:root” that should already be there for an encrypted system (that’s the syntax for the busybox hook) with “rd.luks.name=<your root’s uuid>=root”. On startup you will be asked for your password as usual, but then both root and swap will be decrypted with it (PS: the sd-encrypt hook only tries this once… so if you screw up and misstype your password on the first try, you will then have to type it again two times, once for root, once for swap…)





  • When you say system drive this will also have your efi system partition (usually FAT-formated as that’s the only standard all UEFI implementations support), maybe also a swap partition (if not using a swap file instead) etc… so it’s not just copiying the btrfs partition your system sits on.

    Yes clonezilla will keep the same UUID when cloning (and I assume your fstab properly uses UUIDs to identify drivees). In fact clonezilla uses different tools depending on filesystem and data… on the lowest level (so for example on unlocked encrypted data it can’t handle otherwise) clonezilla is really just using dd to clone everything. So cloning your disk with clonezilla, then later expanding the btrfs partition to use up the free space works is an option

    But on the other hand just creating a few new partitions, then copying all data might be faster. And editing /etc/fstab with the new UUIDs while keeping everything else is no rocket science either.

    The best thing: Just pick a method and do it. It’s not like you can screw up it up as long if your are not stupid and accidently clone your empty new drive to your old one instead…



  • Btrfs can mostly fo everything you would normaly use LVN or raid for natively.

    Btrfs raid0 lets you combine any number of differently sized drives into one (just without the speed boost of traditional raid0 because with flexible drive sizes data is not symmetrical striped). And btrfs raid1 keeps every data duplicated, again with flexible number and sizes of drive (also with metadata on every drive).

    The sytemd hooks (instead of the traditional busybox ones) then manage the one other task you use LVM for: unlocking multiple partitons (for example multiple raid partitons and swap) with just one password. Because the systemd encrypt function tries unlooking all luks partitions it finds with the first password provided and only asks for passwords for each partition if that doesn’t work.

    PS: btrfs subvolumes are already flexible in size and don’t need predefined sizes. So the only things that need to be created separately are non-btrfs stuff like the efi system partition or a physical swap (which you can also skip by using a swap file instead of a partition).






  • I think it’s not a newbie but a general user issue. I have learned to recognize the linux newbies for whom Arch is a good fit over time… just by watching which people distro hop until landing with Archlinux.

    PS: And among the typical distro hoppers is really a big chunk of them… because for a lot of them distro hopping is just a symptom of wanting to make the mandatory big system upgrades every few years at best worth it by trying something new. Those should actually get a rolling distro as a recommendation much earlier.



  • Those usage stats are a fantasy build by nicely asking your browser about your pc’s details. But the answer is complete fiction. And one people often intentionally set to display Windows because idiotic corporate-created webpages will refuse to work properly otherwise.

    (I haven’t touched Windows in many years and still I would end up in those stats as a Windows user (and Chrome which is also wrong)…)

    It’s basically all just marketing bullshit.



  • Cuddling up to the hard right might look like a strategical move but it never works. Normalising them only shifts the discussion further to the right. And let’s face it… in this post-factual time where all that matters is the narratives, giving them a platform will only help to brain-wash more people into believing right-wing fake-solutions to actual problems.




  • Ventoy and…

    Clonezilla, (custom) ArchISO, Tails

    the stuff you might need to safe other people’s PCs sigh

    HBCD_PE, Windows 11

    If I hadn’t included those in my ArchISO already I would probably add…

    one of the usual Rescue ISOs, GParted Live.

    Bonus points for Ventoy’s ISO partiiton doubling as simple storage.

    PS: Thanks for the reminder to update some of them again.