atm I'm seeing lots of messages from David, but not the replies. Is the
list broken? or are the messages still comming (likely)?
David Lehman wrote:
First, some background...
Installation methods utilizing a remote tree enjoy the task of verifying
that the remote tree matches the boot media used. This prevents a user
from trying, for example, to perform an installation using RHEL4 boot
media and a RHEL3 tree. This verification is achieved through the use of
a stamp file that exists in both the initrd image and the stage2 image.
A successful comparison of the stamps is required for a remote tree to
be deemed acceptable.
There is an old shortcut in loader that tries to use a stage2.img from
cdrom when setting up an HTTP install (to save time). This leads to a
short-circuit of the above verification process, since we are only
verifying that the stage2 on the cdrom matches the boot media. The
remote HTTP tree is not verified at all. We have committed to fixing
this bug, starting with RHEL4.
What problem are you trying to fix?
Not "it's a bug," what problems does the existing behaviour actually
cause. The existing behaviour has orrurred for some time, and changing
it may well cause more grief than it saves.
If one can boot an installer and from that install RHEL[n] and the
matching Fedora Core, _that_ is the behaviour I would prefer,
I don't know what the current instructions are for creating a network
install repository (I loop-mount the DVD ISO), but those that prevailed
for prior releases would not copy .discinfo
btw I see the name ".discinfo" as a bug, in the RHL family "disk" is
more usual than "disc."
The simplest fix that I have come up with would be to require that all
exploded remote trees contain the .discinfo from the ISO. Since this
only comes into play when the user has booted with a disc1 (not boot.iso
as it doesn't contain stage2.img) we can assume/require that the cdrom
already contains a .discinfo file.
The thing is, to make it consistent we'd pretty much have to start
requiring the presence of .discinfo in all exploded remote trees, which
we don't currently do. This is bound to incur some amount of
belly-aching.
Thoughts, comments?
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
--
Cheers
John
-- spambait
1aaaaaaa@xxxxxxxxxxxxxxxx Z1aaaaaaa@xxxxxxxxxxxxxxxx
Please do not reply off-list
