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


"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.


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.


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.


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.


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:

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.


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:


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.

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.


Discard pci ACPI information. May fix boot problems.


Do not use ACPI for PCI bus management. May fix boot problems.


Do not use ACPI. Note that modern systems probably will not boot if this parameter is specified.


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.


This parameter tells Fatdog64 where to find the savefile. It can be specified in three different ways:

You can choose layer from one of the following: 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".

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" - you can encrypt the underlying partition of save directory however). 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_.

You can use a keyfile to decrypt the LUKS partition - see the key{n} parameter below.

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:


The actual name of the parameter is actually key1, key2, key3, etc. These parameters specifies the location of keyfile used for decrypting LUKS partition or savefile. Each decryption "consumes" one key, e.g. if you put an encrypted savefile on encrypted partition, you will need to provide two keys (one for decrypting the partition, one for decrypting the savefile). The keys must be in sequential order without any gaps.

The parameter is specified as follows: key{n}=[wait:]type:id:path:[crypt]. Type can be device, label, or uuid, while id varies depending on the type.

For device, id is device id (e.g. sdb3), for label, it is the volume label of the device, and for uuid it obviously give the uuid of the device.

path gives the actual path to the keyfile, on the given device.

wait is an optional parameter that specifies that the system should give you a prompt to plugin a removable device (e.g. USB flash drive) before attempting to load the key from that device. This enables you to boot a system without the removable device plugged in, and only plug it at the time you want to load the key, and the remove it again.

crypt is an optional parameter that specifies that the device that holds the keyfile is encrypted. You can use either crypt or dmcrypt. You have to use passphrase to unlock this, you can't use another "key{n}" parameter to unlock a partition that holds another key.

The complete list of options for key{n} is:

If you specify ask, you will be asked to enter the details at boot time.


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:

The supported types are as follows: The device-settings depends on which types are used. 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.


This parameter tells Fatdog64 where to find the basesfs file (fd64-600.sfs). It can be specified in three different ways:

For details on location, please refer to the savefile here. They are identical.
option can be one of the following; they provide the same functionality as base2ram parameter (and takes precedence over it).


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. This parameter is deprecated, use basesfs options instead.


This instructs Fatdog to uncompress the basesfs into RAM. This will work whether the basesfs is internal (in initrd) or external. Since it uses RAM to keep the uncompressed version of the basesfs, using this option implies base2ram=yes. This parameter is deprecated, use basesfs options instead.


This parameter tells Fatdog64 to pre-load additional SFS files right before the system starts. These SFS files are loaded after the the union filesystem has been setup, and after /etc/fstab has been processed. SFS loaded this way are not kept in permanent record, however they can be un-loaded just like others using System SFS Loader.

You can load multiple SFS-es here, separating them by comma (spaces not allowed in the names):
For details on location, please refer to the savefile here. They are identical, although for now, only device, label and uuid are supported, the rest do not (they will be implemented if there is popular demand for them). Alternatively, you can also specify just a fully qualified path name, to a device that has been mounted earlier in /etc/fstab. "/mnt/home" is popular. The path can be anything, it can even point to a raw device (/dev/sdb) if relevant.

Location can also be prefixed with ram which means that the given SFS will be loaded to RAM (and thus will not hog the device it is loaded from). For consistency, you can also prefix it with direct although it will do nothing.

Example: extrasfs=/mnt/home/s1.sfs,ram:/mnt/home/s2.sfs,device:sdb:/path/to/s3.sfs,/dev/sdc

The last specification will load the entire partition of /dev/sdc as an SFS.


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.


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. Note: mdadm is for Linux software RAID, not for FakeRAID. At the time of writing FakeRAID is not supported at boot time, although they can be accessed after boot by installing the dmraid package.


This tells Fatdog to use posixovl when loading non-POSIX filesystems for use as savedir or savefile. Currently this affects only CIFS and FAT/VFAT filesystems. When this is specified, you can use CIFS or FAT filesystem for save-directory with all features you expect from a POSIX filesystem (file ownership, file-mode, symlinks, hardlinks, etc).

Notes: Due to limitation of FAT and CIFS, you must always use the RAM layer when using these as save-directory; and this is enforced by Fatdog. Also, since posixovl runs in user-space, don't expect great performance. You don't need posixovl to use NTFS as save-directory, as recent versions of ntfs-3g included in Fatdog already support POSIX features directly on top of NTFS.

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.


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. Put the module names in /etc/modules (one line at a time), or load the manually by adding the appropriate command to /etc/rc.d/rc.local instead.

Note: loadmodules takes precedence over blacklist.


/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.


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.


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.


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.


Trace execution of initrd. Output is shown to screen or saved to a file depending on showerr setting above.


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.


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.