On Mon, Aug 26, 2002 at 01:45:03PM +0900, Junichi Uekawa wrote: > I was kind of thinking of "udebootstrap", but that might be a bit more > tricky. I've been kind-of thinking about that too, although I don't think it'd remotely resemble debootstrap on the implementation side. A "udebootstrap" would allow us to distribute the installer as a bootable kernel, udebootstrap-as-init, and a bunch of .udeb files that will be unpacked by udebootstrap to the point where cdebconf, anna and various retrievers and such work. This is by way of defining what "udebootstrap" means -- it creates a udeb-based system where there isn't already one. We don't have to do this at all -- d-i already works by just having an image of a working udeb-based system that you burn onto CD and boot, no bootstrapping required. Anyway. The first question is whether udebootstrap can even be implemented. It probably can be -- a statically linked busybox with ar, gzip and tar should let you do the initial unpacking, and since that _seems_ to be pretty much all that "make tree" does, there doesn't seem any great reason why you couldn't do that as part of booting the installer. Whether there's any point to all that's another matter. You're only buying yourself a smaller "rootfs", and you're only doing it by giving yourself less ways of accessing the first set of udebs you want to install. If that means you can boot from a single floppy disk, rather than a boot-root pair, but only because you then need to insert another couple of floppies to get full versions of libc6 and wget-retriever, that's not a win. What's going to go on the rootfs? Presumably something like: libc6, busybox-udeb, ash-udeb udpkg, cdebconf, anna *-retriever and any dependencies they have /lib/modules/<kernel>/** ? Cheers, aj -- Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Attachment:
pgpbb5ZbskzSF.pgp
Description: PGP signature