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

second review (was: Re: first review of boot-floppies doc for sparc)



Adam Di Carlo wrote:
> 
> On Thu, 25 Feb 1999 00:16:19 +0100 (CET), Eric Delaunay <delaunay@lix.polytechnique.fr> said:
> 
> >   I'm starting reviewing the installation manual for sparc specific
> > parts.  I'm sorry but I just have printed material handy, not the
> > source therefore I'm unable to send you patches directly.
> 
> Wah.  Ok.
> 
> BTW, I just got an Ultra 5!!  Woo woo... so I'll be running
> Debian/Sparc very soon now.  You guys in the porter department need
> help?  Do you know where I can get a Debian/Sparc 2.1 CD?
> 
> 
> > Here are some comments:
> 
> > sec 5.3: Description of Installation System Files
> > -------------------------------------------------
> 
> > -- Root image is required to boot from floppy because it doesn't fit
> > on the rescue disk.  The root floppy should be made along with the
> > rescue floppy to boot from floppy (have to be documented on sec 5.8
> > too "Booting from floppies").
> 
> Well, there are plenty of other stuff wrong there.  I've added mention
> of the -2.2.1 and the -2.2.1-sun4u disks.  It's obvious why someone

Thanks, I forgot to mention it.

> might need to run the sun4u disks; but why would they need the 2.2.1
> disks, just for that newer kernel support?  BTW, I've sync'd up this
> file naming to use the actual altkver variable from the top level
> makefile, cute, eh?

2.0.35 is the main kernel for slink but we also provide 2.2.1 for users who
want to switch to 2.2 on their sun4[cdm].  2.2.1 support was required for
ultrasparc, so I added it for other sparces too.  I just tried it at one time
but don't have much experience with its reliability and other related bugs in
the distribution.
Anyways, I guess it is a real improvement for sun4c users (sparc1,1+,2)
because it fixes the slowdown bug on disk access.

> > sec 5.7: Installing from NFS ----------------------------
> 
> > rescue & drivers images could be also installed from NFS if the
> > network is configured first.  It is important if installation is
> > done for a workstation without floppy and cdrom drives (tftp boot).
> 
> Huh.... how is different from the tftp options?  Or is it the same?
> Where can I get more information about this?

You don't need to put them in the same directory as the tftpboot image, if
it's what you think about.  Just put them on an accessible NFS server, like
the base archive.  Anyways, I checked your new text and found your wording
fine.

> > sec 5.8: Booting from Floppies ------------------------------
> 
> > Create the rescue & root disks then insert the rescue disk first in
> > the drive.  Type "boot floppy" or "boot /fd" (for old PROMs) at the
> > monitor prompt to boot from the rescue disk.  After the kernel is
> > loaded, the disk is ejected, and the kernel is waiting for the root
> > disk to be inserted.
> 
> Ah.  Ok... so the rescue floppy *requires* also a separate root
> floppy.  Added a new switch for this, enabled for sparc.

Thanks.

> Don't you have to select one of the 'ramdisk' methods?

No, after the rescue floppy was loaded, the kernel starts booting then ask for
the root floppy.  If the drive is autoeject, the first floppy is ejected
before asking for the next one.  This is the default when booting from floppy.

> > 7.4: "Configure the Keyboard" ----------------------------- this
> > step still appears even if no keyboard is connected to the host (eg.
> > booting on serial console).  It is a bug but it will not be fixed
> > before the release.  A message like "Cannot open /dev/tty0." is
> > displayed when trying to load a keymap on inexistent device.
> 
> Ugh, yeah, ok.  Is there a bug number open for this?  Could you open
> one and tell me the bug#?

I will post it immediately.  Get the bug number from the debian-boot list...

> Aren't there special boot parameters you have to use for serial
> console booting?  

Not usually: it is autodetected by init from kernel console device (/dev/cua0
for 2.0 kernel and /dev/console for 2.2).
You may need to set input-device & output-device variables of OpenPROM to ttya
to be able to boot on serial console if the workstation is also connected to a
keyboard/framebuffer.  An alternate way is to pass "console=ttya" on the
kernel command line.

> > NB2: step 7.14 "Make Linux Bootable Directly From Hard Disk" is not
> > available to this kind of installation.
> 
> By "this kind" you mean nfs-root?  Does dbootstrap actually skip this
> step for nfs-root?

Oh, yes, this it what it means ;-)

> > You can still create a rescue floppy but the best way to reboot on
> > the newly installed system is to reconfigure the server on which you
> > have installed the root fs (assuming it is the one you boot from):
> > symlink from linux-a.out to <CLIENT IP ADDR IN HEX FORM>.SUN4<TYPE>
> > in /boot symlink from /tftpboot/client_root_fs_top_dir to <CLIENT IP
> > ADDR IN QUAD DOTTED FORM>
> 
> > The reboot the client.
> 
> Um, well, on a sparc you have to tell the OpenProm to boot from the
> network by default, right?

This is the default if you don't have a local disk, otherwise you can enter
"boot net" at the monitor prompt to temporarily boot from the network or
change the "boot-device" variable to "net" to permanently override the
defaults.

> tftp server configuration is already described in ``<sect
> id="install-tftp">Booting from <prgn>tftp</prgn>'', isn't it?
>
> Made some pointers from this section to the other relevant sections.

It is closer to "tftp install for lowmem..." because you don't want to load
the ramdisk anymore but boot from the newly created nfs-root fs.  You then
need to replace the symlink to the tftpboot image by a symlink to the kernel
image (eg. linux-a.out).

My experience on booting over the network was based exclusively on RARP/TFTP
which requires all daemons running on the same server (the sparc workstation
is sending a tftp request back to the server that replied to it's previous
rarp request).  However linux is supporting BOOTP protocol too but I don't
know how to set it up :-((  Do it have to be documented as well in this manual?


> > 7.9: "Install Operating system Kernel and Modules"
> > --------------------------------------------------
> 
> > If you want to install rescue & drivers images from NFS, you need to
> > configure the network first (already done if installing for diskless
> > workstation but not in other cases).  A new entry "nfs : NFS
> > (network filesystem)" will be added to the end of the list of
> > devices from which you can install the kernel & modules.  Selecting
> > it further display a new box to enter the path to the NFS server.
> > resc1440.bin & drv1440.bin should be available on this server.
> 
> Ah... ok... added...

Could you add a note about "Broken loop device detected. Copy to local before
processing..." message ?
In effect the loop device is not working over NFS, therefore the rescue &
drivers images are copied to the local disk (if any) before mounting them via
the loop service.  If no local disk is available (diskless installation), they
are loaded into a ramdisk.
NB: I didn't check the amount of memory required to complete this step, but
    8MB should be sufficient IMHO (the installation I done was on a 24MB
	SparcClassic).

> Yes, we need to iron out and probably correct the tftp, nfsroot, etc,
> stuff.  We need to talk more about how users cna figure out their own
> architecture (pointing to the sparc/linux faq is probably ok) -- we
> probably could use more external pointers in the "where to go for
> further reading section".  Documenation for ultra folks.
> 
> Oh, and SILO!

The doc for SILO is in /usr/doc/silo in the base system.
The primary site for ultrasparc is sunsite.mff.cuni.cz.  Don't remember the
main page however.  You will have look at the site yourself, sorry ;-(
I guess it is more up-to-date than www.geog.ubc.ca.  The latter was not
updated for months :-((

I will be out of my home from tomorrow until sunday night.  I don't know if I
will have time to check the doc again.  Anyways you have done a good job,
Adam. Many thanks to you.

BTW, what should be done to upload the new doc in each disks-<arch> directory?
Should I rebuild & upload a new set of bootdisks even if it don't fix anything
but the doc ?

Regards.

PS: I found another outdated information in sec "2.1.2 CPU, Mainboards, and
    Video Support": sun4u is now supported by Debian/sparc :-))

-- 
 Eric Delaunay                 | "La guerre justifie l'existence des militaires.
 delaunay@lix.polytechnique.fr | En les supprimant." Henri Jeanson (1900-1970)


Reply to: