Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Bootstrapping from other linux distributions.

オープン
  • 何か問題がありますか？
#4,813 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
30/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
活発
技術スタック
linux, python
領域
devops, operating-systems

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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

主要言語
Python
スター
8.5k
フォーク
774
平均マージ
1日 12時間
マージ済み PR（30日）
26

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

archlinux/archinstall のほかの issue

archlinux/archinstall の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。