ds-identify fails to detect NoCloud datastore with LABEL_FATBOOT instead of LABEL (change introduced recently in util-linux-2.33-rc1)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Original bug report with detailed description was created for Xen Orchestra here: https:/
Brief description:
On systems with util-linux-2.33-rc1 or younger (e.g. Debian 10 Buster), ds-identify fails to detect when a disk of a NoCloud datasource has a label written to the boot sector of the disk. Before util-linux-
I ran into this when using cloud-init together with Xen Orchestra v5.48 (Xen Orchestra is a management interface for xen; in my case xcp-ng v8.0.0). I created a VM template based on the recently released Debian 10.0 Buster, which uses util-linux 2.33.1. Upon boot, ds-identify fails to detect the NoCloud datasource / virtual disk which Xen Orchestra generated (the disk is created with this code from https:/
Longer description / likely cause of the problem:
Xen Orchestra creates the NoCloud as a partition-less disk with a FAT16 filesystem which has the NoCloud user-data and meta-data files. The label "cidata" is written into the boot sector of the virtual disk. With the same disk, older versions of blkid report "LABEL=cidata" whereas newer versions detect "LABEL_
Relevant commit message from the util-linux-2.33-rc1 changelog (commit f0ca7e80d7a1717
libblkid: vfat: Change parsing label in special cases
* Use only label from the root directory and do not fallback to the label stored in boot sector. This is how MS-DOS 6.22, MS-DOS 7.10, Windows 98, Windows XP and also Windows 10 behave. Moreover Windows XP and Windows 10 do not touch label in boot sector anymore, so removing FAT label on those Windowses leads to having old label still stored in boot sector (which MS-DOS and Windows fully ignore).
* Label entry "NO NAME" in root directory is treated as label "NO NAME" instead of empty label. In root directory it has no special meaning. String "NO NAME" has a special meaning (empty label) only for label stored in boot sector.
* Label from the boot sector is now stored into LABEL_FATBOOT field. So if there are applications which depends or needs to read this label, they have ability.
* After this change LABEL always correspondent to the label from the root directory and LABEL_FATBOOT to the label stored in the boot sector. If some of those labels is missing or is not present (e.g. "NO LABEL" in boot sector) then particular field is not set.
Possible fix:
I did a trivial change of 2 lines to ds-identify to check for LABEL_FATBOOT after the check for LABEL:
debian@
236a237,238
> LABEL_FATBOOT=*) label="
> labels=
For me this solves the problem, as in: the cloud-init enabled VM boots up, ds-identify finds "LABEL_
Further debug information as requested by @rharper on IRC:
- cloud-init.tar.gz (Debian 10 / ds-identify fail)
- Debian version:
debian@
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
- util-linux version:
debian@
blkid from util-linux 2.33.1 (libblkid 2.33.1, 09-Jan-2019)
- blkid output:
debian@
/dev/xvdb: SEC_TYPE="msdos" LABEL_FATBOOT=
- udevadm outout:
debian@
P: /devices/
N: xvdb
L: 0
S: disk/by-
E: DEVPATH=
E: DEVNAME=/dev/xvdb
E: DEVTYPE=disk
E: MAJOR=202
E: MINOR=16
E: SUBSYSTEM=block
E: USEC_INITIALIZE
E: ID_FS_UUID=
E: ID_FS_UUID_
E: ID_FS_VERSION=FAT16
E: ID_FS_TYPE=vfat
E: ID_FS_USAGE=
E: DEVLINKS=
E: TAGS=:systemd:
# Some experiments:
- This is interesting - dosfslabel incorrectly reports the label, while blkid (above) clearly shows the field is empty / not set:
debian@
cidata
- Here I am first setting the label with dosfslabel to see what happens and then check blkid again:
debian@
fatlabel: warning - lowercase labels might not work properly with DOS or Windows
debian@
/dev/xvdb: SEC_TYPE="msdos" LABEL_FATBOOT=
# Now blkid reports both labels
description: | updated |
description: | updated |
Changed in cloud-init: | |
importance: | Undecided → Medium |
status: | New → Triaged |
Debug info from the Debian 8 system where things are working (with the identical virtual disk as used with Debian 10 above):
debian@debian:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 8.2 (jessie)
Release: 8.2
Codename: jessie
debian@debian:~$ sudo blkid -V
blkid from util-linux 2.25.2 (libblkid 2.25.0, 24-Oct-2014)
debian@debian:~$ udevadm info --query=all /sys/class/ block/xvdb vbd-832/ block/xvdb label/cidata uuid/355A- 4FC2 /dev/disk/ by-label/ cidata /dev/disk/ by-uuid/ 355A-4FC2 /devices/ vbd-832/ block/xvdb ENC=cidata filesystem 355A-4FC2 ENC=355A- 4FC2 D=94333
P: /devices/
N: xvdb
S: disk/by-
S: disk/by-
E: DEVLINKS=
E: DEVNAME=/dev/xvdb
E: DEVPATH=
E: DEVTYPE=disk
E: ID_FS_LABEL=cidata
E: ID_FS_LABEL_
E: ID_FS_TYPE=vfat
E: ID_FS_USAGE=
E: ID_FS_UUID=
E: ID_FS_UUID_
E: ID_FS_VERSION=FAT16
E: MAJOR=202
E: MINOR=16
E: SUBSYSTEM=block
E: TAGS=:systemd:
E: USEC_INITIALIZE