New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cloud-config-url via PXE regression in 1632.2.1 #2342

Closed
ilianaw opened this Issue Feb 2, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@ilianaw

ilianaw commented Feb 2, 2018

Issue Report

Bug

Container Linux Version

$ cat /etc/os-release
NAME="Container Linux by CoreOS"
ID=coreos
VERSION=1632.2.1
VERSION_ID=1632.2.1
BUILD_ID=2018-02-01-2053
PRETTY_NAME="Container Linux by CoreOS 1632.2.1 (Ladybug)"
ANSI_COLOR="38;5;75"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://issues.coreos.com"
COREOS_BOARD="amd64-usr"

Environment

libvirt / KVM on CentOS 7; Container Linux is PXE booted with an older version of this documentation (https://coreos.com/os/docs/latest/booting-with-pxe.html) that used to recommend cloud-config instead of ignition.

$ cat /proc/cmdline 
rootflags=rw mount.usrflags=ro root=LABEL=/ console=ttyS0 cloud-config-url=http://169.254.169.254/latest/user-data

Expected Behavior

cloud-config is loaded from the cloud-config-url.

Actual Behavior

It is not:

Feb 02 19:44:01 hello systemd[1]: user-cloudinit-proc-cmdline.service: Job user-cloudinit-proc-cmdline.service/start failed with result 'dependency'.
Feb 02 19:44:01 hello systemd[1]: coreos-setup-environment.service: Job coreos-setup-environment.service/start failed with result 'dependency'.
Feb 02 19:44:01 hello systemd[1]: usr-share-oem.mount: Job usr-share-oem.mount/start failed with result 'dependency'.
Feb 02 19:44:01 hello systemd[1]: systemd-fsck@dev-disk-by\x2dlabel-OEM.service: Job systemd-fsck@dev-disk-by\x2dlabel-OEM.service/start failed with result 'dependency'.

Reproduction Steps

I am not entirely sure; I no longer appear to have the source code for my iPXE boot ROM, but PXE booting with the above kernel command line should reproduce this.

Other Information

@euank tells me that this is probably related to the fix for #2245.

I'm going to try to work around this by giving my virtual machines an empty partition with the label OEM.

@ilianaw

This comment has been minimized.

ilianaw commented Feb 2, 2018

Attaching a 16 MB ext4-formatted disk labeled OEM worked around the issue. This disk doesn't even get mounted at /usr/share/oem.

I also suspect I could use a systemd.mask= kernel command line argument, but I have no idea how I built the option ROM. :)

@bgilbert

This comment has been minimized.

Member

bgilbert commented Feb 2, 2018

  • user-cloudinit-proc-cmdline.service (and also, incidentally, system-config.target) Requires=coreos-setup-environment.service,
  • which RequiresMountsFor=/usr/share/oem,
  • which shouldn't start on PXE because of ConditionPathExists=!/usr/.noupdate, but now also Requires=systemd-fsck@dev-disk-by\x2dlabel-OEM.service,
  • which is pulled in unconditionally (because that's how systemd handles dependencies of conditional units) and fails when there's no OEM partition.

Thanks for the report. We'll get this fixed.

@bgilbert

This comment has been minimized.

Member

bgilbert commented Feb 4, 2018

This should be fixed in the next releases on all channels (alpha > 1675.0.1, beta > 1662.1.0, stable > 1632.2.1). Thanks again for reporting.

@bgilbert

This comment has been minimized.

Member

bgilbert commented Feb 15, 2018

Should be fixed in alpha 1688.0.0, beta 1662.2.0, and stable 1632.3.0, due shortly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment