Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Manual partitioning without wipe: deleting an existing partition crashes installer (wipefs runs on deleted partition path)

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#4,849 1 bình luận 1 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@Kolgrim33 đang làm issue này rồi.

Từ ngày 25/10/2026.

  • #4853 của @Kolgrim33 — đang mở

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
72/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
linux, python
Lĩnh vực
backend, operating-systems

Hướng nghiên cứu

Đọc archinstall/lib/disk/device_handler.py quanh DeviceHandler.partition() và _setup_partition(), sau đó kiểm tra các hàm hỗ trợ trạng thái của PartitionModification trong archinstall/lib/models/device.py. Theo dõi cách các mục DELETE đi đến vòng lặp xóa chữ ký và tái hiện lỗi với một ổ đĩa không trống, bằng cách phân vùng thủ công mà không xóa. Công việc hoàn tất khi việc xóa một phân vùng hiện có không còn chạy wipefs trên đường dẫn thiết bị đã bị xóa và quá trình cài đặt tiếp tục.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

ISO version

Not reproduced from a specific ISO — this bug was found by source analysis of master (commit 2c25540) and verified at component level (see evidence below). The affected code path exists in current master.

The installation log

No full install log available (static analysis). The failure point is deterministic, see "Root cause" below. The uncaught exception raised at that point is:

SysCallError: ['wipefs', '--all', '/dev/sdaX'] exited with abnormal exit code [1]:
wipefs: error: /dev/sdaX: probing initialization failed: No such file or directory

wipefs returning exit code 1 for a non-existent device node was verified locally:

$ wipefs --all /dev/sda99
wipefs: error: /dev/sda99: probing initialization failed: No such file or directory
$ echo $?
1
Summary

When installing onto a non-empty disk via manual partitioning without wiping the whole device, marking any existing partition for deletion crashes the installation with an uncaught SysCallError: the signature-wipe loop runs wipefs --all against the device path of the partition that was just deleted.

Steps to reproduce
  1. Start archinstall on a machine with a disk that already contains partitions (e.g. a previous installation).
  2. Disk setup → Manual Partitioning (do not wipe the whole disk).
  3. Select an existing partition → Delete partition.
  4. Proceed with the installation (creating new partitions in the freed space afterwards is optional — not required to trigger the bug).
Expected behavior

The partition marked as deleted is removed during DeviceHandler.partition() and the installation continues.

Actual behavior

The installation aborts with the uncaught SysCallError shown above as soon as partition() reaches the signature-wipe loop.

Root cause

Verified on master @ 2c25540:

  1. DeviceHandler.partition() collects every partition that is not EXIST — which also includes DELETE entries — into filtered_part (archinstall/lib/disk/device_handler.py:543):

    # don't touch existing partitions
filtered_part = [p for p in modification.partitions if not p.exists()]

    PartitionModification.exists() only checks status == ModificationStatus.EXIST (archinstall/lib/models/device.py:1028-1029).

  2. For a DELETE entry, _setup_partition() deletes the on-disk partition and returns early, leaving part_mod.dev_path pointing at the now-removed device node (archinstall/lib/disk/device_handler.py:349-361):

    if requires_delete and part_mod.status in [ModificationStatus.MODIFY, ModificationStatus.DELETE]:
    ...
    disk.deletePartition(part_info.partition)

if part_mod.status == ModificationStatus.DELETE:
    return

  3. After disk.commit() (device_handler.py:559) the kernel removes the /dev/sdaX node.

  4. The signature-wipe loop then iterates over the same filtered_part list and runs wipefs on the stale path of the deleted partition (device_handler.py:561-566):

    # Wipe filesystem/LVM signatures from newly created partitions
# to prevent "signature detected" errors
for part_mod in filtered_part:
    if part_mod.dev_path:
        debug(f'Wiping signatures from: {part_mod.dev_path}')
        SysCommand(f'wipefs --all {part_mod.dev_path}')

    Despite the comment, the list is not limited to newly created partitions. The if part_mod.dev_path: guard never filters DELETE entries out: __post_init__ requires a path for all is_exists_or_modify() entries, and that set includes DELETE (archinstall/lib/models/device.py:927-928, 1031-1036).

  5. SysCommandWorker.__exit__ raises SysCallError for any non-zero exit code (archinstall/lib/command.py:111-116) and the call site has no try/except → the installation crashes.

The path is fully reachable from the guided TUI: manual partitioning defaults to wipe=False (archinstall/lib/disk/disk_menu.py:355) and the "Delete partition" action sets status = ModificationStatus.DELETE (archinstall/lib/disk/partitioning_menu.py:355-362).

Suggested fix

Skip entries that were only deleted when wiping signatures:

for part_mod in filtered_part:
    if part_mod.status == ModificationStatus.DELETE or not part_mod.dev_path:
        continue
    debug(f'Wiping signatures from: {part_mod.dev_path}')
    SysCommand(f'wipefs --all {part_mod.dev_path}')

(or iterate over [p for p in filtered_part if p.is_create_or_modify()] instead).

Related observation (same scenario)

While repartitioning a non-empty disk, DeviceHandler.umount_all_existing() (device_handler.py:505-517) only unmounts filesystems and locks LUKS devices — it never calls swapoff (no swapoff call exists anywhere in the codebase). If an existing swap partition on the target disk is active, deleting that partition will make parted fail with "Device or resource busy".

Ngôn ngữ chính
Python
Star
8.5k
Fork
785
Merge trung bình
15 giờ 35 phút
Pull request đã merge (30 ngày)
16

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của archlinux/archinstall

Tất cả issue của archlinux/archinstall

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.