| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Requested by kettenis@
|
|
ramdisks.
OK marco@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tested by krw
|
|
|
|
supplied from ftplist.cgi, ask if the user wants to set it accordingly.
Idea from deraadt@, feedback from sthen@, guenther@
ok deraadt@, krw@ (slightly different version)
|
|
|
|
|
|
system, or something else.
Derive the fdisk instructions in `use the whole disk for OpenBSD' from this
knowledge, and set up a 32MB ext2fs partition on Gdium, and the 1MB elsewhere
(as was already been done).
On Gdium, format this partition in fancy mode (-O 1) and 4KB blocks, so that
PMON has a chance to load files larger than 4MB (such as bsd.rd)
without failing in a pathetic way, and also copy the kernel image to the ext2fs
partition after the installation has completed.
Note that, apart from creating a larger ext2fs partition on Gdium, there should
be no need for this.
Unfortunately, since regular PMON does not have ext2fs code, Lemote wrote its
own code to access ext2 filesystems. Saying that this code is full of
shortcomings and bugs would be an understatement. What is worse is that this
code has been written by people with no knowledge (or even insight) of how
error conditions ought to be handled, and their ext2fs code will happily
abort a read upon error with no error; if one does not compare the final
read size to the file size obtained by stat(), there is no way to figure out
that the read has been aborted. Of course since regular (upstream) PMON code
is written correctly, it does not expect this, so it is easy to end up with
PMON not loading a kernel image completely, yet proceeding happily to transfer
control to this broken image.
I guess the morale behind this is that system software is too difficult to get
done correctly, to be done by hardware people.
|
|
|
|
|
|
|
|
|
|
|
|
enlarge bsd.rd filesystem; this in turn causes a cd oflow, so enlarge
cd filesystem.
ok jsing@ deraadt@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
put the link to sbin/sysctl in the right place to let entries being
alphabetically sorted again.
change reminded by deraadt@
|
|
|
|
- do not mention tape as an installation media on systems where it is very
unlikely that a tape drive can be connected to (i.e. anything with only
USB as expansion capabilities)
- do not mention that fetching the installation sets from a partition is
``for upgrades only''. You may do this for installation, but of course
you can not use a partition which will be newfs'ed for that purpose.
- mention ext2fs partitions as possible installation sets source only on
platforms where the installation media actually can mount an ext2fs
filesystem.
- stress the fact that the sparc miniroot image is a GENERIC kernel with
a little on-disk filesystem, and not a RAMDISK kernel with a little
in-memory filesystem, and thus must not be overwritten during installation
(i.e. be careful if you repartition the disk the miniroot has been put on).
- more conv=sync -> conv=osync for tape setup instructions.
- model-specific layout changes on armish, loongson and socppc instructions.
- fix various typos and grammar mistaeks.
"sure" deraadt@ (without eyeballing)
|
|
looks good to deraadt@
|
|
also don't pull extra goop into the selector (do not use ls -l)
diff from halex
ok krw
|
|
|
|
/etc/X11 already exists. So if you install X to a headless machine
and then upgrade you don't have to remember to add X sets.
Idea from landry@ who installs to a lot of ports boxen.
ok halex@ beck@ deraadt@
|
|
|
|
redundant comment
|
|
|
|
|
|
Octane systems, as well as some Onyxes. With special permission to change a
systemwide .h file and add a manpage from deraadt@
Magic numbers and operation sequencing borrowed from Linux; tested on
Octane + ESI.
ok deraadt@
|
|
controls the serial console speed, and try to explain which video options
are supported and which are not.
|
|
|
|
|
|
ok deraadt@
|
|
|
|
ok jasper@
|
|
reshuffling things a bit ok miod@ jasper@ kettenis@
|
|
|
