This happened to be my first "for real" broken world. I had broken
it once before, but nobody noticed, so it didn't count.
So, how do I get the "I broke world and all I got was the lousy t-shirt"
t-shirt?
- Make as much of the makefile for each of the three flavours
(disk, CDROM, net) common.
- Special-case the libalpha startup module on its use in boot1, not
the other way around.
- Build the loader out of a "loader" directory
Reviewed by: mjacob, dfr
* Make it possible to type a filename to boot1 so that it is possible to
recover from fatally broken versions of /boot/loader.
* Make a start at a CD boot program (not yet functional).
the SRM environment. This makes the traditional "boot [/kernel] -s"
and similar things work on the Alpha. Since the flags are appended,
they augment and/or override those from the SRM environment.
a module. Also modified the code to work on FreeBSD/alpha and added
device vr0 to the alpha GENERIC config.
While I was in the neighborhood, I noticed that I was still using
#define NFPX 1 in all of the Makefiles that I'd copied from the fxp
module. I don't really use #define Nfoo X so it didn't matter, but
I decided to customize this correctly anyway.
is, don't assume that SCSI ID corresponds to a unit number of da
device. Unit number of da device is provided by 2nd stage loader
and 3rd stage loader now use it.
- Fix drive letter to display.
Submitted by: IMAI Takeshi <take-i@ceres.dti.ne.jp>
bootable on 1 FDD PC98 machines. (When an external FDD unit is
installed, unit numbers become discontinuous.)
Submitted by: IMAI Takeshi <take-i@ceres.dti.ne.jp>
result of a joined effort with parts contributed by Doug Rabson, Warner
Losh and Stefan Esser (hope I did not forget anybody). Part of the sources
is obtained from NetBSD with modifications.
This code is work in progress:
As of the time of the initial import, a loader.exe executable is built,
which can be loaded on an Alpha with NT only firmware, but no attempt is
made to switch to OSF PAL code as required to start an actual kernel.
numbers that we have been doing in the past, and read /etc/fstab off the
proposed root filesystem to determine the actual device name and vfs
type for the root filesystem. These are then exported to the kernel
via the environment variable vfs.root.mountfrom.
This should resolve the problem raised in PR 12315, and incidentally
makes it easier to determine what geometry the BIOS is actually using
(by way of boot -v and dmesg).
