-
Notifications
You must be signed in to change notification settings - Fork 0
Boot, Startup and Runtime Configuration
It's an exciting moment. The system is ready to boot - maybe for the first time. From floppy most likely - as described in the Configure and Build TLVC wiki page.
At this point, getting anything at all on the screen is a major milestone. The boot process goes like this:
- System power-on or reset will eventually attempt to load the boot sector from the device specified in your BIOS configuration. Or - if the system is old - it will try floppy A first, then the hard disk known as 'C'.
- The boot-loader assumes a PC-compatible BIOS is available to access the boot device, and calls the BIOS to read the root directory to find the kernel, a file named 'linux'.
- If found, the 'linux' file is read and dots printed on the screen, one per block. Anything other than dots means trouble, but not necessarily serious trouble. More about that later.
- If the kernel load succeeds, the boot program will jump to it and the kernel will start initializing itself and the system, while printing informational messages to the console. These messages are important: Not only do they tell you what's working, they also provide valuable information about why if something fails.
- If everything goes well (you may have to make adjustments to the configuration before you get to this point), you'll end up with a
login:
prompt, which is another milestone.
[TBD]
Boot messages are short messages from various components and stages during the boot and startup process. All operating systems emit messages during startup - some verbose, others rather terse. While not useful to the average user, the messages deliver important information to system administrators and developers. Some times showing error messages, most of the time just status information - of the type 'this device was found at this address'.
A historical example follows - boot messages from a DEC PDP11/70 system loading Berkely Unix BSD 2.11. While this particular example is run on a simulator, the messages look exactly like they did on a real system in the 80s. Notice in particular the error condition reported numerous times - about file system full, which messes up the flow of messages - actually a good thing since it attracts attention.
Most systems keep these messages in a log file so they may be examined later. Extremely useful when tracking down elusive problems that may have developed over time. TLVC does not have that 'luxury' simply because it would be too expensive in terms of resources. Plus such logging require administration, something more or less automatic to manage (delete, compress, archive, ...) the log files. We're not there yet.
In this context our focus is boot messages, but keep in mind that system messages to the console continue while the system is running: Notices about unusual conditions, errors, notable events - or simply printing the time and date at regular intervals in order to keep track of when various events happened. The degree of verbosity may be configurable - a useful aid when diagnosing problems.
Boot from ra(0,0,0) at 0172150
:
: ra(0,0,0)unix
Boot: bootdev=02400 bootcsr=0172150
2.11 BSD UNIX #11: Sep 9 16:28:47 PDT 2019
root@Mon:/usr/src/sys/PIDP11
ra0: Ver 3 mod 3
ra0: RA82 size=1954000
attaching de0 csr 174510
attaching lo0
phys mem = 3932160
avail mem = 3553280
user mem = 307200
January 11 12:33:33 init: configure system
dz 0 csr 160100 vector 310 attached
ra 0 csr 172150 vector 154 vectorset attached
rx 0 csr 177170 vector 264 attached
tms 0 csr 174500 vector 260 vectorset attached
cn 1 csr 176500 vector 300 skipped: No CSR.
erase, kill ^U, intr ^C
# ^D
Fast boot ... skipping disk checks
checking quotas: done.
Assuming NETWORKING system ...
add host pdp11.home.lan: gateway 127.0.0.1
add net default: gateway 192.168.10.1
starting system logger
/usr: file system full
checking for core dump...
preserving editor files
clearing /tmp
standard daemons: update cron accounting.
starting network daemons:Jan 11 12:34:13 pdp11 syslogd: /usr/adm/messages: No space left on device
Jan 11 12:34:13 pdp11 vmunix: ra0: Ver 3 mod 3
Jan 11 12:34:13 pdp11 vmunix: ra0: RA82 size=1954000
inetd rwhod printer.
starting local daemons:Jan 11 12:34:18 pdp11 syslogd: /usr/adm/cron: No space left on device
Jan 11 12:34:18 pdp11 January 11 12:34:18 lpd[97]: unable to get hostname for remote machine rpi
sendmail ntpd.
Sat Jan 11 12:40:09 MET 2025
/usr: file system full
Jan 11 12:40:13 pdp11 January 11 12:40:13 init: kernel security level changed from 0 to 1
2.11 BSD UNIX (pdp11) (console)
login:
TLVC fits nicely into this 'tradition', being slightly on the verbose side which makes sense for a system under development - and just as unintelligible for the average user (line numbers added for later reference):
SeaBIOS (version rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org
Booting from Floppy...
TLVC......Linux OK........................................................................
....................................
TLVC Setup .........Ft00B0 f0FDE d1423
1: Direct console, polling kbd 80x25 emulating ANSI (3 virtual consoles)
2: ttyS0 at 0x3f8, irq 4 is a 16550A
ttyS1 at 0x2f8, irq 3 is a 16550A
ttyS2 at 0x3e8, irq 7 is a 16550A
ttyS3 at 0x2e8, irq 10 is a 16550A
3: 40 ext buffers (base @ 0x95c0), 6K L1-cache, 20 req hdrs
4: eth: ne0 at 0x300, irq 12, (ne2k) MAC 52:54:00:12:34:56 (QEMU), flags 0x80, bufs 2r/0t
eth: wd0 at 0x280, irq 2, ram 0xcc00 not found
eth: ee0 at 0x360, irq 11, (ee16) not found
5: athd0: AT/IDE controller at 0x1f0
athd0d0: IDE CHS: 63/16/63, Multisector I/O, max 16 sects
athd0d1: IDE CHS: 614/4/17, Multisector I/O, max 16 sects
6: athd1: Controller not found at 0x170 (376)
7: athd: found 2 hard drives
8: df: Direct floppy driver, FDC 8272A @ irq 6, DMA 2
9: df0: 1.44M (type 4) [CMOS]
10: Partitions: dhda:(0,63504) no mbr (flat drive assumed)
dhdb:(0,41752) dhdb1:(17,41667)
11: PC/AT class, cpu 7, syscaps 0xff, 639K base ram, 18 tasks, 64 files, 96 inodes
12: TLVC 0.6.0 (62352 text, 17488 ftext, 12128 data, 7680 bss, 45726 heap)
13: Kernel text 0xb0, ftext 0xfe9, init 0x11a7, data 0x142e, top 0x9fc0, 494K free
14: MINIX: inodes 256 imap 1 zmap 1, first data 12
15: VFS: Mounted root 0x0200 (minix filesystem).
16: Running /etc/rc.sys script
Starting networking on ne0
ktcp -b -p ne0 10.0.2.1 255.255.255.0
ktcp: ip 10.0.2.1, gateway 255.255.255.0, netmask 255.255.255.0
ktcp: /dev/ne0 mac 52.54.00.12.34.56 mtu 1500
Starting daemons 'telnetd' 'ftpd -d' QEMU mode
Sun Jan 12 12:24:41 2025
17: /bin/init: Can't open /dev/ttyS2 (errno 6)
[tlvc15] TLVC 0.6.0
login:
Different but pretty much the same, reflecting the three phases of startup - hardware/first level boot, kernel startup, system startup.
Back in the day, the system console was a paper-terminal, a Teletype ASR33, DEC LA120, TI Silent33 or something similar. Slow but with the advantage that neither boot messages nor anything else scrolled off the screen. A sysadmin would come to work in the morning and immediately head to the system consoles to check what had been going on overnight.
Fast forward to the PC, and anything other than the last 24 lines will be gone - scrolling off the top before you can read them (unless you film them using your cell phone!). Which makes using a serial console almost mandatory during development - preferably one with a huge scroll buffer. Thus TLVC may be set up to use a serial console as the default (via menuconfig
) or selected at boot time via bootopts
.
When using serial console, the first few lines will always be missing, showing up on the physical console only, for the obvious reason that redirection of console output is done by the kernel which hasn't started yet. Not a problem if the physical machine is close by. If it's not, you can always peek at the contents of what's on the physical PC screen using the command hd b800:0#3840
which will output something like this:
tlvc15# hd b800:0#3840
0b8000: 53 07 65 07 61 07 42 07 49 07 4f 07 53 07 20 07 S.e.a.B.I.O.S. .
0b8010: 28 07 76 07 65 07 72 07 73 07 69 07 6f 07 6e 07 (.v.e.r.s.i.o.n.
0b8020: 20 07 72 07 65 07 6c 07 2d 07 31 07 2e 07 31 07 .r.e.l.-.1...1.
0b8030: 36 07 2e 07 31 07 2d 07 30 07 2d 07 67 07 33 07 6...1.-.0.-.g.3.
0b8040: 32 07 30 07 38 07 62 07 30 07 39 07 38 07 66 07 2.0.8.b.0.9.8.f.
0b8050: 35 07 31 07 61 07 2d 07 70 07 72 07 65 07 62 07 5.1.a.-.p.r.e.b.
0b8060: 75 07 69 07 6c 07 74 07 2e 07 71 07 65 07 6d 07 u.i.l.t...q.e.m.
0b8070: 75 07 2e 07 6f 07 72 07 67 07 29 07 20 07 20 07 u...o.r.g.). . .
0b8080: 20 07 20 07 20 07 20 07 20 07 20 07 20 07 20 07 . . . . . . . .
*
0b80a0: 42 07 6f 07 6f 07 74 07 69 07 6e 07 67 07 20 07 B.o.o.t.i.n.g. .
0b80b0: 66 07 72 07 6f 07 6d 07 20 07 46 07 6c 07 6f 07 f.r.o.m. .F.l.o.
0b80c0: 70 07 70 07 79 07 2e 07 2e 07 2e 07 20 07 20 07 p.p.y....... . .
0b80d0: 20 07 20 07 20 07 20 07 20 07 20 07 20 07 20 07 . . . . . . . .
*
0b8140: 54 07 4c 07 56 07 43 07 2e 07 2e 07 2e 07 2e 07 T.L.V.C.........
0b8150: 2e 07 2e 07 4c 07 69 07 6e 07 75 07 78 07 20 07 ....L.i.n.u.x. .
0b8160: 4f 07 4b 07 2e 07 2e 07 2e 07 2e 07 2e 07 2e 07 O.K.............
…
In the TLVC boot message listing above, which was captured from a serial console on QEMU, the initial pre-kernel messages were added manually from the physical screen (the lines without line numbers added). These early stage messages are discussed in the boot
chapters above.
… using the line number from the listing above.
-
Direct console, polling kbd 80x25 emulating ANSI (3 virtual consoles)
- Info about the (physical) console and keyboard drivers used (chosen viamenuconfig
, in the 'character driver' section). 'Direct console' is the reliable choice, the other alternatives are for development and special purposes, and their use discouraged. ANSI emulation is the default for screen and cursor control, also chosen viamenuconfig
. The alternatives are 'VT52' and 'None'. ANSI is the default and most powerful, VT52 is more compact (a subset of ANSI). ANSI is also known as 'VT100'. Consequently 'ansi' is the correct TERM setting when running screen oriented programs likevi
on the system. This is also the default. Note that if the system is set up to boot into a shell and not/bin/init
, the normal initialization is not run and environment variables like TERM must be set manually (usingsetenv TERM=ansi
for example). -
ttyS0 at 0x3f8, irq 4 is a 16550A emulating ANSI (3 virtual consoles)
- one or more lines from the serial (tty) driver, informing about what it found when initializing itself. Typically one line, sometimes more. The port addresses are the defaults set in theports.h
file. The IRQs may be changed inbootopts
via thecomirq=
directive, see thebootopts
'manual' below. The type (like '16550A') is useful information only at a very technical level and indicates the capabilities (and generation) of the serial IO chip this line is attached to. -
40 ext buffers (base @ 0x95c0), 6K L1-cache, 20 req hdrs
is system buffer configuration info, either system defaults or from settings inbootopts
. This system is set up to use 40 external (L2) buffers, most likely via thebufs=
directive inbootopts
, refer to the [Memory and Buffer System](TLVC Memory and Buffer subsystem) Wiki for details. The 'base address' is where the external buffer block starts in memory, usually at the top if the main memory section - information useful to developers (you will find it in the display frommeminfo -M
also). '6K L1 cache' is again most likely a setting frombootopts
(thecache=
directive), while 'req hdrs' ('request headers') is a resource used by the asynchronous IO system, useful for developers for scaling purposes. If the system is set ups to use - and has the necessary hardware - XMS buffers, this line will look slightly different:xms: using unreal mode, 120 xms buffers (base @ 0x100000), 8K L1-cache, 20 req hdrs
- In this case, the L2 buffers are located in XMS memory and the quantity set by thexmsbufs=
directive inbootopts
. More about XMS buffers in the Memory and Buffer System document referenced before. -
eth: ne0 at 0x300, irq 12, (ne2k) MAC 52:54:00:12:34:56 (QEMU), flags 0x80, bufs 2r/0t
- The system may have up to 4 Ethernet interfaces configured and possibly installed, even though only one may be active at any time (refer to thebootopts
'manual' below for details). What's interesting here is which interface if any was actually found. As can be seen from the listing above, all Ethernet interfaces (commonly called 'NICs') configured into the kernel will be listed and marked 'not found' if they are not physically present or their hardware settings don't match the default configuration or the one inbootopts
. Having drivers that will never be used in the kernel is a waste of resources. Usemenuconfig
to remove them. -
athd0: AT/IDE controller at 0x1f0
- A standard AT class IDE disk controller was found at the default IO address. Zero, one or two drives may be attached to each controller. In many cases, the controller will not show up if no drives are attached to it. The attached drive(s) will be identified in the following line(s), likeathd0d0: IDE CHS: 63/16/63, Multisector I/O, max 16 sects
andathd0d1: IDE CHS: 614/4/17, Multisector I/O, max 16 sects
.athd
is the controller type, the following number is either 0 or 1,d0
andd1
are drive number, max 2 per controller, max 4 per system. The 'Multisector' message tells the developer the size of the buffer on the disk drive, usually between 2 and 16 sectors. More about CHS values and IDE drives in the Developer Notes pt. I Wiki. -
athd1: Controller not found at 0x170 (376)
- The second standard IDE controller was probed and not found. This message is useful only to the developer and may not show up on your system. -
athd: found 2 hard drives
- This message is really superfluous (for debugging), we know already how many drives were found. This message may not show up on your system. -
df: Direct floppy driver, FDC 8272A @ irq 6, DMA 2
- All vintage PCs have a floppy controller at this address/IRQ/DMA. This message simply confirms that everything is OK and also tells which FDC (floppy disk controller) is installed on the system. 8272A is the same as NEC765C, the chip used on XT and early AT class systems. Newer systems have more capabilities, but most of these are unused by TLVC simply because what they add is not very relevant to the system. Keep in mind though that while the XT and AT have the same controller chip, the floppy drives/densities supported are different. Check out the Floppy Types and Autoprobe chapter in the Developer Notes Pt. III Wiki. -
df0: 1.44M (type 4) [CMOS]
- This line lists the floppy drives found, their type/capacity and the source of configuration info (either CMOS or bootopts). If the system is XT class the there is no configuration info inbootopts
, 2 360k drives will be reported regardless of what is physically present. -
Partitions: dhda:(0,63504) no mbr (flat drive assumed) dhdb:(0,41752) dhdb1:(17,41667)
- Partition check on the hard drives found. 'No mbr' means there was no partition table and the drive is assumed to be unpartitioned, which means there is one file system occupying the entire drive. The numbers in parentheses are the per partition starting sector and size (also in sectors) per partition. -
PC/AT class, cpu 7, syscaps 0xff, 639K base ram, 18 tasks, 64 files, 96 inodes
- Kernel initialization is done. This line shows important basics about the system: AT or XT class, cpu type (7 means 386 or higher),syscaps
has flags indicating whether certain capabilities are present in the system, relevant only for pre-AT systems (keyboard type, disk technology, irq mapping, …). Useful to developers only. The total memory size may be of interest - does it match what is actually in the system? Refer to the Memory and Buffer system Wiki for details. The tasks, files and inodes numbers may be default or set inbootopts
, worth keeping an eye on if you're tuning the system. Check thebootopts
manual for details. -
TLVC 0.6.0 (62352 text, 17488 ftext, 12128 data, 7680 bss, 45726 heap)
- The kernel is identifying itself - name, version and sizes. The latter may be important because memory is usually the most critical resource on these systems. The example shows a really big kernel where the text (code) size almost hits the ceiling (64k) even with a rather big chunk of code diverted to the fartext segment. Data size is moderate, but that's normal because most of the sizeable allocations are made from the kernel heap (use thememinfo
command to see the details). -
Kernel text 0xb0, ftext 0xfe9, init 0x11a7, data 0x142e, top 0x9fc0, 494K free
- More details about kernel memory, these are the starting segments for the various blocks whose sizes were reported in the previous line. 'Top' is actually the total memory size as reported on line 11, this time in hex. 'Free' is the size of main memory, a significant part of which will be occupied before startup has completed. Again usmeminfo
for details. -
MINIX: inodes 256 imap 1 zmap 1, first data 12
- Kernel initialization is on its last leg, mounting the root file system, in most cases the boot drive (the active partition if a partitioned hard disk). The message is actually from themount()
system call which will always report such data when a file system is mounted. -
VFS: Mounted root 0x0200 (minix filesystem).
- This is a diagnostic (for debugging) message that may not appear on your system. It simply confirms the mounting of the root file system, which may be Minix type or FAT type. More about supported filesystems in the Wiki document Developer Notes pt. IV. At this point, kernel startup has completed and/bin/init
or something else (depending on theinit=
setting inbootopts
) is taking over to complete system startup. -
Running /etc/rc.sys script
- At this point,/bin/init
is running and executing the/etc/rc.sys
shell script which starts various subsystems depending on system configuration. If thenet=
directive is present in the environmmountent,rc.sys
will attempt to start the network via the/bin/net
script and the settings in/etc/net.cfg
. It will also run the/etc/mount.cfg
script to check and mount filesystems in addition to root. The message lines following this line reflect whatrc.sys
is actually doing and whether various subsystems and commands succeed or fail. -
/bin/init: Can't open /dev/ttyS2 (errno 6)
- the final step if the system is configured to run multiuser (the absence of the 'n' command inbootopts
) has for/bin/init
to run through/etc/inittab
to start subsystems according to the desired run level (set inbootopts
, usually '3'). This error message warns thatinittab
wants a/bin/getty
(login) process to be started on the serial line/dev/ttyS2
, but that line does not exist on this system ('errno 6' means 'No such device or address').
After this, the getty
process is started on the console and possibly serial lines available. The system is now running (presumably) normally and you're ready to log in. Use 'root' to login, there is no password.
There are two main mechanisms available to configure a TLVC system. The first - and most basic - is menuconfig
, the configuration system that uses the make
command to build compile time parameters for the system. menuconfig
not only configures system/kernel settings and which modules/drivers etc to include or exclude, it also defines the environment, the boot disks, which applications to include and more. Check out the Configure and Build TLVC Wiki for more on menuconfig
.
The second mechanism is the /bootopts
file, the kernel boot-time configuration text-file containing settings that defines the runtime system. While a TLVC system may be built without bootopts
-support or the bootopts
-file may be missing, it is almost unthinkable not having this extremely convenient tool available. As the number of settings have increased over the years, the more indispensable the file has become.
The /bootopts
file may be up to 1023 bytes in size and MUST start with the two characters '##'. If larger - or starting with something else - the file will be ignored, and a message to that effect will be displayed. That message however, is likely to scroll off the screen (unless the system has been menuconfig
ured to use serial console). So, if the system seems to be ignoring the file, pay close attention to the boot messages on the console (or film them so you can scroll back).
[Practical hint] A safe 'trick' to make a missing bootopts
-file easy to detect is to make sure a HOSTNAME=
statement is part of the file. The hostname, when set, will be part of the shell prompt in the running system (as in tlvc15#
). If it's missing (the shell prompt is just a hash character #
), then something is wrong and bootopts
did not get read. Check the size of the file, and whether the mandatory lead-in characters were accidentally deleted.
The bootopts
-file has 3 types of settings: Regular parameters, environment settings and init
-arguments. The regular parameters have the form name=value[,value…], like root=dhda1
or comirq=4,3,7,10
. Environment settings look mostly the same but by convention, most of them have uppercase names - like the HOSTNAME=
setting just mentioned, or LOCALIP=10.0.2.15
. 'Mostly' because there are exceptions both ways: net=ne0
and sync=30
are both environment settings, an efficient way to pass settings from bootopts
to the runtime system (which means /bin/init
). And - in the opposite direction so to speak, there is TZ=
, which is a regular parameter, not an environment setting. You will recognize the environment settings from bootopts
by issuing the printenv
command to the singleuser shell:
# printenv
HOSTNAME=tlvc15
QEMU=1
LOCALIP=10.0.2.15
net=ne0
PATH=/bin
sync=30
GATEWAY=10.0.2.1
HISTPAGE=20
TZ=GMT0
HISTORY=30
#
There is a meaning to this 'mess': While the lowercase environment settings (like net=ne0
) are passed to the first process to run on the system after boot, usually /bin/init
, in some cases /bin/sh
or /bin/sash
, they are not passed on in a multiuser setting. The uppercase settings on the other hand, are passed on. This distinction provides a very flexible means for the developer and user to customize the system in a lot of ways without having to make low level changes.
Finally, there is the #
-character: Like on most Linux and Unix systems, the hash starts a comment which extends to the end of the line.
The available bootopts
settings are described in detail below (check out the example file towards the bottom). Because there are so many, they've been roughly grouped by functionality which hopefully will make it easier to find what you're looking for. Keep in mind that while the default bootopts
file that comes with the system provides many examples, space is limited: Not all of them fit in, and their formats may not be obvious. Thus this rather elaborate document.
debug=0
If debug has been enabled for any of the subsystems in the kernel (see include/linuxmt/debug.h
), this value determines the level of verbosity for the output. Zero means 'turn off'. This mechanism obviously depends on the programmer to actually use the prototypes defined for its use. The number may be anything, but above 5 is rarely meaningful. Details in the Kernel Debugging Wiki.
sync=20
Tells the kernel to sync dirty buffers to disk/floppy with this interval (in seconds). 15-30 is reasonable. If not present, there will be no syncing, which is risky and will lead to data loss if the system crashes. If the system has a large number of xms buffers, syncing may cause noticeable 'lagging' at times. This is an environment setting picked up by the /bin/init
command, which is taking care of the actual syncing. Check the TLVC Memory and Buffer subsystem for details.
cache=8
Sets the size (in k bytes) of the level 1 (L1) buffer cache. The default is 8, numbers between 6 and 12 are reasonable. If the system has no L2 buffers (see below), a higher number (12-20) is advisable to get reasonable performance. Space for the cache is allocated from the kernel heap. The system will not work without a L1 cache. Refer to the TLVC Memory and Buffer subsystem Wiki for details.
bufs=40
If the system is configured to use external buffers, this parameter sets the number of second level (L2) buffers for the system (a buffer is always 1k in size). Buffer space is allocated outside the kernel data segment and up to 64 buffers may be allocated. 32 to 64 are reasonable values given enough memory. Note that if the system is configured for - and is capable of - xms-buffers and the xmsbufs=
parameter is >0, the bufs=
setting will be ignored. Values lower than 4 are unsmart and may lead to 'thrashing'. Zero is not allowed. If set to zero, the system default (from menuconfig
) will be used. More info in the TLVC Memory and Buffer subsystem Wiki.
tasks=16
Tasks (or 'processes') in TLVC are managed by the kernel via a 'task structure array' which occupies a significant 822 bytes per task, and thus represent a significant 'static' memory 'load'. This parameter tells the kernel how many such entries to allocate at startup time, which becomes the max number of processes the system can run at any one time. The smallest possible number is 3, and requires that the systems boots into a shell /single user) instead of starting /bin/init
(see the init
parameter below). The max number is currently 20. The default is 16. Note that there is no sanity check on the value, setting a wild number (i.e. <3, >20) will wither prevent the system from booting or make it unstable.
files=64
Sets the number of files that may be open concurrently on the system. The default is 64, which is reasonable if the number of tasks is 16. A task needs at least 3 open files to run, adding 1 per task delivers this number: Too small for some applications, too large for others - which averages out reasonably.
inodes=96
The size of the kernel inode-table, the number of inodes that may be active on the system at any time. In addition to an inode-entry per open file, the inode table also holds inodes for every open directory, device and mount, thus the extra capacity compared to the open-file table. Refer to the Developer Notes on the Minix File system (TBD) for details.
heap=32
By default the kernel data segment is always extended to its max size, 64k bytes (refer to the TLVC Memory and Buffer Subsystem Wiki for details). The data segment has 3 parts: kernel initialized data ('kernel data'), uninitialized data ('kernel bss') and the kernel heap. The former two have fixed sizes set when the kernel is compiled and linked. The kernel heap normally takes the rest of the segment: 64k minus the sum of kerne data and kernel bss. If this is not desirable, the 'heap=' parameter may be used to reduce the size of the heap appropriately. Use the kernel boot messages and the actual heap usage (using the meminfo
tool) to tune the heap setting. Beware that a too low value will cause system startup to fail.
memsize=512
Sets the size of conventional memory on the system. While normally set correctly by querying the BIOS at startup time, there are cases when the BIOS value may be wrong or the size needs to be adjusted for debugging.
xmsbufs=1250
Set the number of xms-buffers on the system. Reasonable values are 100-2975. Read about xms-buffers in the TLVC Memory and Buffer Subsystem Wiki.
strace
Enables process stack tracing if compiled into the system. Refer to the TLVC Kernel Debugging Wiki for details.
kstack
Enables kernel stack tracing if compiled into the system. Read more in the TLVC Kernel Debugging wiki.
hdparms=306,4,17,128,614,4,17,-1
Defines the CHSW values for the first 2 IDE or MFM drives on the system. CHSW = Cylinders, Heads, Sectors, Write-precomp. Write-precomp is relevant only for the older of MFM drives. While IDE/ATA drives have CHS values that will be read from the drives during boot, these may not always be what you want (refer to the TLVC Developer Notes pt. I for lots of details). For MFM (the XD driver, XT class systems only) this setting is required unless the drive is a standard 10MB PC/XT drive (306/4/17/128 parameters).
fdcache=5
Sets the size of the floppy disk sector cache and requires that memory for the cache has been allocated in the kernel configuration (the default config reserves 7k bytes for this purpose). This cache is useful for slow systems (286 and down) only, and is automatically turned off for faster systems (386+). Check the TLVC Developer notes pt. III for details.
xtide=0x300,5,1,0x320,0,0
This setting is required if running IDE hard disks via an XT-IDE or XT-CF card, and tells the standard IDE driver to behave in certain ways depending on the configuration. Two controllers (with up to 2 drives each) may be configured via this setting. The parameters are 'IOport (hex), IRQ (decimal), flags'. Fields may be empty or missing: xtide=0x300,5,1,,,
and xtide=0x300,3,2
are both valid. The 'flags' field is important: 0 means 'standard XT-IDE, 1 means XT-CF Lite, 2 means XT-IDE HighSpeed PIO. Refer to the detail rundown in Developer Notes pt. I.
xtflpy=3,1
Applies only to XT class systems that don't have NVRAM/CMOS for system parameter storage. Only useful if the system has floppy drive(s) different from the default 360k 5.25in drives. The numbers have the same meaning as on newer (AT+) systems with CMOS, '3' in the example meaning 720k/3.5in drive.
net=wd0
If present, tells the system to start networking automatically at boot time, and defines the default interface for the net
command to use.
netbufs=0,0
Currently applies to the ne0
interface only and specifies the number of receive and transmit buffers (respectively) to allocate. The feature is considered experimental and does not currently have significant performance effect unless the system is very heavily loaded. Reasonable settings are 2,0 or 2,2. 2,0 is the default, set in tlvc/arch/i86/driver/net/netbuf.h`. Refer to the TLVC Developer Notes pt. II: Networking section for details. Also, there is a section devoted to this option in particular in the Wiki document TLVC Networking Guide.
ne0=
, wd0=
, ee0=
, 3c0=
, le0=
These are settings for each individual network interface type. Remember that the system supports only one active network interface at any time. You may, however, install many physical NICs in the system as long as they con't 'collide' in terms of port addresses.
With several NICs installed (and initialized correctly during startup, check the boot messages on the console), you can switch between them on a running system using the net stop
and net start
command. The parameters for all NICs are IRQ (decimal), base IO port (hex), shared memory address (hex), flags (hex), like wd0=11,0x320,0xCC00,0x80
.
Some interfaces does not have shared memory and that field is ignored. Again refer to the TLVC Developer Notes Wiki for details. A physically installed interface may be disabled by setting the port address to 0.
net=
See networking above
LOCALIP=
Set the system's IP address. DHCP is not implemented.
GATEWAY=
Set the system's default router address.
HOSTNAME=
Set the system's hostname. Should match /etc/hosts
.
These are command line parameters to the /bin/init
program, normally the first program started by the kernel when the startup process has completed (unless overridden by the init=
parameter, see below).
n
- Don't run the /etc/rc.sys
script, which means no automatic network startup and not auto-mounting of extra file systems (in addition to root).
3
(runlevel) - This is the runlevel init
uses when parsing the /etc/inittab
table. Introduced in Unix System III, inittab
provides an easy way to switch between runtime settings, typically singleuser and multiuser. Read the comments at the top of /etc/inittab
for details about the 1-6 levels available. The default is 1.
root=
This option is extremely useful during development, in particular storage driver development. It allows for the root device to be different from the boot device. For example, you may be booting off of a floppy drive (/dev/df0
) and mount root on /dev/df1
by setting root=df1
. This is particularly valuable since df1
is not bootable. Likewise you may boot from hard disk, say /dev/dhds
and mount root from /dev/dhdc3
. And so on.
ro
Mount the root filesystem ReadOnly.
rw
Mount the root filesystem ReadWrite, This is the default.
TZ=
Set the timezone for this machine. The default is GMT, which is the CMOS clock setting unless configured otherwise via menuconfig
.
console=tty1
Use this to redirect the system console to a device different from the default PC screen/keyboard (may also be redirected via menuconfig
). The syntax is console=ttyS0,57600
- 'device, speed'. tty2,0
is a valid choice and will redirect the console output to the second virtual screen on the PC (ALT-2). The default is tty1
.
comirq=4,3,,
Sets the IRQ lines to use with the serial lines, match match the hardware settings. The default is 4,3,5,7
. Be aware the IRQ 5 does not work (is not generally available) on many newer systems. comirq=,,7,10
works well if you have 4 ports and configure them correspondingly.
init=/bin/init
Allows the system to boot into a different program than /bin/init
which is the default. Using init=/bin/sh
og init=/bin/sash
are viable choices for a single user system with severe memory constraints. /bin/sash
is the 'standalone shell', which is significantly smaller than the regular shell, and functionally constrained, but very fast.
Below is a typical (the current default) bootopts
file.
## boot options max 1023 bytes, see wiki for details
console=ttyS0,57600 3 # serial console and init-level (3)
debug=0
net=ne0 # start netw on boot w/this interface
#root=df0
#TZ=MDT7
LOCALIP=10.0.2.15
GATEWAY=10.0.2.1
HOSTNAME=tlvc15
ne0=12,0x300,,0x80
wd0=2,0x280,0xCC00,0x80
#3c0=11,0x330,,0x80
ee0=11,0x360,,0x80
comirq=,,7,10 # IRQ for com ports, up to 4
#cache=6 # L1 cache
#bufs=40 # L2 buffers
xmsbufs=0 # if supported
tasks=6 bufs=2 cache=12 files=20 inodes=24 n
#files=64 inodes=96
hdparms=306,4,17,128,614,4,17,-1 # CHSW values for 2 drives, overrides CMOS and drive values
netbufs=2,0 # netw buffers, recv/trans, ne2k only
#tasks=14 # max tasks, default 16, max 20
sync=30 # autosync secs
#xtflpy=3,1 # meaningful for XT systems w/720k drive(s) (type3)
fdcache=5 # floppy sector cache, for slow systems <= 286
#xtide=0x300,,,,, # Set addr, IRQ, flgs for 2 XT-IDE controllers
#init=/bin/init 3 n # multiuser serial no /etc/rc.sys
#init=/bin/sh # singleuser shell
TLVC: Tiny Linux for Vintage Computers