yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #71375
[Bug 1598783] Re: Config drives created on RHEL/CentOS 7.1 can't be found
This bug is believed to be fixed in cloud-init in 18.1. If this is still
a problem for you, please make a comment and set the state back to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1598783
Title:
Config drives created on RHEL/CentOS 7.1 can't be found
Status in CirrOS:
Confirmed
Status in cloud-init:
Fix Released
Status in cloudbase-init:
In Progress
Bug description:
Depending on the exact version of dosfstools used when preparing a
config drive FS, it may not be detected by Cirron on VM boot. This is
due to the fact, that Cirros currently performs a case-sensitive
comparison of FS labels:
http://bazaar.launchpad.net/~cirros-
dev/cirros/trunk/view/head:/src/lib/cirros/shlib#L134
and mkfs.vfat from CentOS will create an uppercase label "CONFIG-2".
Apparently, dosfstools won't let you use lowercase labels on CentOS,
while it works fine on Ubuntu:
http://paste.openstack.org/show/507193/
All the descriptions of the config drive format mention "config-2",
not "CONFIG-2":
http://cloudinit.readthedocs.io/en/latest/topics/datasources.html
https://coreos.com/os/docs/latest/config-drive.html
http://docs.openstack.org/user-guide/cli_config_drive.html
Nothing is said about whether case-sensitive or -insensitive string
comparison should be used for comparing of FS labels.
Looks like FAT standard does not specify how labels should be treated,
but Windows (at least XP) stores those in upper-case:
"For FAT volumes, volume labels are stored as uppercase regardless of
whether they contain lowercase letters. NTFS volume labels retain and
display the case used when the label was created."
https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs
/en-us/label.mspx?mfr=true
E.g. in Debian this was considered to be a bug and was fixed:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714971;msg=2
It even was accepted to upstream:
https://github.com/dosfstools/dosfstools/commit/465dd8cf8f643bdd39a732e7d7f819a6abdf3d83
and made it to 3.0.22 release.
Related bug in MOS: https://bugs.launchpad.net/mos/+bug/1587960
To manage notifications about this bug go to:
https://bugs.launchpad.net/cirros/+bug/1598783/+subscriptions