Arch Linux Installer Archinstall 2.6 Preparing New Features

[ehansin]

On a genuine serious note, does anyone know about the Limine bootloader that is mentioned in the article? I took a look and intend to read up and learn more. Looks like this some sort of evolution of the stivale and sivale2 boot protocols, which I never heard of before either I am happy to ditch Grub where I can, but wondering why I might want to use the Limine bootloader over say systemd-boot? I do often dual-boot with Windows if that matters here. Anyway, got me learning something new, was not aware.

[abracat]

Only reason for me to use Arch is not to have a system that's overly dependent on flatpaks. I don't even know how to arch-chroot into a system set up by the archinstall script I know I can look it up. The automated process does seem to remove some of the kiss philosophy. Also miss the latin1 keymap option form the installer, and the possibility of setting multiple locales. And the selected locale should be uncommented rather than just added to a new line at the bottom of the file.

[sophisticles]

It's not their fault that you don't understand what the aur is.

This is the typical Linux cop-out, create a feature then when people use it and have problems with it blame the user.

I don't remember being part of the team that designed and implicated aur, nor was I consulted, the developers simply said here's something we created for you to use.

[sophisticles]

Only reason for me to use Arch is not to have a system that's overly dependent on flatpaks. I don't even know how to arch-chroot into a system set up by the archinstall script I know I can look it up. The automated process does seem to remove some of the kiss philosophy. Also miss the latin1 keymap option form the installer, and the possibility of setting multiple locales. And the selected locale should be uncommented rather than just added to a new line at the bottom of the file.

Flatpaks are the best thing to happen to Linux, it allows a developer to provide a consistent experience across distros; same with appimages.

I will take it one step further, if i released a Linux distro there would be no package manager or repo, everything would be flatpaks or appimages.

[bachchain]

This is the typical Linux cop-out, create a feature then when people use it and have problems with it blame the user.

I don't remember being part of the team that designed and implicated aur, nor was I consulted, the debelopers simply said here's something we created for you to use.

You probably shouldn't be using Arch. It explicitly doesn't cater to users with your attitude.

https://wiki.archlinux.org/title/Arc...ser_centrality

Whereas many GNU/Linux distributions attempt to be more user-friendly, Arch Linux has always been, and shall always remain user-centric. The distribution is intended to fill the needs of those contributing to it, rather than trying to appeal to as many users as possible. It is targeted at the proficient GNU/Linux user, or anyone with a do-it-yourself attitude who is willing to read the documentation, and solve their own problems.

[Jelgnum]

This is such a handy tool, I have used it to install multiple systems and it has yet to fail me.
I'm happy to see it growing

[Termy]

This is the typical Linux cop-out, create a feature then when people use it and have problems with it blame the user.

I don't remember being part of the team that designed and implicated aur, nor was I consulted, the debelopers simply said here's something we created for you to use.

No, the developers clearly state that you should only use it if you know what you are doing. And only if you do that, only then should you even consider using an AUR-helper.

I agree though that it is really bad that distros like manjaro ship an disguised AUR-helper by default - that's not the fault of Arch or the AUR though...

Flatpaks are the best thing to happen to Linux, it allows a developer to provide a consistent experience across distros; same with appimages.

There are more than enough issues though. While i really love flatpak for many things and really appreciate that it made somewhat reasonable sandboxing (if you double-check the permissions) very approachable and convenient, it's surely not perfect for everything. Last big disappointment was codium - sure, it's not an official package and the devteam clearly stated, that they don't see enough reason to support it (like, wtf dude?), but still there are several things not working (properly) due to flatpak-limitations. As soon as your app is not self-contained but has to interact with 'random' stuff in the rest of the system, that's where flatpak (by design i would say?) breaks down.

[Torxed]

I don't even know how to arch-chroot into a system set up by the archinstall script.

At the end of the script, it asks if you want to arch-chroot into the system.
But it's quite simple,

arch-chroot /mnt/archinstall bash

The automated process does seem to remove some of the kiss philosophy.

In a sense yes, but we try to only install the very very bare minimum for the system to boot, unless options are selected ontop. And even in that case we try to keep those as minimalistic as possible too.

Also miss the latin1 keymap option form the installer, and the possibility of setting multiple locales. And the selected locale should be uncommented rather than just added to a new line at the bottom of the file.

latin1 is not listed by

localectl list-keysmaps

which is why we're not listing it, but it can safely be added post-install if you want to.
Multiple locales would not be too hard to add and uncomment would not be hard to do instead either.

[abracat]

latin1 is not listed by

localectl list-keysmaps

actually it is. Tried that on my system as well as on usb...

Multiple locales would not be too hard to add and uncomment would not be hard to do instead either.

You should always go for native if you have to choose one. I just like my formats to be native and my language to be British,

At the end of the script, it asks if you want to arch-chroot into the system.
But it's quite simple,

We/I don't really need that as such since you can set everything up simply by using the script given you know your way around.

It is necessary to look at (the fstab) and arch-chroot wiki

Section 4.2

Running on Btrfs


On a Btrfs root file system with subvolumes, you have to make sure that all subvolumes are properly mounted as specified in fstab before entering chroot.

An example with the Btrfs default setup from archinstall:
# mount -o subvol=@ /dev/sdXY /mnt
# mount -o subvol=@home /dev/sdXY /mnt/home
# mount -o subvol=@pkg /dev/sdXY /mnt/var/cache/pacman/pkg
# mount -o subvol=@log /dev/sdXY /mnt/var/log
# mount -o subvol=@snapshots /dev/sdXY /mnt/.snapshots
# mount /dev/sdXZ /mnt/boot
# arch-chroot /mnt

something like a script to mount and arch-chroot in on standard defaults and exit and umount -R could be a timesaver (boot is usually set to "1" and the rest to "2" so it's not that big of a deal if you look at it.

It is however more steps than...

arch-chroot /mnt
exit
umount -R /mnt

[guzz46]

I will take it one step further, if i released a Linux distro there would be no package manager or repo, everything would be flatpaks or appimages.

I've always wondered this myself, at what point does an application cease being part of the system or desktop environment and become an application that can be installed or removed via flatpak? a few years ago I considered installing debian stable and using all flatpaks, that way I could have a stable base but with up to date applications, until I realized that there were important parts of the system that aren't flatpaks and so essentially wouldn't get updated for 2 years, like the file manager, the panel, and other software that aren't available as flatpaks, so I decided it was best to go with a rolling release and avoid flatpaks, then all software will be up to date and I wouldn't have two different types of software on my system.