Bug 1314436 - Driver disks do not work with liveimg
Driver disks do not work with liveimg
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: doc-Installation_Guide (Show other bugs)
7.2
Unspecified Unspecified
high Severity high
: rc
: ---
Assigned To: Clayton Spicer
ecs-bugs
: Documentation, Reopened
Depends On: 1361113
Blocks: ovirt-node-ng-platform
  Show dependency treegraph
 
Reported: 2016-03-03 10:33 EST by Ryan Barry
Modified: 2017-04-10 15:08 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-04-10 15:08:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ryan Barry 2016-03-03 10:33:44 EST
Description of problem:
If a driver disk is used with anaconda in conjunction with liveimg (instead of packages), the resulting driver RPM is not installed in the image.

How reproducible:
100%

Steps to Reproduce:
1. Generate a kickstart with liveimg
2. Install from that kickstart with dd

Actual results:
The driver RPM is not present on the installed image

Expected results:
The drivers are installed
Comment 2 David Shea 2016-03-03 10:42:35 EST
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.
Comment 3 RHEL Product and Program Management 2016-03-03 10:45:51 EST
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.
Comment 4 Ryan Barry 2016-03-03 10:53:31 EST
(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.
Comment 5 David Shea 2016-03-04 09:35:36 EST
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.
Comment 6 Fabian Deutsch 2016-03-07 08:39:43 EST
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.
Comment 7 David Shea 2016-03-07 09:18:41 EST
(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.
Comment 8 Ryan Barry 2016-03-08 11:32:18 EST
(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.
Comment 9 David Shea 2016-03-09 09:55:13 EST
(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.
Comment 10 Fabian Deutsch 2016-03-10 02:31:30 EST
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.

Note You need to log in before you can comment on or make changes to this bug.