Arch Linux's Install Media Adds "Archinstall" For Quick/Easy Installations

[Nocifer]

I have not tried Arch yet, but you are saying the right things to make me think it is an option. With 'a bit' of finagling I set up my personal Lubuntu* system fully encrypted with a non-mainstream filesystems, but standard installers make this unnecessarily complicated, so if it is easier on Arch, I may well be persuaded to move to it.

*I used Debian from version 2.0 (Hamm), but got fed up setting up DEs, WMs etc, and went for the ease of a pre-packaged distribution that was 'minimal-enough' (LXDE). While I enjoy fiddling with stuff, being forced to audit config changes on upgrades gets rapidly irritating**, so I chose to let someone else do all the boring integration work for me. Hence Lubuntu, which has since 'jumped the shark', so I'm on the hunt for a grown-up distribution that 'just works' in a sane manner.

**I suspect Arch does just this, which is fine when you are learning, but gets really, really irritating when you are using your workstation as a tool for getting non-Linux things done.When you are in the middle of an update, and a breaking change in a config is presented as a diff with the option of using a cli/non-gui text editor to make fundamental changes, shorn of context, I get...irritated. It would be nice to have a dry-run/preprocessor that would detect if config changes were necessary and flag them up to allow me to research them beforehand. In principle, I just need to set an LVM checkpoint, run an upgrade and revert back if a breaking change occurs. Which is a bit of a faff - but maybe I'll start doing just that...

The beauty of Arch IMHO is that it's one of those distros that encourages you to do those little things that could also be done in every other Linux distro, but that are usually not done because GUI tools have taken over and made us scared of manually changing conf files, reducing our systems into opaquely black boxes that mystify the user instead of empowering them to tinker with them.

As an example, Arch does not forcefully present changes to conf files as a diff in the middle of an update. Instead it simply keeps the existing file (so everything keeps running in exactly the same way as before the update, even if you reboot) and saves the new file with a .pacnew extension (e.g. sshd.conf.pacnew) and then leaves it up to the user to go look for these new files and do whatever they want with them. No preprocessors. But here's the trick: it's actually really easy to write a so-called pacman hook, that will be called after each update and notify you about any new .pacnew files that have been created - and that's that. Or of course you could write yourself a cron task (or systemd-timer service) that does the same thing every X amount of time.

Can we do that in other Linux distros? Of course we can. But do we usually do it? No, because we're used to convoluted, fully automated packaging tools like apt that we really don't want to mess around with because we're afraid (and rightly so) that we'll probably break them.

Regarding simplicity, speaking for myself, I fell in love with Arch way back when because it showed me a simple truth: a complete Linux setup is as simple as partition disks, format disks, mount disks, install base packages, configure basic stuff like fstab/timezone/locales, configure network, optionally install GUI, enable services/init scripts, reboot, done*. Depending on your internet connection speed, you can literally have a brand new Arch system up and running in less than 10 minutes. And afterwards, it's a quick trip to the Arch Wiki (which let's not forget, it's the #1 go-to place for learning how to do stuff on any Linux system) to find out how to configure non-basic stuff like e.g. disk decryption on boot.

(*Terribly sorry if I'm forgetting a step or two, it's been ages since I last installed Arch).

[Nocifer]

For now. This is all I heard when I used Windows. Don't like it? Keep using the current version. Sorry but it doesn't work that way in real life. Support ends and what you hate becomes the only option. You have no choice.

A valid concern in theory, but really, it's practically impossible to have end-of-support forced on you for something like running common Linux commands in a terminal in order to manually install your system.

[Firnefex]

The best thing about this installer is not needing a second PC to look at the wiki.

Have seen a video where this installer only created 2 partitions: EFI and / with btrfs.
So the question is, can I also create a swap, a /home partition with XFS and do the btrfs snapshots really work without subvolumes?

[Mateus Felipe]

Ouch, the Arch diehards aren't going to like this as they believe that Arch shouldn't be quick and easy to install.

But Arch is already quick and easy to install.

[skeevy420]

Are there big fundamental differences between Arch and Manjaro or EndeavourOS once the system has been installed?
On a day-to-day basis, regarding pacman and pacman-mirrors, pamac, yay, the AUR, etc...
Let's say I decide to switch from Manjaro and I'm already familiar with these. Would I really see a big difference in maintaining the distro once it's set up?
And before that, could you give me some benefits that would be killer enough for me to switch (and keep using the same tools as they work very well for me)? In other words, what makes Arch worth using beside its tailored installer?

If you use kernels from the AUR there are some Manjaro/Arch annoyances where their included modules conflict with global dkms packages. They also do custom themes and things like that so you don't get the vanilla experience that Arch is known for. Basically, it's not as developer and power user friendly as Arch is until you get some of their helpers out of the way. After that it is really close to Arch, only you lag behind a tiny bit so sometimes, infrequently, packages in the AUR get updated and you'll have to wait a few days or a week until the next Manjaro update to update your AUR packages.

Been awhile since I've used anything on the EndeavourOS side, but back when I used Antergos their updates would lag behind Arch by a day or so which occasionally led to package version issues. The same thing can happen on Arch when enough user repos are added. It's just the nature of rolling and diverging from upstream. While I'm not sure how much of an issue that is with Endeavour, it is something to keep in mind if you're the kind of person that updates often and you've strayed from only Arch (and the AUR) in your mirrorlist.

On-topic, I'm surprised at the negativity here. I thought more people would be happy about both an official method to script an Arch install around and a way to introduce it to the masses. IMHO, the most difficult part of any OS install is disk management so being able to simplify that process to make the overall OS accessible to everyone is a good thing. That doesn't apply to us or most posters here, but we're too smart for our own goods and we forget that.

[TemplarGR]

On-topic, I'm surprised at the negativity here. I thought more people would be happy about both an official method to script an Arch install around and a way to introduce it to the masses. IMHO, the most difficult part of any OS install is disk management so being able to simplify that process to make the overall OS accessible to everyone is a good thing. That doesn't apply to us or most posters here, but we're too smart for our own goods and we forget that.

I agree with this. That is why sometimes i use a live usb from another distro, for example Ubuntu or gparted, to partition a disk to my liking, before booting the arch installation usb. Having a gui is more comfortable when working with multiple partitions/disks and sadly if you are not careful partitioning tools from the terminal can be fatal to your data.

[skeevy420]

The beauty of Arch IMHO is that it's one of those distros that encourages you to do those little things that could also be done in every other Linux distro, but that are usually not done because GUI tools have taken over and made us scared of manually changing conf files, reducing our systems into opaquely black boxes that mystify the user instead of empowering them to tinker with them.

As an example, Arch does not forcefully present changes to conf files as a diff in the middle of an update. Instead it simply keeps the existing file (so everything keeps running in exactly the same way as before the update, even if you reboot) and saves the new file with a .pacnew extension (e.g. sshd.conf.pacnew) and then leaves it up to the user to go look for these new files and do whatever they want with them. No preprocessors. But here's the trick: it's actually really easy to write a so-called pacman hook, that will be called after each update and notify you about any new .pacnew files that have been created - and that's that. Or of course you could write yourself a cron task (or systemd-timer service) that does the same thing every X amount of time.

Can we do that in other Linux distros? Of course we can. But do we usually do it? No, because we're used to convoluted, fully automated packaging tools like apt that we really don't want to mess around with because we're afraid (and rightly so) that we'll probably break them.

Regarding simplicity, speaking for myself, I fell in love with Arch way back when because it showed me a simple truth: a complete Linux setup is as simple as partition disks, format disks, mount disks, install base packages, configure basic stuff like fstab/timezone/locales, configure network, optionally install GUI, enable services/init scripts, reboot, done*. Depending on your internet connection speed, you can literally have a brand new Arch system up and running in less than 10 minutes. And afterwards, it's a quick trip to the Arch Wiki (which let's not forget, it's the #1 go-to place for learning how to do stuff on any Linux system) to find out how to configure non-basic stuff like e.g. disk decryption on boot.

(*Terribly sorry if I'm forgetting a step or two, it's been ages since I last installed Arch).

While I agree with all of that, I did have a good laugh at as simple as these 11 steps which require a fair amount of general Linux and PC knowledge.

[skeevy420]

I agree with this. That is why sometimes i use a live usb from another distro, for example Ubuntu or gparted, to partition a disk to my liking, before booting the arch installation usb. Having a gui is more comfortable when working with multiple partitions/disks and sadly if you are not careful partitioning tools from the terminal can be fatal to your data.

This one time at band camp I tried to install Gentoo from Ubuntu and picked the buggiest Ubuntu RC ISO ever...couldn't even change windows with mouse clicks buggy. Tried to knock out two birds with one stone -- preview the latest Ubuntu, install Gentoo...I failed miserably at both

[Nocifer]

I agree with this. That is why sometimes i use a live usb from another distro, for example Ubuntu or gparted, to partition a disk to my liking, before booting the arch installation usb. Having a gui is more comfortable when working with multiple partitions/disks and sadly if you are not careful partitioning tools from the terminal can be fatal to your data.

Yeah, working with partitions is the only thing I also still mostly do by GUI, especially when we're talking about modifying existing partitions on disks with data already on them. In fact that's the reason I've nowadays mostly abandoned LVM (which I used to like the concept of because of snapshots) in favor of normal partitions; I just can't stand the stress of growing/shrinking by hand in the terminal.

While I agree with all of that, I did have a good laugh at as simple as these 11 steps which require a fair amount of general Linux and PC knowledge.

Well, to my defense I only meant that installing a Linux system is easy as a concept, in that it only consists of ~15 clearly defined pieces to complete the whole puzzle. As to the difficulty of each specific step, let's not forget that we're talking about copying and pasting commands from the cheat sheet that is the Arch Wiki

[X_m7]

I've thought about adding a wifi-configuration step some where.
Archinstall is branded as a "guided installer", but in it's basic form it's actually a lib/api that ships a guided installer. And I'm thinking to add wifi configuration to the library part - and users would be able to in a very simplified manner configure `iwd` to some extent. Essentially just ask "Which wifi? and what's the password?" and set up the appropriate iwd systemd script for it. But people haven't been outspoken about this specific need so haven't added it yet

But I'm always open to feedback (main developer here)

The reason people haven't been outspoken about it is that plain old WPA2-Personal with just SSID and password is quite straightforward to set up with just CLI, or if people want a more interactive way nmtui (NetworkManager's TUI interface) can do it too, whereas the WPA2-Enterprise simply has a lot more options that need to be filled in, and depending on which protocols the network requires the specific options needed can differ too. Other distros that have a GUI installer have access to the GUI frontends, which does have support for all that stuff (at least the NetworkManager ones do, like GNOME's and KDE's). It doesn't help that the Arch wiki is very long-winded when it comes to configuring networks for each specific daemon (out of necessity given all the possibilities, but still), which made an install that should've taken an hour or so of an evening (being my first time, so I was quite nervous and triple checking all the commands I was typing in) stretch all the way to like several hours of the next day.

In short, I don't think it would be all that useful (as indicated by the lack of people asking for it evidently) to just handle the SSID and password bit, and if you wanted to handle the esoteric cases too it'd probably have to be a TUI to be any better than CLI or writing out a config file, which would probably only make people stuck with those networks during the install happy (in my case I was living on-campus during that first install) while possibly pissing off others, while also being a lot of work to boot.

Besides, archinstall was never meant to completely replace the standard installation procedure, right? It's kind of like partitioning really, there's just so many options (and lots of ways to break stuff too in that case) that there's just no way to handle it all in a simple, sane manner. Either way, I still appreciate the work you're doing here, just making Arch easy to try out in a virtual machine is already a success as far as I'm concerned.