RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1314436 - Driver disks do not work with liveimg
Summary: Driver disks do not work with liveimg
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: doc-Installation_Guide
Version: 7.2
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Clayton Spicer
QA Contact: ecs-bugs
URL:
Whiteboard:
Depends On: 1361113
Blocks: ovirt-node-ng-platform
TreeView+ depends on / blocked
 
Reported: 2016-03-03 15:33 UTC by Ryan Barry
Modified: 2019-03-06 01:15 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-04-10 19:08:29 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Ryan Barry 2016-03-03 15:33:44 UTC
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 15:42:35 UTC
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 Program Management 2016-03-03 15:45:51 UTC
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Comment 4 Ryan Barry 2016-03-03 15:53:31 UTC
(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 14:35:36 UTC
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 13:39:43 UTC
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 14:18:41 UTC
(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 16:32:18 UTC
(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 14:55:13 UTC
(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 07:31:30 UTC
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.