Red Hat Bugzilla – Bug 888307
Inserting an install DVD does not automatically add the DVD repo to running gnome3 installation
Last modified: 2016-09-22 09:06:43 EDT
Description of problem:
Inserting a f18 TC3 DVD does not automatically add the DVD repo to running gnome3 TC3 installation
Does not seem to work anymore
Version-Release number of selected component (if applicable):
Steps to Reproduce:
be able to yum install from DVD repo
> "Does any of the package management applications (GUI or command-line)
> support installing stuff from the official DVD media without requiring the
> user creating repo files?"
> Yes, PackageKit does. See:
> Basically you insert the DVD with PackageKit open and it automatically
> mounts the disk, grabs the media repo off the disk, and adds it to the list
> of sources. This was added to Fedora in *2009*. If you find the support no
> longer working, please file a bug under the PackageKit package.
I just tested this and could not get it to work in a fedora18 TC3 DVD Gnome3 VirtualBox install - Inserting the DVD and removing the network adapter with the VirtualBox application running (DVD selected in VirtualBox) did not let me use the repo on the DVD with a yum install command,
I've found (testing on F17) that if I create a local.repo file in /etc/yum.repos.d/ with the contents
I can then use the DVD as a local repo (disabling all other repos to avoid downloading updated packages) with a command such as
yum --disablerepo=\* --enablerepo=local install XXXXXX
I never use PackageKit so don't know if it can be made to work with that.
Running gpk-application, I note that when checking or unchecking repos in System/Software Sources, it immediately writes the change into the corresponding .repo file (so the "enabled=X" line changes). I think it would be better to not do that, so one could easily change the selected repos without having to change the defaults back again. To do with gpk-application what can be done with yum, --disablerepo, and --enablerepo, it's necessary to write down a list of the enabled repos, then check local, uncheck all other repos, use the DVD, then set all the repos back to their original settings.
Yumex appears to work well with enabling and disabling repos - the changes are temporary. It is also on the 18 Final TC3 DVD (although not on the F17 DVD).
I was going to file a bug against gnome-packagekit regarding its making permanent changes to enabled repos, but after looking at the long list of existing bugs, I think the best bet is to use command-line yum, or to install yumex from the DVD and then use that for a GUI if necessary.
One obvious point of failure here is that we don't use gpk-update-icon any more. Update checking is now part of Shell's responsibilities, I believe, and it may well not do this fiddle with media repos, if nothing else because it's very Fedora-specific.
So the initial bug for this was https://bugzilla.redhat.com/show_bug.cgi?id=591534 .
I believe it regressed when gpk-update-icon functionality was migrated into gnome-settings-daemon.
Here's the commit that took it out of gnome-packagekit:
and here's the commit that put it into gnome-settings-daemon:
if you look at what got took out of gnome-packagekit there's the function gpk_check_update_mount_added_cb , which seems to do the work of this feature. If you look at what got put into g-s-d, it seems to have disappeared: nothing in that code references 'media' or 'mount', the obvious search strings I checked for.
Richard, can you comment? I tried looking for discussion of this in the GNOME ML archives, but couldn't really find anything much, it's hard to search. Is this not considered appropriate for a generic upstream component like g-s-d and rather something that should be done by some kind of plugin, maybe?
Hmm, actually, now I look at it, looks like the function is in plugins/updates/gsd-updates-manager.c in gnome-settings-daemon. Digging deeper.
Well, my code fu isn't totally up to it, but I _think_ it seems like the code no longer tries to add hotplugged mounts as general-purpose repos, but only checks them for updates. Looking at the code of the mount_added_cb function in gsd-updates-manager.c it really just checks mounts to see if they're repos, and then checks for updates if they are, but that's all it does. It doesn't seem to try and write out a yum config or anything. It just uses them as possible update sources. I'm not sure if even that much is working (offline updates may be screwing with it), but it's clearly less than the original plan.
The procedure I described in comment 1 doesn't seem to work for me in actually installing packages, only for viewing the repo (though I thought I'd fully tested it). Instead I copy the DVD ISO to the HDD and loop mount it (/media is normally unused so makes a good mount point), which also makes access faster. I normally have a HDD copy of the DVD anyway as a backup in case the optical disk is damaged.
Originally, packagekit functionality was depend on a media.repo file available on DVDs. AFAIK, since it is removed, the PK functionality doesn't work any longer (except if new development have been done in this regard).
Also note that media repositories didn't have any 'baseurl' option, but they had a mediaid option which was included in media.repo file in DVD itself. I don't know how it is calculated.
This is how it worked in 2009.
This bug should be probably against packagekit. However, if there is still any way to detect if the current inserted DVD is actually a Fedora DVD (or more generally, a Yum repo dvd). If not, something in pungi should be fixed first. I don't know why media.repo was omitted in the first place.
Not quite. It actually looks for the contents of the gsettings key org/gnome/settings-daemon/plugins/updates/media-repo-filenames , and on my system, the default contents of that key appears to be "media.repo,.discinfo". So it looks for *either* media.repo *or* .discinfo. Current Fedora media include the .discinfo file.
I wonder what that gsettings key is used for, but AFAIK the media repo is installed in PackageKit backend code (since the frontend does not have root privileges to be able to create the new repo in yum.repos.d/), and after reading the backend code I should say that it doesn't have any code to actually create a .repo file and it merely tries to copy DVD's media.repo into /etc/yum.repos.d/packagekit-media.repo . If media.repo doesn't exist, it won't do anything.
When a media repository is installed, backend code uses .discinfo of the disk to see if it is actually the repository associated with that repository.
Therefore, if you create a media repository manually (which uses mediaid field matching Fedora DVD's .discinfo file) PackageKit will be able to use it. But it is currently unable to create the repository file on its own and relies on the availability of media.repo on the disc.
Well, after reading PackageKit's media-repo.txt file (available in PK git repo and probably source tarbals), it seems that the gsettings key is used to notify the backend about a media repository, which is necessary but not enough. The backend code should be changed to create a .repo file directly from .discinfo rather than relying on the existence of media.repo. (Another PK limitation is that it assumes that user uses only one media repository (Fedora DVD), but it would be nice if it can use multiple media repositories. I'm not sure, but probably it is enough to not use a constant file name (packagekit-media.repo) for the recognized media repositroy))
hedayat: the code I was looking at is the code I mentioned above - gnome-settings-daemon 's plugins/updates/gsd-updates-manager.c . So that ties in with what you found, yes.
So it seems we either need to make PK better (as you suggest) or start putting media.repo on the discs again. Hughsie, Bastien, could you figure something out here? It's rather an important bug now, due to the removal of the ability to select multiple desktops in anaconda.
add as f19AlphaBlocker proposed
When using the DVD image, the installer must be able to use the DVD as a package source
The funcionality requested used to exist in a DVD and is not working due to the omission of incuding the media.repo on the DVD.
That's about using it as a package source *during the install*. using it as a package source after installation is not even a Final requirement, never mind an Alpha one.
As Adam pointed out - it's post installation issue, not installer one.
Discussed at 2013-04-08 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-04-08/f19alpha-blocker-review-5.2013-04-08-16.01.log.txt . Rejected as a blocker: as explained in comment #14, the cited criterion is about install time, not post-install. This doesn't meet any criteria.
Richard, have you had a chance to look at this? It's rather important to those who use the DVD for offline installations.
I've pushed this to PACKAGEKIT_0_8_X:
Author: Richard Hughes <firstname.lastname@example.org>
Date: Thu Jan 2 10:41:38 2014 +0000
hawkey: Support .treeinfo DVD repos
This means we also have to use the package cost when choosing a repo to use.
:100644 100644 9e8c3a7... 07f3091... M backends/hawkey/hif-package.c
:100644 100644 a10f5bf... db2dc8f... M backends/hawkey/hif-package.h
:100644 100644 a1d9020... bce6fe7... M backends/hawkey/hif-repos.c
:100644 100644 887a944... 28c1a65... M backends/hawkey/hif-sack.c
:100644 100644 cc09d3a... bb71f6e... M backends/hawkey/hif-source.c
:100644 100644 3796d08... 9b57b85... M backends/hawkey/hif-source.h
:100644 100644 4ca234e... f1f404c... M backends/hawkey/hif-utils.c
:100644 100644 9768124... e50917e... M backends/hawkey/pk-backend-hawkey.c
I'll do a new upstream release in a couple of weeks which will fix it for those using the hawkey backend in F20 and rawhide. For the yum backend all the code is centered on having a media.repo on the DVD and copying it system-wide, so is much harder to fix, and I'm wondering if there is much point given the yum backend won't be supported in F21. If anyone is desperate for the yum backend to work (using the old MediaGrabber interface) I'd certainly accept patches.
For testing the DVD media fix with hawkey, it's just a case of inserting as many DVDs as you want to test, then doing normal PackageKit operations (e.g. using gnome-software). There is normally a few-second delay when the CD is spinning up and the SAT-index is being created, but after that it's basically the normal speed of any other repo. I've been testing with the F20 install DVD, but should work with any of the other add-on CD/DVDs with an iso9660 filesystem and a .treeinfo file in the root directory.