How does dd know about correct disk label when burning iso to usb?

Question

I used dd to burn arch linux image to usb stick, but now I need to store additional files on the same usb stick. The usb stick is read-only after dd so I decided to format it manually. The stick was recognized as bootable but the arch failed to load the system since it was looking for a disk labeled "ARCH_201912". As far as I know I can use -n flag with mkfs.fat command like this:

mkfs.fat -F 32 -n "$label" "$partition"

I just do not want to type it manually as it changes every month (I am writing bash function). And dd somehow knows what the label should be and correctly set it to usb device. I thought there is a file storing this value, so I issued:

$ grep --directories=recurse ARCH_201912 .

./arch/boot/syslinux/archiso_pxe.cfg:APPEND archisobasedir=arch archisolabel=ARCH_201912 archiso_nbd_srv=${pxeserver}
./arch/boot/syslinux/archiso_sys.cfg:APPEND archisobasedir=arch archisolabel=ARCH_201912
Binary file ./EFI/archiso/efiboot.img matches
./loader/entries/archiso-x86_64.conf:options archisobasedir=arch archisolabel=ARCH_201912

Is there a way to get this label without parsing the file (as it seems that archisolabel is specific for arch linux)? I want this method work both for linux and windows. Though I am not sure if windows 10 require proper label set.

Answer 1

And dd somehow knows what the label should be and correctly set it to usb device

The label is not actually set on the device in any special way. It is simply part of the filesystem metadata (which itself is stored as regular data), and gets blindly copied along with all other filesystem structures.

dd marks drive as read-only,

It doesn't. If that happens, either it's at filesystem level (maybe the image only contained a filesystem that does not support writing, e.g. ISO9660 is read-only by design), or the drive has physically reached end-of-life (as cheap USB sticks often do).

so it is up to maintainer of the .iso file to make it ddable (like setting partitions or label)?

Yes. A "pure" .iso file only contains the ISO9660 filesystem used by CDs – it's up to the maintainer to use tools to convert it into a hybrid image containing a BIOS MBR bootloader and a FAT32 or similar filesystem.

(Or the maintainer could of course skip the .iso part and just directly build a regular "dd-able" disk image from the beginning.)

I thought there could be kind of standard for EFI specifying label of the disk.

Disks have no label. Partitions can have a label, as well as filesystems. The only thing about USB sticks is that they normally have just one partition (and one filesystem), so its label is often seen as the disk's label.

Both kinds of labels are stored on the disk itself, as regular data. (Partition labels are indeed stored in the UEFI GPT partition table, but you usually don't see them.)

Filesystem labels – the usual kind that you see – are stored in the filesystem metadata, e.g. in the Ext4 header or in the FAT32 master file table.

However, the label is not stored as an actual file – in FAT32 it is a special MFT record type; in other filesystems it is a dedicated filesystem header field.

Is there a way to get this label without parsing the file (as it seems that archisolabel is specific for arch linux)?

On Linux you'll want to use libblkid, which has a corresponding CLI tool blkid. The library can extract basic information (filesystem label, UUID) from dozens of filesystem types.

However, blkid requires root privileges in order to read physical devices, so you'll want to get the cached data from udev using lsblk, leaving blkid for image files.

lsblk -n -o LABEL /dev/sda2