/
README
249 lines (200 loc) · 11.3 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
$FreeBSD: src/sys/boot/README,v 1.3 2000/05/01 20:26:17 peter Exp $
$DragonFly: src/sys/boot/README,v 1.4 2005/02/26 12:00:55 swildner Exp $
README file, for the boot config file setup. This is meant
to explain how to manage the loader configuration process.
The boot and loading process is either defined, or being
defined in boot(8) and loader(8).
The ongoing development of the FreeBSD bootloader, and its
rapid deployment while still in the development phase, has
resulted in a large number of installations with outdated
configurations. Those installations actively tracking the
FreeBSD development should also ensure that their bootloader
configurations are updated. If you see files discussed here
that your system doesn't yet have, add them yourself.
This is an effort to give the currently correct method for
setting up your boot process. It includes information on
setting up screen savers and plug and play information, and
also on recording any changes you make in your kernel
configuration. This file is temporary, because as I noted,
the process is still undergoing development, and will still
change. Man pages are coming out, but they're still going
to be somewhat fragile for a while. If you note anything in
here that's broken, it would be a good idea to report it to
the FreeBSD-current list, or to Daniel C. Sobral
<dcs@FreeBSD.org> or Mike Smith <msmith@FreeBSD.org>.
NOTE:
Please understand, all this is very current development, and
while getting this working for STABLE is a goal, it's not
yet ready for that. It's possible that parts of this might
indeed work for stable, but if you're not absolutely sure
what you're doing, you're better off not using the
information in this README for STABLE. Use this for current
only for a while longer, please!
After the first two stages in the booting process (described
in boot(8)), the last stage of the booting process, called
the loader (see loader(8)) reads in the /boot/loader.rc
file. The two lines you should have there are:
include /boot/loader.4th
start
This reads the ficl (forth) initialization files, then
/boot/default/loader.conf. This file, which strongly
resembles in form /etc/rc.conf but functions quite
differently, has spots for endless user customization but
isn't yet completely finished. For one thing, it used to
assume a /kernel.config instead of a /boot/kernel.conf.
Watch the first few lines of /boot/defaults/loader.conf to
see if the file name changes.
[See the section at the end on loader.conf syntax]
You don't actually want to make any changes to
/boot/defaults/loader.conf, the file that is a hacking-
target is:
/boot/loader.conf
and might very likely not exist yet on your system). You
should copy /boot/defaults/loader.conf to /boot/loader.conf,
and then cut out anything you didn't want changed.
The start command also loads your kernel for you, so don't
put any lines in there like "load kernel", they'll fail (but
really have already worked for you). Start also reads in
the file /boot/defaults/loader.conf and /boot/loader.conf.
If you don't have /boot/loader.conf, you'll see a message on
boot about it, but it's a warning only, no other effects.
See the section on loader.conf syntax at the end of this
document, for some more pointers on loader.conf syntax.
The best way to manage splash screens is with entries in
/boot/loader.conf, and this is very clearly illustrated in
/boot/defaults/loader.conf (which you could just copy over
to /boot/loader.conf). I'm going to illustrate here how you
*could* do it in /boot/loader.rc (for information only)
but I don't recommend you do this; use the
/boot/defaults/loader.conf syntax, it's easier to get it
correct.
You can load your splash screen by putting the following
lines into /boot/loader.rc:
load splash_bmp
load -t splash_image_data /path/to/file.bmp
The top line causes the splash_bmp module to get loaded.
The second line has the parameter "-t" which tells the
loader that the class of DATA being loaded is not a module,
but instead a splash_image_data located in file
/path/to/file.bmp.
To get your plug and play data correctly set, run kget,
redirecting the output to /boot/kernel.conf. Note that kget
right now adds an extra "q" to it's output (from the q for
quit you press when you exit config), and if you want, you
can remove that from the file. Kget reports data only, so
feel free to run it, just to see the output. Make certain
you have the kernel option USERCONFIG set in your kernel, so
that you can do a boot -c, to initially set your cards up.
Then, edit /boot/loader.conf so that the following line
shows up (overwriting, in effect, a similar line in
/boot/default/loader.conf):
userconfig_script_load="YES"
My own pnp line looks like:
pnp 1 0 os irq0 15 irq1 0 drq0 1 drq1 0 port0 1332
(kget changes numbers from hexadecimal to decimal). Note
that, at this moment, the change from using /kernel.config
to using /boot/kernel.conf as the storage place for kernel
config changes is going on. Take a look at your
/boot/defaults/loader.conf, see what's defined as
userconfig_script_name, and if you override, make sure the
file exists. Note that the loader only has access to the
root filesystem, so be careful where you tell it to read
from.
o If you interrupt autoboot, you'll engage interactive
mode with loader. Everything you type will have the
same effects as if it were lines in /boot/loader.rc.
o While in interactive mode, you can get help by typing
"?", "help [<topic> [<subtopic>]]" and "help index".
These are mostly commands one would expect a normal
user to use. I recommend you play with them a little,
to gain further familiarity with what's going on.
Note that it is not possible to damage or corrupt your
system while experimenting with the loader, as it
cannot write to any of your filesystems.
o The command "unload" will unload everything. This is
very useful. Once loader.rc has finished and the
system is in the autoboot count-down, you will usually
have the kernel and other modules loaded. Now, suppose
your new /kernel is broken, how do you load
/kernel.old? By typing:
unload
load kernel.old
[any other modules you wish to load]
boot
o If you use loader.conf, you can do:
unload
set kernel=kernel.old
boot-conf
this will then load all the modules you have
configured, using kernel.old as kernel, and boot.
o From loader, you can use the command "more" to read the
contents of /boot/loader.rc, if you wish. This is not
FreeBSD's more. It is one of loader's builtin commands.
Useful if you can't quite recall what you have there.
:-) Of course, you can use this command to read
anything else you want.
o "boot -flag" works, "boot kernelname" works, "boot
-flag kernelname" doesn't. "boot kernelname -flag"
might work, but I'm not sure. The problem is that these
flags are kernel's flags, not boot's flags.
o There are a number of variables that can be set. You
can see them in loader.conf, but you can get much more
detailed information using the "help" command, eg. help
set <variablename>.
o The variable root_disk_unit is particularly important,
as it solves a relatively common problem. This problem
shows when the BIOS assign disk units in a different
way than the kernel. For example, if you have two IDE
disks, one on the primary, the other on the secondary
controller, and both as master, the default in most
kernels is having the first as ad0, and the second as
ad2. If your root partition is in ad2, you'll get an
error, because the BIOS sees these disks as 0 and 1
(well, 1 and 2), and that's what loader tells the
kernel. In this case, "set root_disk_unit=2" solves the
problem. You use this whenever the kernel fails to
mount to root partition because it has a wrong unit
number.
FILE OVERVIEW
o /boot/defaults/loader.conf -- Master configuration
file, not to be edited. Overridden by
/boot/loader.conf.
o /boot/loader.conf -- local system customization file,
in form very much like /boot/defaults/loader.conf.
This file is meant to be used by local users and the
sysinstall process.
o /boot/loader.conf.local -- local installation override
file. This is intended for use by installations with
large numbers of systems, to allow global policy
overrides. No FreeBSD tools should ever write this
file.
o /kernel.config -- old location of kernel configuration
changes (like pnp changes).
o /boot/kernel.conf -- new location for kernel
configuration changes.
o /boot/loader.rc -- loader initial configuration file,
chiefly used to source in a forth file, and start the
configuration process.
NOTES ON LOADER.CONF SYNTAX
I'm copy here from the last 11 lines from
/boot/defaults/loader.conf:
##############################################################
### Module loading syntax example ##########################
##############################################################
#module_load="YES" # loads module "module"
#module_name="realname" # uses "realname" instead of "module"
#module_type="type" # passes "-t type" to load
#module_flags="flags" # passes "flags" to the module
#module_before="cmd" # executes "cmd" before loading module
#module_after="cmd" # executes "cmd" after loading module
#module_error="cmd" # executes "cmd" if load fails
The way this works, the command processor used by the loader
(which is a subset of forth) inspects these variables for
their suffix, and the 7 lines above illustrate all the
currently defined suffixes, and their use. Take the part
before the underscore, and customize it i(make it unique)
for your particular use, keeping the suffix to allow the
particular function you want to activate. Extra underscores
are fine, because it's only the sufixes that are scanned
for.
(authors Chuck Robey and Daniel Sobral).