On Wed, Dec 07, 2005 at 02:12:08PM -0500, Rich Johnson wrote: > > On Dec 7, 2005, at 12:27 PM, Hans Ekbrand wrote: > >> > >>So, yeah, I'd say it doesn't provide a clear description. > > > >Here a draft on the possiblities involved. If my understanding of the > >issues are correct, the installation manual needs some extensive > >rewriting. > > > >There are three different stages A, B and C, that can be loaded by > >different means: > > > >A. How to *start* the debian-installer? > > > >1. Boot from removable media that has an installer-image on its boot > > block (e.g. CDROM, floppy, usb) > >2. Use a bootloader from within a existing operating system (yaboot, > > BootX, penguin) > > 2b. (possible, but not very common) Use a native bootloader (yaboot, > > grub, lilo) installed on harddisk) > >3. Netboot (pxe or other methods gets a bootloader by dhcp and tftp) > > (pxelinux or yaboot loads (by tftp) the kernel and initrd needed) > > > >B. From where is the debian-installer to get its *own modules* > >(needed for its own functioning)? > > > >1. From the removable media (CDROM or usb) that started the debian- > >installer at boot > >2. From .iso-file on local harddisk (Filesystem must be readable by > >the debian-installer, which exludes HFS+) > >3. From the net (internet or local debian-mirror) > > Oh, I get that all right. Where you lose me is the rationale for > the bootstrap/installer being incomplete in the first place. What's > preventing the a complete set of debian-installer modules from > residing on the ram-disk--as it did with the woody installer? I *think* it is size issue (lowmem and/or boot issues with too big initrds). > I'd like to know the rationale for why HFS+ is not supported by the > installer--especially as the kernel is specifically compiled for > systems that are likely to have only HFS+ filesystems. What's so > difficult about building powerpc installer kernels with > CONFIG_HFSPLUS_FS ? Don't know why, I am not a d-i developer. > Supposing that there is a compelling reason for an incomplete > installer: In such cases the installer should _always_ provide a > route to B.3. The modules needed for network support (both kernel modules and d-i modules) would then have to be in the initrd, which might get too big (this is only me speculating though). > Instead the etch hd-media installer insists on _ONLY_ > B.2 while not bothering to support the only FS likely to be available. Sounds stupid indeed. > In short there are three perfectly reasonable ways to resolve the > situation: > 1. A complete ram-disk -- everything loaded by the bootstrap from > whatever source is selected in A. The possibility of low-mem installs is a nice thing. > 2. Kernel supports whatever filesystem is likely to be present on > the bootstrap source (including HFS+) Sounds reasonable. > 3. Installer is _always_ provides a path for fetching module from > the network. That would require the nic drivers to be in the initrd. I don't know if the are or not. If they were, then changing the priority within d-i might give you the possibility to fetch more kernel-modules over the net. -- Hans Ekbrand (http://sociologi.cjb.net) <hans@sociologi.cjb.net> A. Because it breaks the logical sequence of discussion Q. Why is top posting bad?
Attachment:
signature.asc
Description: Digital signature