Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Bootstrapping from other linux distributions.

Abierto
  • ¿Algo no está bien?
#4,813 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
30/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
linux, python
Área
devops, operating-systems

Línea de trabajo

The issue names no implementation file; begin at the existing running_from_host path and the proposed check_foreign entry point, then map host/target assumptions and dependency availability for one distro tier. A useful first milestone is a scoped PoC for one tier, with reproducible bootstrap and cleanup behavior documented and validated before expanding to other distributions.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

describe the request

Description

This is a larger ask, that is in three tiers.

Tier 1. Bootstrapping from systemd based distros.

Targets: Fedora, Debian(sid/forky), Nix

They all ship both pacman and arch-install-scripts making it just a matter of a few changes + Maintaining a compatible dependency list name equivalents.

Tier 2. Bootstrapping from non-systemd based distros.

Targets: Alpine, Void, Chimera

Alpine also already ships pacman and arch-install-scripts but require more changes to the code base. If not entirely new bootstrap mechanisms.

Tier 3. Bootstrapping from the bootstrap archives

https://wiki.archlinux.org/title/Install_Arch_Linux_from_existing_Linux

Another alternative. Which could reduce a lot of the drawbacks mentionned in this post. Perhaps would automate/own parts of the process within archinstall.

Motivations

An effort in this area would help answer a couple of questions.
Some of which I've already been wondering about:

  • What is left in "unclean" states?
    I.e Host-2-Target #3978 instead of always assuming always ISO temp envir. Clean-ups, #4491. This is also a broader good practice.
  • What assumptions are made about the host?
    Dependencies in target vs host (chroot or not), order of operations, that probably need fallback mechanisms? For instance, our current crypt loading might fail on another distro, or a shelling out to a systemd utility might be better off as an actual function looking for local files.
  • What is left to "bootstrap"?
    I.e Debian doesn't ship a pacman.conf or Alpine doesn't ship the key-ring components.

Yet these are all things that archinstall could handle in the "not-so-happy" paths.

Then is practically just following error logs, on each distro (and is kinda fun to do/learn about, not going to lie). Overall. this would make the code base a lot more robust, I believe and help us spot things, we might never have thought of previously.

Think of it as a stress-test for general error-handling, portability, reproducibility and "isolation".

Prior art

This was also already discussed with @Torxed in the discord (sorry for the spotlight):

I like the idea of being able to bootstrap from other places.
This was actually one of the (personal) ambitions, that I could use this script from say ubuntu and then push in arch..

And seeing as alpine/pkgs/pacman is a thing, it's more possible now than ever.. Which wasn't the case when I started. It would be interesting to see a PoC, and how to work around arch-chroot being used (which, I'd also like to see if we can replace with systemd-nspawn) as well as the possibility to replace pacstrap with ALPM using their Python bindings (still in development phase which I'm following closely).
I'd like to also replace package search with ALPM (this is something that does work, I just haven't submitted the code and PR yet for it).

The cleanup scenario, is also something I was interested in.

For tier 2/3. I'd argue that systemd-nspawn is less portable. While arch-chroot is just shell around mount chroot and details.
(I believe using -S in arch-chroot also relies on systemd-run), not sure how these are related or portable to bootstrap from ANYWHERE.

I've already been trying to hunt down repro and availability of each package:

https://github.com/h8d13/archinstoo/blob/master/distros

Which works for the most part, as a PoC. But keep in mind this is highly experimental (+ stripped of certain dependencies) and almost impossible to maintain solo, (hence why I'm posting about this here). And has been the better part of my days for the last 9 months.

It may be a beneficial idea to keep a seperate public branch for this, as it cooks up. First few steps might be some kind of check_foreign to extend the original running_from_host

Lenguaje dominante
Python
Estrellas
8.5k
Forks
774
Merge medio
1 d 12 h
PR fusionados (30 d)
26

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de archlinux/archinstall

Todos los issues de archlinux/archinstall

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.