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

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

On 22 Nov 1999, Adam Di Carlo wrote:
> > 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, ...).

For consistency with alpha, powerpc, and m68k you should use sub-arches.

> BTW, I note we have sun4c kernels in base... will that be a subarch?

> > 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?
> Ok, my scheme is now:
>  [special/][subarch/]disks/file
> And this goes in 'dists/unstable/main/disks-sparc' as per usual.
> So for spare we would have:
>   # stuff that applies to all arches
>   common/tftpboot.img  # should be in common subdir?
>   common/root.tar.gz   # should be in common subdir?
>   common/root.bin
>   # sun4[cdm] only
>   sun4cdm/common/drivers.tgz
>   sun4cdm/common/tftpboot.img # was tftpboot-noultra.img
>   sun4cdm/common/linux
>   sun4cdm/disks-1.44/rescue.bin
>   sun4cdm/disks-1.44/driver-1.bin
>   sun4cdm/disks-1.44/driver-2.bin ...
>   sun4cdm/disks-1.44/base-1.bin ...
>   # sun4u only
>   sun4u/common/linux
>   sun4u/common/drivers.tgz
>   sun4u/disks-1.44/rescue.bin
>   sun4u/disks-1.44/driver-1.bin
>   sun4u/disks-1.44/driver-2.bin ...
>   sun4u/disks-1.44/base-1.bin ...

I would be tempted to leave out the first common/
i.e.,	disks-sparc/tftpboot.img

> Is this too many directories?  Obviously a downside here is that we
> don't have single directories with all the needed stuff in it...
> Obviously, dbootstrap would need a "fallback system":
>   * look for [special/][subarch/]disks/file
>   * look for [special/][subarch/]common/file
>   * look for [special/]common/file
>   * look for common/file
> Is this sounding functional or ... ?

It is probably just my ignorance about how dbootstrap works...
but doesn't it know what system it is installing?
and if it does... why not just build the worst case path.
So, if wants to find root.bin and is installing an i386, raid system
that needs the safe option, from 1.44M floppies... it would build:
Now, lets say that the root.bin file is common to all i386 systems...
(at this point I don't care if this reflects the reality of i386,
it is a worst case example that could apply to any platform)
I would expect dbootstrap, upon failing to find the file, to back up one
directory and try again... and keep doing so until it found the file.


or, Adam, have I just repeated what you wrote (wrt fallback)?

- Bruce

Reply to: