Architect install: It worked like a charme


I'd like to give you a big compliment!

This morning I installed Manjaro Architect and it worked like a charm, or how do you Americans say?
Bravo, simply wonderful!!

But, as you know, nothing is so good as not to be improved a little bit.

  1. if possible, please use the --geoip and not --fasttrack parameter for pacman-mirrors. I live in Berlin, Germany and there the European mirrors would be quite enough for me. Every time I hang on to this Iranian mirror and China or New Zealand are not necessarily recommended either.

  2. i have a wifi dongle with RTL8812AU chipset, the driver of which was not installed, otherwise everything seems to be perfectly recognized and running fine, but i have to install it now via the AUR. Could this be improved or do I have to live with it because the driver comes from a third party?

  3. I would like an even faster installation procedure. Yes, I have to admit that I had MATE installed as a desktop environment, but must this inevitably lead to more than 1 gigabyte of packages being downloaded? Couldn't this be partially postponed until later, after the installation of the system?

  4. i had chosen german as local from the beginning, but you don't have to believe that firefox-i18n-de would have been installed with it. That should be the same for thunderbird and libreoffice. It would be nice if there was something like tasksel language-packs for it here. :wink:

  5. after the installation I first installed hw-probe with all optional dependencies. I would like this to be an automatic selection, since you know immediately what kind of machine you have in front of you and whether everything was recognized correctly. Sample URL:

Otherwise I am very satisfied and do not want to miss to express my gratitude again.

  1. An undocumented feature/possiblity is to create the mirror list before launching the installer - then omit the step of testing the mirrors.
    sudo pacman-mirrors -c Germany
  1. You cannot build AUR packages using Architect

  2. Architect uses the list of packages from the iso-profiles used to create the distribution ISOs. As such the user of the architect installer is limited to the choices made by the maintainer when the minimal and full package sets was decided. You can choose to install a vanilla desktop - and later customize it to your liking.

  3. Architect offers the option of adding additional packages - including extra language packages.

  4. An Architected installation should not make too many choices on behalf of the user - you are assumed to know what you are dealing with.

Thank for sharing this positive experience. I am sure the maintainer of Architect scripts appreciates your input.


I bow to Your wisdom, oh Master. :wink:

  1. i will try again, this time with the parameter --geoip before setup.

  2. Do you mean: "You can not build packages at all." perhaps? Cause the installation runs by pacstrap or so? Or will there be a other reason?

Do you know the Ubuntu way when Debian does not provide something special what they want to offer?
They create a extra PPA, the user enables it and the installation simply runs. Would they name it "runs out of the box"?

I am here to find solutions, not for discussion of problems. And when this means I have to setup my own repository or so to provide my wanted drivers or maybe whole kernels(lts and latest) with this drivers build in. This would not be impossible, right? This rembers me, that I have a still unused root server at Kimsufi/OVH still waiting for me. :wink:

So before starting a new install I will read what are the requirements for a personal repository. May it run on debian also or should it better be a Arch system and how to setup?

  1. So next try I will use the minimal installation of packages. There are only two things important then: The system comes up with lan driver r8169 is installed and the packages dhcpcd, mc and Links are installed, I think. I am trained with Archlinux doing all by hand while reading the documentation... :wink:

  2. Yes, I installed mc this way but the user has to know what the mintainer of the architect misses to know what he needs to install on his own, right? A tasksel for german, french or danish by example would help, I think.

  3. From my point of view hw-probe should not be a choice. :wink:
    It is a must have and I please and encourage everybody to use it for their own favor and to contribute to the growing database of devices a linux user may use.

The AUR is build scripts. Not actual packages.

This requires the user to be knowledgeable on the issues that may rise during the build process.

It also requires the user to know how to install the resulting package into the chroot.

There is too many unknowns which may makes the build and subsequent install of a given package for a given hardware fail.

Many drivers for hardware - available from AUR requires building every time the kernel changes - this can be facilitated by using dkms labeled drivers but in case where no dkms packages exist - it requires build in a chroot against a specific kernel which often is not the same as the running Architect ISO.

A personal repo can be a local set of packages with a database created by the repo-add utility. The repo can be manually added to the ISO's pacman.conf - and must be available from either a mounted disk device or a webserver.

For the hw-probe - not all needs it - because they know their hardware.

The driver installation tool mhwd provides mostly the same info as hw-probe - just from the looks of it.

mhwd -lh

There is a wiki article on user-repos at

The article mentions a connection to the buildiso script but that is not a requirement if you just want to make a repo of prebuilt packages for you own use and has no plans of creating an ISO.

You mention the r8168/69 driver - you don't need that - because the kernel now has excellent support for that specific device (and the repo driver is know to cause issues after the kernel got the modules added).

Thank you! We Finnish say "toimi kuin junan vessa (worked like a toilet in a train)" :slightly_smiling_face:

Adding more choices to mirror selection makes sense. I'll look into it.

If it is not in the repos, then aur is the way to go. If it is common enough and license permits, it might get included in the repos.

Yes, don't select a desktop environment and only add packages you want as custom packages.

I am not familiar with tasksel. I'll look into it.

This sounds like a profile level issue.

I know the AUR so far but hen a build script is in a good maintained state and is popular enough a distribution may decide to offer it from their own repository, right? So does Manjaro does it with yay.

So far I would be the only user but I understand not to offer it to the public if it not runs for sure.
I see this is to difficult to offer it as a general solution like a distribution must think about.

You write webserver, so you mean it may be a debian web server also, only requirement a running apache?

Knowing your hardware is one thing, okay. But everybody is pleased and encouraged also to provide his system information to the database to show he is interested in hardware where Linux is supported. There must be tenths of thousand or may be 100.000 or more Linux users but the database got some thousend data samples up to now, it seams to me.

mhwd was and may be will be a solution for running on Manjaro only, right. Even a Archlinux user has no reason to use it. So does Red Hat with anaconda and Mandrake with drakconf in the past. This was not really useful for other Linux users of a other distribution, right? But it seems SUSE and Fedora, may be others also, in the end had found a way to work together and do all Linux users a long awaited favor. Now I see also many Ubuntu systems providing their data sets to this database.

Could you imagine this collected buying power on the market? Should this not be more than the market share of Apple users after all this years of development? But ZyXEL, my wifi dongle manufacturer, states, that Windows and Apple systems are supported. Linux? Not stated. So may be never heard about?

As far as I understand a repo could be created by the command repo-add on the local mashine, right?

But how come the packages in the remoe server and are accessible from my local system? Will I have the possibility to upload them to the root server by ftp? Will this be sufficient? So that I can pull them, after a new installation of my local server, by wget? How comes the database information to the remote server? By uploading it also or will it be better when on the remote server runs something like Archlinux too for creating and updating the so named database on the remote server local?

I have stated the r8169 only cause I need it for my LAN NIC not cause I want to install it individuell.

That is correct. (read the wiki article)

  • Create a folder to hold the packages.
  • Build the package(s).
  • Copy the package(s) to the folder.
  • cd to the folder
  • Run repo-add to create a database with the package(s)
    run repo-add -h to get the syntax

The repo is added to the pacman.conf using

#Server = file:///repo/db/location
#Server = http(s)://server.tld/repo/db/location

There is no special requirements for the web server. This can be anything - apache, nginx - just to name two widely user server types.

repo-add is a bash script - runs on any *nix based device

Thanks a lot. So I will fullfill the setup of my root server now which I had do interrupt cause I also setup a OpenWRT-router and some things on this pc. Will come back later and report.

Forum kindly sponsored by