[Libosinfo] Script broken for Fedora net ISO

Zeeshan Ali (Khattak) zeeshanak at gnome.org
Thu Mar 26 14:39:31 UTC 2015


Hi,

On Fri, Feb 13, 2015 at 2:49 PM, Zeeshan Ali (Khattak)
<zeeshanak at gnome.org> wrote:
> On Thu, Nov 6, 2014 at 10:24 AM, Christophe Fergeau <cfergeau at redhat.com> wrote:
>> Hey,
>>
>> On Tue, Nov 04, 2014 at 06:21:31PM +0100, Zeeshan Ali (Khattak) wrote:
>>> Hi everyone,
>>>
>>> Vladimir Benes recently told me about the issue of express
>>> installation and net ISOs of Fedora in Boxes. There are two issues
>>> with this:
>>>
>>> 1. Internet is required w/o script communicating this requirement to App.
>>> 2. Some remote repositories need to be setup, otherwise installer
>>> waits for user to manually set them up.
>>>
>>> I thought of some solutions but none without any issues:
>>>
>>> 1. a. Add 'needs-internet' to media entries
>>>     b. Pass media info to script generation functions.
>>>     c. Modify fedora script to add required repos if 'needs-internet'
>>>
>>>     This would be my first choice but how can we implement (b) w/o breaking API.
>>>
>>> 2. a. Add 'internet-available' param to InstallConfig
>>>     b. Modify fedora script to add required repos if 'internet-available'
>>>
>>>     This would add to the work of App as they'll have to check
>>> availability of internet and set this. FWIW this won't be an issue for
>>> Boxes at least as it already checks that to ensure scripts requiring
>>> internet have it available. Perhaps we can assume that for other apps
>>> too?
>>>
>>> 3. a. script templates specify variants supported
>>>     b. Add variant info to net ISOs
>>>     c. We add separate scripts for netiso variants
>>>
>>>     The main/first issue with this would be the fact that volume IDs
>>> on ISOs are the same for both full and net installer ISOs. AFAIK this
>>> is true for all distros, not just Fedora.
>>>
>>> Better ideas welcome!
>>
>> 3. sounds much better than the other alternatives. One hackish way to
>> detect net install images VS full images is that the former will usually
>> be much smaller than full images (100MB VS 700MB). This must correspond
>> to 'volume size' in isoinfo output. The Eltorito bootoff (boot offset?)
>> is different too.
>
> Thinking more about this issue, I think this is not a bad idea. i-e we
> can add a volume-size property to media.

Now that I've laid down the ground work for this and we have ways to
distinguish various ISOs with the same volume-id, I was looking into
this.

One important thing I somehow did not realize before is the even with
approach#3, we'd need new API and apps will need to be changed so they
use the correct installer script. The new API would be:

osinfo_os_get_install_script_list_for_variant(OsinfoOs *os, const char *variant)
osinfo_os_find_install_script_for_variant(OsinfoOs *os, const gchar
*profile, const char *variant)

So I was thinking, if we are to add API for this and Apps have to
update their code anyway, why not implement a more generic solution
that allows us to keep the same script templates:

* Add new API to pass media info (which includes variant info) to scripts:

osinfo_install_script_generate_for_media(OsinfoInstallScript *script,
                                                             OsinfoOs *os,

OsinfoMedia *media, ..)
osinfo_install_script_generate_output_for_media(OsinfoInstallScript *script,
                                                             OsinfoOs *os,

OsinfoMedia *media, ..)
// And the async variants

* Add separate media entries/variants for netiso.

* Modify the fedora install script to add/remove yum repos based on the variant.

* Add a requires-internet to media entries, which defaults to 'no'.

* Set requires-internet="yes" to netiso media entries.

This would probably be more work than what I planned previously but I
think this solution makes more sense and would be more future safe
(e.g we could need some other media info from install script
templates).

-- 
Regards,

Zeeshan Ali (Khattak)
________________________________________
Befriend GNOME: http://www.gnome.org/friends/




More information about the Libosinfo mailing list