Bug 1314436

liveimg does not use rpms, and anaconda is not involved in the boot process of live environments. Using driver disks with liveimg is not supported.

Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

(In reply to David Shea from comment #2)
> liveimg does not use rpms, and anaconda is not involved in the boot process
> of live environments. Using driver disks with liveimg is not supported.

Is this documented somewhere? It's not indicated in the kickstart documentation:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Installation_Guide/sect-kickstart-syntax.html

Does this also mean that driver disks do not work during the installer?

Anaconda supports liveimg as an install source instead of %packages, and if driver disks are not supported (either in the installer or by installing the packages on the filesystem before %post), a link to the appropriate documentation, a documentation update to reflect this, or an RFE to support this would be appreciated.

I feel like the nature of the payload, which as you say is "liveimg (instead of packages)" implies that packages will not be installed. Moving to docs so that can be clarified.

A driver disk will still be used during the install if the environment was booted from installer media (boot.iso, dvd, PXE, etc), regardless of the payload type. I thought that since this is about liveimg this may have also been about live media, in which case driver disks are not used since the anaconda dracut modules are not used. This may not be the case, however.

If a driver disk is used with a liveimg payload, the driver disk packages will not be included on the installed system. liveimg simply copies the contents of the payload to the target system, and it does not use packages.

I understand that the current driver disk implementation depends on the package payloads. However, driver disks also make sense in the other payloads, though I need to admit, that we can not directly assume that each other payload has the capability to install rpms.
But couldn't anaconda be optimistic about the payload being able to install rpms? Regardless of how the payload is being delivered?

Or: Could the payload provide a predefined script (i.e,. /usr/sbin/install-driver-disks, comparable to new-kernel-pkg) to handle the driver disks.
I just wonder if driver disks should be excluded from non-package payloads, or said different: If each non-package payload should implement it's on driver disk handler.

(In reply to Fabian Deutsch from comment #6)
> I understand that the current driver disk implementation depends on the
> package payloads. However, driver disks also make sense in the other
> payloads, though I need to admit, that we can not directly assume that each
> other payload has the capability to install rpms.
> But couldn't anaconda be optimistic about the payload being able to install
> rpms? Regardless of how the payload is being delivered?

No, that is not a safe assumption. Since liveimg can be used to create images without all of the usual infrastructure of a package-based Fedora/RHEL system, one easy way to save a couple hundred MB is to omit the rpm database.

And it's not safe to just unpack the files in an rpm, either. Even if it can be assumed that the liveimg payload includes all of the dependencies from the driver disk rpms that can not be checked, the scripts in the rpm will not be run.

> Or: Could the payload provide a predefined script (i.e,.
> /usr/sbin/install-driver-disks, comparable to new-kernel-pkg) to handle the
> driver disks.
> I just wonder if driver disks should be excluded from non-package payloads,
> or said different: If each non-package payload should implement it's on
> driver disk handler.

I do not think it would be a good idea to add additional rules and complexity to the simplest payload types so that they can accommodate a corner case of an uncommon feature that is not particularly well documented to begin with. If you need to modify the installed system in ways that cannot be included in the payload, use %post.

(In reply to David Shea from comment #7)
> No, that is not a safe assumption. Since liveimg can be used to create
> images without all of the usual infrastructure of a package-based
> Fedora/RHEL system, one easy way to save a couple hundred MB is to omit the
> rpm database.

Is this a supported use case? Omitting the rpmdb is an easy way to save space, but I'm not sure if anybody is currently doing this, or if non-rpm (debian, etc) images are supported payloads for anaconda. Certainly they should work technically, but I'm not sure what the current stance is if a bug were to be opened with such a payload.


> I do not think it would be a good idea to add additional rules and
> complexity to the simplest payload types so that they can accommodate a
> corner case of an uncommon feature that is not particularly well documented
> to begin with. If you need to modify the installed system in ways that
> cannot be included in the payload, use %post.

We can work around this in %post, and move over/handle the RPMs from OEMDRV, since that still exists. But we'd like to also have an interactive anaconda install which doesn't need to be kickstarted, which works great with the current liveimg implementation (it just leaves the appropriate spokes open for users to configure).

Driver disks work appropriately with interactive install with package payloads, and it would be jarring for users if this silently failed with liveimg payloads.

If an RFE for this will be denied, Anaconda should at least present a very clear warning to users who attach driver disks.

(In reply to Ryan Barry from comment #8)
> (In reply to David Shea from comment #7)
> > No, that is not a safe assumption. Since liveimg can be used to create
> > images without all of the usual infrastructure of a package-based
> > Fedora/RHEL system, one easy way to save a couple hundred MB is to omit the
> > rpm database.
> 
> Is this a supported use case? Omitting the rpmdb is an easy way to save
> space, but I'm not sure if anybody is currently doing this, or if non-rpm
> (debian, etc) images are supported payloads for anaconda. Certainly they
> should work technically, but I'm not sure what the current stance is if a
> bug were to be opened with such a payload.

Live install is not a supported use case. None of the install media for the various Red Hat Enterprise Linux variants include a live installer. Live images can be created using livemedia-creator, but the content of those images is up to the user. And since these are entirely custom payloads, the driver disk rpm could just be included in the kickstart passed to lmc. This would make more sense anyway, since that way the drivers could be included and used in the live environment.

That's interesting.

RHEV-H is delivered as an squashfs image created by RH, and we plan to use the liveimg installation method for deployment.

I've opened

Bug 1316392 - [RFE] Add test coverage for the liveimg installation method

to get at least minimal test coverage for this installation path.