Re: 2.2.4 boot-floppies and powerpc/apus subarch.
On Fri, Jan 07, 2000 at 11:41:02AM +0100, Sven LUTHER wrote:
> kernels. But it is not possible to put uncompressed kernels in the rescue
> disk, for lack of space. How can i tell the boot-floppies stuff to use one
> kernel for the linuxapus kernel that get used for booting, and another for
> generating the unused rescue disk ? Anyway, better would be to fix bootstrap,
> i think.
Vigorous nod of agreement. The "rescue disk" concept is useless on almost
every architecture+subarchitecture except for i386, and even there we have
separate disks for the kernel and the root.bin. For that matter, so is the
idea that you can just install a bootloader in your boot sector and reboot
into Debian. This certainly is not the case on the two architectures I'm
dealing with (Alpha and 68k Macintosh).
I guess it is too late to really overhaul dbootstrap now, but we should at
least have the capacity to install the kernel from a "loose" kernel image
instead of a misnamed "rescue disk". (If I had a dollar for every time I've
had to tell a potential mac68k user "no, the rescue disk is useless, don't
bother writing it to a floppy"...)
Alpha will require up to three "rescue" disks, BTW ... SRM machines can get
away with two (kernel+aboot, root.bin), but ARC/AlphaBIOS will need an extra
one for MILO and loadlin.exe.
Perhaps I am talking out my arse again though. What are the sparc/powerpc
people doing about this problem (since in some cases they also need
uncompressed kernel images)?
> Speaking of this, what is the policy regarding bootstrap programs ? They have
> to be compiled on the bootstrap os, with tools and libraries that are not all
> considered free, and require some rather involved stuff to build. Can i still
> include them in the boot disks ? Can i make a package of them (in executable
> format, without source) ? For bootstrap this is no problem, because they are
> free, and a amigaos version of gcc is used, but there is also a nice GUI for
> it, that uses the MUI library which is shareware. all stuff needed for using
> it can be found on aminet, and i think the license permit us to ditribute a
> binary version of the library needed to launch the little script.
Alpha has a similar problem which we seem to have simply ignored for slink.
MILO itself is free, but it uses a non-free 8086 emulator from DEC. There
is a free emulator, but it is not yet a viable option (it can't initialize
my Matrox card, at least). We also don't have a source package for MILO,
the main reason for this being that it's difficult to build it (you must
first build a specific kernel with a specific configuration, then link parts
of this kernel into MILO). So, I would also like to know what is the
recommended strategy...
Reply to: