Bug 1259596

Summary:	Client-side initramfs generation during deployment to i.e. include multipath related configuration
Product:	Red Hat Enterprise Linux 7	Reporter:	Fabian Deutsch <fdeutsch>
Component:	ostree	Assignee:	Colin Walters <walters>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.2	CC:	atodorov, bbreard, cwu, gangelop, jamills, lfriedma, rpalco, walters, ycui
Target Milestone:	rc	Keywords:	Extras
Target Release:	7.4
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:	Feature: The Atomic Host component `rpm-ostree` which is used for updates of the host has a new `initramfs` command. Reason: By default, Atomic Host uses a generic initramfs built on the server side. This is distinct from a yum-based Red Hat Enterprise Linux where the initramfs is generated per-installation. However, in some situations, additional configuration or content may need to be added. Result: Administrators of Atomic Host may use `rpm-ostree initramfs --enable` to run the underlying `dracut` program on the client machine (and all future updates).	Story Points:	---
Clone Of:
Clones:	1433501 (view as bug list)		Environment:
Last Closed:	2017-04-11 14:32:52 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1186913, 1399379, 1433501

Description Fabian Deutsch 2015-09-03 06:52:27 UTC

Description of problem:
Currently the initramfs used to boot Atomic is generated at tree build time.

The benefit of this approach is, that the initramfs is never touched, and thus we can be sure that it works for the customer, if it worked in testing.

The drawback is that some host- or site-specific configurations are not integrated into the initramfs during installation time.
The most obvious topic where this is highly visible is multipath.
The wwids and the exact multipath configuration must be part of the initramfs to ensure that the multipath configuration is setup correctly during the early boot.

This is most important for multipath devices which are used for booting. If an incorrect multipath configuration is used in initramfs, then different problems i.e. the aggregation of the multiple paths (of the device used for booting) into one logical multipath device can fail - something similar can happen if the multipath config inside the initramfs and outside are different.

To include host specific configurations in the initramfs the suggestion is to rebuild the initramfs during deployment.

The risk is that this creation will fail. Furthermore the initramfs will be different on each host.

Multipath served as an example here, there are possibly other components which will also benefit from per-host-configurations in the initramfs - but these have to be identified.

Comment 1 Alexander Todorov 2015-09-25 12:29:16 UTC

(In reply to Fabian Deutsch from comment #0)

> Multipath served as an example here, there are possibly other components
> which will also benefit from per-host-configurations in the initramfs - but
> these have to be identified.

Here's a very realistic example: customer uses a funky disk or NIC which needs external drivers (not included in RHEL by default). They can supply a DUD disk during installation but if initrd.img isn't rebuilt then the drivers will not be available after reboot and may lead to failing to find the root filesystem.

Comment 2 Fabian Deutsch 2015-09-25 12:31:10 UTC

A very good example. DUD support is also pending, including supporting it in anaconda in combination with atomic.

Comment 3 Colin Walters 2015-09-25 12:46:56 UTC

I'd say 3rd party kernel modules fall into the "rpm layerying" or SPC model, where we *would* generate a local initramfs.

Comment 4 Colin Walters 2015-09-25 12:47:27 UTC

See for example:
https://bugzilla.redhat.com/show_bug.cgi?id=1261647#c9

Comment 5 Colin Walters 2015-09-25 12:48:54 UTC

To elaborate, what I'm arguing is that we should try to differentiate between "configuration" and code (and I know this can get blurry).

The multipath thing is configuration.  Perhaps awkward and very nontrivial configuration, but still.

Kernel modules are code - and we want code to be tracked by RPM.

Comment 6 Fabian Deutsch 2015-09-25 12:52:51 UTC

(In reply to Colin Walters from comment #3)
> I'd say 3rd party kernel modules fall into the "rpm layerying" or SPC model,
> where we *would* generate a local initramfs.

I wasn't aware that a regenration is happening in that case.

(In reply to Colin Walters from comment #5)
> To elaborate, what I'm arguing is that we should try to differentiate
> between "configuration" and code (and I know this can get blurry).

Right, I agree on that separation.

Comment 11 Colin Walters 2017-01-24 17:58:27 UTC

https://github.com/projectatomic/rpm-ostree/pull/574

Comment 14 Colin Walters 2017-04-11 14:33:47 UTC

Upstream commit: https://github.com/projectatomic/rpm-ostree/commit/cac4522e5b00b9d316367f2b2bbae5be78c006f8

$ git describe --contains cac4522e5b00b9d316367f2b2bbae5be78c006f8
v2017.1~3