Move Ignition-Dracut into Ignition #1039

Copy Ignition base/user configs from OEM to Ignition system dir

The "After=disk-uuid.service" in ignition-setup.service doesn't actually work because disk-uuid.service is templated. Instead, disk-uuid@.service should sequence itself Before units that access device nodes. Sequence disk-uuid@ Before ignition-setup, and remove "After=disk-uuid.service" from Ignition units.

dracut: correctly sequence disk-uuid@ before ignition-setup

The kernel will automatically bond it to the synthetic interface, so ensure networkd doesn't try to configure it separately.

dracut: ignore Azure SR-IOV VF interface

automated PR: update CoC and legalese

The current invocation is broken (should be $env{DEVLINKS}) and pointless, so drop it. The last arguments to the `mdadm --incremental` command are just aliases that can be used in /etc/mdadm.conf (see the "INCREMENTAL MODE" section of man 8 mdadm). We don't use /etc/mdadm.conf in the initramfs, so just drop it.

99start-root: drop DEVLINKS from mdadm invocation

Fixed upstream in systemd/systemd@e1c42e1.

dracut: drop obsolete comment

This reverts commit 61f8967.

Alter ignition-generator to only run ignition when coreos.first_boot is present on the command line, add a base Ignition config that removes coreos.first_boot from the grub config, add coreos.first_boot to the grub config in the instructions in README.txt

Also reformat ignition-quench.ign to be more readable

Only run on first boot, enable the disks stage

README: Note instructions are for classic systems

Added a few binaries and also a few modules.

It was there for compatibility with some older CL systems and isn't needed AFAICT for RH/Fedora. Migrate the remount-sysroot service to the ignition module as I do think that is still needed.

Tidying things up a bit

Otherwise, it's not obvious that this unit comes from ignition.

The actual `/sysroot` we want `ignition-files` to manage is not the physical root, but our deployment root. So we need to make sure it runs *after* `ostree-prepare-root.service`.

ignition-files.service: run after ostree-prepare-root.service

without ignition-disks we get a booting system. This is somehow related to the ordering with ignition and ostree mounting during the initramfs. Disable ignition-disks service for now.

no disks

This new service file adds a special file in `/run` and runs before `ostree-prepare-root.service` so that the latter mounts `/var` rather than relying on the OSTree generator post-switchroot. This also requires us to remount `/var` read-write so that Ignition can e.g. create new users.

Add ignition-ask-var-mount.service

This is another hack like the xen = ec2 one to get RHCOS ignition working in OpenStack for now. A lot of our infra and scripts currently interop well with OpenStack, so I'd like to unblock this to make it easier to hack on and test RHCOS overall.

ignition-generator: add hack for openstack support

On OSTree systems, we need to remount both `/sysroot` and `/sysroot/var` to read-write for Ignition. On classic systems though, we only need the former. Split out those two remounts into separate units and only run the `/sysroot/var` remount if it's not already read-write.

We now explicitly stamp images for their respective cloud providers so we no longer need to try to guess.

remount-sysroot: only remount on OSTree systems

Drop 'auto-detect' hacks in generator

There was an extensive discussion of this on IRC. The basic idea is we have a stamp file in `/boot`, same as CL does. However, we use a GRUB *variable* `$coreos_firstboot` which is hardcoded in the kernel arguments, but evaluates to the empty string if we're not in the first boot. This way we don't have to change the kernel arguments post-boot. We previously had a systemd "quench" unit as a hardcoded Ignition config here - I moved that to a regular installed unit that is part of the package.

Rework how we run Ignition on first boot

This makes ignition logs show up on ttyS0. Without this option, ignition logs only shows up on tty0.

Add Journald 'forward to kernel log buffer' option

It defaults to notice, which doesn't print out the "info" level information we want to get from ignition.

change the default level of messages send to kmsg

See ostreedev/ostree#1697 Just noticed this while investigating our services after the recent machine-id regression.

coreos-firstboot-complete: RemainAfterExit=yes

This drop some legacy/commented line for installing CL-specific udev rules. We'll likely grow some more bits to install into initramfs in the future, which should not be part of this ignition module.

dracut/ignition: remove CL-legacy udev references

If we do that then we get "double logs" on the console device because both kmsg and console output is getting dumped there.

journal: don't log to console AND kmsg

This adds all relevant bits to run the "disks" stage.

30ignition: add support for ignition-disks

Follow up to https://src.fedoraproject.org/rpms/ignition/pull-request/9

module-setup: Make mkfs.btrfs optional

Make it explicit that we need the `qemu_fw_cfg` kernel module in the initramfs. This works for Fedora right now before I think because we run dracut with `--no-host-only` at compose time. (It's the default if `initramfs-args` isn't in the manifest, as in FCOS, and in FAH we explicitly have it in the manifest). Closes: coreos#22

module-setup.sh: explicitly install qemu_fw_cfg

This is important for `Type=oneshot` services that may be depended upon by other services. See ostreedev/ostree#1697.

Mirror the same requirements as `ignition-files.service`. I.e. we don't strictly *require* networking, but if there is networking, we'd rather run after it so that we can pull down the config. See also coreos#17. (Anyway, I think we want `network-online.target` here instead of `network.target` but I haven't tested that).

Prep misc patches

We previously messed around with changing the files service to adapt to `ostree-prepare-root.service` running so late in the boot process. Now that OSTree runs at more semantically appropriate times, we can restore ordering here so that it runs right after `initrd-root-fs.target`. This also undoes the hacking around in `ignition-generator` to get the services pulled in by `initrd-switch-root.service` instead of the more appropriate principal target of the initrd (`initrd.target`). Another nice thing about this is that we drop the explicit dependency between `ostree-prepare-root.service` and `ignition-files` since they're now synchronized through `initrd-root-fs.target`. Closes: coreos#20

These are no longer needed now that we explicitly pass `rw` on the kernel command-line. For more information, see: systemd/systemd#8268 openshift/os#199

ignition: run files stage at original CL ordering

Otherwise we'll error out on kernels which have the functionality builtin. This was tested on FCOS (which uses `m`) and RHCOS (which uses `y`). We need to check `/usr/lib/ostree-boot` since on el7 that's the only place where the config is.

30ignition: only instmods if module available

to make options more distribution neutral. Update dracut/README.txt to take into account recent changes. Resolves: coreos#24

Rename `coreos.firstboot` kernel cmdline arg to `ignition.firstboot`

Prep for ostreedev/ostree#1265

ignition-firstboot-complete.service: Remount /boot rw

* Remount /sysroot rw Some Linux Distributions don't pass a rw option on the kernel commandline and thus mount the root filesystem ro by default. In this case, remount /sysroot to rw (issue coreos/ignition-dracut#37)

It's good to provide some history so that we can know when we can drop these changes.

journal: add clarifying comment for context

Add ability to parse config.ign file on boot

See coreos/ignition-dracut#32 and coreos#668.

This adds support for platform base/user configs and also user provided base/user configs that were embedded in the /boot/ partition. Fixes: coreos#32

This allows you to query the status of it afterwards.

Otherwise ignition-setup.service won't work :)

Mount boot partition so that we can see if there are any embedded ignition files in /boot/.

- use config.ign for user facing stuff - only support copying config.ign -> user.ign - use /usr/lib/ignition/platform/${OEM_ID} for platforms - only support copying base.ign -> base.ign for platforms

This will guarantee the /boot mount won't outlast the unit.

This makes it so that disks and files stages more explicitly depend on igntion-setup.service similar to the way it is done in CL today.

copy_file_if_exists is more descriptive of what is going on.

Systemd MountFlags=slave will take care of it for us so let's not risk the error inside the script.

support platform configs and user configs in /boot

With coreos#735 merged, we need to fix our service units to use `--platform` here. Also just do the equivalent thing here and start to move away from the oem terminology. Crucially though, we still look for `coreos.oem.id` until downstreams have adapted (notably coreos-assembler). Closes: coreos#31

dracut: adapt for s/oem/platform in Ignition

We're past the MVP phase now. Let's reflect that in our codebase by dropping all the telltale signs of quick hacks and experimentations. This makes the tree nicer to hack on as well. Remember, all your code are belong to Git. We can always revive things as needed as we get around to supporting Packet/DO, etc... Though those units will need to be tweaked anyway. Closes: coreos#33

dracut/30ignition: general hack cleanups

…ks out of box on all arches

module-setup.sh: Simplify the qemu_fw_cfg kernel module check

On UEFI systems the grub $root might be the /boot/efi/ partition and not the /boot/ partition so let's search for the partition with the `boot` label and then detect the file directly. Fixes coreos#51

grub: find boot partition and use it directly

On UEFI systems the grub $root might be the /boot/efi/ partition and not the /boot/ partition so let's search for the partition with the `boot` label and then detect the file directly. Fixes coreos#51 (cherry picked from commit 552edb5)

spec2x: grub: find boot partition and use it directly

It's true it's only pulled into the transaction right now by the other services. But just on principle, let's not even write it if we know we're not going to use it.

dracut/30ignition: Only write ignition-setup.service on first boot

There's no need to generate it dynamically, so let's just split it out to be more explicit and easier to hack on.

From the comment block of the unit: This target is reached when Ignition finishes running. Note that it gets activated *only* on first boot (or if ignition.firstboot=1 is provided). Thus, it is also an API for units to use so that they are activated only on first boot. Simply add a link under ignition-complete.target.requires in the initrd. Thus, units themselves don't need to add explicit `Requires=`; the canonical way to get pulled into the transaction is through `ignition-complete.target`. This will also be used by the upcoming CoreOS units that are required for separate `/var` support.

Add ignition-complete.target

The ignition binary is not intended to be run by users or in the real root filesystem, and thus should never be in PATH. Expect distros to install it into the dracut module directory instead.

Today coreos-assembler is hardcoding the initramfs networking kargs to do DHCP; this is problematic for e.g. bare metal where one often wants to configure static networking. Let's only enable initramfs networking if we're doing Ignition.

02_ignition_firstboot: Enable networking if Ignition will run

dracut/30ignition: expect ignition binary in module directory

Drop the outdated distro-specific instructions and instead guide folks perusing the repo towards FCOS artifacts and coreos-assembler for how to play with it. Closes: coreos#62

README.md: update documentation

This allows us to set network kcmdline args by setting the ignition_network_kcmdline variable inside the ignition.firstboot file that resides on the /boot/ filesystem and triggers ignition run on boot. This functionality will allow the coreos-installer to promote static networking arguments that were used during the installer run to the first boot of the real system. After that they are no longer needed as ignition can configure networking as requested by the user.

grub: support overriding network kcmdline args

coreos-assembler is going to pass both keys during the transition period, so we don't need to check them both here.

The 30disk-uuid module never made it over from bootengine, and it's not clear that we want it. Don't break boot if coreos.randomize_disk_guid is requested.

Right now, we enable our services by adding a link in `initrd.target.requires`. However, it seems like systemd doesn't necessarily fail the boot even if `initrd.target` fails. That unit has: OnFailure=emergency.target OnFailureJobMode=replace-irreversibly But looking at the logs, it seems like that can get overridden by the `systemctl isolate initrd-switch-root.target` call that `initrd-cleanup.service` does. Let's just be really explicit here and tell systemd we want to immediately switch to `emergency.target` if any of our units fail.

Add support for the new Ignition `mount` and `umount` stages. The `mount` stage runs *after* the `disks` stage and `initrd-root-fs.target`, since we need to be able to mount under `/sysroot`, but *before* the `files` stage, which will of course drop files under those mounts. Combined with coreos/fedora-coreos-config#70, this allows us to drop all OSTree-specific bits and no longer rely on `ostree-prepare-root.service` to mount `/var` for us.

30ignition: minor cleanups

This module is the integration point between Ignition and Fedora CoreOS. Notably, we add two new systemd services in the initrd which mesh with Ignition's own systemd services: 1. `coreos-mount-var.service`, which finds the `/var` stateroot bind mount and mounts it under `/sysroot/var` before `ignition-mount` potentially adds more mounts underneath (or even shadowing `/var` itself). 2. `coreos-populate-var.service`, which sets up `/var` on first boot using `systemd-tmpfiles` before `ignition-files` runs. NOTE: this is a temporary holding place to make packaging easier. Eventually, we will move this module to the FCOS overlay: coreos/fedora-coreos-config#70

Add mount and umount service units

The Ignition openstack platform needs to be able to read from a virtual cdrom and needs to include the uedv rules to create the symlink. Add those rules.

module_setup: include cdrom rules for openstack

I think this was the missing piece in the issues described in coreos#61. Essentially, `ignition-complete.target` wasn't explicitly ordered wrt to `initrd.target`, so its completion was racing against system's `isolate` to `initrd-switch-root.target`. Ordering ourselves before `initrd.target` (which is also the unit that pulls us in through `initrd.target.requires`) ensures that the target can only be reached successfully if we're successful. And if our target fails, then we immediately trigger `emergency.target`.

This is already the case from the fact that it runs before the files stage, but just to be explicit, let's make sure all of Ignition's own systemd units have `Before=ignition-complete.target` so it's clear that all Ignition units must successfully complete for that target to be considered reached.

This is mostly cosmetic, but it helps make it easy to see that all the Ignition units follow the same standard header.

…rget The way `isolate` works is interesting. When systemd does `systemctl isolate initrd-switch-root.target`, it does two things: (1) enqueue stop jobs for all the services not required for the new target, and (2) enqueue start jobs for all the services required for the new target. However, there is no default ordering between the stop jobs and start jobs. One would think that systemd by default would first stop all the services, and only then starts the new services. That is not the case (see [1] and [2]). We need to explicitly tell systemd that we want our services to be stopped first before starting the new services. The way to do this is to add an explicit `Before=initrd-switch-root.target` in the units (see [1]). Otherwise, the `ExecStop` in `coreos-mount-var.service` and `ignition-mount.service` may not run before the switch root. (Note systemd does serialize its state across the reexec, but it seems like it doesn't correctly resume the "stop" jobs, presumably because it can't access the systemd units anymore. Regardless, we definitely want to umount everything before the switchroot anyway). Closes: coreos#70 [1] https://systemd-devel.freedesktop.narkive.com/wb1UNand [2] systemd/systemd#3436

We need these to make sure that failures during `ExecStop=` result in failing the boot. For details, see discussions in: coreos/ignition-dracut#72

Clean up switching to emergency on error and fix ExecStop= race condition

We shouldn't actually need to do `OnFailure=emergency.target` in `ignition-complete.service` here. Our unit is already a requirement of `initrd.target`, and so once we fail, `initrd.target` should fail, which in turn should trigger *its* `OnFailure=emergency.target`. However, this doesn't work in f29/el8: https://bugzilla.redhat.com/show_bug.cgi?id=1696796 Add a comment about that. See also: coreos/ignition-dracut#61

dracut/30ignition: link to RHBZ in ignition-complete

Now that things are calmer, let's finish what we started and completely excise the CoreOS-specific services from this repo.

If Ignition fails, instead of immediately dropping to an emergency shell, output a message indicating that Ignition failed and point to ignition-validate. Offer to drop to an emergency shell if the user presses Enter. If the user doesn't respond in 5 minutes, reboot to try again. While waiting for the timeout, keep updating the prompt with the time remaining until reboot. Brought forward from the `99emergency-timeout` dracut module present in Container Linux, with minor modifications: https://github.com/coreos/bootengine/tree/c691205c0046e3828a8536d553aea7307ca3abee/dracut/99emergency-timeout Closes: coreos#35

dracut: add 99emergency-timeout

Now that FCOS no longer regenerates GRUB2 configs, this logic was moved to the static one in coreos-assembler: coreos/coreos-assembler#616

Require that we scramble the guid and fix the gpt header before running ignition.

randomize the disk guid and fix the gpt header on boot

Split ignition-setup into two units/scripts. This allows other distros to override how we fetch user configs without changing how we fetch the base config.

ignition: split ignition-setup into base and user

Given that this isn't causing errors there's probably something else pulling it in by the correct name, but we ought to include it here as well for clarity's sake.

dracut/30ignition: fix typo in module_setup

The correct path is /dev/disk/by-label/root. Signed-off-by: Tuan Hoang <tmhoang@linux.ibm.com>

ignition: fix correct device path when randomizing UUID

ignition-dracut doesn't use it.

update-bootengine: drop file

Add ignition-diskful.target, containing units that expect a writable boot disk. Enable it from the generator unless there's a command "is-live-image" which returns 0.

In live boots there's no /boot partition with a flag file to remove.

Conditionalize units which require a boot disk

Minor cleanup; should have no functional consequences.

Minor cleanup, with no intended functional change.

Allow the user to append a custom initrd containing /config.ign, and have ignition-setup-user copy it into place. This means ignition-setup-user.service needs to Require the boot device only on diskful boots, so we need to generate that dependency in ignition-generator.

It was being ignored.

On live images, read config.ign from custom initrd

See https://github.com/cgwalters/build-api With this for example, we can just have the Fedora spec file do `make install DESTDIR=$RPM_BUILD_ROOT` just like everything else; helping to ensure that as much logic as possible remains upstream. Mainly I want this for hacking so I can just `make install DESTDIR=/srv/walters/fcos/overrides/rootfs` without building an RPM or copying files manually.

Omitting this can cause the unit to be executed multiple times if it's a dependency of another unit (as these are). See ostreedev/ostree#1697 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750683

Add RemainAfterExit=yes to systemd units of Type=oneshot

Ensure dependencies of a target are sequenced Before the target so failures correctly propagate to the target.

Failures are correctly propagating to the OnFailure handler of ignition-complete.target.

This invokes the new `fetch` stage which does just that - fetch the Ignition config into `/run/ignition.json` and nothing else. Prep for adding support for redeploying the rootfs, which is an expensive process, so we only want to do it if the fetched Ignition config is replacing the `rootfs`.

dracut: Add an ignition-fetch.service

Overriding initrd.target to OnFailureJobMode=isolate avoids the problem. I don't think we actually want to do that, and the workaround is localized to one unit now, so let's just update the comment.

30ignition: Failure handling improvements

Make sure to run before the file system checks, as sgdisk will trigger udev events, potentially resulting in race conditions due to disappearing devices. Executing earlier will avoid this (and hopefully similar) problems. Fixes coreos#114.

Run ignition-disks earlier to avoid race condition

See: openshift/installer#2554 Basically the OpenShift installer on vSphere injects a service which reboots the first time, but I believe this could easily race with `ignition-firstboot-complete`. Let's mark the boot complete much earlier.

ignition-firstboot-complete.service: Run as part of basic.target

This is needed for Fedora CoreOS work on reprovisioning the rootfs. We tried to split out a systemd unit to handle mounting the root in this commit: coreos/fedora-coreos-config@a6fe374 with `ignition-ostree-mount-sysroot.service` but the problem is that needs to have different dependencies/ordering if we're doing the "Ignition boot" versus a "subsequent" boot. Add a new target that's queued up if we detect we're doing a "subsequent" boot.

lsblk doesn't have PTUUID in the version on RHEL 8, but we can get it from blkid.

coreos-gpt-setup: workaround old lsblk not having PTUUID

zipl records need to be updated, because ignition.firstboot is burned into target disk during coreos-installer As a short-term solution for: coreos/ignition-dracut#84 Depends on: ibm-s390-linux/s390-tools#71 ibm-s390-linux/s390-tools#74 Related: coreos/coreos-installer#61 coreos/coreos-assembler#780

We don't actually need write access to `/boot` here to pull out any baked Ignition config. Just mount it read-only. This also helps in the case where any other service is concurrently also mounting `/boot`: trying to mount a device as read-write that's already mounted read-only elsewhere will fail. I hit this when playing with FIPS mode, which does this: https://github.com/dracutdevs/dracut/blob/718aefda1374c7b6c3790b08cae27fd6bde505af/modules.d/01fips/fips.sh#L49

30ignition/ignition-setup-user: mount /boot partition ro

This is required by the new relabeling code in Ignition: coreos#846 (This is another good example of why merging this repo into coreos/ignition would be nicer I think.)

I noticed that several of our units appeared to run twice, including `ignition-files.service` (!) and `ignition-ostree-mount-firstboot-sysroot.service`. [Later investigation revealed this was actually a double-logging issue.] Looking deeper into this, I discovered a bit of the initrd that I didn't even know existed, which is `initrd-parse-etc.service` that actually runs `ExecStart=-/usr/bin/systemctl --no-block start initrd-fs.target` *post* switch root, after services that are part of that target have already run (and then been shut down). This adds a big wrinkle to my understanding of system bootup. Then I noticed that `initrd-fs.target` has: `ConditionPathExists=/etc/initrd-release` which will be false post-switchroot. The semantics here are...strange. It seems like the goal is to ensure that the rootfs is definitely still mounted, perhaps in very complex rootfs scenarios? In our case it will still be mounted, we definitely don't want to rerun any of our Ignition units. [We discovered the units aren't actually being rerun, but this still seems like a best practice]

Add ConditionPathExists=/etc/initrd-release to targets

This is standard practice for units that are only meant to run in the initrd. It matches what e.g. `systemd` does for its initrd units. See also: coreos/ignition-dracut#140. I also snuck in `Documentation=` lines in there.

Make it easier to understand what the branches are and how they relate to FCOS/RHCOS.

To support coreos#865 Reported-by: XiaoMeiZheng <xmzheng@cn.ibm.com>

setfiles is only required on systems using SELinux.

grub: drop 02_ignition_firstboot

`make install` was failing now that the grub bits are gone.

Makefile: Remove grub/ install bits

@jlebon

This target is a combination of `ignition-subsequent.target` and `ignition-diskful.target` - units here should only run when we have a boot disk and *aren't* doing the first boot. This came out of discussion in coreos/fedora-coreos-config#271 Will be used by FCOS. Suggested-by: @jlebon

This is the first repo that we hook up to the new CoreOS CI interface. And it's sorely needed too, since patches here can easily result in broken boots.

Dracut pulling in several binaries as dependencies which have long been replaced by native implementations or other mechanisms.

The Ignition configuration supports quite a few features, from setting the user password over adding systemd services to creating partitions. For a lot of these features external helper applications are called. However not all of these configuration options are available or make sense on all systems - the current code for example lists mkfs.btrfs as an optional dependency, but mkfs.ext4 is declared as mandatory. This is not consistent, so only add those dependencies as mandatory which are required for Ignition to start / process an empty configuration file. All the other applications are declared as optional. If the Ignition configuration is using a feature where the helper application is not installed in the initrd it will boil out with an error.

Dracut dependency cleanup

This is a forward port of coreos-teardown-initramfs-network.service from the spec2x branch [1] (used for RHEL CoreOS). When moving to NM in the initrd [2] we decided that we also needed a mechanism to take down the networking between the initramfs and the real root. While we would like to use NetworkManager's logic to do this operation in the future it's currently not easily achieved because NetworkManager is not running persistently in the initramfs [3]. [1] coreos/ignition-dracut#78 [2] coreos/fedora-coreos-tracker#394 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1814038

This will make it easier for us to add a bit more code into this file.

…g if desired The policy here is: - If a networking configuration was provided before this point (most likely via Ignition) and exists in the real root then we do nothing and don't propagate any initramfs networking. - If a user did not provide any networking configuration then we'll propagate the initramfs networking configuration into the real root. See coreos/fedora-coreos-tracker#394 (comment)

Remove the removal of the `/tmp/net.$1.did-setup` (used by network-legacy dracut module) and start removing files under /run/NetworkManager/ instead.

down_teams() is a placeholder for now to remind us that teams do exist and need to be considered. If we find things that need to be done then we'll add actions to do in the down_teams() function in the future.

On recommendation from the NM team let's take down routes as well.

On recommendation from the NM team let's try to delete the device first and if that doesn't work then set it to down and flush any associated addresses. Deleting virtual devices (bonds, teams, bridges, ip-tunnels, etc) will clean up any associated kernel resources, so this makes the logic for bringing down these devices easier. A real device can't be deleted so that will fail and we'll fallback to setting it down and flushing addresses.

Since we have ignition-complete.target we don't need to use the generator to enable the unit.

add coreos-teardown-initramfs-network.service

Required by coreos-teardown-initramfs-network.service

Debugging failures in the initrd is annoying; this code looks for a virtio-serial port named `com.coreos.ignition.journal`, and runs as part of `emergency.target`. I plan to change mantle to set up this port by default, so if something fails in the initramfs we'll at least reliably get the journal in a sane parsable format. This is a special targeted subset of coreos#585

This isn't needed because the meat of this unit runs in the ExecStop.

…n units We want to run the teardown after all other Ignition stages have run because some platforms (like Packet) do remote status reporting for each Ignition stage. Since we are tearing down the networking using an ExecStop we need to make sure we run the ExecStop *after* any other ignition*.service unit's ExecStop. The only other one right now is ignition-mount that has an ExecStop for doing an unmount. Since the ordering for ExecStop is the opposite of ExecStart we need to use `Before=ignition-mount.service`. Partial fix for coreos/fedora-coreos-tracker#440 This would most likely not be necessary if Ignition cached an empty result: coreos#950

coreos-teardown-initramfs-network: order ExecStop after other ignition units

Add ignition-virtio-dump.service

The files in the real root ended up with unlabled_t file context. I'm suprised we didn't see any issues with this before. Let's fix it now.

Not skipping it means that we get an extra error message in our output during bootup. Let's skip it.

…for RHCOS For RHCOS we still support ifcfg files so let's consider the ifcfg directory (/sysroot/etc/sysconfig/network-scripts/) when checking to see if a user has provided networking configuration via Ignition.

Add coreos.no_persist_ip to allow for explicitly disabling the network config propagation. This is supported on the spec2x branch of ignition-dracut (i.e. for RHCOS) right now so we might as well have it in the master branch so we can keep the maintenance burden lower. Note that this adds two new functions load_dracut_libs() and dracut_func(). We needed to create these new functions in order to wrap in set +/- euo pipefail because dracut was written with set -eu in mind and there are unset variables and commands that fail in a lot of places.

This is a forward port of 1f8184e (coreos#156). If the admin specified a hostname in the ip= karg static networking config and no hostname was specified via Ignition then we'll make sure the hostname from the ip= karg gets applied to the real root (persistently). Ideally in the future there will be better support for this in NetworkManager itself as the `network-legacy` dracut module did at least provide more support for setting the hostname via ip= kargs than `network-manager` currently does. The discussion about this problem is in [1]. The fix for that will most likely implicate changes to the propagation code introduced here. Fixes: coreos/fedora-coreos-tracker#466 [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/419

…mprovements coreos-teardown-initramfs-network: propagate hostname, support coreos.no_persist_ip

Outputting stdout and stderr to /dev/kmsg is the only option for logging for generators for now. Let's start using it so we can at least get some messages if we ever have problems with one of our generators.

dracut: add logging to systemd generator

If another unit failed (like ignition-fetch.service) then don't run the ExecStop when isolating to emergency.target. We can do this by setting IgnoreOnIsolate=true. Otherwise you end up with errors like the following in the logs, which can lead someone investigating a problem in the wrong direction. ``` Stopping Tear down initramfs networking... info: taking down network device: eth0 RTNETLINK answers: Operation not supported info: flushing all routing info: no initramfs hostname information to propagate ls: cannot access '/sysroot/etc/NetworkManager/system-connections/': No such file or directory ls: cannot access '/sysroot/etc/sysconfig/network-scripts/': No such file or directory info: no networking config is defined in the real root info: propagating initramfs networking config to the real root cp: cannot create regular file '/sysroot/etc/NetworkManager/system-connections/': No such file or directory ```

…n-emergency-target coreos-teardown-initramfs-network: don't run when emergency.target

If the config is invalid, the failure will show up here.

Line-wrap to 80 characters and add some line breaks.

The original intent here was that on arches where `fw_cfg` is available, then we definitely want to make sure that either it's built into the kernel or if a module, added to the initrd. However, this check has been watered down now to to the point where it's not that useful. In coreos/ignition-dracut#176, there's a reasonable request to support not having the `qemu_fw_cfg` module installed at all even if the architecture would support it. IMO, I think we should just drop this whole logic entirely. The `qemu` module (which we depend on) already does an `instmods qemu_fw_cfg` (without `-c`), and qemu testing is the backbone of our CI testing. So realistically, we would notice very fast if `fw_cfg` support in the initrd went missing. Closes: coreos#176

99emergency-timeout: improvements to failure message

In Fedora CoreOS we have a ton of stuff going on the initramfs; our custom mount units, resizing the rootfs etc. Change this to dump all failed services, but special case Ignition services to note that something may be wrong with the config.

Rename coreos-teardown-initramfs-network.* to coreos-teardown-initramfs.* and add function to propigating automatic configuration through to boot. Signed-off-by: Ben Howard <ben.howard@redhat.com>

coreos-teardown-initramfs: propagate the automatic multipath conf

First, put the order of the stages in every unit file. Then, make sure to include both the appropriate `After=` and `Before=` in accordance with the unit's place in the chain. There's redundancy there, but it makes it really obvious and explicit how they go together.

This is required because the unit needs read-only access to `/boot` in order to extract any baked in user-provided config and multipathd might claim ownership. See: coreos/ignition-dracut#183

In systemd v245, which is in f32, the `OnFailure=` directive in target units stopped working. This seems to be by design though: systemd/systemd#14142 If target units were never meant to handle this, this might be why we've had issues like boot loops on failure in the past (see coreos#115). Anyway, let's just pepper our services with the directive instead.

Needed for coreos#991.

30ignition: add wipefs to the initramfs

This unit must the first to run when the disk holding the root partition becomes available. To avoid relying on the name of the root partition which is different between RHCOS LUKS setup and current FCOS setup, we wait for the partition labeled 'boot' to become available. This is reliable as we don't have any plan to support re-provisioning/re-writing the /boot partition, This is the only unit where it is safe to wait only on a specific disk label as this will call udevadm settle after the GPT setup. Units that requires the boot and root partitions to be available should order themselves after this unit.

This is symmetrical to coreos#994.

Make use of the new `fetch-offline` stage: coreos#979 We run this between the `setup` and `fetch` stages (the latter possibly being skipped if networking is not required). We hit the same issue here that `coreos-copy-firstboot-network.service` hit, which is that we can't run before the `cmdline` hook because that runs *before* udev, but we want the `by-*` symlinks for `ignition-setup-user.service`. The hack we do here is to rerun the NM cmdline hook in case ignition dropped a snippet in `/etc/cmdline.d`. As mentioned in coreos/fedora-coreos-config#346, we'll be able to do this more cleanly once we run NM as a systemd service directly.

No reason to leak this outside the function.

This tweaks permissions when installing units in order to avoid the following warning at boot time: ``` systemd[1]: Configuration file /usr/lib/systemd/system/ignition-firstboot-complete.service is marked executable. Please remove executable permission bits. Proceeding anyway. ```

make: install systemd unit as non-executable

Adds LUKS related binaries to dracut & a udev rule to discover unformatted encrypted devices.

*: add LUKS

Mistakenly the udev rule is using `:=` which is already being assumed by udev to mean `=`. Change it to stop emitting a warning.

ignition-check-neednet.sh knows too much about distro-level networking configuration. In addition, other things in the initramfs might want to conditionally enable networking, and they'd currently need to reimplement ignition-check-neednet.sh to do so. Instead, let the distro provide its own unit that checks for /run/ignition/neednet. That unit can use dependencies to sequence ignition-fetch-offline.service correctly for its own needs.

Move conditional network startup out of ignition-dracut

The CoreOS specific modules have been moved to https://github.com/coreos/fedora-coreos-config.

Commits on Nov 18, 2017

dracut: fix comment

bgilbert committed Nov 18, 2017

Configuration menu

View commit details

Copy full SHA for 127bd66

Browse repository at this point

Copy the full SHA

127bd66 View commit details

Browse the repository at this point in the history

Move Ignition-Dracut into Ignition #1039

Move Ignition-Dracut into Ignition #1039

Commits on Nov 18, 2017

Commits on Dec 3, 2017

Commits on Dec 6, 2017

Commits on Dec 12, 2017

Commits on Dec 19, 2017

Commits on Dec 26, 2017

Commits on Jan 4, 2018

Commits on Jan 9, 2018

Commits on Jan 10, 2018

Commits on Jan 23, 2018

Commits on Mar 27, 2018

Commits on Apr 5, 2018

Commits on Apr 6, 2018

Commits on Jun 1, 2018

Commits on Jun 5, 2018

Commits on Jun 7, 2018

Commits on Jun 13, 2018

Commits on Jun 18, 2018

Commits on Jun 29, 2018

Commits on Jul 20, 2018

Commits on Jul 21, 2018

Commits on Aug 17, 2018

Commits on Aug 28, 2018

Commits on Aug 29, 2018

Commits on Sep 3, 2018

Commits on Sep 4, 2018

Commits on Sep 20, 2018

Commits on Sep 21, 2018

Commits on Sep 25, 2018

Commits on Oct 12, 2018

Commits on Oct 13, 2018

Commits on Oct 16, 2018

Commits on Oct 18, 2018

Commits on Oct 19, 2018

Commits on Oct 24, 2018

Commits on Oct 25, 2018

Commits on Nov 20, 2018

Commits on Jan 3, 2019

Commits on Jan 9, 2019

Commits on Jan 25, 2019

Commits on Feb 4, 2019

Commits on Feb 5, 2019

Commits on Feb 8, 2019

Commits on Feb 14, 2019

Commits on Feb 15, 2019

Commits on Feb 26, 2019

Commits on Feb 27, 2019

Commits on Feb 28, 2019

Commits on Mar 1, 2019

Commits on Mar 4, 2019

Commits on Mar 5, 2019

Commits on Mar 6, 2019

Commits on Mar 7, 2019

Commits on Mar 14, 2019

Commits on Mar 16, 2019

Commits on Mar 18, 2019

Commits on Mar 20, 2019

Commits on Mar 22, 2019

Commits on Mar 25, 2019

Commits on Mar 26, 2019

Commits on Apr 3, 2019

Commits on Apr 4, 2019

Commits on Apr 5, 2019

Commits on May 3, 2019

Commits on Jun 14, 2019

Commits on Jun 25, 2019

Commits on Jul 16, 2019

Commits on Aug 5, 2019

Commits on Aug 6, 2019

Commits on Aug 21, 2019

Commits on Aug 22, 2019

Commits on Aug 29, 2019

Commits on Aug 30, 2019

Commits on Sep 10, 2019

Commits on Sep 16, 2019

Commits on Sep 18, 2019

Commits on Sep 23, 2019

Commits on Sep 24, 2019