Installing Arch Linux on a Laptop(giacomo.coletto.io)
giacomo.coletto.io
Installing Arch Linux on a Laptop
https://giacomo.coletto.io/blog/arch-amd/
138 comments
These types of posts are often more harfmul than helpful. ArchLinux already has proper installation instructions and those who cannot follow them aren't recommend to run it. The main installation issues the ArchLinux forum sees is from people following outdated third party installation guides.
I think the post title is understated, since I had a related thought: it's not hard to install most Linux distros on a laptop, and this post will intimidate people.
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...
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 article isn't about how to install a Linux distribution on your laptop. It's about installing Arch on your laptop.
The fact that installing Debian is easier is true, but also irrelevant.
The fact that installing Debian is easier is true, but also irrelevant.
The Debian example is relevant to my point that I think this article will intimidate people who don't already know Linux (but over the years have heard that it's a pain to get working on laptops, etc.).
That's just a normal arch install, no hard mode about it.
Launch the guided archinstall is the comfortable mode, 2/3 of the article are done automatically through option selects at the beginning, and one installs Arch within two minutes. A configuration file can be saved also.
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.
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.
> disk sector-size
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...
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...
Just as an example, this guide suddenly assumes that "yay" is installed. Even though AUR helpers like yay aren't officially recommended by ArchLinux and also aren't trivial to install.
Only "suddenly" after he links to his other post describing AUR and installing yay:
https://giacomo.coletto.io/blog/arch-conf/
https://giacomo.coletto.io/blog/arch-conf/
The design decisions around AUR befuddle me to this day. It's utterly arcane in how to use it. Or rather it feels like it wasn't designed at all and simply evolved.
I highly recommend people to use "yay" and similar helpers that make a lot of the problems simply go away.
I highly recommend people to use "yay" and similar helpers that make a lot of the problems simply go away.
The AUR makes either perfect sense or no sense depending on what you think it is. If you think it's an extra repo with more software, then it's a bit odd: Why no binaries? Why the antagonistic view of AUR helpers? Heck, why doesn't pacman just have an option to automatically use the AUR? Just add it as another repo next to extra. On the other hand, there's another viewpoint, where the AUR is what happens if you provide a free-form place for random users to post build scripts. Not packages, really, just "here's the commands I used to build this software on Arch". In that view, you're not expecting a streamlined experience, and binaries are a ridiculous idea; you grab someone's notes, read them over, and if they seem reasonable enough then you execute them (because the notes came in executable format). Or if they don't quite look right, you edit them into shape and then run them, and that's expected because this is just a way for a bunch of hackers to pass around suggested build steps.
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.
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.
It's really only meaningfully used as the first thing by virtually anyone.
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.
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.
> 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.)
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.)
I've always thought it was more for developers. You can get something into AUR easily, and it is basically the basis for a real package.
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.
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.
I think it's great. You clone a git repository which is amazing since you can just pull in new commits to get updates. Then you read and understand the PKGBUILD. When you are satisfied that it's not malware, you basically just run makepkg and it does everything. Then you vote on the package so that it's more likely to be included in the official repositories in the future.
> Then you vote on the package so that it's more likely to be included in the official repositories in the future.
Out of curiosity, do you count community as official?
Out of curiosity, do you count community as official?
Depends on what you mean by "community". There used to be a repository named "community", it is now called "extra" and it is indeed an official repository.
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.
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.
Interestingly, I’m not sure why more people don’t use archinstall, which is provided with the official live ISO: https://wiki.archlinux.org/title/Archinstall
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.
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.
The post by itself is not harmful, since it can be that the person posted it for their own blog because they like to write for themselves. Someone now finding it and using it for their own benefit/loss, that's a problem.
> ~~Someone~~ *An LLM training bot* now finding it and using it for their own benefit/loss, that's a problem.
I believe you meant.
I believe you meant.
nonsense.
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 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)
Most issues on any Linux forum are people using outdated/unofficial guides or going off the beaten path for god knows why.
Isn't there a GUI installer for Arch. I am sure I am capable of installing it but I don't feel the need to get that involved.
No. There are distributions of Arch like EndeavourOS that provide an installer.
There is an official install script now
so we should stop making blog posts about anything that is hard/custom/outside of the blessed path?
these days I ask chatgpt for help to install arch instead of using the docs which are designed as a gate keeping mechanism to discourage the uninitiated by making them feel stupid.
chatgpt just tells you how to do and turns out its really not that hard.
chatgpt just tells you how to do and turns out its really not that hard.
I really think that's unfair. The install docs are quite long but they try to give people options. It's not gate keeping to provide a lot of detail.
I actually agree that the Arch docs are absolutely excellent in their level of detail, precision and helpfulness. I also think its possible for them to simultaneously be a gate keeping mechanism and stand by what I said
well if you stand by them, do you plan to present actual evidence of the alleged conspiracy or are you just making these statements to troll?
isn’t gatekeeping inherently subjective? it’s going to be hard to present objective evidence to a subjective expression of opinion.
[deleted]
Gatekeeping is an active effort to keep others out of something (out of a field, away from information, etc.). Where is the active effort to keep people out of Arch when the documentation is made available for free?
I think you're talking past the person you're replying to.
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.)
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.)
> 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.
In my times, we called such people lazy. No gatekeeping needed.
In my times, we called such people lazy. No gatekeeping needed.
[deleted]
I haven't had that feeling. In fact, installing Arch Linux is easy. The hardest part is the bad partition editor UX and that you need to have an understanding of how UEFI booting works. There is also the problem of GRUB being a terrible bootloader, but that is another story for another day.
The install wiki is full of outdated information that causes people to install outdated and old methods of doing things. So I wouldn't advise people to use it, other than the fact there's no other option.
I find that hard to believe. I've always found the Arch Wiki to be excellent and very up to date. Do you have any examples of articles which document outdated ways to do things?
If you have found incorrect information, please edit the wiki to improve it.
If you have found incorrect information, please edit the wiki to improve it.
[This video](https://www.youtube.com/watch?v=68z11VAYMS8) was a godsend when I first got started and I recommend it for anyone installing arch.
ArchWiki: your source for Arch Linux documentation on the web.
https://wiki.archlinux.org/title/Main_page
Not just Arch documentation. It often has general use information, too, applicable to other distros and Unixes.
Arch has some of the best documentation for Linux in general. I ended up there a lot for a Manjaro install but it has solved issues on Ubuntu machines for me. Always pretty obscure stuff.
Agreed! I've never used Arch, but the Arch wiki often comes up in search results when I'm looking to solve a problem, and it's usually very helpful.
The duality of linux distributions
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.
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.
I'm getting some mixed messages in this thread alone. Who do I believe?
https://imgur.com/a/ylkWLfQ
https://imgur.com/a/ylkWLfQ
I recommend reading the wiki and judging for yourself.
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.
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 Arch wiki is the 1st party official place for developers, maintainers, and users to maintain updated reference material. Whether one considers it up to date "enough" will be a personal judgement call but there is no better place to go in the long run.
ArchWiki: your source for Linux documentation :)
Outside of the pacman part (relevant to Arch only) the "how to configure your app" is wonderful.
This is really a fantastic documentation
Outside of the pacman part (relevant to Arch only) the "how to configure your app" is wonderful.
This is really a fantastic documentation
I've had the same Arch installation between four laptops over 12 years. Boot from a USB Linux distro and enter command line. Partition the new laptop, setup disk encryption, rsync the file system via USB external enclosure, modify the ftab, crypttab, and refind.conf, reboot. Don't have to re-install any software or re-setup and sync any accounts.
Same, but with Debian for almost 20 years.
Don't remember how I did it before, but the last few migrations were just `dd if=/dev/sda.old of=/dev/sda.new` and then gparted to enlarge the root partition to fill out the new disk.
This is how I do it also. Sometimes if I feel like changing the partition layout for some reason, I partition the new drive first and use dd offsets to copy the partitions one at a time. And of course you may need to resize the filesystem(s) as well. Works with Windows, too, although I usually change the storage driver to some generic ATA or something first to prevent it from blue screening on the first boot. And sometimes with newer versions of Windows you have to fiddle around with bootrec and whatnot.
How do you know you're not propagating bitrot over time? Feels like a binary here and there may accumulate mismatching checksums over the years from bad hardware or some filesystem error... Not to speak of malware. All it takes is once...
Feels a lot safer to do the system- and package installation from scratch and then rsync/dd only /home and /etc.
Feels a lot safer to do the system- and package installation from scratch and then rsync/dd only /home and /etc.
The base system and packages are usually smaller than home, so the possibility of a bitrot is actually lower. Package files' integrity can also be automatically checked by some tools. In addition, they are much easier to reproduce, as you said, one can always just reinstall the system and download all packages again.
Your home and /etc actually matter more.
Your home and /etc actually matter more.
On Debian at least you can check for modified, removed or added files using cruft-ng.
ZFS is how.
Over almost 20 years, on Linux? I doubt it.
There've been a bunch of integrity-impacting send/receive bugs in zfs over the years.
There've been a bunch of integrity-impacting send/receive bugs in zfs over the years.
Personally, I just gave root "enough" and set up a separate user partition. Although admittedly it gets more complex if using lvm, so realistically I end up setting up sd-encrypt on the new drive, manually partitioning, then rsyncing everything over reserving permissions
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....
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....
Debian too, but for some reason I just feel good about doing a fresh install whenever I get a new laptop. I do rsync over my home directory and a few other things, but it just feels nice to have a fresh machine with a minimal amount of packages on it, where I can install stuff as I need it, and leave out anything I haven't used in a long time and have forgotten I'd even installed.
I like running a debfoster session every once in a while.
Would this work when upgrading from one Ubuntu LTS to another one? I’ve been thinking of going from 22.04 to 24.04 but I just get lazy.
No, it is cloning existing installation from one drive to another. Basically what clonezilla would do.
For upgrading ubuntu lts among releases, you go through their do-release-upgrade tool.
For upgrading ubuntu lts among releases, you go through their do-release-upgrade tool.
Similar here, but I used a TB4 cable so didn't have to take out the storage.
Interesting arrangement. What's your backup and recovery strategy?
This is the step-by-step process I followed to install Arch Linux on my laptop with the following features:
- Wayland - Plasma 6 - Plymouth - PipeWire - LVM on LUKS - Unified Kernel Image - TPM PIN unlock - Secure Boot
Let me know what you think!
- Wayland - Plasma 6 - Plymouth - PipeWire - LVM on LUKS - Unified Kernel Image - TPM PIN unlock - Secure Boot
Let me know what you think!
Thanks for sharing!
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:
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]"
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]"
Thank you for the feedback! As you and other have suggested, I removed the "yay" requirement and added a brief explanation that its install instruction can be found in the other guide
Nice write-up! My install process is slightly different (I suspect everyone who uses Arch ends up having their own little procedure built up over the years that varies slightly, since the flexibility is part of the appeal), so I'll try to focus on substantive feedback rather than feedback on hyper-specific choices that don't matter:
* 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!
* 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!
Great attention to security -- but what is your strategy for backup, as preparation for recovery from loss of the hardware?
I wrote my own python wrapper around Rustic and RClone to achieve 3-2-1 file-level backups: https://github.com/AlphaJack/rusticlone/.
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.
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.
What's everybody's favorite distribution on the Frame.Work 13?
Getting it next week, and toying around with Arch/Debian/Ubuntu/Suse/NixOS/etc in VMs while waiting for it. I think I'll have to throw a coin (or just take Debian).
Not a Framework but a System76 laptop, I got to a point where I couldn't stand any desktops based on Gnome and wanted something more predictable and better documented than PopOS or even Ubuntu.
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'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.
Big fan of Silverblue/universal blue Fedora immutable installs. I'm using Aurora, a KDE respin, on my framework 13 AMD. There's a framework specific image and it was one of the most complete out of the box Linux installs I've ever used. I truly think that immutable distros are the way forward for desktop Linux
Fedora has worked flawlessly for me.
After years on Ubuntu, then Arch I also just recently discovered Fedora as a well polished alternative.
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.
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.
I set up Fedora for family but I still use Arch myself, because there is no good alternative to AUR on Fedora and there are more packages that I need for software development.
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.
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.
I'm using Nix package manager on Fedora and it's OK.
As I founnd out myself, there is almost no tinkering involved once you get the initial Arch setup done. Just update once a week. Fedora repos have considerably fewer packages than Arch or Debian. For some reason Redhat land has always been off putting for me. SELinux, dropping docker in favor of podman, CentOS debacle are just a few things that make me look elsewhere. I'm glad you found your sweetspot though. Just a friendly banter from a fellow Linux user.
Fedora was almost required on AMD framework for a while, because hardware was brand new and Debians were too old. Now with Mint updated, I'd recommend take Fedora or Mint and Cinnamon.
Beware, I just realized my AMD does not support S3 sleep. Too late to return.
Beware, I just realized my AMD does not support S3 sleep. Too late to return.
Mint was the worst experience for me. The trackpad acceleration curves are bad and there's no easy configuration for it. I was willing to either toy with sliders or copy an already tuned config into a file. But the best I found was how to go into a config file and disable the acceleration entirely.
If you prefer to understand how your OS work, and want a system simple enough that you can understand what it's doing, go with Arch. If you don't care about that and just want something that mostly works with little hassle, Debian, Ubuntu, Suse, or Fedora are all fine; there's little practical difference, except maybe Debian's software is always a little out of date.
I'd say only go with NixOS if you want to learn the Nix language, specifically need reproducible builds, or really hate mutable state.
I'd say only go with NixOS if you want to learn the Nix language, specifically need reproducible builds, or really hate mutable state.
I'm running SUSE Tumbleweed. Fast package manager, up-to-date versions of just about every package you could want. Never had any driver issues or issues installing.
After going through Centos, Ubuntu, Arch, and Mint, I’m settling down on OpenSUSE. The rolling updates just work.
I use Arch, but I might be biased
I don't have a Framework machine, but my favorite distribution on any machines has been Arch, because especially if you follow the wiki install, you end up with a lot more knowledge of how modern Linux works, and you get to pick any/all of the the options (desktop env (or tiling window manager), bootloader, display manager, etc) available for modern Linux systems.
I have a Framework 16, but I installed Arch on it a couple months ago as a dual boot to play around with. Process was largely painless but I did end up disabling secure boot. (actually I partially started the process of getting secure boot working, decided 'nah' and just disabled it...)
I'm on a framework 13 AMD edition since early this year, running arch. There were issues early on but seemed to be mostly on the firmware side and would not have been distro specific. After then April(?) firmware updates I have not had any issues.
[deleted]
I've been using Void Linux for the last 1.5 years because I wanted an Arch-like experience but without systemd. I haven't had any unsolvable problems.
I've been using Arch+hyperland on a framework 13, and it's been pretty good. Screen sharing seems to be the only thing that acts up now and then.
Haven't used a Framework, but I'll throw arch-based CachyOS. Super simple setup and optimized binaries for modern machines are a plus.
On the 16 I bounced between a bunch before settling on Manjaro. It seemed to "just work" better than any other distro.
Debian (stable or testing, depending on your taste).
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 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.
"From now on, I will assume you have created an unprivileged user to run yay."
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.
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.
Follow the link just before using yay, where he explains makepkg, yay and an unprivileged user.
This was the process I followed:
1. Downloaded EndeavourOS
2. Installed it as easily as Ubuntu
Edit: the arch documentation is second to none
1. Downloaded EndeavourOS
2. Installed it as easily as Ubuntu
Edit: the arch documentation is second to none
Installing Arch is just boring and uneventful. You follow the guide from the wiki and that's it. I had more fun installing Debian manually with debootstrap some 15 years ago or so, as it wasn't as well-documented back then and the process left some space for me to screw things up. The most interesting thing to figure out was when I forgot to set the loopback network interface up. All sorts of random things were broken in peculiar ways, but the whole system worked well enough to make it seem you already succeeded :)
nixos is even worse, I have a configuration.nix that I only look at when I'm upgrading, to fix one or two warnings about deprecation.
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 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 had plenty of… fun, trying to write a mix config file from scratch. But I also didn’t know a thing about the language when I got started. :)
Same here. I used to do the arch manual install thing, but after a few times doing it, it's just easier to run a script to do it for you. I could write one, or I could just install EndeavorOS, so that's what I do. I used Manjaro before, but they've had some sketchy happenings to say the least, and something breaks a little too often for me. EndeavorOS is fantastic.
> the arch documentation is second to none
I am willing to argue that it's the best documentation of any distribution
I am willing to argue that it's the best documentation of any distribution
Isn't the pain of installing Arch the point?
Some people might just like the rolling release model, huge software library through AUR and good documentarion.
Not at all. The point is to have a rolling release, up to date, mostly unpatched Linux distribution.
Nit picking a bit but I prefer btrfs even if it's slower. Easier to work with.
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 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 bootloader is this using? Or is it just straight EFI booting?
Well, Plasma 6 made it the default. Some things are better with Wayland (e.g., performance), but others are worse (e.g., no session restore so far...).
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 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.
> How is Wayland support these days? I love i3 but I know Sway promises to be close enough.
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.
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.
How's Asahi these days? Stable enough to run as a daily?
Depends on your tolerance level. I get random crashes under heavy load at least once a month or so under CPU-bound tasks. As I said, GPU/Sway stability is perfect - I've had no issues there, but large rust builds seem to tip the system over occasionally.
Thermals? Can you nice down the process? Reserve a core for the OS? RAM issue?
(Come on you post a HW issue on hacker news, you know the peanut gallery is coming out in force ;-) )
(Come on you post a HW issue on hacker news, you know the peanut gallery is coming out in force ;-) )
> How is Wayland support these days? I love i3 but I know Sway promises to be close enough.
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).
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).
> In our case, LVM makes it easy to allocate virtual partitions inside an encrypted SSD partition.
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.
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.
That sector size change is interesting. I got warned off of doing that for my SSDs with some vague statement that lots of software expects 512 byte sectors. Can anyone further comment?
If people want Arch with a GUI installer I would recommend EndeavourOS instead of Manjaro. EOS offers a much more native/close-to-Arch experience while Manjaro has many more of its own repos/packages/OS modifications (and issues) and is more of a Linux Mint to Ubuntu situation.
I have a friend which is really happy with EndeavourOS, I am hearing only good stuff about it. Back when I switched to Linux, the choice was either Manjaro or Antergos, and Manjaro had a far wider community.
Antergos was eventually archived, and from my understanding EndeavourOS become its spiritual successor.
Antergos was eventually archived, and from my understanding EndeavourOS become its spiritual successor.
i use Manjaro but i switch to the unstable branch as soon as possible so i can get the closest to Arch
I am not sure I understand the point of using TPM + PIN to decrypt the drive for a single user system.
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.
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.
I found TPM + PIN to be more secure than TPM automatic unsealing, and faster than typing my long passphrase.
I haven't tried pam_autologin yet, but I see the convenience of it.
I just use archinstall, which is similar in difficulty to GUI installers, i.e. not at all difficult.
My vote goes to EndeavourOS as others have already mentioned here. Manual install was the way to go and is still the preferred way to setup a server/cli. With that experience in mind for a daily driver with GUI I use EndeavourOS. The default KDE works.
If the disc is encrypted (and otherwise nothing would save you anyway), why do I need the Secure Boot, really? What harm it can do for somebody to boot my device from an unauthorized drive?
The threat model is the Evil Maid Attack.
I found Secure Boot + UKI + TPM PIN (God forbids automatic unsealing) + FDE to be great for both security and usability.
[0]: https://en.wikipedia.org/wiki/Evil_maid_attack
[0]: https://en.wikipedia.org/wiki/Evil_maid_attack
I know SteamOS uses an immutable file system over a custom Arch install.
Have any people here tried this kind of thing with immutable file systems on Arch and is there a realistic benefit?
Have any people here tried this kind of thing with immutable file systems on Arch and is there a realistic benefit?
Usually better to just install on btrfs and use rollbacks/snapshots
Arch is pretty much the opposite of immutable.
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.
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.
Have you used SteamOS? I don't know the particulars but I'm pretty sure they do indeed make all the important bits read-only. You can temporarily use pacman as root, but it isn't supported so any changes made are overwritten when an upgrade happens or a system crash causes a the partition to be verified.
Again, very much out of my depth here so sorry if i'm misusing terms etc.
Again, very much out of my depth here so sorry if i'm misusing terms etc.
I tried playing with it long ago (like 1.0 era) but it was too specific.
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.
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.
I followed a very similar process a couple of years ago (time flies!) and I'm very happy with the results. I'm not even using Arch but Artix Linux but the system runs very smoothly, almost not a single problem updating in years, using all kinds of cutting edge software which is amazing.
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.
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.
“Modern” is an utterly meaningless word and this blog uses it a lot.
Modern means "better designed with the current software usage environment in mind".
It definitely doesn’t mean that.