Re: disposition of boot-floppies in woody
On Sat Dec 30, 2000 at 01:48:00PM -0500, Adam Di Carlo wrote:
>
> Anthony Towns claimed on debian-devel that it would take us "a few
> months" to prepare boot-floppies for woody. I think it can be done by
> Feb. I don't think there many major issues. Here's the one's I know
> of:
>
> - use busybox.deb from woody rather than the local CVS copy
The current busybox.deb needs a little work (about 1 hour) before it will be
ready to replace the one in boot-floppies. Mostly, I need to go through and
turn off everything that isn't enabled in the boot-floppies CVS. Also, some of
the choices re what to enable or disable in busybox (such as sed) should be
re-considered. For example, busybox sed has been rewritten (again) and may
well do the job now.
The next thing that needs to be done is deciding on the method by which busybox
gets its applet links installed. Busybox now supports a runtime '/bin/busybox
--install [-s]' command to install hard (or soft) links for each and every
busybox applet. Using this method, the only thing that actually needs to be
installed is /bin/busybox (or /sbin/init or wherever you put it). I recommend
we use this method to install all the needed links at runtime. This will
ensure that the set of links we install is _always_ in sync with the binary.
On the downside, there is a chance that you might get an EEXIST error (it will
not overwrite existing binaries with links) when it tries to install something
that already exists on the boot-floppies filesystem, but at least that make
things easy to debug...
I would be happy to integrate this support into boot-floppies (just adds a
couple of lines into /etc/rc.d/rcS).
I can probably get at least the initial part of this work done this weekend.
> - dealing with new kernel (what is the proposed kernel for woody,
> anyhow?)
Well, the updated busybox (unlike the version in the boot-floppies CVS), copes
gracefully with 2.4 kernels so that, at least, isn't going to be a problem
anymore... Beyond that (where busybox wouldn't boot on 2.4.x kernels) the only
real issue I can think of is how we handle all the new kernel modules...
-Erik
--
Erik B. Andersen email: andersee@debian.org
--This message was written using 73% post-consumer electrons--
Reply to: