[SOLVED/CANCELED] Tailored Arch Linux laptop installation

ectospasm · 2023-09-23 19:35:35

SOLVED/CANCELED: Seeking opinions is against the forum rules, and following the guide I link to is unsupported by the Arch Community. My guide represents one specific way to set up an Arch Linux laptop, given that it meets certain hardware requirements. It is not intended to be comprehensive, nor is it guaranteed to be error-free. Caveat lector, if you're seeking to install Arch, please follow the Arch Linux Wiki.

Original post for posterity:

I have purchased a Lenovo ThinkPad X1 Carbon, 11th Generation laptop, which appears to be fully compatible with Arch according to the Arch Wiki (I specifically chose the compatible webcam to ensure full compatibility). It should arrive in a few weeks.

In the meantime, I have drafted installation instructions that I'd like the community to review before I publish it. It's not written in the Wiki style, a bit more conversational, and I give some reasons about the choices I make during the installation. Any constructive feedback would be appreciated. Comments on my website won't be available since this is not published, but you can provide any comments on this Arch Forums topic.

I will likely not publish this until I've installed Arch on the X1 Carbon, which likely won't be until late December. This will actually be a Christmas gift from my wife that I will unwrap Christmas morning, after I've performed the preparation steps on the tailored instructions. I may also delay publication until I'm able to repeat the instructions on my old ThinkPad 25th Anniversary Edition. The instructions should still be valid for the older laptop, but there may be quirks, gotchas, and caveats I will encounter differently than the X1 Carbon.

Last edited by ectospasm (2023-09-24 16:32:54)

dogknowsnx · 2023-09-23 20:12:48

Maybe you could/should mention that by following your instructions one doesn't qualify for official support (on these forums) which however will have to be kindly provided by you (I didn't read all of it, but couldn't find anything like it searching for keywords - please ignore this post in case I've missed it).

ectospasm · 2023-09-23 20:31:04

dogknowsnx wrote:

Maybe you could/should mention that by following your instructions one doesn't qualify for official support (on these forums) which however will have to be kindly provided by you (I didn't read all of it, but couldn't find anything like it searching for keywords - please ignore this post in case I've missed it).

Thanks for the feedback! I hadn't thought of this, but I do want to know: why doesn't this qualify for official support (other than using an AUR helper to install some AUR packages)? I did briefly mention that using makepkg alone is the official Arch recommendation for AUR packages, but the rest comes straight from the Arch Wiki, just collated to appear in one place rather than bouncing between multiple Wiki articles to achieve this. I don't understand why this wouldn't qualify for official support, either on these forums, or on IRC.

Trilby · 2023-09-23 20:56:03

Because of the rules.

But more relevantly, why are you writing your own instructions? The only valid instructions for installing arch have one step:

1. Follow the arch wiki

That said, I was happy to see none of the most common problems that show up in most of the crap guides out there. And I appreciate the way in which you clarify which steps are optional and / or based on your own preference - e.g., you explain why you use pikaur and how one can choose another helper or none at all rather than just instructing users to blindly copy-paste your commands to install pikaur.

So if you want feedback on the current quality, writing style, etc, that may be possible - but again, why? No matter how good your guide is now, it couldn't be supported as it will be outdated and / or just wrong in no time when something changes. If you think the installation guide is missing something or can be improved, feel free to contribute to the talk page on our wiki.

Then there's this:

ectospasm wrote:

I may also delay publication until I'm able to repeat the instructions on my old ThinkPad 25th Anniversary Edition. The instructions should still be valid for the older laptop, but there may be quirks, gotchas, and caveats I will encounter differently than the X1 Carbon.

This is a big problem. In fact, it's a perfect example of two of the Six Dummest Ideas In Computer Security. If your confidence in the validity of your instructions depends on testing it on multiple machines, then 2 machines is an insufficient test, as would be three, or four. One might argue that testing on hundreds of very different machines might incrementally raise the confidence in the instructions ... one might - but even that would again be a perfect example of two of the six mistakes.

Last edited by Trilby (2023-09-23 21:01:38)

jonno2002 · 2023-09-23 21:14:47

if you already have a working arch install on your current laptop then why waste time doing a fresh install, just clone/rsync your installation across, saves alot of time !
https://wiki.archlinux.org/title/Migrat … _to_bottom

i havent "installed" arch in years, i just rsync an existing install and make necessary changes, if any.

Last edited by jonno2002 (2023-09-23 21:17:58)

ectospasm · 2023-09-24 02:21:27

Trilby wrote:

Because of the rules.
But more relevantly, why are you writing your own instructions? The only valid instructions for installing arch have one step:
1. Follow the arch wiki

Thank you for the feedback! And point well taken. To be honest, I am the primary audience intended for this guide. My main complaint with the Arch Wiki is that to do it the way I want, I have to scour through several Wiki articles, and piece it together. Without writing down how I want to do it beforehand, I run the risk of missing or forgetting some step. I really only posted this to see if anyone identified any glaring gaps in my process. But again, this is primarily for me, so I don't have to remember how to do it the way I want, since I've already done the research on the wiki.

Trilby wrote:

That said, I was happy to see none of the most common problems that show up in most of the crap guides out there. And I appreciate the way in which you clarify which steps are optional and / or based on your own preference - e.g., you explain why you use pikaur and how one can choose another helper or none at all rather than just instructing users to blindly copy-paste your commands to install pikaur.
So if you want feedback on the current quality, writing style, etc, that may be possible - but again, why? No matter how good your guide is now, it couldn't be supported as it will be outdated and / or just wrong in no time when something changes. If you think the installation guide is missing something or can be improved, feel free to contribute to the talk page on our wiki.

I should probably go a step further and put a disclaimer near the top: this is just one to do it, according to my preferences as of today. I will have a few months to keep reviewing the Wiki and refining this document. And then repeat the process again when I revamp my old laptop.

The built in obselence of such a guide is a good point, I don't intend for this to be found too high on search results, going back to this guide really being only for me. Again, the main reason I posted this here at all is to see if anyone finds any technical deficiencies in my process, if there is something missing or I'm forgetting something crucial. I do try to link back to the wiki so I can look to see if anything has changed before I execute the process for the first time.

Trilby wrote:

Then there's this:
ectospasm wrote:
I may also delay publication until I'm able to repeat the instructions on my old ThinkPad 25th Anniversary Edition. The instructions should still be valid for the older laptop, but there may be quirks, gotchas, and caveats I will encounter differently than the X1 Carbon.
This is a big problem. In fact, it's a perfect example of two of the Six Dummest Ideas In Computer Security. If your confidence in the validity of your instructions depends on testing it on multiple machines, then 2 machines is an insufficient test, as would be three, or four. One might argue that testing on hundreds of very different machines might incrementally raise the confidence in the instructions ... one might - but even that would again be a perfect example of two of the six mistakes.

I read through that PDF, and I'm having a hard time seeing how it applies. Which of the six dumbest ideas am I falling into? Educating Users? I'm not making the claim that my article makes the target computer secure. I'm just using some advanced PC security tools, namely Secure Boot and Unified Kernel Images, more as a learning exercise for myself more than anything else. I've never used either of these before, and the Arch Wiki presents many ways to achieve this goal. I'm just selecting one of the ways to do this, i.e. with systemd's kernel-install, and its related mkinicpio and sbctl plugins.

Absolute security is a mirage, and I don't have the time or resources to test this on a multitude of machines. Not even the Arch Wiki is perfect in this regard. The Arch Wiki presents many options, and discusses some tradeoffs. But it is up to the user to determine what they want to do and how they want to install their systems. My article is mainly a document that should be good enough for my purposes with it. Whenever seeking help with Arch, the user needs to know how and why certain decisions were made when installing Arch. I need to make it clear in my article that this is one way to do it, it doesn't necessarily make the laptop more secure.

This is really condensing the series of Wiki articles needed to do it this way in one document, I try to give the reader who is not me options and alternatives so they can make their own decisions regarding their systems. I will state at the top of my article that if the reader blindly follows everything in this document, they will likely not be supportable by the wider Arch community (forums and IRC). Caveat emptor lector indeed.

Last edited by ectospasm (2023-09-24 12:55:51)

ectospasm · 2023-09-24 02:35:35

jonno2002 wrote:

if you already have a working arch install on your current laptop then why waste time doing a fresh install, just clone/rsync your installation across, saves alot of time !
https://wiki.archlinux.org/title/Migrat … _to_bottom
i havent "installed" arch in years, i just rsync an existing install and make necessary changes, if any.

The installation process has evolved since I last did it, I want to give it another try with different (better?) options. I also want to make use of technologies that either weren't available or weren't mature enough the last time I did it, or better use of technologies I am more familiar with now (e.g. Btrfs). Also, there is a lot of cruft I've installed over the years, and I don't necessarily want to have an identical clone of the system. Not only that, I enjoy installing a new operating system, even if it is something I'm already familiar with. I also want to test my backup systems, a mixture of Git, borg, and Backblaze B2, rather than a simple rsync from the old system.

Honestly, I'm tired of GRUB, which is installed on this existing system. Back when I last installed it, it was only compatible with LUKS1, and ultimately I was quite unhappy with having to store the keys twice; kind of a hack to avoid having to enter the decryption key twice. systemd-boot and UKI with Secure Boot seems much cleaner (and systemd-boot is what I use on my other UEFI systems already).

Trilby · 2023-09-24 03:22:34

ectospasm wrote:

I am the primary audience intended for this guide

It you are the sole audience, then it's wonderful - by all means use it. But then don't publish it. If you are not the sole audience, then others will be effected by it. The fact that you see yourself as the primary audience does not limit the effect it would have on other members of the audience.

extospasm wrote:

I read through that PDF, and I'm having a hard time seeing how it applies. Which of the six dumbest ideas am I falling into?

Enumerating badness and penetrate and patch.

extospasm wrote:

I don't have the time or resources to test this on a multitude of machines.

Precisely my point. If your instructions are correct / valid by design, then testing on other machines is irrelevant. If they can be seen as correct only after verification of testing on multiple machines, you'll never be able to test enough. So your confidence in publishing the instructions should not scale with the number of machines you have used it on.

The installation guide in the wiki is the correct and supported way of installing arch. Any difference between your instructions and the wiki instructions in terms of whether they result in a stable functioning system would imply that either the wiki needs revision, or that your instructions include flaws. As you test on your first system, then a second, then perhaps a couple more, all you could possibly do is enumerate previously-undetected-flaws in deviations from the installation guide that you added. But in testing just a handful of systems, you would enumerate only an infintessimal fraction of the problematic deviations. You'd likely then fix up your instructions to avoid that specific problem (penetrate and patch), while remaining unaware of others.

So again, if you were able to test on hundreds to thousands of machines, the best you could acheive would be to thoroughly enumerate the badness and then try to "patch" it away. But as you will not come close to that, the confidence you (or anyone else) could have in your instructions cannot be based on whether you tested it on your one, two, or few machines - that's just not relevant.

jonno2002 · 2023-09-24 05:42:36

ectospasm wrote:

The installation process has evolved since I last did it, I want to give it another try with different (better?) options. I also want to make use of technologies that either weren't available or weren't mature enough the last time I did it, or better use of technologies I am more familiar with now (e.g. Btrfs). Also, there is a lot of cruft I've installed over the years, and I don't necessarily want to have an identical clone of the system. Not only that, I enjoy installing a new operating system, even if it is something I'm already familiar with. I also want to test my backup systems, a mixture of Git, borg, and Backblaze B2, rather than a simple rsync from the old system.
Honestly, I'm tired of GRUB, which is installed on this existing system. Back when I last installed it, it was only compatible with LUKS1, and ultimately I was quite unhappy with having to store the keys twice; kind of a hack to avoid having to enter the decryption key twice. systemd-boot and UKI with Secure Boot seems much cleaner (and systemd-boot is what I use on my other UEFI systems already).

all of that can be changed with an existing install, if you want to change filesystems or add encryption then you prepare the new disk/partitions/lvm's and then copy your existing system over, bootloaders are easy to change too, and cruft can be removed.

for example my main arch install is my first and only arch install from 2016, started out with simple ext4 partitions and xfce, and now ive got 'lvm on luks' and a fully custom bspwm setup and its been through 3 laptops and has migrated from sata ssd to nvme ssd, needless to say i installed alot of cruft back when i was learning and trying things but all that has been removed and my system is clean and tidy.

and as for the grub luks1 thing, why do you need to encrypt /boot ? theres nothing in there that needs to be private, and keys only need to be on the root filesystem which you unlock with your password at boot and then crypttab does the rest.

ectospasm · 2023-09-24 12:27:41

Trilby wrote:

Enumerating badness and penetrate and patch.

How am I enumerating badness? I'm not listing software to avoid, I'm just collecting the various Wiki articles into one document with certain choices I've made, so it's straightforward to follow. This seems like you have this argument against any such guide, which is OK. The Arch Wiki leaves much of this to the user, and my post is how I will be approaching the problem: installing Arch.

"Penetrate and test" may be applicable, as I will run through this document and list any gaps I find, or problems encountered and hopefully solutions. But beyond that I don't see how this dumb ideas paper applies. Other than using some technology which I'm hoping will make my laptop more resistant to physical attacks (something I'm not trying to prove correct), the article is less about security and more about making certain decisions and following the Wiki in its current form, and putting all the pieces together in one document.

And your point about updating the Wiki is a good one. If I run into any problems, I can go to the relevant section of the Wiki and at least mention it on the Talk page, or update the Wiki if something works differently than the documentation I copied straight from the Wiki.

ectospasm · 2023-09-24 12:54:13

jonno2002 wrote:

all of that can be changed with an existing install, if you want to change filesystems or add encryption then you prepare the new disk/partitions/lvm's and then copy your existing system over, bootloaders are easy to change too, and cruft can be removed.
for example my main arch install is my first and only arch install from 2016, started out with simple ext4 partitions and xfce, and now ive got 'lvm on luks' and a fully custom bspwm setup and its been through 3 laptops and has migrated from sata ssd to nvme ssd, needless to say i installed alot of cruft back when i was learning and trying things but all that has been removed and my system is clean and tidy.
and as for the grub luks1 thing, why do you need to encrypt /boot ? theres nothing in there that needs to be private, and keys only need to be on the root filesystem which you unlock with your password at boot and then crypttab does the rest.

This is precisely why I'm intending to use systemd-homed for the first time, to make my home directory (where most of my data resides) easily portable between systems. I've been bad about removing the software cruft I've installed, it's easier to read through pacman -Q to see what I want to keep and install on a new laptop.

And encrypting /boot was a bad decision on my part, one I made three years ago and haven't given myself enough time to revamp it (in my opinion it's easier to reinstall and start fresh). It's why I have file-level backups in the first place. I don't backup the entire system, as restoring from backup quickly is not one of my requirements for my hobby projects, which all of my Arch systems are. Restoring from backup, after first rebuilding the system, grants me the opportunity to change the way I set up Arch in the first place.

I may follow your rsync suggestion when I do reinstall Arch on my old laptop, to conserve time. But there are things I wouldn't want to copy verbatim, like stuff in /etc (especially SSH host keys, and machine ID stuff).

Trilby · 2023-09-24 13:19:07

ectospasm wrote:

How am I enumerating badness? ... I will run through this document and list any gaps I find, or problems encountered

Asked and answered.

But I'll end my contributions to this thread here. I've been trying to elaborate why your guide - just like every other third party guide - would be unsupported. Trying to clarify this rule does not imply it is up for debate. It isn't.

Last edited by Trilby (2023-09-24 13:20:27)

ectospasm · 2023-09-24 16:25:42

Trilby wrote:

ectospasm wrote:
How am I enumerating badness? ... I will run through this document and list any gaps I find, or problems encountered
Asked and answered.
But I'll end my contributions to this thread here. I've been trying to elaborate why your guide - just like every other third party guide - would be unsupported. Trying to clarify this rule does not imply it is up for debate. It isn't.

Thank you, point well taken, and I'm not intending to debate the forum rules (though it doesn't mention third-party guides as an example of something for the bikeshed; perhaps it should). I did post near the top of my guide that blindly following this means you would be unsupported, and I refer anyone reading my guide to the Arch Wiki, where they should go in the first place. It's not meant to be comprehensive, which is wha the Wiki is.

I'll go ahead and mark this as solved, in a way (since it was asking for opinions, which is definitely against the rules). You can have a moderator dustbin this topic if you feel that strongly about it.

Arch Linux

#1 2023-09-23 19:35:35

[SOLVED/CANCELED] Tailored Arch Linux laptop installation

#2 2023-09-23 20:12:48

Re: [SOLVED/CANCELED] Tailored Arch Linux laptop installation

#3 2023-09-23 20:31:04

Re: [SOLVED/CANCELED] Tailored Arch Linux laptop installation

#4 2023-09-23 20:56:03

Re: [SOLVED/CANCELED] Tailored Arch Linux laptop installation

#5 2023-09-23 21:14:47

Re: [SOLVED/CANCELED] Tailored Arch Linux laptop installation

#6 2023-09-24 02:21:27

Re: [SOLVED/CANCELED] Tailored Arch Linux laptop installation

#7 2023-09-24 02:35:35

Re: [SOLVED/CANCELED] Tailored Arch Linux laptop installation

#8 2023-09-24 03:22:34

Re: [SOLVED/CANCELED] Tailored Arch Linux laptop installation

#9 2023-09-24 05:42:36

Re: [SOLVED/CANCELED] Tailored Arch Linux laptop installation

#10 2023-09-24 12:27:41

Re: [SOLVED/CANCELED] Tailored Arch Linux laptop installation

#11 2023-09-24 12:54:13

Re: [SOLVED/CANCELED] Tailored Arch Linux laptop installation

#12 2023-09-24 13:19:07

Re: [SOLVED/CANCELED] Tailored Arch Linux laptop installation

#13 2023-09-24 16:25:42

Re: [SOLVED/CANCELED] Tailored Arch Linux laptop installation

Board footer