Booting OpenBSD on a Flash Card
4 June 2007
In building a pair of
firewalls,
I wanted to minimize points of failure. Hard drives are one of the most
failure-prone components of a server, and since a dedicated firewall
doesn't
need gigabytes of storage, I went with
storage with an IDE-to-CF adapter. This vignette quickly explains how
to
prepare a flash card to boot OpenBSD. I plan to address the larger
issue of
building dedicated, redundant OpenBSD firewalls in a separate article.
The OpenBSD boot process can be a bit daunting to the newcomer. Though
there's plenty of detailed documentation that explains how things work,
piecing it together for an embedded application such as this can take a
while
unless you know what you're doing. Though I give a little recipe of
sorts
here, I'll add the disclaimer that every system configuration is a
little
different and blindly entering commands without some understanding and
verification of what they do can only get you into trouble!
There are basically four things that need to happen to prepare a disk
for
booting a kernel:
- Write a master boot record (MBR) and partition table;
- Edit the disk label to define the partitions for OpenBSD;
- Initialize the filesystem; and
- Copy and "install" the boot loader on the card.
Once these things are done, you can copy over a kernel, files, etc., but
that's all beyond the scope of this discussion.
First, some background about the hardware. I've got an old laptop I'm
using
to stage the flash cards before installing them in the firewalls. The
cards
are 256 meg SanDisk Compact Flash cards, though these instructions
should
apply to just about any size or flavor of card. (I did run into trouble
on
my firewall machines with newer cards that support direct memory access
(DMA):
though they worked fine with both the PCMCIA adapter and a USB reader,
some
IDE-to-CF adapters don't support DMA and, unless the motherboard's BIOS
can be configured to disable DMA, they will either run very
slowly or
won't work at all.)
![Compact Flash card.]()
Compact Flash card.
For accessing the card on my staging laptop, I'm using a SanDisk Compact
Flash PC Card adapter, which slides right into the laptop. USB adapters
will
also work, but note that disk device name may be slightly different than
the
example here.
![Compact Flash PCMCIA adapter.]()
Compact Flash
PC Card (PCMCIA) adapter.
Next, a few handy reference links that will explain the below commands
in
much more detail. If you run into problems, or you don't understand
what's
going on, these should help (somewhat specific to the i386 platform):
- : Instructions for managing disks under OpenBSD.
- : MBR partition maintenance program.
- : Install, examine, or modify the label on a
disk drive.
- : Install a "first-stage" boot
program into the boot area of a disk partition.
- : i386-specific "first-stage" boot
program.
- : i386-specific "second-stage" boot
program.
Now, on to business. Go ahead and plug in your flash card - USB,
PCMCIA,
whatever. The OpenBSD kernel should print some messages indicating that
it's
recognized the hardware, similar to:
wdc2 at pcmcia1 function 0 "SanDisk, SDP, 5/3 0.6" port 0xa000/16
wd1 at wdc2 channel 0 drive 0:
wd1: 1-sector PIO, LBA, 245MB, 501760 sectors
wd1(wdc2:0:0): using BIOS timings
You need to take note of the device name, which will probably start with
either wd or sd. For example, if you're doing this on a
laptop
with a single IDE hard drive using a PCMCIA adapter, the device is going
to
be wd1 (since wd0 is already taken by your hard drive). On the
other
hand, if you're using a USB adapter, the device is going to be sd0
(since you don't have any other SCSI disks). Of course, your particular
mix
of drives and devices is going to determine the device name: make
certain that
the device name you use in the below commands is indeed the flash card!
I'll
be using wd1 in the example.
All of the below commands must be run as root (or under sudo). Be sure
to
replace wd1 with your card's device name!
- Initialize the master boot record partition data:
fdisk -i wd1
If you want to see what's on the device without changing anything, just
run:
fdisk wd1
Frequently it's instructive to view the partitions with this command
both before
and after updating the MBR. On a virgin flash card, you'll probably see
one DOS partition; on an updated card, you'll see one OpenBSD partition.
- Edit the disk label, deleting any existing partitions and
adding a
4.2BSD partition for the whole card (or however you want to divide it
up, but the rest of these instructions assume a single 'a'
partition):
disklabel -E wd1
Print the existing partitions with the command 'p'; delete, for example,
an
existing 'a' partition with 'd a'. Don't delete partition 'c'
-
that's necessary and always present. Add a new 'a' partition
with
'a a'; it should be of type '4.2BSD' (the default values the add command
offers should be fine). The '?' or 'h' commands print some help. Quit
the
utility and write the new label with the 'q' command. You can print out
the
disk label without changing anything using:
disklabel wd1
Again, it's sometimes handy to print the label both before and after
your
changes to see what's going on.
- Initialize a filesystem on the 'a' partition (note
that we append
the partition letter to the device name):
newfs /dev/wd1a
- Create a mount point on your staging machine for the card:
mkdir /flash
Note that /mnt is used by some small-footprint OpenBSD distributions
(e.g.,
)
while
building, so it might not be a good choice for your mount point.
- Mount your partition. We'll use a couple of options to
minimize writes
to the card and just to be conservative:
mount -o sync,noatime /dev/wd1a /flash
- Copy the boot loader over to the flash card:
cp -p /usr/mdec/boot /flash
- Tell the MBR where on the disk your boot loader is:
cd /usr/mdec; ./installboot /flash/boot biosboot wd1
Slight aside: One thing that concerned me about this command is the
"/flash/boot" parameter: given all of the examples I had read, I wasn't
sure
if prepending the mount point was going to work since the disk is
mounted as
"/" on the firewalls. However, what matter here are the file's block
and
inode on the disk, not its path. This part of the boot process happens
before mount points come into play.
The drive is now bootable; all that remains is to give it a kernel to
boot.
Ordinarily this means copying a kernel to "/flash/bsd". or are two
packages useful in creating a kernel appropriate for booting off of a
flash card.
第二篇
| from the keep-it-simple dept.
On Tue, 30 Mar 2010 17:13:55 -0500 Ron McDowell wrote:
> Hi J.C., anytime anyone has posted to misc@ asking about how to build
> a bootable install image on a USB stick, there is much vitriol and
> little information, so I'm asking privately.
>
> I've got a DOS formatted 2GB USB stick seen as sd0, and
> a /usr/release directory full of stuff made by 'make release':
>
> In the past I have used unetbootin from an XP box to build one from
> installXX.iso, but others on the list claim it's so easy to do... but
> never tell how.
>
> Frustrating.
>
Thanks Ron for giving me permission to put this up on undeadly.
When your goal is to create USB Flash Stick install media, the
typical terse
response of, "Just do a normal installation," can be real
frustrating
without further explanation. Part of the frustration is being told
to make
other install media (floppy/CD) to make the desired install media
(usb flash).
The trouble is, you're essentially looking to create a problem where
none
exists, and worse, a detailed explanation like the one below might
scare
people away rather than show them how simple the suggested way of
doing it
is. When you combine this with the normal standing against blind
"How-To" recipes, we'll be spending time going into the torrid
details without gaining much of anything.
Let's start with the suggested way to create a bootable USB flash
stick as
stated in
.
- Do a normal installation of OpenBSD to your flash stick.
- Copy the install set files to the device.
- Copy bsd.rd to the root partition.
The result is you can both run the operating system from the stick
and
install the operating system from the stick. To do an installation,
at
the "boot>" prompt type in "bsd.rd"
and then do the installation normally. As suggested in FAQ.14, you
can copy
over the install set files for both i386 and amd64 so you'll be able
to
install either from the same device.
There is endless debate regarding "wear leveling" issues on flash
based storage devices. If you get the wild idea to avoid the "wear
leveling" by doing something weird, you will probably do it wrong,
and
the result will be an unreliable system.
Explaining why the above is the suggested best practice is where
things
start to get complicated. The short answer is, a default
installation
process of OpenBSD contains a whole lot of know-how applied in an
attempt to
get things right. More importantly, if it's not right, you want to
find out
about problems quickly, and having a full installation of OpenBSD
gives you
the best chance of figuring out if your hardware is reliable.
Even a very lengthy long answer would be incomplete, so if you want
to
understand all the details, you are better off reading the source.
Below
will only cover some of the most basic aspsect of flash storage
devices, and
provide a less reliable answer to the qeustion of how to make
bootable
install media with them.
USB flash sticks are the modern equivalent of unreliable floppy
diskettes.
Though flash devices often work, they are not as reliable as other
storage
devices like hard disks. Similar can be said for Compact Flash,
{mini,
micro, pico, nano, femto, whatever}SD, supposedly SmartMedia, and
all the
rest of the related flash based storage devices, even including some
of the
Solid State Disks (SSD) currently available.
Part of the reliability problem is caused by the high-volume,
low-cost,
and poor-quality manufacturing of the devices and their components.
They are
designed to be inexpensive and compatible with existing systems, but
to
achieve these goals, significant trade-offs were made. Some would
even say
the trade-offs resulted in very poor design decisions. The most
obvious of
these trade-offs is the fact flash devices are treated as "disks"
by both the system and the software, when internally, they are very
different from disks.
Another issue with flash storage devices is inconsistency. Since
flash
storage devices are put together in countless different ways, and
use
countless different kludges to appear as "disks" to the system,
having both the system and software treat them as disks is a risky
proposition. It doesn't always work, and if you test enough devices,
you'll
find some combinations of systems, software and devices which simply
refuse
to work.
When you're talking about hardware so cheap that people give it away
as advertisements at trade shows (like 4+ GB flash sticks), the
probability of it being good enough to work reliably is so close to
zero
it's negligible. Many of the flash sticks you own only seem
to work
correctly when you run
(MBR partition table partitions),
(filesystem partitions),
,
, copy, move, delete and whatever, but often they fail
miserably if you run
on them or do any other serious file integrity checks
(e.g. ).
Sadly, this is very common, and you have to be more than a bit
strict to
catch this kind of shoddy hardware.
The problems with flash storage devices are magnified by the way
various
systems boot also being horribly inconsistent within a single
architecture.
Of course, this is magnified yet again due to the differences across
multiple
architectures.
Here's a classic example. If you take one of the floppy diskette
installation images like "floppy47.fs" and mindlessly
the floppy image onto a USB flash stick, there are at least a few
systems which actually can still boot from the resulting
monstrosity.
The resulting USB flash stick has no fdisk partition table (MBR),
but
since some rare systems are built to use USB-based floppy diskette
drives (e.g. some brands of laptops), they mistake the USB flash
stick
as being a floppy and continue to boot from it.
In this very messy situation, all possible "best methods" are
bad, and suggesting anything is unwise. The FAQ makes the
suggestion it does only because it's your best chance at getting
things
working in a reliable fashion.
If you insist on shooting yourself in the foot through manual
attempts
to make bootable flash sticks, below is the target practice yours
truly
did on his own feet.
First you want to read
and
,
the set up your fdisk partition table and MBR
# fdisk -iy sd0
Writing MBR at offset 0.
Next, you want to read
and read
again.
You'll want to delete all the existing disklabel partitions and
create a new "a" partition accepting the defaults so it
covers the whole disk. By default, the first "track" is
skipped (offset: [63]), even though tacks don't actually exist on
flash
based storage.
# disklabel -E sd0
Label editor (enter '?' for help at any prompt)
> p m
OpenBSD area: 63-4160835; size: 2031.6M; free: 0.0M
# size offset fstype [fsize bsize cpg]
c: 2035.0M 0 unused
i: 2031.6M 63 MSDOS
> d *
> a a
offset: [63]
size: [4160772]
FS type: [4.2BSD]
> p m
OpenBSD area: 63-4160835; size: 2031.6M; free: 0.0M
# size offset fstype [fsize bsize cpg]
a: 2031.6M 63 4.2BSD 2048 16384 1
c: 2035.0M 0 unused
> q
Write new label?: [y] y
Next we toss a file system (ffs) on the new partition.
# newfs /dev/rsd0a
/dev/rsd0a: 2031.6MB in 4160772 sectors of 512 bytes
11 cylinder groups of 202.47MB, 12958 blocks, 25984 inodes each
super-block backups (for fsck -b #) at:
32, 414688, 829344, 1244000, 1658656, 2073312, 2487968, 2902624, 3317280,
3731936, 4146592,
And finally we do a quick test with fsck(8) to make sure things are
working.
# fsck -fp /dev/rsd0a
/dev/rsd0a: BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN LAST ALTERNATE
/dev/rsd0a: UNEXPECTED INCONSISTENCY; RUN fsck_ffs MANUALLY.
Lovely. It seems we have a piece of junk, so unplug it and throw it
away.
"But But But But But I don't want to throw it
away!!!!"
Seriously, you are far better off throwing it away and spending your
time on more important things like making reliable hardware work for
you.
"But But But But But can't fsck fix it????"
The only fair answer is, "maybe," but this seldom works with
flash devices, and even if it does seem to work at first, it may
silently fail again immediately afterwards.
"But But But But But are you sure????"
Nothing is ever certain with flash storage devices, so if you insist
on
further target practice on your feet, you can try the following.
One of the tricks you can try is erasing the flash device entirely,
but
you need to realize the "erased state" for flash is when it is
filled with all 1's. People regularly make the mistake of filling
flash
based storage devices with all zeros (as is typically done with real
disks) without every realizing what they are doing.
# tr '\000' '\377' < /dev/zero | dd bs=16384 of=/dev/rsd0c
dd: /dev/sd0c: end of device
130241+0 records in
130240+0 records out
2133852160 bytes transferred in 714.616 secs (2986009 bytes/sec)
The above doesn't consider what might be done to the input data of
all
1's by the disk controller of the system, the usb controller of the
system, or the super double secret flash controller on the device
itself. None the less, it's as close as you'll get to overwriting
the
whole device with 1's to put all the flash in the erase state. From
here, repeat the previous steps through doing your fsck test, but if
it
fails again, this time, just throw it away.
Assuming you were a bit more lucky than me and your device passed
fsck,
now it's time to make the flash stick device bootable.
# fsck -fp /dev/rsd0a
/dev/rsd0a: 1 files, 1 used, 967555 free (19 frags, 120942 blocks, 0.0% fragmentation)
# mount /dev/sd0a /mnt
# cp /usr/mdec/boot /mnt
# cp bsd.rd /mnt/bsd
# /usr/mdec/installboot -v /mnt/boot /usr/mdec/biosboot sd0
boot: /mnt/boot proto: /usr/mdec/biosboot device: /dev/rsd0c
/mnt/boot is 3 blocks x 16384 bytes
fs block shift 2; part offset 63; inode block 24, offset 936
using MBR partition 3: type 0xA6 offset 63
# umount /mnt
# fsck -fp /dev/rsd0a
/dev/rsd0a: 3 files, 3047 used, 964509 free (13 frags, 120562 blocks, 0.0% fragmentation)
One of the important things to note in the above is the use of
installboot(8) to make the device bootable is only correct for some
architectures. Other architectures need to use disklabel(8) to
properly install the first (and if needed second) stage bootstrap
code. Additionally, the second stage bootstrap loader,
,
/usr/mdec/boot file in the example above can be arch specific.
Although I'm yet to see the i386 boot(8) fail on amd64, mixing and
matching other archs will most likely make a real mess.
The minimal install set for i386 (from a snapshot or release) would
be:
# l files/
total 500060
drwxr-xr-x 2 root wheel 512 Mar 31 03:04:36 2010 ./
drwxr-xr-x 3 root wheel 512 Mar 30 15:48:38 2010 ../
-rw-r--r-- 1 root wheel 2162 Mar 30 15:48:52 2010 SHA256
-rw-r--r-- 1 root wheel 50551104 Mar 30 15:50:08 2010 base47.tgz
-rw-r--r-- 1 root wheel 7592844 Mar 30 15:49:56 2010 bsd
-rw-r--r-- 1 root wheel 7616392 Mar 30 15:49:54 2010 bsd.mp
-rw-r--r-- 1 root wheel 6304746 Mar 30 15:49:51 2010 bsd.rd
-rw-r--r-- 1 root wheel 92648166 Mar 30 15:49:43 2010 comp47.tgz
-rw-r--r-- 1 root wheel 514498 Mar 30 15:49:21 2010 etc47.tgz
-rw-r--r-- 1 root wheel 2618018 Mar 30 15:49:19 2010 game47.tgz
-rw-r--r-- 1 root wheel 9463948 Mar 30 15:49:17 2010 man47.tgz
-rw-r--r-- 1 root wheel 364819 Mar 30 15:49:16 2010 misc47.tgz
-rw-r--r-- 1 root wheel 15550317 Mar 30 15:49:12 2010 xbase47.tgz
-rw-r--r-- 1 root wheel 70053 Mar 30 15:49:10 2010 xetc47.tgz
-rw-r--r-- 1 root wheel 39684757 Mar 30 15:49:05 2010 xfont47.tgz
-rw-r--r-- 1 root wheel 19879062 Mar 30 15:48:53 2010 xserv47.tgz
-rw-r--r-- 1 root wheel 2946170 Mar 30 15:50:14 2010 xshare47.tgz
# du -h files/
244M files/
Without getting dangerously creative with newfs, a supposed "256
MByte" flash stick will only give you roughly 235 MByte of usable
space, so you'll need something larger to hold the minimum install
set
files. You'll want to put the install sets in the typical directory
(e.g.
/4.7/i386/) to keep from overwriting the kernel in / as well as make
your
life easy when installing from the device (e.g. the default location
where
the installer looks for the files).
# mount /dev/sd0a /mnt
# mkdir -p /mnt/`uname -r`/`uname -m`/
# cp files/* /mnt/`uname -r`/`uname -m`/
At this point, you should test the integrity of the files you
just
wrote to the flash stick as well as run fsck one more time.
# cd /mnt/4.7/i386
# for i in *; do grep -e "($i)" SHA256 >> ../sha ; done;
# cksum -c ../sha || echo "FAILED!!!"
(SHA256) base47.tgz: OK
(SHA256) bsd: OK
(SHA256) bsd.mp: OK
(SHA256) bsd.rd: OK
(SHA256) comp47.tgz: OK
(SHA256) etc47.tgz: OK
(SHA256) game47.tgz: OK
(SHA256) man47.tgz: OK
(SHA256) misc47.tgz: OK
(SHA256) xbase47.tgz: OK
(SHA256) xetc47.tgz: OK
(SHA256) xfont47.tgz: OK
(SHA256) xserv47.tgz: OK
(SHA256) xshare47.tgz: OK
# cd /
# umount /mnt
# fsck -fp /dev/rsd0a
/dev/rsd0a: 20 files, 128062 used, 839494 free (14 frags, 104935 blocks, 0.0% fragmentation)
Congratulations! You now have a supposedly bootable install media on
a USB
flash stick which might actually work for an unknown period of time
with
some, but not all, systems supposedly capable of booting some
unknown
percentage of USB flash devices.
Did I put enough weasel-words in the above statement to make you
nervous?
The simple method suggested in the FAQ of doing a normal
installation and
copying over the needed install set is a lot easier, is more
reilable, and
gives you more functionality. You will still occasionally hit
problems where
particular USB flash sticks and particular systems are incompatible,
but
luckily, the flash devices are now cheap enough where you can just
try
another one.
|
![[topiceditorial]](http://www.undeadly.org/images/topiceditorial.gif)
|
<< | |
|
| >>
|
|
| |
Re: Bootable Installation From USB Flash Sticks (mod 2/12)
by wim wauters ()
(undeadly@unisoftdesign.co.uk)
on Sun Apr 4 22:12:19 2010 (GMT)
|
| |
Excellent piece of work, but I'll be sticking to the FAQ :-)
|
| |
|
|
|
(1/7) by J.C. Roberts
on Sat Apr 10 23:39:34 2010 (GMT)
|
|
| |
Re: Bootable Installation From USB Flash Sticks (mod 6/8)
by paulo pereira ()
(vodoom@gmail.com) on Wed
Apr 14 15:23:03 2010 (GMT)
|
| |
good stuff.
you may want to update the disklabel link in your article (smalll typo).
|
| |
|
|
| |
Re: Bootable Installation From USB Flash Sticks (mod 2/10)
by Rolf Sommerhalder ()
on Thu Apr 15 06:44:24 2010 (GMT)
|
| |
Thank you for this article which helped me to improve my own
procedure.
Maybe you are interested in the hint to use "soft updates" option once
you (re-)mount the Flash before copying the large files to it, e.g.
mount -o softdep /dev/sd0a /mnt
I found that soft updates noticeably speeds up writing (a large number
of files) to both CompactFlash cards and USB sticks. Also, it may reduce
wear and tear somewhat, although that's not a big concern with
wear-leveling.
| |
第三篇
thanks to merdely and someone whose email i lost for some pointers
i got tired of rolling my own install CDs and wasting CD-Rs, so i wanted
to
make bootable, and be able to install openbsd from it.
but, i also wanted to be able to use it for storage too
from the somewhere (your system, ftp, etc) get:
you can get these files from your own system if you're using openbsd to
prepare the usb key
if your system is older and you want a newer version on the usb key,
either upgrade (long time) or grab baseXY.tgz and bsd.rd from ftp, then
extract /usr/mdec/boot & /usr/mdec/biosboot from baseXY.tgz
general overview
- get files
- nuke usb key
- partition key
- format partitions
- copy files onto partitions
- boot stuffz
- play!
on with it!
zero out the flash drive (if needed)
dd if=/dev/zero of=/dev/rsd0c bs=32k
then, make sure we get a completely fresh disk to work with by using
fdisk -i
$ sudo fdisk -i sd0
-----------------------------------------------------
------ ATTENTION - UPDATING MASTER BOOT RECORD ------
-----------------------------------------------------
Do you wish to write new MBR and partition table? [n] y
use fdisk to create partitions
$ sudo fdisk -e sd0
Enter 'help' for information
fdisk: 1> p m
Disk: sd0 geometry: 124/255/63 [974 Megabytes]
Offset: 0 Signature: 0xAA55
Starting Ending LBA Info:
#: id C H S - C H S [ start: size ]
------------------------------------------------------------------------
0: 00 0 0 0 - 0 0 0 [ 0: 0M] unused
1: 00 0 0 0 - 0 0 0 [ 0: 0M] unused
2: 00 0 0 0 - 0 0 0 [ 0: 0M] unused
*3: A6 0 1 1 - 123 254 63 [ 63: 973M] OpenBSD
we want 2 partitions. one that is fat32 (type 06) and another that is
ffs (type A6). the fat32 partition will be used for general storage and
the ffs partition will be used to house the openbsd installer. the
openbsd partition must start at the 32nd sector on the disk (C/H/S -
0/0/32)
fdisk:*1> p m
Disk: sd0 geometry: 124/255/63 [974 Megabytes]
Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H
S [ start: size ]
------------------------------------------------------------------------
0: 06 1 5 37 - 123 254 63 [ 16416: 965M] DOS > 32MB
1: 00 0 0 0 - 0 0 0 [ 0: 0M] unused
2: 00 0 0 0 - 0 0 0 [ 0: 0M] unused
*3: A6 0 0 33 - 1 5 36 [ 32: 8M] OpenBSD
we need to make the openbsd partition bootable, which we can do from
within fdisk using the 'flag' command as such. a bootable ("Active")
partition is noted with an * in front of the partition number, so if
you see something like:
3: A6 0 0 34 - 16 4 37 [ 33: 8M] OpenBSD
you need to make it active, which you can do with the 'flag' command
within fdisk
fdisk:*1> flag 3
Partition 3 marked active.
fdisk:*1> p m
Disk: sd0 geometry: 1978/16/63 [974 Megabytes]
Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H
S [ start: size ]
------------------------------------------------------------------------
0: 06 1 5 37 - 123 254 63 [ 16416: 965M] DOS > 32MB
1: 00 0 0 0 - 0 0 0 [ 0: 0M] unused
2: 00 0 0 0 - 0 0 0 [ 0: 0M] unused
*3: A6 0 0 33 - 1 5 36 [ 32: 8M] OpenBSD
write the partition info to the disk and exit from fdisk using 'quit'
fdisk:*1> quit
Writing current MBR to disk.
now, we need to edit the disklabel.
$ sudo disklabel -e sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: U3 Cruzer Micro
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 124
total sectors: 1994385
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0 # microseconds
track-to-track seek: 0 # microseconds
drivedata: 0
16 partitions:
# size offset fstype [fsize bsize cpg]
a: 16384 32 unused 0 0 # Cyl 0*-1*
c: 1994385 0 unused 0 0 # Cyl 0 - 124*
i: 1975644 16416 unused # Cyl 1*- 123
we need to set the fstypes for 'a' and 'i'. 'a' is our openbsd
partition, or 4.2BSD. 'i' is our general storage partition, so we'll
set MSDOS
by adding the total sizes for the 'a' and 'i' partitions, you should
equal the number in the 'c' partition. if you are short, you can
squeeze out a little more space for storage by adding the difference to
the size for 'i'
in other words, some algebra
S = SIZE; O = OFFSET
iS = cS - (aO + aS)
16 partitions:
# size offset fstype [fsize bsize cpg]
a: 16384 32 4.2BSD 0 0 # Cyl 0*-1*
c: 1994385 0 unused 0 0 # Cyl 0 - 124*
i: 1977969 16416 MSDOS # Cyl 1*- 123
once you are done squeezing out all of the extra space, save that to
disk by doing a :wq from within vi (assuming that's the editor you're
using)
now, let's format the partitions
(openbsd partition, /dev/rsd0a)
$ sudo newfs /dev/rsd0a
/dev/rsd0a: 8.0MB in 16384 sectors of 512 bytes
4 cylinder groups of 2.00MB, 128 blocks, 256 inodes each
super-block backups (for fsck -b #) at: 32, 4128, 8224, 12320,
(msdos partition, /dev/rsd0i)
$ sudo newfs /dev/rsd0i
/dev/rsd0i: 1974080 sectors in 246760 FAT32
clusters (4096 bytes/cluster)
bps=512 spc=8 res=32 nft=2 mid=0xf8 spt=63 hds=255 hid=16416
bsec=1977969 bspf=1928 rdcl=2 infs=1 bkbs=2
now, we need to start populating our disk with stuff. mount our 'a'
partition, and copy files (bsd.rd and boot to it)
$ sudo /sbin/mount /dev/sd0a /mnt
$ sudo cp bsd.rd boot /mnt
$ ls /mnt
bsd.rd boot
but, we want bsd.rd elsewhere on the disk so we don't have
to play any
boot.conf magic,so, as merdely suggests, simply:
$ sudo mv /mnt/bsd.rd /mnt/bsd
no magic stuff needed. continuing ...
now, we need to use installboot to install the first (biosboot) and
second (boot) stage boot programs. we'll do a dry run (using -n) to
make sure everything is ok first
$ sudo /usr/mdec/installboot -nv /mnt/boot /usr/mdec/biosboot sd0
boot: /mnt/boot
proto: /usr/mdec/biosboot
device: /dev/rsd0c
/usr/mdec/biosboot: entry point 0
proto bootblock size 512
/mnt/boot is 3 blocks x 16384 bytes
fs block shift 2; part offset 32; inode block 24, offset 936
using MBR partition 3: type 166 (0xa6) offset 32 (0x20)
$ sudo /usr/mdec/installboot -v /mnt/boot /usr/mdec/biosboot sd0
boot: /mnt/boot
proto: /usr/mdec/biosboot
device: /dev/rsd0c
/usr/mdec/biosboot: entry point 0
proto bootblock size 512
/mnt/boot is 3 blocks x 16384 bytes
fs block shift 2; part offset 32; inode block 24, offset 936
~marco/openbsd/flashkeyinstaller/
using MBR partition 3: type 166 (0xa6) offset 32 (0x20)
take note of that last line. the 'offset 32 (0x21)' part in particular.
32 should match whatever the offset is for your 'a' partition from
disklabel
now, unmount /mnt and reboot your target computer with the key
plugged
in. as long as your computer supports booting from usb thumb drives,
you should be good to go
