Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Bootstrapping from other linux distributions.

未关闭
  • 哪里不对？
#4,813 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
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 小时
30 天内合并 PR
26

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

archlinux/archinstall 的其他 Issue

查看 archlinux/archinstall 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。