> > syslinux actually. and it can take a root= argument but if you don't > > give a root= argument you get a root disk prompt. > > Yeah, that's what I said/meant. The boot-floppy-hfs.img floppy > doesn't work the same way as the rescue floppy does for other > architectures. My point is that for powerpc, the "rescue" function
The 'rescue floppy' doesn't even work as this on a whole other bunch of architectures I bet. Can you boot from this floppy on sparc? Alpha might work. None of the m68k machines will boot from it if you happened to kill the machine's old OS. Call it 'kernel floppy image' and emphasize that there's no need to copy it to a floppy disk on those architecures that can't boot from floppy, and maybe people will understand. > of the floppy with the word "rescue" in it's image file name is > somewhat impotent. This can be somewhat confusing if you're not a > graduate of the powerpc debian booting/installing gauntlet. Most > especially because of the way the generic debian install docs refer > to the rescue floppy for everything. That one-size-fits-all install doc is truely evil, even with all the arch-specific customizations. True, once you're booted into the installer it works the same for all architectures. The steps leading up to that are just too different. Alternatives? We used to have a separate quick reference style install guide for installation on Amiga, Atari, Mac and perhaps VME on m68k. That was considered a bad idea by the boot-floppies team, and we tried to fold the specific 'what files to get, how to boot' instructions into the generic docs. Confusion ensued. I now think having separate documents that detail the initial steps (choice of install method, partitioning, reinstalling your OS, what install files to get, how to unpack them, how to boot the installer, how to boot into the installed system finally) would be the easiest way to solve the problem. For PPC, separate descriptions for oldworld (miboot or BootX) and newworld (yaboot) as well as CHRP/PREP and other flavors might make sense. For the remaining tasks, the generic install doc is the better guide indeed. My statement above didn't mean I'd like to replace the generic docs with per-arch ones. Just separate out the specific things to be more flexible in structuring the description. Michael