[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

anna's hard-coded priority list of retreivers



I keep stumbling over anna's hard-coded priority list of retreivers.

    static const char * const retrievers[] = {
        "net-retriever",
        "cdrom-retriever",
        "floppy-retriever",
        NULL
    };

anna defaults to using the one closest to the top that is installed. 

When I was working on floppy images, the image had both the floppy
retreiver, which most users will need to use first, and the net
retrevier, which is only useful at first if you have a very common
network card that fits on the root floppy. anna's behavior made it try
to configure the network first thing, which was wrong.

Now that I am working on hard-disk-as-media installs, I have the cdrom
retriever on the initrd, because most people will download an ISO to
disk and it will be loop mounted. But for the few who won't do that, or
who will mess up, I want to include full network support in the initrd,
including the net-retreiver. But if I do, it will try to configure the
network first off, and download the installer from the network, which
will be wrong 99% of the time.

Of course, net-retreiver has to come before floppy if you're doing a
netboot or CD install. It looks like I could get away with moving
cdrom-retreiver above net-retreiver, at least for now. Until another
image came along.. This hard-coded list defeats modularity, and seems
comnpletly wrong.

One fix for my problems would be to ship a config file in the initrd,
/etc/retriever. This could be provided by a udeb or whatever to override
anna's hard-coded default. I hope that's not the _best_ fix.

Another idea I've had is to turn anna inside-out, removing it from the
menu, and put the retreivers themselves on the main menu. Well, not
quite, the menu items would really be separate udebs customized to the
type of install, that picked a retreiver and called anna, forcing it to
use that retreiver.

Floppy:

   Configure language
   Retrieve modules from floppies
   Configure the network
   Retrieve modules from network

This flows perfectly! At high proprity, you are prompted for a driver
floppy, then it sets up the network with the modules probably loaded
from that floppy. If network setup fails (maybe you inserted the
cd_drivers instead), priority is lowered and you can see the menu and
pick what to do by hand (load another drivers floppy to get the net
drivers, or pick the new "Retreive from CD" that the cd_drivers floppy
might have added to the menu).

If you instead start in low priority and know you have a common card,
you can skip right to retreiving modules from the network[1].

Cdrom:

   Configure language
   Detect CD
   Retreive the rest of the installer

Here the menu item would see if the CD is mounted and use the CD
retreiver. Failing that, it would fire up the floppy retreiver, or any
other retreiver that worked.

Note that this menu item could just thunk to anna, so it would be very
easy to implement, Eventually we would move the hard-coded list out of
anna and into menu items like this one.

netboot:

   Configure language
   Configure the network
   Retreive the rest of the installer

Simularly, the third menu item here will use net-retreiver if it works,
but will fall back to floppies in extremity.

Again, this menu item could, at first, just call anna, using its
present-day behavior.

hd-as-media:

   Configure language
   Scan hard drives for an ISO
   Retrieve modules from ISO
   Configure the network
   Retrieve modules from network

Here after it mounts the ISO and loads the installer from it, it would,
somewhat annoyingly, still bother the user about setting up the network.
(Perhaps that's ok; the user has to set up the network sometime..) 
If it cannot find the ISO, the priority is lowered, and the user can go
on to a network install if he desires.


Well this feels right to me, and not too dreadful to implement.

-- 
see shy jo

[1] However, main-menu would persist in highlighting the second menu
    item until you did it. Though I think this behavior of main-menu's
    can be fixed, by making it highlight the next item on the menu after
    a menu item that has successfully been called, instead of the first
    un-done item. Whatever, minor point.

Attachment: signature.asc
Description: Digital signature


Reply to: