Installing Arch Linux on a Laptop
giacomo.coletto.io
giacomo.coletto.io
chatgpt just tells you how to do and turns out its really not that hard.
Not sure why you use the word "active", as it's unnecessary. Gatekeeping is just erecting barriers of whatever sort in an effort to keep people out. Making install documentation that is very very detailed to the point that some people will be turned off by it and go away could very much be considered gatekeeping. Even if that documentation is objectively good documentation.
Obviously we can't know the motives of the people who wrote the documentation. But it's fair to look at the docs and believe that the authors are engaging in gatekeeping. That belief might be wrong, but there's no evidence either way. Unless the authors have come out and said something about this topic, of course. And even then, it depends on if you believe what they've said.
It's subjective.
(I personally have no dog in this race. I don't use or particularly care about Arch; Debian suits me just fine. My main experience with Arch is positive, though: their wiki is amazing, and when I search for answers for various questions about Linux and Linux desktop software, the Arch wiki comes up very often, and is nearly always helpful.)
In my times, we called such people lazy. No gatekeeping needed.
If you have found incorrect information, please edit the wiki to improve it.
I highly recommend people to use "yay" and similar helpers that make a lot of the problems simply go away.
So low effort for developers.
Meanwhile I think the high effort for users of AUR is an appropriate barrier to entry.
Every dangerous thing I've seen in life benefits from good situational awareness, and all the "learn makepkg" stuff plus "can't be root" seems to match the learning effort to the risk.
Out of curiosity, do you count community as official?
https://wiki.archlinux.org/title/Official_repositories
It is maintained by a group of trusted users who need to be sponsored by at least two other maintainers. This creates a web of trust rooted at the Arch Linux developers.
https://wiki.archlinux.org/title/Package_Maintainers
The Arch User Repository is what I consider to be a "community" repository. It is essentially the programming language package manager model. You create an account and push whatever packagers you want.
And to be clear, I think the AUR certainly started as the second thing, but it's often viewed as the first, and maybe it even should be the first thing. But if you assume it came from the second option then all its design choices make sense.
People who cite the AUR as a major reason to use or prefer Arch (which seems to be a lot) definitely see it and use it as the former. If it's not that, pretty much all of the package availability arguments in favor of Arch disappear.
(Which is fine— I don't think package availability arguments are very good when it comes to distro selection in general, except for non-technical people and absolute noobs.)
Arch's whole identity as a distro is that of a coworker who is capable and competent at all the most useful aspects of his job whilst being completely useless at things which ultimately don't matter so you ignore his body odor, taste in music, and mismatched socks.
Nobody obtains security by watching the package script flash through their terminal just like nobody gains anything useful by doing a manual install at the terminal. These don't matter because you can use a script to install arch and use a helper script the same way you use apt.
This post is about how one person did it on hard mode, to get it just how they want it. That's fine.
I suspect that most of the people on HN could pretty easily install Debian, without documentation (just write this file raw to a USB flash drive, boot the laptop from it, and mostly accept the defaults from the menus):
https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/d...
The fact that installing Debian is easier is true, but also irrelevant.
The archinstall command/script doesn't (yet?) implement disk sector-size selection and some of the other relevant details of the article, but the introduction of this installation mode within Arch makes life easier, besides do not intimidate people.
It is a notoriously big leap in the direction of usability, IMHO this is a path to follow (one of the paths to follow).
PS:
The article uses yay to install the DE. I think the article should have commented the difference between Core, Extra and AUR packages.
At least in the case of NVMe disks, changing the LBA format does not seem to increase performance, and more importantly, in some cases could degrade the random read-write speed for just increasing sequential a little (bad thing, random read-write it is more important that sequential for a SO).
In theory the mainboard will select the appropriate format for the NVMe disk.
https://www.techpowerup.com/forums/threads/setting-4k-sector...
I learned the arch linux installation from the arch web page. I've stepped through it probably 50 times over the years to install various systems.
It becomes this "choose your own adventure" style installation, and you quite quickly get worn down by the branches and start making expedient choices over more involved choices.
So many of my laptop installs have had simple partitions, systemd boot, and on and on and ending with a text login.
Each choice for a more capable system would require extensive learning and the risk of having to start over.
These instructions take you through complex choices like secure boot, LVM, choosing a desktop, a graphical boot and more.
This installation guide gives you a fully functioning system (like you would get with a full distribtion).
The author had to learn from a fully-functional manjaro install, and then walked us through the same thing with arch.
Having a full desktop os with arch in the end is a really wonderful goal, and might be worth the risk of having problems with the install (which I seem to get with arch anyway)
I believe you meant.
I have no issue doing Arch installations by hand, but sometimes it’s nice to save time when you don’t have any special configurations. That being said, knowing how to do installations manually has been pivotal in me knowing how to recover borked Linux systems.
When I contributed a binary QR code decoding feature to zbar and the new version landed in the arch repositories, the first thing I did was edit the arch wiki with usage information.
I also documented a process for encoding and decoding PGP keys to and from QR codes using that feature by editing the paperkey article on the arch wiki.
When I installed arch on my laptop, I wasn't able to configure my screen's brightness. Searching the arch wiki revealed that by default the kernel's Intel iGPU drivers would set brightness by PWMing the screen which doesn't work over eDP connections which is what my laptop used, and also documented the exact kernel command line option I needed to make it work.
The worse the installer the better the documentation.
It's a joke, but perhaps there may be a core of truth in there. An underlying psychological process at play.
Outside of the pacman part (relevant to Arch only) the "how to configure your app" is wonderful.
This is really a fantastic documentation
Feels a lot safer to do the system- and package installation from scratch and then rsync/dd only /home and /etc.
There've been a bunch of integrity-impacting send/receive bugs in zfs over the years.
Your home and /etc actually matter more.
Last time I did it I threw away my root install too because I figured it had been around long enough that either my drunken younger self messed up the install or otherwise something "dirtied up" the install.
I also figure it's nice to clean the slate just in case someone put a gnarly rootkit on my box.
Over the last two years I've migrated to fedora/Ubuntu and trying to do everything really secure, but I finally broke down and re enabled community a month or two ago. Just too much user space desktop quality of life stuff which only lives in community....
For upgrading ubuntu lts among releases, you go through their do-release-upgrade tool.
- Wayland - Plasma 6 - Plymouth - PipeWire - LVM on LUKS - Unified Kernel Image - TPM PIN unlock - Secure Boot
Let me know what you think!
* For something as nebulous as specific cryptographic settings, I think it's worth elaborating on _why_ you pick the settings you did for `cryptosetup`. I'd imagine it's probably very possible for someone to pick a bad set of arguments that either degrade security or don't improve it but make it much slower. I suspect you didn't do this though, so as someone who just uses the defaults that `cryptsetup luksFormat` uses, I'd be super interested to hear how you decided on the options you used!
* It looks like you linked to another post explaining your use of `yay` as a pacman wrapper/AUR helper, but I'd worry that a lot of people this guide would be useful too (i.e. newer people to Arch) would be confused when they try to follow it and suddenly run into the issue where they don't have anything called `yay` installed or know how to install it (since it's not something you can get from the default repos). From what I can tell, the only two AUR packages you reference in this post are `plymouth-git` and `plymouth-theme-arch-breeze-git`. Maybe for the purposes of this post, you could stick with `plymouth` and `breeze-plymouth` in the main repos (and possibly link to the section of your other article where you detail AUR stuff)?
* The stuff about how to configure secure boot is super interesting; I've never found it worth the hassle and just turn it off on all of my machines, so I wasn't aware of all of the tooling available like `sbctl` and `sbsigntools`. A standalone post on how to configure secure boot on Linux would definitely be worthwhile!
* I love the section on the specific packages for each GPU combination. This is definitely something where a lot of people will benefit from a concise list rather than having to comb through the details in the wiki (which are useful when you need them! but often you just want the packages to install)
* For unmounting all of the stuff post-install, you can use `umount -a /mnt` to recursively unmount all of the nested mounts. Super small change, but it's nice not to have to type all of it!
Leaning on and only waving to yay might do the reader a disservice and cause more confusion by making the context very easy to skip over, and without that it will probably just be frustrating to keep using Arch and keep treating yay like a traditional pacman-style package manager... Doing it via makepkg first gets you some understanding of "what's going on under the hood" and what's basically the same regardless of which wrapper you use. Might be a game-changer in X years whenever the community moves on to the next wrapper.
You have some cases where yay is being used to actually install repository packages (not AUR). Would recommend changing these from yay to pacman. Like from:
yay -S mesa mesa-demos mesa-utils vulkan-intel intel-media-driver intel-gpu-tools
pacman -S mesa mesa-demos mesa-utils vulkan-intel intel-media-driver intel-gpu-tools
Could consider instead an approach like "There's this thing called AUR ([Link]). [Brief explainer]. Some people use a helper like yay([current link]) aurutils or aurch. [Proceed to show manual build-and-installation via git-clone and makepkg, as well as how to rebuild/update later]"
I first tried Rustic's native RClone support, but performance were awful. Backups are automated and run on a daily basis. To restore all my repo (or just one) I run a single command, if I have the repo configs in place.
To backup the repo configs I manually make a second backup by putting them, among all other configurations for my devices, in an encrypted .7z archive, which I upload in a remote cloud storage.
To reinstall Arch, I turned my notes into an automated script that does that in few minutes. The guide in the post derives from it, so it's quite up-to-date.
That sentence can have a lot of meanings, when one thinks that everything is possible with enough effort ..
I do love the Arch community. But I feel less motivation to tinker nowdays and Fedora was a pretty nice works out of the box experience so far.
Sometimes Arch saves so much time, that even the infrequent necessary manual maintenance after updates makes it worth it.
And even when trying to run stuff on distros other than Arch, I frequently look up instruction on Arch Wiki and in AUR PKGBUILDs.
Beware, I just realized my AMD does not support S3 sleep. Too late to return.
I'm enjoying AlmaLinux with KDE and not seeing any reason to switch so far, it's rock solid stable and RHEL docs are better than anything aside from maybe Arch. All the dev tools they tend to not have without fail have an `asdf` plugin, or they're written in Rust and `cargo` can install them from source just as easily. KDE might be bloated but not in a way you'd notice with a modern processor and I love the customization options.
Arch is a great option too if you want all the latest and plan to stay on top of upgrading. I like `paru` as a package manager there. Most important thing you can do on Arch is add a quick search shortcut for the Arch Wiki, it's so good I'll reference it for help on any distro.
I hope your experience is better than mine, though. I've had mine (12th-gen Intel) for 2 years now with a terrible thermal throttling issue, and support alternates between asking me to do the same things over and over, and ghosting me for months at a time. Judging by the community forums, it's a common-enough problem too.
I assume you're getting either the Core Ultra or whatever the current AMD board is... hopefully they're better.
If they come out with a new mainboard next year, I feel like (after 3 years of owning the 12th-gen) I can justify a mainboard upgrade (though I guess it'll also mean new RAM, ugh), and pray that it's actually a hardware problem (and not a problem with the embedded controller's firmware), and that it's been quietly fixed.
I'd say only go with NixOS if you want to learn the Nix language, specifically need reproducible builds, or really hate mutable state.
Was this written by a human?
Jumping from a cut down step by step para-phrasing from the official manual to yay is a big step. If it was written by a human, then leave a ### TODO in the text to show its a work in progress or incomplete.
"CUTEBOLLOCKS (this will not translate well!), CUTEBOLLOCKS (this will not translate well!)"
---
I'd better explain the above: There's a UK TV programme called "8 out of 10 cats does Countdown". Prior to advert. breaks an anagram with a clue is presented to viewers (and they are specified twice), the anagram itself is generally rude. ---
"Cute bollocks" is one way that I think of the original post - they have taken the Arch install manual and ripped most of the useful bits out and created a narrowly focused synopsis. They have been "cute" - link on HN, with engagement. Bollocks - that's my considered review of the quality of their article.
We've all got better things to do than engaging with wankery. Please stop.
1. Downloaded EndeavourOS
2. Installed it as easily as Ubuntu
Edit: the arch documentation is second to none
I don't even look at it more than once per major version upgrade, as I've never had to wipe and re-install.
stay away if you want a bit of excitement in your installs.
I am willing to argue that it's the best documentation of any distribution
What bootloader is this using? Or is it just straight EFI booting?
I helped write a guide a few years back that still is what I do using systemd-boot. https://github.com/lunasec-io/lunasec/blob/master/docs/blog/...
How is Wayland support these days? I love i3 but I know Sway promises to be close enough.
What bothers me is that I have the impression that when I switched from X11 to Wayland a few months ago, Wayland was a bit more stable when it came to suspending and restoring the pc. But after a few months, I had the same problems (crashes) as with X11. It feels like someone fixed something in the wrong direction.
Maybe it is just bad luck.
What bootloader is this using? Or is it just straight EFI booting?
I think it depends on what you mean by “Wayland”, but I’m an Arch/Sway user with AMD hardware on my desktop and Apple silicon on my laptop, and Sway performance/stability is great on both, with the caveat that my laptop is now running the Asahi Fedora remix instead of Arch, since the Asahi team killed the Arch port off a while back.
(Come on you post a HW issue on hacker news, you know the peanut gallery is coming out in force ;-) )
Pretty darn good. So good in fact that my personal computers have run with xwayland disabled for years (YMMV, there is certainly some Linux software that still requires X).
Is it really, though?
The author is using LVM to manage "virtual partitions", but then it's using 100%FREE for the larger partition, and using ext4 for all partitions.
In my experience this setup makes it actually harder to manage partition sizes, as before shrinking a partition a resize of the underlying ext4 partition would be necessary.
Nowadays it would have been better to use one of the modern volume-managing filesystems.
AFAIK the option available out-of-the-box in Arch Linux would be btrfs, but ZFS is another excellent (better, in my opinion) option.
Antergos was eventually archived, and from my understanding EndeavourOS become its spiritual successor.
I am fine just using the passphrase and I just configure my graphical login manager to log straight to my preferred user on start in order to not have to type crefentials twice at boot time.
Have any people here tried this kind of thing with immutable file systems on Arch and is there a realistic benefit?
An immutable filesystem sort of implies a specific collection of packages chosen by someone else and combined in a monolithic release. Everyone gets the same OS, and overlays their data on top of it.
Arch contains the specific packages you have chosen, and they are all updated asynchronously using a rolling release system.
Not that you couldn't have a read-only os partition and a user overlay partition. With pacman it wouldn't really match the philosophy of immmutable.
Again, very much out of my depth here so sorry if i'm misusing terms etc.
From what I can tell, it seems that 3.x os updates are distributed as an entire os image?
It is based on arch, but you don't update individual packages with pacman.
Basically everyone gets the same unchanging os, with individual games and data separately.
On top of what the article mentioned a few tips:
- To achieve really good battery duration I installed powertop (which I run on every boot for auto-adjustment) and thermald which does a great job with Intel CPUs.
- Suspension issues are common, in many cases often was about different part of the system overlapping. I ended up disabling hibernation which I never use anyway, but suspending after closing the lid for me is a must in a laptop.
- Fusuma or something similar is also a must to take advantage of the touchpad.
- Yet another gem, fprintd was a GREAT discovery. First time I autorized a sudo with my finger I couldn't help it but have a big laugh.
PS. Bonus point: This is the second NVidia Optimus laptop that I own and even if Optimus support has gone a long way and now it almost works perfectly out of the box to achieve a really good performance eg in videogames, I use a script to switch between an Nvidia only mode or an Optimus mixed mode.