The pre-write check is safe and does not affect the write even if probing fails. It merely warns and prompts for confirmation when detecting that the device appears mounted, contains a partition table, or is an LVM physical volume.
If the user confirms, dd proceeds unaltered—the warning is dismissed; if the user was mistaken, the prompt prevents accidental data loss. Consequently, existing scripts and documented workflows (e.g., writing ISOs to USB drives) are unaffected. The check provides a safety net against accidental data loss. thanks, Jianing Weng On 09/09/2026 09:42, ii wrote: >I have revised the patch substantially: remove the file‑system structure overwrite check entirely. remove the libblkid dependency – the new implementation does not pull in any extra library. retain only a best-effort check that warns the output block device appears to be: currently mounted, LVM physical volume, or containing an MBR or GPT partition table >These checks are performed by reading a few initial sectors directly >and parsing the on‑disk signatures. The detection is purely advisory: >any failure during probing is silently ignored and treated as >"nothing detected", so dd will never fail or change its behaviour >because of pre-write safety check. The warning is only issued when >dd is run interactively, and it asks for user confirmation before proceeding. ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >On 08/09/2026 15:11, Collin Funk<[email protected]> wrote: >Wouldn't this change break common instructions people use to create >flash drives for installing GNU/Linux, or other operating systems? At >least, I remember 'dd' commonly being recommended for that. Asking one >of the major slop bots: > > How do I write a Fedora ISO to a usb? > >Resulted in an answer involving the following steps: > > $ sudo umount /dev/sda*> > $ sudo dd if=Fedora-Workstation.iso of=/dev/sda \ > bs=4M status=progress oflag=sync > >If I understand correctly, the above steps would now give a warning with >this change if the drive has an MBR/GPT partition table, e.g., if I >previously used the drive to install FreeBSD using a memstick image: > > $ od -Ax -tx1 -j 510 -N 2 FreeBSD-15.1-RELEASE-amd64-memstick.img > 0001fe 55 aa > 000200 > $ fdisk -l FreeBSD-15.1-RELEASE-amd64-memstick.img | tail -n 3 > Device Boot Start End Sectors Size Id Type > FreeBSD-15.1-RELEASE-amd64-memstick.img1 1 66584 66584 32.5M ef EFI (FAT-12/16/32) > FreeBSD-15.1-RELEASE-amd64-memstick.img2 * 66585 3032424 2965840 1.4G a5 FreeBSD > >While I am sympathetic to making things safer, I worry that this >behavior might come as welcome surprise to others. > >Collin ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > On 04/09/2026 22:54, Pádraig Brady <[email protected]> wrote: > On 04/09/2026 10:22, ii via GNU coreutils Bug Reports wrote: >> if dd is used to write block device, would destroy in-use devices, or LVM, &nbsp;partition tables on devices. &nbsp; >> Before opening the output, probe with libblkid and warn if content is recognized, prompting for confirmation. > > Checking whether a device is mounted does seem potentially useful. > > Checking whether to overwrite existing file system structures seems less useful, > as that would be a very common scenario. Also that functionality adds the > libblkid dependency which isn't ideal. > >thanks, >Padraig ii [email protected]
