Kernel Command Line
Parameters (aka Boot Options)
Kernel command line parameters are parameters that you pass on
to the Fatdog64 during the boot process.
They are also known as "boot options". Some of these parameters
are understood by the Linux kernel,
some are understood by Fatdog64 system scripts. They influence
how Fatdog64 brings the system up
and operates, they also control how the Linux kernel behaves.
There are so many parameters (especially for Linux kernel), this
page will only address some of the
most important ones.
Applying Parameters
These parameters must be passed on to Fatdog64 before the
system boots up, during boot-loading stage. Boot loaders can be
configured to pause and ask for parameters during boot up (like
the one in Fatdog64
Live CD/DVD), or you can put it in the configuration file.
For example, with Fatdog64 Live CD/DVD, it will display
Fatdog64 logo and pause for 5 seconds for you to key in any
parameters. Here, you can enter the parameters like
this:
boot: fatdog paramA paramB ...
where "boot:" is the boot prompt displayed by the boot loader,
"fatdog" is the operating system label understood by the
bootloader (it has to be "fatdog" for Fatdog64 Live CD/DVD), and
"paramA", "paramB" etc are the parameters.
If nothing is typed for 5 seconds, the system will continue to boot-up with
default parameters.
If you use GRUB, the parameters are passed on the kernel line. For example:
title Fatdog64
root (hd0,0)
kernel /vmlinuz paramA paramB
initrd /initrd
If you use syslinux and its friends, the parameters are passed
on the append line. For example:
label fatdog
kernel vmlinuz
initrd initrd
append paramA paramB
Note 1: parameters are case sensitive. Most of them
are in lower case, so if you specify them in upper case (capital
letters),
it won't work. Also remember that all parameters cannot
include space or colon.
Note 2: For Windows users - the word module
in Linux terms is roughly equivalent to what you usually know as
drivers in Windows.
Commonly Used Parameters
These are the commonly used parameters to tune system operation or
to troubleshoot issues.
Fatdog64 Parameters
waitdev
"wait for device" - this instructs Fatdog64 to delay boot process
by a few more seconds, so that save devices have time to settle
and be ready - so that they can be accessed (and the savefile can be
read off them). By default, Fatdog64 boots as fast as it can.
You need this if your save device is not recognised during boot - the easiest
symptom is that you have a savefile but Fatdog does not use it.
Thist mostly happens for USB devices. My computer for example requires at least
3 seconds for flash drives to be recognised; delays of up to 5 seconds is not uncommon.
Some slower devices may need even longer time.
The syntax is: waitdev=n,
where n is the number of seconds to wait.
search=n
Control searching of possible savefiles in subdirectories.
This parameter tells the boot process "at which subdirectory level in a given path, searching for savefiles is to end".
If n is not specified it defaults to 1.
Fatdog will search for fd64save* (or whatever filename you specify
in the savefile parameter) starting
in the directory you specified there too (default is root directory).
If, for example, you want it to search in subdirectories up to
3-level deep, specifiy search=3
instead. If more than one savefile matching the pattern if
found, they will be listed and you will be asked to choose the
one to use.
Search is only performed when savefile specifies
a location of local or usb. Other location types
do not perform searching regardless of this parameter.
We generally recommend not to depend on this parameter on as searching slows down the boot process;
it is always better to specify the exact location of the savefile (using device / uuid / label locations) if possible.
Prevent named list of modules (drivers) to be loaded. Use this
if the system cannot start-up due to suspected bad modules. The
syntax is: blacklist=module1,module2,module3
and so on. Note: separate module names by comma, and there is no
space in between.
pfix=xorgwizard
Launch xorgwizard automatically to select the driver, screen resolution, and bit depth
before you start the desktop. This option only has effect if you choose autologin or
console login, it is ignored when graphical login manager is in effect.
pfix=nox
Do not automatically start X server and graphical desktop after
login. You can always start it manually later by running the
command xwin from console.
pkeys
Set the keyboard layout and console font you want to use for
the Linux console. Default is US keyboard (pkeys=us), with whatever font
the system has. You can change that here. Only restricted
options are available:
- de, be, br, dk, es, fi, fr, it, no, se, pt --- these will
use ISO-8859-1 font.
- cz, hu, pl, ro, sk, croat, slovene --- these will use
ISO-8859-2 font.
Specify it like this: pkeys=br to
enable Brazilian keyboard.
Note that once you go to the graphical desktop, you need to set
it separately using Keyboard Localization
from the Control Panel.
dofsck
Perform filesystem check on filesystems that will be used by savefile and basesfs,
before they are used. It will check both the physical partitions as well as the savefile.
Only ext2/3/4 and FAT filesystems will be checked.
Linux Kernel Parameters
This is a kernel boot option that tells the kernel not to
enable kernel mode setting (KMS). Video support is usually a
combination of a drm kernel driver and a Xorg driver working
together. KMS is used with Intel, Nouveau, and Radeon kernel
modules. KMS is required for Intel and Nouveau, and optional for
Radeon (although, with different features).
If you want to use the vesa Xorg driver, and you have hardware
that uses the Intel, Nouveau, or Radeon kernel modules, you may
need to boot with nomodeset, or blacklist
the matching module, or just delete the module. The modules will
be found in
/lib/modules/<kernel-version>/kernel/drivers/gpu/drm/.
This kernel boot options tells the kernel KMS driver on what resolution and/or
frequency to use. For this to work, KMS must not be disabled (see above).
The format of the option is as follows:
video=conn:res[M][R][-bpp][@refresh][i][m][eDd]
This option can be specified multiple times, one for each different connection name - so you can have
on settings for VGA, one for HDMI, etc.
- conn means the connection name, which depends how your monitor is connected
to the system. Listed are some common connection names, their names are self-explanatory:
- VGA (VGA connector)
- DVI-I (DVI connector, supporting both digital and analog - rare)
- DVI-D (DVI connector, digital only)
- DVI-A (DVI connector, analog only - rare)
- composite (composite video)
- s-video (S-video output)
- LVDS (Laptop panel)
- component (component video output)
- displayport (Mac display)
- HDMI-A (the first HDMI port)
- HDMI-B (the second HDMI port)
- TV (TV output)
- res stands for the resolution.
It is specified as widthxheight, in pixels
(e.g. 800x600).
- M if specified, means that the display timing frequency will be computed
using VESA CVT standard,
otherwise a hard-coded timing table will be used.
- R if specified, means that a "reduced blanking" display timing frequency
will be used. This is useful for digital displays (LVDS, DVI or HDMI). Otherwise standard timing will be used.
- -bpp stands for bit-per-pixel, that is, the bit-depth of the display, that is,
the number of colours to be used. If not specified, the driver will choose the highest supported one.
Common values are:
- -32 (32-bit per pixel: 16million colours)
- -24 (24-bit per pixel: 16million colours)
- -16 (16-bit per pixel: 64thousand colours) - you're unlike to use this nowadays
- -15 (15-bit per pixel: 32thousand colours) - you're unlike to use this nowadays
- -8 (8-bit per pixel: 256 colours) - you're unlike to use this nowadays
- -4 (4-bit per pixel: 16 colours) - you're unlike to use this nowadays
- @refresh specifies display refresh rate (also known as the vertical frequency refresh rate).
Usually @60 or @59 for digital displays, you can specify others for analog / CRT monitors. If not specified the highest
supported rate will be used.
- i, if specified, means to use interlaced mode for calculation.
Only makes sense for analog / CRT monitors.
- m, if specified, means add some margins to the display timing calcuation (add 1.8% margin).
- m, if specified, means add some margins to the display timing calcuation (add 1.8% margin).
- e, if specified, means to enable the port (even if no device/monitor is detected).
- D, if specified, means to enable the port (even if no device/monitor is detected) and use the Digital interface.
- d, if specified, means to disable the port (even if there is a monitor attached there).
Note: This is a generic parameter used to set framebuffer display resolution.
It can also be used for non-KMS drivers too. That is not discussed here because
it is irrelevant, for further reference you can refer to Linux Kernel Framebuffer Documentation.
pci=nocrs
Discard pci ACPI information. May fix boot problems.
pci=noacpi
Do not use ACPI for PCI bus management. May fix boot problems.
acpi=off
Do not use ACPI. Note that modern systems probably will not boot
if this parameter is specified.
loglevel=n
Verbosity of kernel boot-up message. n is between 0 to
7. loglevel=0 means don't print
anything, loglevel=7 means print any
single details. Default is n=3.
More Linux kernel parameters can be found here
or here.
Advanced Parameters
Advanced parameters are used to fine-tune system operation at a
deeper level.
Once you are familiar with Fatdog64 basic operation, we recommend
you to read
this section. At least, read the savefile parameter - it is the
most useful.
savefile
This parameter tells Fatdog64 where to find the savefile. It
can be specified in three different ways:
- savefile=layer:location
This instructs Fatdog64 to load the savefile from the
specified location, and using the layering mode specified.
- savefile=none
This instructs Fatdog64 not to use any savefile at at all. In
earlier version of Fatdog, this parameter is called pfix=ram)
- savefile=ask
This instructs Fatdog64 to ask for the savefile details during
boot time. At boot time, you can either specify none or layer:location.
You can choose
layer from one of the
following:
- direct
This tells Fatdog64 to use the savefile directly - any writes
will go direct to the savefile.
- ram
This tells Fatdog64 to use the RAM layer. Any writes will
first be stored and collated in RAM, to be periodically
flushed to the actual savefile.
location
are split into two - the first part is always the "command" - you
have to type this as is, and the second part are options. These
are the "command" and the "options".
- local:path:crypt
Where:
- "local" is the command, you have to specify it as is. It
tells Fatdog64 to search for the specified savefile (see
below) on all local devices - harddrives, flash drive,
CD/DVD drives, etc.
- "path" is the path to the savefile including the
filename. Example: /fd64/600/fd64save.3fs
Path is optional, if you don't specify it, the default of
/fd64save.ext4 will be used.
- "crypt" is an option, it informs Fatdog64 that the
device where the savefile is in, is encrypted (not the
savefile itself). When this is specified, Fatdog64 will
ask for password during booting and try to decrypt the
device before attempting to mount it. Crypt is optional.
- usb:path:crypt
"usb" command is identical to "local" command above except
that it will only search USB local devices instead of all
devices. The limitations of the "local" command also applies
here.
- device:dev:path:crypt
Where:
- "device" is the command, you have to specify it as is.
It tells Fatdog64 that the savefile is available on the
specified device (see below).
- "dev" is the device/partition name where the savefile is
located, for example sda1, sdb, etc.
- "path" is the path to the savefile including the
filename. Example: /fd64/600/fd64save.3fs.
Path is optional, if you don't specify it, the default of
/fd64save.ext4 will be used.
- "crypt" is an option, it informs Fatdog64 that the
device where the savefile is in, is encrypted (not the
savefile itself). When this is specified, Fatdog64 will
ask for password during booting and try to decrypt the
device before attempting to mount it. Crypt is optional.
Fatdog64 also accepts "dmcrypt" option, which means that the
encryption will use dm-crypt (LUKS) instead of cryptoloop.
- label:dev-label:path:crypt
"label" command is identical to "device" command, except that
instead of specifying the device/partition by its device name,
you specify the device label. You can name your
device/partition using tools such as Gparted. Note: label
cannot contain space or colon.
- uuid:dev-uuid:path:crypt
"uuid" command is identical to "device" command, except that
instead of specifying the device/partition by its device name,
you specify the its uuid. You can set uuid for your
device/partition using tools such as Gparted. Note: uuid
cannot contain space or colon.
- cifs:user:pass:unc:path
Where:
- "cifs" is the command, you have to specify it as is. It
tells Fatdog64 that the savefile is available on the
specified CIFS (SAMBA/Windows) share. For this command to
work, you also need to tell Fatdog64 to enable network
during boot - use the net
parameter.
- "user" is the userid for the cifs share. If user is set
as +, Fatdog64 will ask you for
the user/password at boot time.
- "pass" is the password for the cifs share.
Note:
whatever you specify here can be seen in /proc/cmdline
after the system boots up. If you don't want anyone to see
your cifs password, use +:+ as the
user password and Fatdog64 will ask it at boot time -
nothing will be shown in /proc/cmdline.
- "unc" is the UNC (Universal Naming Convention) path to
the CIFS share. Specify the IP address (or the hostname)
of the CIFS server, as well as the shared folder name. Do
not include path within the shared folder - if you need to
specify this, use "path" option below. UNC cannot include
space. Example: //192.168.1.5/MyShare.
- "path" is the path to the savefile including the
filename. Path is optional, if you don't specify it, the
default of /fd64save.ext4 will be used.
- nbd:host:port:crypt
Where:
- "nbd" is the command, you have to specify it as is. It
tells Fatdog64 that the savefile is available on a NBD
(network block device) on a specified hostname and port.
For this command to work, you also need to tell Fatdog64
to enable network during boot, and of course don't tell it
not to load modules (or drivers) during boot - use the net parameter.
- "host" is hostname of the NBD server. You can specify
either IP address or hostname.
- "port" is the port number to connect to on the NBD
server.
- "crypt" is an option, it informs Fatdog64 that the the
nbd device is encrypted. When this is specified, Fatdog64
will ask for password during booting and try to decrypt
the device before attempting to mount the device. Crypt is
optional.
- multi:dev:path:skip
Where:
- "multi" is the command, you have to specify it as is. It
tells Fatdog64 to use multisession mode.
- "dev" is device where to keep the multisession savefiles
to. If not specified, this will be sr0,
presumably the first CD/DVD drive on your computer. If
this is not the case, you need to set it to the correct
device.
- "path" is the path to the savefile including the
filename. Path is optional, if you don't specify it, the
default of /fd64save.ext4 will be used. Note that in
multisession mode, only the basename (without extension) is used,
and Fatdog64 will prepend "multi" prefix and append the current date and time of when
the session is saved, for example for the default filename
of /fd64save.ext4, the actual
session savefile will be /multi-fd64save-2012-04-23T12-54+1000-save.sfs
- with the date and timestamp will be changed with every
save.
- "skip" is an integer that tells Fatdog64 to skip loading the
last "skip" number of sessions. This is to filter for
bad sessions or sessions you don't want to use. For
example, if you have 100 sessions, you can specify "5" as
the skip value here to tell Fatdog64 to load only the first 95
(=100 - 5) sessions. After this, you can burn and save to a new DVD
and save the session there - it effectively remove the
last 5 sessions. "skip" is optional, if you don't
specify it, Fatdog64 will load all available sessions.
Note: multission mode has only been tested with DVD+RW. It
will not work with CD, it may or may not work with
DVD-R/DVD+R/DVD-RW/DVD-RAM and others. It will also work with
hard drive and flash drive - but please ensure that they have
been properly set-up and initialised. Multisession does not
support encryption.
All commands that specify a savefile path, with exception of multi,
also accept a directory. If a directory is specified, the sessions will be saved
into that directory (="save directory") instead of a savefile. It works if the filesystem the partition is on
is ext2/3/4, for others success rate varies. The directory must already exist - Fatdog will not
create and use one if it doesn't. You can use the entire partition by specifying "/"
as the save directory - this would be identical to "save to partition" under Puppy Linux. (Note: Under previous version
of Fatdog (Fatdog 600 and 610), the same thing is accomplished using "+" to save to partition. This is no longer supported).
Savefile can be encrypted (but not "save directory"). This
is done by having the filename contains _crypt_,
e.g. fd64save_crypt_me.ext4.
This is separate and different from the :crypt option, which
says that the device/partition where the savefile is, is
encrypted. You can also specify _dmcrypt_, which tells Fatdog64
to access the savefile using dm-crypt (LUKS) instead of cryptoloop which is used if you use _crypt_.
The default settings for savefile if you don't specify anything
is savefile=direct:local. This
approximates the behaviour of previous version of Fatdog (and
Puppy Linux).
Some examples:
- savefile=direct:device:sda1 --- use savefile named
fd64save.ext4 located in root directory of /dev/sda1, save
directly to it
- savefile=ram:device:sda2:/fd600/fd64save.3fs --- use
savefile named fd64save.3fs located in /fd600 directory of
/dev/sda2, use RAM layer
- savefile=ram:usb --- use savefile named fd64save.ext4
located in root directory of the first found usb device, use
RAM layer
- savefile=direct:multi --- use multisession on device
/dev/sr0
net
This parameter tells Fatdog64 to start network as early as
possible, during boot time, so that it can be used to load
basesfs and savefile from network locations (cifs and nbd). It
also automatically enables coldplug parameter. It can be
specified in two different ways:
- net=type:device-settings:ip-address-settings
This instructs Fatdog64 to load the basesfs from the specified
location.
- basesfs=ask
This instructs Fatdog64 to ask the savefile during boot time.
At boot time, you can either specify none
or location.
The supported
types are as follows:
- wired - for wired network
- wpa - for wireless network using WPA security
- wpa2 - for wireless network using WPA2 security
The
device-settings depends on which types
are used.
- For wired network, you only need to specify the network
device name e.g. eth0
Example: wired:eth0
- wpa or wpa2 network, you need to specify the
ssid:password:device.
Example: wpa2:myhome:xyzzy:wlan0
Note: the password you specify here is visible in
/proc/cmdline after you boot. If you don't like this, you
should use net=ask and key in at boot time instead.
The
ip-address-settings determines whether
you want to use dhcp or static IP address. It is optional, if you
don't specify it, dhcp will be used.
- For dhcp, you only need to specify dhcp.
Example: net=wired:eth0:dhcp
- For static IP address, you need to specify
ip:ip-address:netmask:gateway:dns
gateway and DNS is optional.
Example:
net=wired:eth0:ip:192.168.1.2:255.255.255.0:192.168.1.1:192.168.1.1
basesfs
This parameter tells Fatdog64 where to find the basesfs file
(fd64-600.sfs). It can be specified in three different ways:
- basesfs=location
This instructs Fatdog64 to load the basesfs from the specified
location
- basesfs=none
This instructs Fatdog64 not to use any basesfs at at all.
Booting with no basesfs will run a console-only minimal system
based on busybox (bulldog).
- basesfs=ask
This instructs Fatdog64 to ask for the basesfs during boot
time. At boot time, you can either specify none
or location.
For details on
location, please refer to
the
savefile here.
They are identical.
base2ram=yes
This instructs Fatdog to load the basesfs into RAM. By default, basesfs is
contained within the initrd itself ("humongous initrd") and is automatically to
loaded to RAM; but if you use external basesfs, they are not, except when
this parameter is used.
withlvm
This tells Fatdog to enable its LVM support. When LVM is enabled, Fatdog64
will recognise LVM partitions and can load savefile / basesfs from these partitions.
withmdadm
This tells Fatdog to enable its mdadm (Linux software RAID) support. When mdadm is enabled, Fatdog64
will recognise mdadm partitions and can load savefile / basesfs from these partitions.
Advanced Troubleshooting / Debug Parameters
These parameters are listed here for completeness. Do not use them
you understand what you are doing,
or unless you are asked to for troubleshooting purposes.
Some of them are harmless but others can cause improper
functioning of Fatdog64.
coldplug
Do hardware detection and driver/module loading as early as
possible at boot-time. This option is automatically enabled if
you use the net
parameter - it is required to load the network drives (modules)
before network can be started.
This parameter is the opposite of blacklist. It tells Fatdog64 to
load specific modules that are not automatically loaded,
probably because it is not detected or because it has a conflict
with others modules. This can be used to load any modules,
although it is meant for loading modules required to access save
devices (the device where the savefiles are located) - although
if this is the case, coldplug may be a
better option (at a cost of slightly longer boot time).
The syntax is: loadmodules=module1,module2,module3
and so on. Note: separate module names by comma, and there is no
space in between. If the modules are not required during boot
time, don't use this parameter. Load modules from /etc/rc.d/rc.local instead.
Note: loadmodules takes precedence over blacklist.
keepvar
/var and /usr/local/var are places where system usually keep
logging messages and other run-time variables. Without proper
management, they can grown indefinitely big. Fatdog64 handles
this by deleting all files inside them during system start-up.
But sometimes the log files contains valuable messages that you
want to review (especially if you have a crash), so this
parameter tells Fatdog64 to "keep the files in /var" directory.
earlyshell
Get a shell as soon as it is possible to do so. You will be
running in busybox environment at the beginning of the init
process, just after modules have been loaded (after loadmodules/coldplug
are processed), but before anything else have been done.
Only /dev, /proc, and /sys are mounted.
This is in contrast with earlier Fatdog /
Puppy Linux "pfix=rdsh", which launches the shell after the
stackable filesystem has been constructed (see below). Type "exit" to
continue system startup.
Note: The shell you are running is not PID 1, you cannot
switch_root inside it.
lateshell
Get a shell just after the stackable filesystem has been setup.
This enables you to modify the root-to-be filesystem, for example
during troubleshooting. The root-to-be filesystem is located at
/aufs/new_root. You will still be running
in busybox environment, in the very final stages of init process.
After this, the system to switch the root to the stackable filesystem.
This option is roughly equivalent to Puppy Linux "pfix=rdsh" boot option.
Type "exit" to continue system startup.
Note: The shell you are running is not PID 1, you cannot
switch_root inside it.
showerr
Show verbose error messages on screen during system boot-up. It is normal
to see a lot of error messages, but most of them are harmless
(or meaningless).
When this option is not used, these messages are redirected to /dev/initrd.err.
debuginitrd
Trace execution of initrd. Output is shown to screen or saved to a file depending on showerr setting above.
DRV_DEBUG
Show the summary of modaliases processed. Use DRV_DEBUG=verbose to display all the
modaliases as they are being processed. This parameter only has
effect when coldplug is being used.
DRV_WAIT=n
Hardware detection (coldplug) is done twice (at least); n
specifies how many seconds to wait between each round. The
default is zero. This parameter only has effect when coldplug is
being used.