原来的系统：Ubuntu 24.04 / Debian 12（Scaleway 纯 IPv6 VPS）
要安装的系统：Ubuntu 24.04
遇到的问题：执行 reinstall 进入中间系统（Alpine initrd）后，apk 的联网装包失败，反复报 “temporary error”，安装流程无法继续。
排查结论：Alpine 阶段 accept_ra=0，未学习到默认 IPv6 路由；在仅 IPv6 且通过 RA 下发默认路由的环境（如 Scaleway）下，会导致外网不可达，从而 apk 失败。

1. 环境与版本

• 云服务商：Scaleway；
• 网络形态：仅 IPv6（无 IPv4）；默认路由通过 RA 下发（无 DHCPv6 默认路由）。

2. 实际表现与日志

• 在 Alpine 阶段网络操作失败，apk 装包反复报错（节选）：
  ***** COPY EFI PARTITION UUID *****
  (1/1) Installing mtools (4.0.47-r0)
  ERROR: mtools-4.0.47-r0: temporary error (try again later)
  …（同错误多次重试）
• 当场连通性检查（位于 Alpine 内）：
  ping -6 2001:4860:4860::8888 -> Network unreachable
  cat /proc/sys/net/ipv6/conf/eth0/accept_ra -> 0

3. 复现步骤（稳定复现）

• 在 Scaleway 的 IPv6-only VPS 上运行 reinstall，选择安装 Ubuntu 24.04。
• 系统引导到 Alpine initrd 阶段，在 ***** COPY EFI PARTITION UUID ***** 附近执行 apk add mtools / apk update 等网络操作时反复失败。
• 在 Alpine 内检查：
  cat /proc/sys/net/ipv6/conf/eth0/accept_ra 返回 0；
  ip -6 route 无默认路由；
  ping -6 2606:4700:4700::1111 / ping -6 2001:4860:4860::8888 不可达。

4. 排除项

• 镜像源可达性：同一平台其他系统或在有默认路由的情形下，IPv6 镜像可达，说明并非镜像源宕机/无 IPv6 的问题；
• 地址获取：接口可分配 IPv6 地址，仅缺省默认路由。

5. 诊断与结论

• 问题点在 中间 Alpine 阶段：接口已拿到 IPv6 地址，但没有默认路由；
• accept_ra=0 → 忽略 RA，无法从 RA 学到默认路由；
• 在 IPv6-only + RA 下发默认路由 的环境（典型如 Scaleway）中，这会直接导致外网不可达，从而所有 apk 联网操作（apk update / apk add mtools / 依赖下载等）均以 “temporary error” 失败；
• 由此可判定：根因是 Alpine initrd 未学习到默认 IPv6 路由，并非镜像源问题。

6. 临时绕过（用于确认根因）

• 在 Alpine 内手动启用接收 RA 后，网络立即恢复，安装可继续并完成：
  # 任选其一（二者任意其一均可使 RA 生效）
  sysctl -w net.ipv6.conf.eth0.accept_ra=1 # 未开启转发时接收 RA
  sysctl -w net.ipv6.conf.eth0.accept_ra=2 # 即使开启转发也接收 RA（更稳）
  ip -6 route # 应出现：default via fe80::... dev eth0
  apk update && apk add mtools # 成功
  /trans.sh # 流程继续并最终完成

7. 期望

• Alpine 阶段应自动学习 IPv6 默认路由，使 apk update / apk add 可正常联网，整个重装流程无需人工干预即可顺利完成。

8. 可能原因与改进方向（仅供参考）

• 原因方向：Alpine initrd 的网络初始化流程中未显式启用接收 RA，或在后续清理/切换配置时将其重置为 0；在 IPv6-only 环境下导致默认路由缺失。
• 改进建议：
  a. 在 initrd 网络初始化阶段显式启用接收 RA（推荐 accept_ra=2，即使开启转发也接收），并确保后续逻辑不再将其覆盖；
  b. 启用时机要早于 SLAAC/RA 学习步骤，以避免时序竞态；
  c. 可在 bring-up 后对接口级 accept_ra 做一次确认写入，确保接口值与 all/default 一致。

9. 补充信息

• 受影响范围：IPv6-only 且默认路由依赖 RA 的环境（部分 VPS 提供商常见形态）；
• 触发点：***** COPY EFI PARTITION UUID ***** 阶段装包（mtools 等）或后续需要联网的步骤；
• 期望协助：请在 initrd 的起网流程中处理上述场景，避免类似平台/地区用户在纯 IPv6 环境下反复遇到相同问题。

Original system:Ubuntu 24.04 / Debian 12 (Scaleway IPv6-only VPS)
System to be installed:Ubuntu 24.04
Issues encountered: After executing reinstall to enter the intermediate system (Alpine initrd), network installation of the apk package failed, repeatedly reporting "temporary error", and the installation process could not continue.
Troubleshooting conclusion: In the Alpine stage, accept_ra=0 was set, and the default IPv6 route was not learned. In an IPv6-only environment (such as Scaleway) where the default route is distributed via RA, this causes external network unreachability, resulting in apk failure. **

1. Environment and Version

• Cloud Service Provider: Scaleway;
• Network Configuration: IPv6-only (no IPv4); the default route is distributed via RA (no DHCPv6 default route).

2. Actual Performance and Logs

• Network operations failed during the Alpine stage, and APK installation repeatedly reported errors (excerpt):
  ***** COPY EFI PARTITION UUID *****
  (1/1) Installing mtools (4.0.47-r0)
  ERROR: mtools-4.0.47-r0: temporary error (try again later)
  …(Same error retried multiple times)
• On-site connectivity check (within Alpine):
  ping -6 2001:4860:4860::8888 -> Network unreachable
  cat /proc/sys/net/ipv6/conf/eth0/accept_ra -> 0

3. Reproduction Steps (Stable Reproduction)

• Run reinstall on Scaleway's IPv6-only VPS, choosing to install Ubuntu 24.04. - When the system boots into the Alpine initrd, network operations such as apk add mtools and apk update repeatedly fail near ***** COPY EFI PARTITION UUID *****.
• Checking within Alpine:
  ** cat /proc/sys/net/ipv6/conf/eth0/accept_ra returns 0;
  ip -6 route shows no default route;
  ping -6 2606:4700:4700::1111 and ping -6 2001:4860:4860::8888 are unreachable. **

4. Troubleshooting

• Mirror source reachability: The IPv6 mirror is reachable on other systems on the same platform or with a default route, indicating that the mirror source is not down or IPv6 is unavailable.
• Address acquisition: The interface can be assigned an IPv6 address, but only the default route is used.

5. Diagnosis and Conclusion

• The problem lies in the intermediate Alpine stage: the interface has obtained an IPv6 address, but no default route.
• accept_ra=0 → RAs are ignored, preventing the default route from being learned.
• In an IPv6-only environment with RAs delivering default routes (typically, Scaleway), this directly causes external network unreachability, resulting in all apk network operations (e.g., apk update, apk add mtools, and dependency downloads) failing with a "temporary error".
• Therefore, the root cause is that the Alpine initrd has not learned the default IPv6 route, not an issue with the image source.

6. Temporary Bypass (for root cause confirmation)

• After manually enabling RA acceptance within Alpine, the network immediately recovered, and the installation could continue and complete:
  # Choose either option (either will enable RAs)
  sysctl -w net.ipv6.conf.eth0.accept_ra=1 # Accept RAs when forwarding is disabled
  sysctl -w net.ipv6.conf.eth0.accept_ra=2 # Accept RAs even when forwarding is enabled (more stable)
  ip -6 route # Should display: default via fe80::... dev eth0
  apk update && apk add mtools # Success
  /trans.sh # The process continues and completes

7. Expectations

• The Alpine stage should automatically learn the IPv6 default route, allowing apk update and apk add to connect to the network normally. The entire reinstallation process should complete smoothly without manual intervention.

8. Possible Causes and Improvements (for reference only)

• Cause: RA acceptance is not explicitly enabled during the Alpine initrd network initialization process, or is reset to 0 during subsequent configuration cleanup/switchover. This results in the loss of the default route in an IPv6-only environment.
• Improvement Suggestions:
  **a. Explicitly enable RA acceptance during the initrd network initialization phase (recommended accept_ra=2, which allows acceptance even when forwarding is enabled) and ensure that subsequent logic does not overwrite it;
  b. Enable RA acceptance before the SLAAC/RA learning step to avoid timing races;
  c. After bringing up, perform a confirmation write to the interface-level accept_ra to ensure that the interface value is consistent with the all/default setting. **

9. Additional Information

• Affected Scope: IPv6-only environments where the default route relies on RA (a common pattern among some VPS providers);
• Trigger Point: During the ***** COPY EFI PARTITION UUID ***** phase of package installation (e.g., mtools) or subsequent steps requiring an internet connection;
• Request for Support: Please address the above scenario during the initrd network startup process to prevent users on similar platforms/regions from repeatedly encountering the same issue in IPv6-only environments.