Re: Booting to floppy
> > 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
Reply to: