Re: Hamm on UDB?

[Loic Prylli <Loic.Prylli@ens-lyon.fr>]

Bdale Garbee writes:
 > 
 > I've copied the contents of ~lprylli/public_html/axp/bf980630/ on master to
 > the hamm/disks-alpha/1998-06-30 directory.  I have also updated the README
 > files, and removed the 1997-06-08 and 1997-08-12 trees.  

Thanks, guess it helped having people to test it, actually the bugs that were
revealed are quite problematic, so I suggest to replace that directory
with the contents of
  ~lprylli/public_html/axp/bf980702 (on master.debian.org),
and also to put the new
 ~lprylli/public_html/axp/README (thanks to Kristoffer Rose and Wim
Vandeputte for their suggestions).

Although there are still some issues, this new set 
seems to work much better.

 > Someone suggested at one point that we might want to have a different
 > subdirectory per machine type, leaving the root of each tree to contain just
 > the pieces that work on all AXP machines.  I'm not sure that really makes
 > things any clearer than to just name the files the way they are being named
 > now... so I'm leaving it all in one place.

I suggested it some time ago, the simple names are needed when used by
the installation process, as Kristoffer suggested to me:
  please name the images in a way that is
  useful also on the CD-ROM later, or by NFS, i.e., use the following
  structure: 
  
  	root1440.bin
  	base2_0.tgz
  	base14-1.bin
  	...
  	avanti/resc1440.bin
  	avanti/drv1440.bin
  	...
  	xl/resc1440.bin
  	xl/drv1440.bin
  
  This way one can easily boot right, and the rescue/driver images suggested
  by the installation procedure will be intuitively clear.


 > ps:  Loic, should we be including the config files you're using to build the
 >      kernels along with the other stuff, as was done before?  Or, are they
 >      included in the rescue images in /boot/config-<ver> as in i386 land?  

Yes I will put there somewhere soon. Anyway kernel generation should
be probably coordinated with Christophe Chimelis, which did the work
on the kernel set. Where the previous kernels generated with some
scripts to allow a common configuration and maintain only a few lines
of changes for each architecture?

We also need to choose what we put in modules, the i386 kernels are
now very modular (for instance serial, nfs, all ethernet are modules),
only scsi which is needed to boot is not. Putting ethernet modular can
be useful, but then we need 2 floppies instead of 3 for network
installations.

Loic


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