Re: Booting to floppy
Michael Schmitz <schmitz@opal.biophys.uni-duesseldorf.de> writes:
> 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?
Sure.
Only on architecture, PowerPC, is in bad enough shape to require one
image for actual booting (when possible at all) and other one to
supply the kernel to dbootstrap.
Wouldn't it be easier to just get the kernel directly from one of the
'linux' files lying around, in the case that the user is installing by
a method other than floppies? This might be an easy, general fix we
can do for all arches.
> Alpha might work. None of the m68k machines will boot from it if you
> happened to kill the machine's old OS.
Well, you would now about that more than I...
> 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.
That's not a bad name for it... It also has a boot loader, and, on
some arches, some documentation and stuff.
> That one-size-fits-all install doc is truely evil, even with all the
> arch-specific customizations.
Some things about the documentation is indeed evil, but I still think
it was the right idea to do it that way. I would love it if there a
"quick start" mode -- that could be added to the front of the
documentation easily. And you can cross-link into the full
documentation.
> 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.
Some of the steps are rather different, but SGML has facilities for
blocking off areas as one arch only.
It's pretty easy to just chop around whole sections (although you have
to make sure that any references to those sections are conditionalized
out as well).
> 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.
Well, I don't think this necessarily reflects on the documentation but
rather on the lack of strong documenters, who know what they are doing
with document maintenance issues, putting out leadership and getting
things done.
I mean, you could easily have a completely gut install-methods.sgml
and have install-methods-powerpc.sgml (if that's really the right
thing to do, if there is really so little commonality), so long as
they both have sections with the same IDs in them.
I guess my conclusions are a bit different. Some things, such as
laying out files on a TFTP server, for instance, are remarkably
identical across architectures, and decided not i386-centric.
Yet that is barely documented at all.
My conclusion is not that the 'one size fits all' is to blame, because
if that was true, we'd see the more common stuff documented better and
the wierd arch stuff not documented well.
In fact, what we have is very limited involvement by
porter/documenters. I pretty much conclude there is no such thing as
a porter/documenter.
> 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.
Fine, but as I said above, you can do all that in the current
documentation just as easily (easier?) that doing it from scratch.
> 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.
I don't disagree that some structural changes would have to be made to
the main documentation to facilitate this. Better layout and break-up
of files to make it clear for porters with not much time where to edit
stuff, focusing on the points of divergance.
My point is that this can be done in the main SGML file, without
spinning off a bunch of little ASCII files.
--
.....Adam Di Carlo....adam@onshore.com.....<URL:http://www.onshored.com/>
Reply to: