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

image file names (was Re: boot-floppies tasks)

>> I believe the whole problem  was that msdos partitions can't tell the
>> difference between resc1440-tecra.bin and resc1440.bin, and rawrite
>> can't understand vfat.  (BTW, there is no rawrite maintainer, AFAIK).
>Wrong.  dbootstrap is *always* looking for resc1440.bin.  There is not
>way currently dbootstrap knows that it was booted off of resc1440-tecra.bin
>or something else and that it should look for a different image than

Hmm... From utilities/dbootstrap/main.c:

    { "tecra",     1, &bootargs.istecra  },

So it needed a boot arg of 'tecra'.  It *is* implemented.

Now the system *should* autosense this condition rather than
requiring a boot flag, perhaps have syslinux configuration on the
appropriate rescue image populate this automatically...

I'll add a todo item for this...

>> >Should be easy to fix, add some more parameters and stuff, add a flag
>> >to the boot-image etc.
>> Huh?  There is a tecra flag already accepted in dbootstrap, handed
>> down from init.

Ah, from syslinux rather...

>Ah, good.  Though, I'd like to have it more flexible.  There are
>about four images iirc.  Not only tecra.  I might be mistaken.

Well -- there probably *will* be a number of different variants in
potato.   This will be for IDE patches etc that the kernel needs which
might not be robust for all arches.  

I don't know how m68k or alpha handles multi-arch stuff.  Right now,
we're heavily messing with the file layout and dbootstrap is not yet
doing the right thing (and in fact only i386 implements the new

In fact, we don't even have a consistent file naming convention that
works for all platforms.  This is going to get ugly fast.  One issue
here is that i386 has 8.3 restrictions that other arches don't have.
So for i386 we have:


But m68k does something like:


I don't know -- I guess we should adopt a consistent naming scheme:

  common/... # all common stuff

Thus the m68k example would be:


But I haven't heard any word from porters (m68k, alpha, powerpc,
sparc) on how they feel on this, nor have I utterly gone thru the
details on how we could implement this for file searching in

.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>

Reply to: