Re: image file names (was Re: boot-floppies tasks)
Adam Di Carlo wrote:
>
> >> 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
> >resc1440.bin.
>
> 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...
rescue image & drivers archive names are build dynamically from several boot
infos, like boot args, kernel revision, processor type,... They are somewhat
architecture specific (except for the kernel revision feature).
For example, when tecra is passed on kernel command line (I hope syslinux do
that for tecra bootdisks), dbootstrap is searching for resc1440tecra.bin &
driverstecra.tgz. Take a look at setup_image_names() in main.c.
> >> >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
> system).
>
> 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:
>
> common/modules.tgz
> common/base2_2.tgz
> disks-1.44/rescue.bin
> disks-1.44/base-1.bin
> ...
>
> But m68k does something like:
>
> atari/resc1220.bin
>
> I don't know -- I guess we should adopt a consistent naming scheme:
>
> common/... # all common stuff
> [subarch/][disk-size/]image-name
>
> Thus the m68k example would be:
>
> atari/disks-1.20/rescue.bin
> atari/disks-1.44/rescue.bin
> ...
>
> 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
> dbootstrap.
sparc is providing 2 set of rescue/drivers disks: one for sun4[cdm] and one for
sun4u (ultrasparc). The former have no suffix hardcoded in names (just
resc1440.bin and drv14-1.bin) and the latter contain -sun4u part
(resc1440-sun4u.bin, drv14-sun4u-1.bin, ...).
We could put them under sparc/ and ultra/ subdirectories:
sparc/rescue.bin
sparc/drivers.tgz
ultra/rescue.bin
ultra/drivers.tgz
...
But sparc is also distributed with many network boot files:
tftpboot.img boot both sun4[cdm] & sun4u
tftpboot-noultra.img boot only sun4[cdm]
linux a.out kernel (sun4[cdm]) for tftp boot+nfsroot
linux-sun4u a.out kernel (sun4u) for tftp boot+nfsroot
root.tar.gz nfsroot archive to put on some server
Where those files will go in your name scheme?
--
Eric Delaunay | "La guerre justifie l'existence des militaires.
delaunay@lix.polytechnique.fr | En les supprimant." Henri Jeanson (1900-1970)
Reply to: