wipe_dev() fails with ENOSPC on partitions smaller than 1024 bytes (ChromeOS GPT layouts) #4807

Which ISO version are you using?

Omarchy 4.0.4 ISO, which ships archinstall 4.4 unmodified: its archinstall/lib/disk/device_handler.py is byte-identical to the 4.4 tag. The affected code is unchanged on master.

The installation log

Not available: the live session was rebooted before /var/log/archinstall/install.log was saved. There is a standalone reproduction below instead. omacom/omarchy#9246 quotes the traceback from the same failure on other machines, ending in open(dev_path, "wb") → OSError: [Errno 28] No space left on device.

describe the problem

A wipe/full-disk install of a disk previously used by ChromeOS or ChromeOS Flex fails with OSError: [Errno 28] No space left on device.

DeviceHandler.wipe_dev() calls _wipe() on every existing partition, and _wipe() writes a fixed 1024 bytes:

with open(dev_path, 'wb') as p:
	p.write(bytearray(1024))

ChromeOS GPT layouts contain several 512-byte partitions (KERN-C, ROOT-C, reserved and firmware slots). The ChromiumOS disk-format reference says "Each minimal-size partition (including the C kernel and C rootfs) is only 512 bytes". Writing 1024 bytes to one of them fails after 512 bytes with ENOSPC, which aborts the installation.

Reproduction (as root, any Linux):

truncate -s 64M t.img
sgdisk -o -a 1 -n 6:100:100 t.img && sgdisk -a 2048 -n 1:2048:0 t.img   # one 512-byte partition, one normal
LOOP=$(losetup -fP --show t.img)
python -c "with open('${LOOP}p6', 'wb') as p: p.write(bytearray(1024))"   # OSError: [Errno 28] No space left on device
python -c "with open('${LOOP}p1', 'wb') as p: p.write(bytearray(1024))"   # fine

Reproduced on Linux 6.8 (loop device) and under the Omarchy ISO's 7.2.4 kernel with an NVMe disk. Seen on real hardware on a Lenovo ThinkPad (Samsung NVMe) and on two MacBook Airs (omacom/omarchy#9246), each after ChromeOS Flex. Clearing the partition table first (wipefs -a + sgdisk --zap-all) avoids it.

A fix follows in a pull request: write min(1024, device size) bytes, taking the size from seeking to the end of the block device. On normal partitions the behaviour is unchanged (1024 bytes zeroed); on a 512-byte partition all 512 bytes are zeroed instead of raising.