From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sun, 30 Jun 2013 10:06:06 +0200 From: tlaronde@polynum.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20130630080606.GA488@polynum.com> References: <9BC2CD34-5485-4EAD-A60C-E37EFB73DF4C@gmail.com> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.2.3i Content-Type: multipart/mixed; boundary=x+6KMIRAuhnl3hBn Content-Disposition: inline Subject: Re: [9fans] Install Advice requested Topicbox-Message-UUID: 69c74a76-ead8-11e9-9d60-3106f5b1d025 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jun 30, 2013 at 02:31:44AM -0400, Terry Wendt wrote: > > I copied the plan9.iso over to the plan9 partition, and even copied > all the files and directories as well. The plan9 partition is not an uniq filesystem but a slice of the disk allocated to plan9 and organized in several sub-partitions, with the first one being a fat partition. It is unlikely, a priori, that simply "copying" a plan iso to "the" plan9 partition will give the plan9 install any data it can access. I attach to the message a "howto" I wrote when I had to install Plan9 on a host with no CD drive. It is not to be used mandatorily if your CD/DVD works, but it will give you clues about the organization of the plan9 slice. HTH, -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="boot.txt" 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.] --x+6KMIRAuhnl3hBn--