Bug 435976 - RFE: anaconda should use a mirrored repo on a hard drive
RFE: anaconda should use a mirrored repo on a hard drive
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-03-04 13:48 EST by Todd Denniston
Modified: 2008-03-31 21:00 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-04 14:01:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Todd Denniston 2008-03-04 13:48:54 EST
Description of problem:
When you select an install source as a local hard drive, anaconda only expect to
find a MS-DoS filesystem with an iso image in it.  This prevents the use of
Everything directories that exist in an ext3 file system on a USB hard drive.

Version-Release number of selected component (if applicable):
As late as anaconda- 

How reproducible:

Steps to Reproduce:
1. start an install with a rescue cd
2. tell anaconda you want to install from a hard drive (USB, PATA, SATA...)
Actual results:
Anaconda indicates it can not find install media.

Expected results:
Anaconda works with the directory structure it finds, as if it had nfs mounted
it from a server.

Additional info:
extra credit, also allow it to use the updates/$releasever/$basearch/ directory
which is also on the hard drive.
Comment 1 Bryn M. Reeves 2008-03-04 13:54:42 EST
Not saying that this shouldn't be changed, but afaik the requirement to have a
directory full of ISOs for a "hard disk" type install has existed for a long
time (at least back as far as RHL8/RHEL3 - I think since this install type was
first introduced).

Comment 2 Jeremy Katz 2008-03-04 14:01:11 EST
You're not actually limited to msdos for holding the isos.

But the reason that the requirement is for the ISOs and not the tree is that we
actually used to allow the tree, but people would inevitably only have partial
mirrors of what they thought mattered and installs would fail.  After a few
years of these bugs, we cut our losses and also reduced the testing matrix a
bit.  So not really interested in adding it back and making things worse again
Comment 3 Todd Denniston 2008-03-04 14:25:07 EST
Thats why this is an RFE=Request For Enhancement.
and I be not the only one:
Yes jigdo and isoinfo help, but why should I have to build a DVD image when I
have the correct stuff right there on the hard drive.

Re Comment #2
So you never have folks reporting problems with the NFS mounted file systems?
Comment 4 Jeremy Katz 2008-03-04 14:55:45 EST
Yes, this comes up from time to time.  But the amount of requests is very very
low in comparison to the amount of effort required for maintaining another path
through the installer.  And while there's a very occasional such report with
NFS, they're far rarer -- I suspect due to the higher barrier to entry keeping
out people who are more likely to do things that are unwise.
Comment 5 Bruno Wolff III 2008-03-04 15:30:14 EST
I had occasion to wish for this feature. I only have one x86_64 machine and
wanted to use buildinstall to build a new set of images on that machine and then
use them to install in another partition. (netinst.iso didn't work and I thought
rebuilding it might use a slightly more recent version of anaconda.) It seems
silly to have to go to an extra step (making an iso file that will end up being
loop mounted to get back the original structure) or copying the images back to
another machine so that they can be used for a url install.
While this is not a high priority, it is something that might help people with
only one local machine participate in rawhide testing.
As far as the broken trees goes, I think that is a separate problem. My guess
would be that people aren't skimping on getting the trees, but probably they are
dealing with out of sync mirrors. Even the fedoraproject mirror has partial
updates regularly. I have learned to check the time stamps to make sure that the
images, repo meta data and packages all appear to be in sync. There might be
things that the project could do to cut down on this. Perhaps the master could
be doing directory renames (if it isn't) instead of copying over updates.
Comment 6 Andrew Farris 2008-03-05 15:20:21 EST
I understand the increased complexity in Anaconda, but I have also wanted to have this option available.  
I'm wondering why the installer failing causes any more issue than trying to debug network installs that 
fail?  The same outputs would end up on virtual terminals (can't find file xxx, etc).  Wouldn't it be possible 
to install from local harddrive, with files, only if there is repo metadata present?  That would at least 
remove alot of the issue with half-complete mirrors right?   (essentially, a network install with a local 
Comment 7 Bill Crawford 2008-03-28 08:00:55 EDT
It would be perfectly acceptable to insist on metadata; a particular use for
this is test installs of rawhide, where doing it every day might be considered
prohibitive via the usual make-an-iso route not just because of the cost of DVD
blanks, but for the time involved.
Comment 8 Bill Crawford 2008-03-28 08:01:45 EDT
(in other words, why can this not be supported only within rawhide, or with an
option like "iamanext4developer" ;o))
Comment 9 Jerry Vonau 2008-03-31 21:00:19 EDT
Funny, I have patches to make this work.


And proof that it works, note the boot line at the top:


If this does not make it into anaconda proper, I could maintain this setup if
there is interest and someone could host the initrd.img for me.

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