Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Bootstrapping from other linux distributions.

Aperta
  • Qualcosa non va?
#4,813 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
30/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
linux, python
Ambito
devops, operating-systems

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
Python
Stelle
8.5k
Fork
774
Merge medio
1g 12h
PR unite (30g)
26

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di archlinux/archinstall

Tutte le issue di archlinux/archinstall

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.