[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#23143: make-kpkg fails on Alpha



On Sunday,  7 Jun, Michael Alan Dorman wrote:
> 
> Jesse's not entirely right---there's a milo.exe, which, under the ARC
> console, is called by linload.exe, which is called directly bar ARC.  But
> milo doesn't have to be re-run, and it doesn't have a config file.  This is
> an unfortunate defect, one Chris and I may try to remedy (it would be damn
> nice if it did, as it would simplify stuff a lot...)

Absolutely.  Not even mentioning that on systems where MILO can't keep
settings in the NVRAM it is plain impossible to boot up Linux without
having to type a long `boot ...' line (thus, no automatic reboot).

However, a question: which disk and partition the config file should be
read from?  Shall we employ RTC memory or reserve a place inside MILO's
executable image?

Or can parameters be passed to MILO from SRM or ARC?  (I believe both
SRM and ARC can store their settings in some kind of non-volatile memory
on all types of systems.)  If they can, do we want it done that way?
(It will prevent people on whose systems MILO works OK even when run
straight from the NVRAM from installing it there.)

Next idea in this direction is that it would be nice to have MILO
load the kernel automatically even on the first run, from the boot
floppy or CD or whatever.  Or at least read a config file with the
choices.  Not a problem with ARC (when MILO is on a FAT floppy, isn't
it? - so the config file can be there as well), but an SRM bootable
floppy can't have a reasonable filesystem unless partitioned, and
(correct me if I'm wrong) Linux doesn't support partitioned floppies.

So we probably need to be able to supply a raw block number instead of
partition number along with the disk specification.  Any ideas?

If nobody else wants or has started already, I can try to hack MILO
accordingly (I've just finished the project that was eating up 110% of
my time).  However, as Mike has already shown his potential interest in
doing this, I leave it up to him for the moment.

	Nikita


--
To UNSUBSCRIBE, email to debian-alpha-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: