Re: non-free firmware and d-i
On Mon, Sep 18, 2006 at 01:12:52PM -0400, Nathanael Nerode wrote:
> <posted & mailed>
>
> Wouter Verhelst wrote:
>
> > On Tue, Sep 05, 2006 at 11:35:25AM +0200, Wouter Verhelst wrote:
> >> Feedback is welcome.
> >
> > Since the only feedback I received thus far was Goswin von Brederlow
> > saying he liked the idea, and since I didn't have much else to do today
> > (other than wait for a supplier...), I went ahead and wrote it. It's
> > committed to /people/wouter/customization-modules in d-i svn.
> >
> > It hasn't been tested at all yet (hence the commit to /people rather
> > than /trunk), but this is mostly meant as a proof of concept anyway. I'm
> > particularly not very happy about the way I currently "look" for usb
> > storage devices (really all I'm doing is find any devices called
> > /dev/fd*, or anything which is situated under /dev/cdrom/ or /dev/discs)
> >
> > Can people please have a look and comment? I'd like to avoid some
> > specific GR by making whatever is going to be voted upon moot ;-)
> >
>
> So I'm looking at how much of d-i is ready for multiple udeb sources....
>
> Checking the net-retriver modules makes it clear that it ASSumes that
> there's only one source. I'm not entirely sure how to disabuse it
> of that assumption.
I've been thinking that the best way here is to just nuke the
configuration of the retriever before (or while) running
customization-modules in some way. We'll be assuming that there is at
least one way to get udebs onto the running debian-installer session; so
the assumption that udebs have been downloaded isn't totally unfair, and
there won't be a need to download additional modules at that point
anymore. At least I think so; would have to do a test run to be sure.
> There's an easy way to do it: make a copy of net-retriever
> (customization-net-retriever)
> which instead of using the choose-mirror debconf information, prompts for
> a URL (and *doesn't* cache it, so that it can be run repeatedly with
> different URLs).
>
> I hate to duplicate code, but some of the net-retriever code (like the
> signature checking) should be torn out for this purpose anyway, so this
> is probably the way to go.
Except that you'll inflate the initrd's by unnecessary amounts, which
will make it harder to install Debian on RAM-limited machines. Clearly
not the way to go.
[...]
> The other way is to make the net-retriever program handle both alternatives,
> but if it's invoked from anna (as it should be), there's no way to tell it
> which version is wanted, so I think that's not workable.
>
> I think maybe I should just write this now.
Be my guest ;-)
> ----
> If we use the more complicated anna-using version I suggested rather than
> your very straightforward code, then for local disk udeb loading:
>
> floppy-retriever seems good to go; it even invokes mountfloppy, and
> it doesn't need a Packages file or anything.
Right.
> This should be the model for other 'customization' retrievers.
>
> cdrom-retriever looks pretty much good to go as well, but it doesn't
> similarly handle mounting and umounting, and it wants a fairly complicated
> setup on the CD. So maybe it should be forked.
The complicated setup isn't too big a problem; the mounting and
umounting can be done from customization-modules.
As above, duplicating code is a bad idea for d-i, and I'm not convinced
here.
> I believe the main customization menu is the
> place to handle ejecting and replacing the installation CD (which is
> clearly the Hard Part).
> Why? Mostly because it has to be done for all
> local media (CDs, floppy, USB stick, etc.), and will be done in
> approximately the same way for each one: check whether the device is
> mounted, umount if it is, do the work, remount it at the end.
Right.
> (Frankly I'm unsure how the multiple installation
> CDs work now: I guess none but the first contain udebs.)
Exactly.
> I'm not *quite* sure how to write that code (everything else mentioned here
> I think I could write right now pretty much).
>
> There is no usbstick-retriever or harddisk-retriever. There should be, for
> reasons beyond customization disks: it's a little silly that those
> options require an ISO image. :-)
Couldn't agree more, but they're not as urgent as 'making sure it
works'.
> These should be substantially
> simpler than cdrom-retriever or floppy-retriever.
at least easier than cdrom-retriever, yeah. Hard to be simpler than a
shell script that is 30-ish lines long.
--
Fun will now commence
-- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
Reply to: