I mean no harm.
I tried Luks and BTRFS more than 6 times leading to a script error each and every time.
This was actually my experience also, so I went back to a manual install to just get it done. I think the archinstall script won’t get any configuration of device-mapper/LVM right (including disk encryption with cryptsetup). The disk encrypt setup had even more hoops to go through than just LVM.
Why would learning be gatekeeping? I wish I could just teach my secrets… The manuals are only a shallow guide to knowledge. E.g. ls, has condensed for me to ls -laR mostly, and that ls<tab> usually gives tools that list something. ch<tab> gives tools to “change something”, like chmod. mk<tab> to “create something” mkdir etc.
I may navigate in the terminal, but putting me at front of Blender etc. and I’m back to crawling speed of RTFM, and all I would see is a zoo of buttons.
The time you took to answer the archinstall questions and what would take to do them manually is (nearly) the same. The manual way is that you are forced learn the system (which does take time), and it’s thus more exact of what you want. Once you successfully boot a manual install on a bare hardware, you’ll get all the swag. ;)
(I was lazy last time I had to do a full install, and I prepared the system almost entirely in a VM, for which I used the physical disk I would finally boot it from. The final step was to chroot’d into the nearly complete system and make it boot outside of the VM…)
I actually don’t get the fuzz/meme about Arch Linux. Yes, the installer drops you into a shell where you need to fix the keyboard layout for starters and the next thing is preparing enough disk resources for the OS which is somehow ungodly hard. My point is that if you can’t then you are not qualified to maintain the installation, or actually RTFM and start to fr think what you do.
deleted by creator
René Rebe, I’ll watch him blast about bad code occasionally.
BTW. With clang lto’d kernel 6.9. When non-Arch get the buggy updates, We have already moved on.
Wayland has much more up-to-date graphics technologies behind it to put it simply.
Mint was the distro that converted me. After 8-10 years, I’m still using the cinnamon DE, but just on top of Arch. Next hope is the devs port it over wayland so I can also ditch xorg. (There is a demo/alpha available)
I just did: “rm -rf xz”
pacman -Syu
find / -name "*xz*" | sort | grep -e '\.xz$' | xargs -o -n1 rm -i
pacman -Qqn | pacman -S -
(and please, absolutely don’t run above as root. Just don’t.) I carefully answered to retain any root owned files and my backups, despite knowing the backdoor wasn’t included in the culprit package. This system has now “un-trusted” status, meaning I’ll clean re-install the OS, once the full analysis of the backdoor payload is available.
Edit: I also booted the “untrusted” system without physical access to the web, no gui, and installed the fixed package transferred to it locally. (that system is also going to be dd if=/dev/zero'd)
The first kernel I built was not entirely happy with the .config I had made for it. Only thing it could do was BEEP-ing in panic for any key presses. [insert noot noot meme]
BIOS/UEFI likely tried to fuck up the CPU, or hardware fault. NMI => Non Maskable Interrupt.
So it is btrfs snapshot time again and making it a bootable backup before pacman -Syu?
I have had only single time I remember when the Arch upgrade truly fucked up the system: libreadline.so was broken so bash didn’t work. :D
I always have a second bootable system in case the main system is unable to boot… So I can at least troubleshoot the main system.
The default systemd target to boot into can be overriden from the kernel command line.
If the GUI ever gets broken, having a such fallback boot entry just for the (VT) console mode is invaluable. (The boot-entry can reuse the same kernel and initrd images from the regular boot.)