[9fans] [RFC] How to install without

[9fans] [RFC] How to install without

[tlaronde]

Since it seems that Iruatã Souza, who had accepted to give a second look
at what I wrote, is as short on time as I am, here is for review an
explanation about "how to do [an install] without". [Still TODO: fix
disk/fdisk.]


       Installing Plan9 without a CD reader or a PXE boot.

                            Abstract

The Plan9 distribution is available for installation by the mean of a
bootable ISO image supposed to be burnt on a CDROM. But this image has
indeed all the pieces needed to realize an installation, without a CD
reader, or without a PXE boot.

What follows is an illustration of "how to do without".

0. What was first? The egg or the goose? Well: the egg, that is some
BIOS.

In the following, the names will match the pc world; but, more or less,
there is a mapping between pc idiosynchrasies and something else
idiosynchrasies.

When a pc starts, it first initializes its hardware before giving the
hand to an user provided program---generally an operating system. But to
be able to hand over to something else, it has to know the rendez-vous
point. This BIOS entry point is a 512 bytes sector, that is a program,
and that is (for disks and like) the very first sector of the device.

On disks, it is called: MBR. It is a program with a signature (for basic
verification that it is indeed the expected program), and some data 
embedded: a partition table.

To be able to boot Plan9, the information has to be in the MBR, this
means that the first sector must be able to hand over to another program
(generally one sector size too) customized for Plan9.

Since the partition table has 4 entries, for things to work, the
MBR program must be able to read the partition table and load the
very first sector of one partition, whether because it is flagged:
ACTIVE, or because the MBR allows to select it. The only Plan9
peculiar thing in the MBR is not the program by itself (the MBR
provided by other systems will generally do the job), but a Plan9
entry in the partition table. 

Plan9 has to have a _primary_ partition (and not a secondary "extended"
---indirect---one that the bootstrapping blocks will not be able to
access).

Recommended reading: 9load(8).

1. Defining a Plan9 partition (MBR partition table).

As the name: partition, shall suggest, the 1 to 4 (max) primary
partitions shall realize a partition of the disk: the reunion covers the
whole disk; and there is no overlapping. One supplementary property: a
partition is declared by its type (magic number proper to the system),
its beginning and its size. This means that a partition defines a
continuous slice of sectors.

Since this partition table is what, due to hardware bootstrapping
design, is shared between different systems (multi-boot), the partition
shall declare what is each system realm in terms of space used on the
disk; and let others realms alone. (In what follows, since we will use
an already installed system to prepare for Plan9, this will be
relaxed---but as an exception and with caution.)

So the first step is to declare enough space for a Plan9 realm (for what
follows, since we do not reduce the size of the installed data and
declare 100Mb for the particular 9fat, say: 512Mb at least---this can be
reduced once you know how it works, or if you install only a terminal).
So declare a primary partition as a Plan9 : 0x39 type, with (here) at
least 512Mb. You can do that with whatever fdisk(8) is available on the
"other" system.

But do repeat: the Plan9 partition is a partition, that is do not have
any intersection (of data) with others. Plan9 can write whatever it
wants in its realm without risking overwriting others data.

Recommended reading: prep(8).

2. The Plan9 partition realm: its organization.

Fdisk(8) has declared a Plan9 realm. But this realm is, as far as
fdisk(8) and the MBR are concerned, just a continuous area of disks
blocks. There is no organization of the blocks; no data in the blocks.
It is a virgin (read: random) area.

So even if the Plan9 partition is declared active (or if the boot
process allows to select it), this will not magically work, since the
very first sector of the Plan9 partition is, at this moment, random
bytes, not a dedicated sector able to bootstrap Plan9.

We need so to organize a part of the realm the way Plan9 and the Plan9
bootstrapping process expects it to be.

The conditions that have to be met are the following:

1) The very beginning of the Plan9 partition coincides with the
beginning of a FAT12 or FAT16 subpartition.

2) This FAT has 2 reserved sectors: the first one is the "classical" FAT
sector; the second one will hold the informations about the Plan9
partition subpartionning.

3) The very first sector (of the Plan9 partition and so of the FAT too)
has a Plan9 PBS---a Plan9 bootstrapping block.

4) The volid field of the FAT first block is set with the address of
the beginning of the root dir.

5) The program 9load exists in the FAT and is the very first entry
in the root dir.

6) [Not necessary for bootstrapping] So that 5) remains true, the 9load
file must be tagged SYSTEM, so that it is not moved when updating.

7) That other files: a Plan9 kernel with an embedded root file system,
the Plan9.ini and the vgadb be there.

8) That the existence of the FAT subpartition be declared so Plan9 
knows that it is already there.

This could seem complicated at first, but indeed the majority of "other"
systems have the utils to set this.

Recommended reading: 9load(8), disk/format.c.

3. Illustration of what has to be done with a NetBSD system.

We will show below an implementation of the steps using NetBSD utils
(all default provided ones).

Do note that under Unices, for the most part, you will need to be root
(or to use dedicated tricks to work as an unprivileged user).

First we create (assuming there is room in some disk) a Plan9 partition.
Basic usage of fdisk(8).

To avoid using brutally dd(1) on the whole disk, we will make the first
part of this partition, that will be a FAT16 file system, visible for
NetBSD. (This is the temporary exception signalled above.)

To do this, we simply add an entry in the disklabel of the very disk
where Plan9 is declared and will be installed. The disklabel is like
Plan9 partitionning: NetBSD sees only what is declared in its disklabel
and it is partly orthogonal to what is declared in the MBR (this is
both handy and dangerous if one plays too much with the possibilities).

Here, we have declared a Plan9 partition on wd0, with the following
characteristics:

0: Plan 9, or Theos spanned (sysid 57)
    bootmenu: Plan9
    start 63, size 2232972 (1090 MB, Cyls 0-138)

Plan9 is the very first primary partition, starting at sector 63, with
a size of 1090MB. (The values are not mandatory; it could another
offset, and another size.)

We will create a FAT16 of 100MB (to put the iso image in it; there are
more than one way to do combining the commands described below). This
FAT16 has to coincide with the very beginning of the Plan9 partition; so
_here_ sector 63.

We declare this in the disklabel, adding an entry (here the 'n') using
disklabel(8) on wd0:

 n:    204800        63      MSDOS                     # (Cyl.      0*-    203*)

So it starts at 63, is MSDOS and is 204800 blocks (so far less than
the whole plan9 partition, but _inside_ the Plan9 partition: check and
recheck; we will format and write so it has to be a scratch zone!).

>From now on, we will be able to use this dedicated area, and to 
constrain for some safety, the actions to this area, we will be using 
/dev/wd0n or /dev/rwd0n.

disk=wd0
part=n
dev=/dev/r${disk}$part

Before formatting (disklabel declares subpartitions but does no
formatting), we will need to retrieve Plan9 PBS and 9load.

Where to find them? In the ISO image.

The ISO image is an ISO file system in the form of an uniq file. To read
it, one has simply to find the way on the system to treat a file as
a disk. Under Plan9 this is partfs(8). Under NetBSD, this is
vnconfig(8).

So assuming the ISO is in $plan9iso (uncompressed), and a mount point 
/cdrom exists:

vnconfig -c vnd0 $plan9iso
mount -t cd9660 /dev/vnd0d /cdrom

Now you have access to all the iso files under (here) /cdrom.

One file will be of special interest: bootdisk.img. What is it?

The CD is "bootable" using El Torito BIOS extensions. When the BIOS
supports this, it can present a "file" (here: bootdisk.img) as a floppy
(of whatever size, from 5"1/4 to the diverse 3"1/2; commonly, 1.44MB or
2.88MB---the latter here) or even as a hd (I have not seen this
implemented yet; this is in the spec, but in the real?).

When the PC boots, the BIOS tricks to offer this data as a fd# or hd#.
This explains why, sometimes, the CD boots---user cries: Hurrah! my
hardware is recognized!---but when the system, on the CD, takes the
hand, it panics, unable to read the CD! That's because the initial
programs use the BIOS, and use a fd# that is a fake one, accessing it
via the BIOS, while when the system takes the hand and doesn't use 
anymore the BIOS services (DOS was using BIOS...), if it has not the
drivers, it doesn't know how to access.

So this image, that is a FAT filesystem, we will explore it too. Same
process (assuming a mount point named /floppy, for illustration):

vnconfig -c vnd1 /cdrom/bootdisk.img
mount -t msdos /dev/vnd01 /floppy

This image is a FAT, has what we need. So why not simply dd(1) it to the
beginning of the Plan9 partition and been done with it? For 3 reasons:

1) This is a 2.88Mb file system. A bit short if we want to put extra
stuff.

2) There is a field that has to be set with the correct address: the
volid. This value is not the correct one, unless we dd(8) on the MBR,
which I do not recommend...

3) The PBS has to bootstrap a diskette, so is not an LBA aware one. On a
disk, the Plan9 partition can be a far, far, far, far realm...

So now we have all what is needed to format the FAT16. First, we will
occupy ourselves with the PBS, taking the lba flavour. One caveat,
though: it has not the signature and it has to be there (for NetBSD
newfs_msdos(8); other programs may handle this by themselves). So we 
add it:

cat /cdrom/386/pbslba /dev/zero | dd of=/tmp/pbs count=1 bs=510 conv=notrunc
printf "\x55\xAA" >>/tmp/pbs

Next, we need to compute some numbers: the fatsize, and the volid. The
details can be found in disk/format.c. The offset is the offset of the
first sector of the FAT (== first sector of the plan9 partition); the
partsizebk, is the size in 512 blocks; these 2 informations were given
above in the disklabel:

 n:    204800        63      MSDOS                     # (Cyl.      0*-    203*)

So _here_ (has to be adapted):

disk=wd0
part=n
offset=63
partsizebk=204800

Then:

fatsize=$(( (16 * ($partsizebk / 4) + 8 * 512 - 1 ) / ( 8 * 512 ) ))
volid=$(( $offset + 2 * $fatsize + 2 ))

We have all the informations to format the Plan9 FAT subpartition
(9fat):

newfs_msdos -B /tmp/pbs\
	-F 16 -S 512 -b 2048 -a $fatsize -r 2 -I $volid /dev/r${disk}$part


We add the information about the 9fat in Plan9 partition sector (the 2nd
reserved one):

printf "part %s %d %d\n" 9fat 0 $partsizebk\
	| dd of=/dev/${disk}$part seek=1 conv=notrunc

We have now a FAT ready that we can mount:

mount -t msdos /dev/${disk}$part /mnt

We copy 9load first (see 5):

cp /floppy/9load /mnt

Then the rest:

cd /floppy
cp 9pc* plan9.ini vgadb /mnt

We add the bzip2 iso image (we could put it elsewhere, or even retrieve
it by network etc.):

cat $plan9iso | bzip2 >/mnt/plan9.iso.bz2

Unmount everything:

umount /mnt
umount /floppy
vnconfig -u vnd1
umount /cdrom
vnconfig -u vnd0

And finally, for cleanliness, set the SYS flag (plus archive) on 9load 
in 9fat:

printf "\x24"\
	| dd of=/dev/${disk}$part conv=notrunc\
		seek=$(((2 * $fatsize + 2) * 512 + 32 + 11)) bs=1 count=1

Now, you have a bootable Plan9. And you will discover that the
all-in-one 9pcflop.gz (a Plan9 kernel and a small root fs) has already
a lot, a lot, a lot of possibilities in a very small size. So keeping
it will make a repair tool very handy.

[Note: the installation scripts have to be adapted, since they assume
that if 9fat is here, everything is already set. This is wrong after the
above procedure.]

-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C