Fatdog64 64-bit GNU/Linux Operating System
Fatdog64 is an all 64-bit version of GNU/Linux built from source packages for Intel/AMD systems. Despite its 'fat' name (and a 'fat' dog icon), Fatdog64 is a small, fast, yet versatile operating system targeted for the desktop home users.
Run it in LiveCD mode, LiveUSB mode, install it 'frugally' to your harddisk or SSD, or run from and save changes to a multi-session DVD. Use it in 'throwaway mode' (no persistent data is kept - all things are wiped out after you reboot), or persist your personal settings and configurations across reboots using savefile or save directory.
Fatdog64 installation requires no dedicated partition. Fatdog64 will happily use existing partitions of other operations systems to store its system files and savefiles - it can even use existing NTFS partitions.
What's the obsession with 'Fat'? Why the name 'Fat' dog? Fatdog64 was originally derived from Puppy Linux, yet another fast, small and versatile Linux operating system for 32-bit Intel/AMD systems. Fatdog Linux (the precursor to Fatdog64) started as an "extended" or "fatter" derivative of Puppy Linux, including extras such as the complete Xorg, inclusion of large packages such as Firefox, Pidgin, Gimp, Kino, etc that made it larger (in terms of size) than Puppy Linux. Over the time, Fatdog migrated to support 64-bit platform (hence Fatdog64 name) and grew became an independent distribution of its own - while striving to keep the original spirit of Puppy Linux of being small, fast, and versatile. For a fuller history click here.
Fatdog64 900 series - the latest iteration of Fatdog64 - is hand-built based on recipes from Linux From Scratch, version 11.3.
Additional Software
Additional software for Fatdog64 comes in two forms: regular software packages that needs to be installed to your system, and bundled prepared 'SFS' packages that you can load/unload on demand.
Regular packages
Starting from version 700, Fatdog64 regular software packages are packaged in Slackware-style tarballs, in fact, we use Slackware package management system (pkgtools) for handling local packages. Fatdog64 uses Gslapt from www.jaos.org as the user-friendly GUI front-end for easy access to package repository: viewing, downloading, and and installing packages (Gslapt replaced custom-brewed Fatdog Package Manager (FPM) and Puppy Package Manager (PPM) used in earlier versions of Fatdog64).
You can of course download packages directly from here (ibiblio), or one of ibiblio's many mirrors.
Note: Do not use Puppy pet packages in Fatdog64, Puppy's 32bit packages won't work.
SFS Packages
An 'SFS' package is a collection of packages, pre-installed in a 'SquashFS compressed filesystem' which will be 'merged' with your filesystem when you use it. SFS packages are usually commonly provided for a collection of software that are tightly integrated to each other; or packages which are very large (SFS helps because the packages in it are compressed. With regular packages, they get expanded during installation). There are common packages that are always provided in SFS format, for example the fd64-devx_xxx.sfs package is the "development" package and contain GCC compiler, perl, python, headers, version control systems (git, svn, etc) - everything you need to compile stuff. Fatdog64 kernel sources are provided in kernel-source-x.y.z.sfs (where x.y.z denotes the kernel version) - so you can build your own custom kernel (and kernel modules) too if you need to.
To use SFS packages, download it from here (ibiblio) (or its mirrors) and put it in /mnt/home, then launch System SFS Loader (from Fatdog64 Control Panel, the System tab). From there, choose the SFS you want to load. The loading can be done for just one time, or permanently at each boot time. Or you can use SFS Manager (also from Fatdog64 Control Panel) to download and activate the SFS at the same time.
Source packages used to build Fatdog64 can be found here.
Internet
Wired internet is automatically configured using DHCP when the system starts. To change the configuration afterwards click the Network Tool icon. Wireless Internet can be configured from the same Network Tool icon.
More info: How to connect to a network. More network tools are available in the Control Panel.
Useful Links
Puppy Linux Discussion Forum.
This is the main forum for Puppy Linux. Fatdog was initially derived from Puppy Linux and thus were part of the Puppy Linux family and community. Fatdog64 posts have its own section in the forum. Older posts about Fatdog64 can be found in Puppy Linux old forum, and are usually found in the Puppy Projects sub-forum.
Frequently Asked Questions
Info on the latest Fatdog64 release.
Contributors
While Fatdog64 is primarily maintained and developed by "kirk", "jamesbond", "SFR" and "step", there are many people who have contributed packages, ideas, applications, scripts, bug testing, artworks, patches and many other things over the years. The following list is just a small, non-exhaustive subset of the contributors, in no particular order: 01micko, rcrsn51, billtoo, WillM, zigbert, L18L, and many others.
Fatdog64 logo is contributed by AFG Sinaulan ("afgs" from Puppy Linux old forum). Original images here.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from home.html on 2024-12-09.
Frequently Asked Questions
Listed in no particular order.
- Primer for Puppy Linux users
- Panel icons
- How to connect to a network
- My Broadcom Wireless does not work
- How to install Fatdog64 to a BIOS machine
- How to install Fatdog64 to a UEFI machine
- How to install Fatdog64 to a flash drive that works for both BIOS and UEFI machines
- Where can I find rEFInd boot loader?
- How to add keys to boot with Secure Boot enabled (Windows 8).
- How does Fatdog's layered filesystem work?
- Browser won't save to xxxx or import my bookmarks
- Okay I understand browser runs as spot, but then why cannot browser yet read contents of
/root/spot
? - I'm auto logged in as root, what's up with that?
- How do I install extra packages for Fatdog?
- I have amassed a large collection of pet packages from earlier Fatdogs, how do I use them now?
- How can I share files with other computers on my network?
- My laptop's touch pad ................
- Blank screen! (or texts are too small)
- My screen brightness controls don't work
- No sound!
- Why doesn't this Debian/Ubuntu package work?
- How can I make a new package?
- How can I make a new SFS package?
- How can I recompile one kernel module?
- How can I build an entirely new kernel?
- How can I replace the kernel modules in the initrd?
- How to use a different kernel
- How to temporarily boot with a different kernel
- Basic keyboard shortcuts
- How to use Fatdog64's built in sandbox environment
- User Mode Linux (UML) environment
- Boot options
- Humongous initrd (or, why does my computer boot slowly?)
- Printing problems?
- How to play BluRays
- Found a bug?
- How to enable the firewall
- How to change default programs (default browser, default editor, etc)?
- My savefile is not loaded after reboot!
- Clean desktop, I don't like it. How to put program icons back to desktop?
- How can I update my Browser or Flash Player?
- Can I use Netflix with Fatdog64?
- What happened to the Flash Player?
- Small lines or video noise in Google Chrome.
- How can I enlarge my savefile
- Bad 2d performance, tearing, or freezing with Radeon.
- Screen tearing, applications crashing on Nouveau
- OpenGL 2.1 not supported on Intel graphics
- Desktop takes a long time to show up on old Intel graphics
- Kernel thread (kworker) eats 100% of my CPU or my Mac is running super hot while doing nothing
- Suspend and hibernate
- Urxvt terminal issues
- Bluetooth issues
- How to listen to music using bluetooth speakers / headphones
- Using NVIDIA proprietary driver with Optimus-equipped laptop
- NetBIOS (Samba) Name Resolution
- How to change desktop icon themes
- How to find firmware for your devices
- How to build a custom Fatdog ISO
- Help! I cannot choose my savefile, my keyboard is unresponsive at boot time!
- My computer slows down after updating to the latest Fatdog ...
- Miscellaneous other known issues
- More links.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from faq.html on 2024-12-09.
Frequently Asked Questions
File list.
- bluetooth-audio
- bluetooth
- bluray
- boot-keyboard-problem
- boot-options
- brightness
- broadcom
- bugs
- chrome
- clean-desktop
- cpu-mitigations
- Debian
- defaults
- desktop-icon-themes
- disable-gpe
- enlarge-savefile
- faq_file_list
- faq
- fd-packages
- filesystem
- firefox-spot
- firewall
- firmware
- flash_player
- full-install
- get-refind
- harddrive
- home
- huge-initrd
- initrd
- intel-graphics
- iso-builder
- kernel-build
- kernel
- kernel-module
- keys
- libinput.4
- links
- login
- misc
- mtrack
- netflix
- Networking
- no-savefile
- nouveau
- optimus
- p4p-index
- panel-icons
- pet-package
- printing
- radeon
- sandbox
- screen
- secure-boot
- sfs-package
- sharing
- smb-browser
- sound
- spot
- suspend
- synaptics.4
- temp-boot-kernel
- touchpad
- uefi-flashdrive2
- uefi-flashdrive
- uefi-harddrive
- uefi-lick
- uml
- updates
- urxvt
- usb-boot
- winbindd
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was created on 2024-12-09.
Foreign software packages (Debian/Ubuntu/Slack/...)
You may find many foreign packages (Debian/Ubuntu) that work; however, many will not. This is because of incompatible libraries. You may be more successful if your foreign packages are released close to the build date of the Fatdog64 version you use. For example the Fatdog 500 series (500, 510, 520/521) build date is 2009, so for Debian this would be Etch or Lenny. For the Fatdog64 600 series (released in 2012), you may be able to use Debian Squeeze. The 700 series is near in time to Debian Jessie, and the 800 to Debian Stretch.
Even then this may not work, because of missing software libraries or how libraries are compiled differently in Fatdog. You can try to extend your luck by also installing the missing libraries as well from your foreign package source, but this is pushing it.
If you still cannot get it to work, you might try using either a similar package from Fatdog64 repository, or compiling that package from source.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from Debian.html on 2024-12-09.
Networking
The main network connection manager is Network Tool (forked from wpa_gui). The auxiliary connection manager is Network Setup.
Network Tool
Network Tool supports wireless and wired connections.
Click its panel icon to set up connections. If connections need your attention the icon could look like this:
Right click to restart the connection.
Connect to Wireless Networks (Network tool Wifi tab)
The Network Tool automatically connects to one of the enabled network profiles listed in the Manage Networks sub-tab.
Press the Scan button to discover which networks are available in your current location. Add new network profiles to the Manage Networks sub-tab as explained below.
To add a new profile and connect to the network:
- If your computer has multiple wireless adapters, Network Tool can only connect using one wireless adapter at the time. Select which one from the Adapter pull-down. See also: Wireless Antenna Manager.
- Click Scan to open the Scan results window. Click the Scan button if needed to refresh results. You might have to wait several seconds for your network to show.
- Select and double click the network SSID of your network.
- Select the authentication method appropriate for your network, and type all required credentials. For WPA2-Personal authentication the password goes into the PSK field.
- Enable the DHCP field to receive an automatic network address. If you prefer to configure a static address disable the DHCP field and press Configure Static Address (see Configuring a Static Address for further instructions).
- Press Add to add the new profile to the Manage Networks sub-tab. Click Save Configuration in the File menu to save for the next reboot.
- On the Current Status sub-tab, you should see a connection being made to your newly added profile unless the Network Tool has already connected to another network. To manually select a network, use the Network pull-down and press Connect.
Tips:
- To always connect to a specific network disable other networks in the Manage Networks sub-tab.
- The Flags column (Scan results window) shows the authentication and encryption methods that the selected network supports.
- If [WPS] is shown you may also use the WPS tab to connect with your network Access Point (AP) without a password. Refer to your AP manufacturer's documentation.
Configuring a Static Address
When you disable DHCP in the Wifi (or Wired) tab you come to this dialog to set a static address. The dialog guesses reasonable defaults for a simple home LAN setup. For more advanced configurations, and for troubleshooting issues, you will need to read up what each parameter really does. Getting static addressing right needs some experience.
- Enter IP address, Subnet Mask and Gateway.
- Enter DNS1 address and optionally DNS2. The default values set Google's DNS servers. You may want to replace these with your ISP's DNS server addresses.
- Select a save method for the new configuration. You can always change the save method later. Choose Interface to tie the static address to your interface name, like wlan0 or eth0. This is recommended if you run Fatdog64 on the same system all the time, like your notebook or desktop system. Choose Mac Address otherwise, for instance, if you carry Fatdog64 on a USB flash key, and boot several systems in different network environments with it.
Tips:
-
Configuration files for static addresses are located in directory
/etc/wpa_gui
. -
Unlike an Interface name, the Mac Address uniquely identifies a network adapter. The interface name (wlan0, wlan1, eth0, and even longer names), is unique within the same computer, but will likely clash if re-used for multiple computers.
-
Linux assigns and remembers Interface names automatically. Sometimes it can be useful to clear all saved names and force Linux to start assigning them again. This can be done from the Network Setup Troubleshooting menu. If you do this, you will need to reconfigure static addresses.
-
Optionally, by editing file
/etc/resolv.conf.head
you can add DNS servers that take precedence over the servers configured with the Network Tool. Both server sets are enabled, but the latter is used only when the former isn't available. Here is a sampleresolv.conf.head
:# static DNS.WATCH nameservers for privacy nameserver 84.200.69.80 nameserver 84.200.70.40 # end of /etc/resolv.conf.head
Connect to Wired Networks (Network Tool Wired tab)
A wired connection hooks up your computer to your home network router with an Ethernet cable.
- If your computer has multiple wired adapters, the Network Tool can only connect using one wired adapter at the time. Select which one from the Adapter pull-down.
- Enable the DHCP field to receive an automatic network address. If you need to configure a static address disable the DHCP field and press Configure Static Address (review Configuring a Static Address).
- Link Status should be "up". If it isn't either the network cable is not connected, Fatdog64 is still busy starting network services, or the adapter isn't properly installed or configured at boot time.
- Press Connect/Enable and watch the red "Interface disabled during boot" line change to a green "Interface enabled during boot" line. This refers to the next time you will boot the system. Also, the current session is connected via the wired adapter.
Restarting the Connection
If you have problems connecting to a network, right click the Network Tool icon and select Restart Connection. This action will restart wireless network services.
If the Network Tool manages your wired connection, this action will also restart wired network services. (The other way to manage wired connections is Network Setup).
When the Network Tool is left free to automatically select the best network, it will do so based on the order of network entries in the Manage Networks sub-tab, their network security level (WPA/WPA2 is preferred), and signal strength. Network entries are saved to the configuration file.
Configuration file: /etc/wpa_supplicant.conf.
Wireless services: wpa_supplicant, wpa_cli, dhcpcd.
Wired services: dhcpcd.
Wireless Antenna Manager
The Wireless Antenna Manager applet can be started from the Control Panel Network tab.
It can be used to temporarily enable/disable the antenna of a wireless adapter. This can help in troubleshooting network connections for computers equipped with multiple wireless adapters.
Network Setup
Network Setup can be used to connect wired and wireless networks in a way that is independent of Network Tool.
For ease of use and breadth of features most users should prefer Network Tool over Network Setup, which still provides some unique features. Most prominently, the ability to set up network connections without running Xorg. Network Setup uses text-based dialogs that work for both the system console (no Xorg), and a terminal window (Xorg).
For the system console, start Network Setup with command network-setup.sh
. For Xorg start the Network Setup applet from the Control Panel Network tab.
To navigate the dialog use the Up and Down arrow keys to hightlight a menu entry, the Enter key to activate it, the Tab and Shift Tab keys to cycle across the input fields and the buttons, and the Esc key to go back one level.
Connect to Wireless Networks with Network Setup
You can configure a static or automatic (DHCP) address for your wireless (wlan0) adapter.
The concepts and actions that are involved are similar to those for Network Tool, where they are explained in more detail.
To add a new profile and connect to the network:
- In the main window select Configure IP address then choose the interface adapter to configure, wlan0 in this example, but the actual name may be different for your computer.
- Select Auto-configure using DHCP, and acknowledge the confirmation window. If you prefer to configure a fixed IP address select instead Use static IP (see Configuring a Static Address with Network Setup for further instructions).
- Go Back to the main window.
- In the main window select Configure access profile then choose the same interface adapter, wlan0.
- Select New profile from existing networks. This will scan for available wireless networks.
- Select the name (SSID) of your wireless access point, "homewifi" in this example.
- The SSID and Security fields are automatically filled in. Normally you don't need to change them.
- Fill in the password for "homewifi" and press OK.
- Go back to the main window.
- In the main window select Activate settings now then choose the same interface adapter, wlan0.
- Select the name of the profile you want to activate. For wireless it is the SSID name.
Tips:
- Network Setup saves configurations under directory
/etc/network-setup
Configuring a Static Address with Network Setup
When you select "Use static IP" in step #2 above you come to this dialog to set a static address.
- Enter IP address, Netmask and Default Gateway.
- Enter DNS server 1 and optionally DNS server 2. The default values set Google's DNS servers. You may want to replace these with your ISP's DNS server addresses.
- Press OK to save the configuration for your interface name.
See also Configuring a Static Address for wireless networks for general information about static addresses.
Connect to Wired Networks with Network Setup
To add a new profile and connect to a wired network follow the instructions given for wireless networks, but select a wired interface (eth0). You will not need to scan for networks or to enter an access password.
Disable / Enable WpaGui
In the main window you can disable / enable Network Tool services. This applies at the next reboot and every reboot after, until Network Tool is enabled again from Network Setup.
Troubleshooting Menu
"Reset udev persistent net rules" clears the interface names that Linux automatically assigns to network adapters. Then Fatdog64 will restart wired adapter names from "eth0" and wireless adapters from "wlan0". If you use this entry you will need to configure all static IP addresses again.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from Networking.html on 2024-12-09.
How to listen to music using Bluetooth speakers or headphones
Overview
There are three methods to listen to music using Bluetooth speakers or headphones. But before you begin, you need to ensure that your Bluetooth connection works; and your devices (speakers/headphones) can be paired with your computer. The easiest method to do this, is by using the Simple Bluetooth Manager which you can find under the Control Panel (for Fatdog 812 and up). For older Fatdogs, you will have to use command line methods as explained here.
Once that's settled, you're ready to go.
The three methods are:
- Direct connection to the Bluetooth speakers.
- Connect to the Bluetooth speakers using bmixd ("bluealsa dmix daemon").
- Connect to the Bluetooth speakers using aloopd ("ALSA Loop Sound Daemon")
All methods use of the "Fatdog Default Sound Card" applet (a configuration program found in the Control Panel); and some require additional steps.
1. Direct Connection
This is the oldest, and the simplest method to set up, but it comes with certain restrictions. For one, only one audio application can deliver audio to the Bluetooth device. If another audio application tries to send audio, it will fail (at best, no sound is heard, at worst, the application will crash or it will refuse to start).
Follow these steps:
- Make sure that your Bluetooth device has already been paired.
- Launch the "Fatdog64 Set Default Sound Card" applet found in Control Panel's "Sound" tab.
- In the device selection screen, choose "Bluetooth Devices".
- You will see another selection screen that shows the Bluetooth devices that you have previously paired. Choose one which is already paired.
- Choose optional audio features (plugins) as needed, then click "OK".
- The program will attempt to connect to your device, and if successful, you will hear sound from your speakers. You may want to use the "Fatdog Speaker Test" applet found in Control Panel's "Sound" tab to confirm that sound ouput works.
That's all. If you didn't see "Bluetooth devices" in the selection screen, it means the Bluetooth service is not running. You need to start it first. If you cannot start it, something is wrong and you will need to troubleshoot the service first. Some possible problems and fixes are discussed here.
To switch sound to another Bluetooth device in future, and/or to switch back to the computer's internal soundcard, you will need to stop all audio applications, then run the "Fatdog Default Sound Card" applet again. Don't forget to "disconnect" your Bluetooth speaker too using the Simple Bluetooth Manager or any other tool of your choice.
You will need to re-connect your Bluetooth device after each reboot.
2. Connect using bmixd
The second method is to use bmixd, a background process that runs continuously to support plug-and-play of the devices. This method is more flexible than a direct connection because multiple applications can share the speakers; their audio outputs will be mixed together. You can also disconnect a device and re-connect sound to a different device, without re-starting all the audio applications.
Follow these steps:
- Make sure that your Bluetooth device has already been paired.
- Launch the "Fatdog64 Set Default Sound Card" applet found in Control Panel's "Sound" tab.
- In the device selection screen, choose "Bluetooth audio using blue-alsa bmixd".
- Choose optional audio features (plugins) as needed, then click "OK".
- You will be reminded to start the bmixd service. You can do so either manually from terminal by typing "service bmixd start", or with the "Manage Servers and Services" applet found in Control Panel's "System" tab.
- Lastly, connect your Bluetooth device.
That's all. To switch devices in future, you will need to disconnect the current device, and re-connect to another one. You won't need to stop all audio applications and restart them again; except if you want to use the computer's internal audio again.
You will need to re-connect your speaker again after each reboot, and re-start the bmixd service (unless you set it to auto-start).
3. Connect using aloopd
This method is only available from Fatdog 812 and up.
In addition to the features you get from bmixd, if you use this method, you will be able to switch the audio to any device without restarting the audio applications, either Bluetooth or internal computer device or a remote computer using network audio.
Follow these steps:
- Make sure that your Bluetooth device has already been paired.
- Launch the "Fatdog64 Set Default Sound Card" applet found in Control Panel's "Sound" tab.
- In the device selection screen, choose "ALSA Loop sound server (aloopd)".
- Choose optional audio features (plugins) as needed, then click "OK".
- You will be prompted to launch aloopdcfg, the "Configure ALSA Loop" applet, to set the output. device. Choose "Yes".
- In the selection screen, choose "Computer >--> Local Speaker" then choose the Bluetooth output device you want to connect to.
That's all. To change the output device in future, you will need to launch the "Configure ALSA Loop" applet again, which you can do from the Control Panel "Sound" tab.
You will need to re-connect your speaker again after each reboot, and re-start the aloopd service (unless you set it to auto-start).
Aloopd can do more than just connect bluetooth speakers. You can use aloopd to output to multiple devices (e.g. to your bluetooth and to your internal soundcard), use it to record what you hear, and other things, which is beyond the scope of this FAQ entry.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from bluetooth-audio.html on 2024-12-09.
Bluetooth known issues
1. Bluetooth does not work.
Like Wi-Fi adapter, the support for bluetooth adapter in Linux varies greatly, depending on hardware vendor support. So the first thing to check is whether your adapter is supported by the Linux kernel.
Intel-based adapters usually work very well with few exceptions. All you need to ensure is you have the latest firmware.
Broadcom-based adapters are very quirky. Some requires firmware that is not publicly available - you need to fish it out from somewhere else (e.g. Windows drivers); and you need to use special tool to upload it to the the adapter. Fatdog64 includes two of those tools: brcm_patchram_plus and brcm_patchram_plus_usb but due to great variation between models, they may not work.
Run dmesg in a terminal and check for signs whether the kernel detect problems with your adapter.
Run "hciconfig hci0 up" in a terminal and see if you have got any error messages.
2. Where is the bluetooth applet?
In Fatdog64 800, the bluetooth stack (bluez) is updated to version 5.50 (older Fatdogs used bluez 4.101). This is a major change, and the bluetooth applet used in previous versions does not work with the new bluez. Thus it has been removed. Starting from Fatdog 812, we now have a Simple Bluetooth Manager as a replacement, which can do most of the tasks that the bluetooth applet used to handle. The manager can be found in the Control Panel, or it can be launched from terminal as btmanager.sh. The manager will work both on GUI and in console terminal.
In addition to the simple manager (and for earlier versions of Fatdog before 812), Fatdog offers an extensive CLI-based management for bluetooth devices. Aside from bluetoothctl, bluez's own CLI tool (which is much improved than older tools), Fatdog64 includes bluez-tools (bt-adapter, bt-device, bt-network) which makes most bluetooth operations such as pairing, connection, and disconnection very simple.
To find out nearby device: bt-adapter -d (press Ctrl-Break when done)
To pair with nearby device: bt-device -p XX:XX:XX:XX:XX:XX (where XX:XX is the bluetooth mac address you get from discovery process, above).
To connect: bt-device -c XX:XX:XX:XX:XX:XX (this works for all devices: mice, keyboard, speaker, etc)
To disconnect: bt-device -d XX:XX:XX:XX:XX:XX
To view all existing paired device: bt-device -l (this is lower-case L, not a capital i).
To remove a paired device: bt-device -d XX:XX:XX:XX:XX:XX (where XX:XX is the bluetooth mac address from the list, above)
3. My adapter is supported but it does not work. I plugged it in after the system is up and running.
You need to bring the device up: "hciconfig hci0 up". This is usually done at boot-up but if you haven't plugged automatically, it can't be done, so you will have to do it manually.
Also, if you plan to connect to a bluetooth speaker, then you need to restart the bluetooth service: service bluetooth restart . This is because bluealsa (the component that provides bluetooth audio support) will fail to start if there is no bluetooth adapter; so you need to restart the entire stack.
4. "Setup Bluetooth Modem", in the Network tab, in Control Panel, does not work.
It might as well probably be. Due to the major upgrade between bluez 4.101 in earlier Fatdogs and bluez 5.x in Fatdog 800 and newer, the modem setup GUI may not work anymore.
Unfortunately, we can neither test it nor fix it, as we no longer have a device that can be used to test this functionality, so you are on your own.
The relevant function is located in /usr/sbin/fatdog-bt-find-dun.sh and /usr/sbin/fatdog-bt-find-dun.awk, if you want to troubleshoot it yourself. Don't forget to send a patch if you make it to work.
5. My Microsoft Bluetooth Mouse does not work.
Certain bluetooth mice, such as some models of MS mice, requires the "uhid" kernel module to work. Otherwise, they can pair, trust and connect, but they will not work.
The solution to this problem is:
- To load the uhid kernel module. This can be done by running modprobe uhid in terminal, or, you can do this automatically at every boot by editing /etc/modules and adding a line containing the word uhid all by itself.
- Then, you need to edit /etc/bluetooth/input.conf and uncomment the line UserspaceHID=true (remove the # in front of it), and then restart the bluetooth service (do that from Control Panel --> System --> Manage Servers and Services).
6. How to listen to music on my bluetooth speakers/headphones?
Bluetooth audio has its own support page, here.
7. I paired with my phone, but when I tried to send files, my phone cannot see my computer.
The problem is the computer device class, which is advertisement of what the computer can do (to other devices). The default value is 0x000100, which only identifies it as a computer, but does not include any capabilities. Some phones can cope with this, some cannot.
To be able to send/receive files, the computer needs to advertise that it supports Object Transfer (that is, file transfer). To do this, please set the computer device class to 0x100100 using the Simple Bluetooth Manager (if you want to do this yourself, edit /etc/bluetooth/main.conf.
You can synthesise the required device class value by looking at this website: http://bluetooth-pentest.narod.ru/software/bluetooth_class_of_device-service_generator.html
Other good source of information is available in ArchWiki Bluetooth article as well (but not all of them are applicable to Fatdog, especially the one concerning systemd, because Fatdog does not use systemd).
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from bluetooth.html on 2024-12-09.
BluRay support
The VLC media player in Fatdog64 can support BluRay playback. For that to work you must install a file containing the keys. The name of the file is KEYDB.cfg and is placed in ~/.config/aacs/. The KEYDB.cfg file provides processing keys and a host key that provides decryption. The processing keys are changed occasionally. The revision of the processing keys corresponds to the Media Key Block (MKB) version. Currently there are KEYDB.cfg files that support up to MKB version 30. Another optional file named vuk which would also be placed in ~/.config/aacs/, contains keys that are specific to a particular disk. The vuk keys can also be combined into the KEYDB.cfg file.
Steps to play a BluRay in Fatdog64:
- Check your local laws to see if it is legal for you to play the disks that you own. Sadly that's not a joke.
- Find a KEYDB.cfg file and put it in ~/.config/aacs, for most users you'll have it here: /root/.config/KEYDB.cfg
- Click on the optical disk icon on your desktop. VLC should play the Bluray.
If it does not play it probably means that your KEYDB.cfg doesn't have a key to support the MKB version of your disk.
A good page to look at for more information is here.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from bluray.html on 2024-12-09.
My keyboard does not work at boot time
Among other things, symptoms for this problem include:
- Not able to select a savefile from list of available save files.
- Not able to type anything when entering initrd's shell (either earlyshell or lateshell).
- Not able to type anything when dropping to the Fatdog's Bulldog rescue shell.
The main cause of this problem is that the driver (=module, in Linux parlance) for your keyboard is not loaded yet.
Drivers for most keyboards are built-into the kernel so that keyboards get recognised and work immediately; but a certain number of keyboards don't. Some supported keyboards could also be connected using proprietary USB hubs whose drivers are not built-in; and these end up having the same problem.
To expedite the boot process, the drivers for all system devices are loaded __after__ boot time, not at initrd's time. This however is a problem if we need to use devices (e.g. these keyboards) that require drivers at initrd time, whose drivers are not loaded yet.
The solution is simple: use the coldplug parameter. This parameter forces all drivers to be loaded at initrd time. It slows down the boot process a little bit, but it should make all your devices work. (If they still don't work then it is another problem altogether).
Of course, in order for this parameter to work, it assumes that the kernel can find the drivers. This is true for the standard initrd as it contains all the drivers, but it is not true for initrd-nano (the smallest variant of Fatdog's initrd). So it means that if your system requires coldplug to work, you will have to use the standard initrd and cannot use initrd-nano.
PS: This problem does not only involve keyboard. Sometimes your internal harddisks (or SSD) may require drivers which are not built-in as well; and in this case, you also need to use the coldplug parameter. Otherwise, whatever you do, you cannot load a savefile created on your internal disks.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from boot-keyboard-problem.html on 2024-12-09.
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.
On Fatdog64 720 onward, the syntax is waitdev=n[:n[:n[...]]] where each number represents the number of seconds to wait, for each "wait points". In 720, there are two "wait points", one is at early boot before basesfs/savefile is loaded (this is the same as the original waitdev), and the second one is in rc.sysinit, before pkeys is processed and before Xorg is loaded. The two wait points is independent, you can specify one without another. For example, if only want to wait for 3 seconds at the second wait point, you can specify it like this: waitdev=:5 (the colon is not a typo).
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.
autoswap
(Fatdog64 803 onwards): Detect and use all existing swap partitions. It detects and uses only swap partitions, not swap files.
blacklist
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
nomodeset
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/.
See also here.
video
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.
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 using the specified layering mode. - savefile=none
This instructs Fatdog64 not to use any savefile at all. In earlier version of Fatdog, this parameter is called pfix=ram) - savefile=ask
This instructs Fatdog64 to ask for the savefile details 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 is split into parts - the first part is always the "command" - you have to type this as is, and the remaining parts are the "options". Here is the list of commands and their respective 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, which can be either "crypt" (cryptoloop) or "dmcrypt" (LUKS). It informs Fatdog64 that the device that the savefile is in is encrypted (not the savefile itself). When this is specified, Fatdog64 will ask for a password during booting and try to decrypt the device before attempting to mount it. Crypt is optional. As of version 811, Fatdog64 can detect LUKS encrypted devices automatically, so "dmcrypt" doesn't have to be specified anymore.
-
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, which can be either "crypt" (cryptoloop) or "dmcrypt" (LUKS). It informs Fatdog64 that the device that the savefile is in is encrypted (not the savefile itself). When this is specified, Fatdog64 will ask for a password during booting and try to decrypt the device before attempting to mount it. Crypt is optional.
As of version 811, Fatdog64 can detect LUKS encrypted devices automatically, so "dmcrypt" doesn't have to be specified anymore.
-
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.
-
9p:tag:path
Where:- "9p" is the command (available from Fatdog64 900 onwards), you have to specify it as is. It tells Fatdog64 that the savefile is available on the specified 9p remote filesystem. This command is meant for use with Qemu's 9p support (although with suitable modification you can use it to connect with real 9p network filesystem). For this command to work, you need to pre-load 9p related modules, using the loadmodules parameter. At the time of writing, the required modules are: 9p, 9pnet, 9pnet_virtio and virtio_pci, although this can change depending on different kernels. Or you can just use coldplug. (If you use this to connect to a real 9p network filesystem, then you need to enable network as well using the net parameter).
- "tag" is the mount-tag specified in the Qemu host. See details here on how to setup the Qemu host. For a real 9p network filesystem, this is the hostname or IP address of the server exporting the share.
- "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, which can be either "crypt" (cryptoloop) or "dmcrypt" (LUKS). It informs Fatdog64 that the device that the savefile is in is encrypted (not the savefile itself). When this is specified, Fatdog64 will ask for a password during booting and try to decrypt the device before attempting to mount it. Crypt is optional.
As of version 811, Fatdog64 can detect LUKS encrypted devices automatically, so "dmcrypt" doesn't have to be specified anymore.
-
multi:dev:path:skip
-
multi:device:dev:path:skip
-
multi:uuid:dev-uuid:path:skip
Where:- "multi" is the command, you have to specify it as is. It tells Fatdog64 to use multisession mode.
- "device" and "uuid" are subcommands (multi:dev:path:skip is equivalent to multi:device:dev:path:skip).
- "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.
- "dev-uuid" is the device's uuid.
- "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" - 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_.
As of version 811, Fatdog64 can detect LUKS encrypted savefiles automatically, so _dmcrypt_ doesn't have to be a part of the filename anymore.
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:
- 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
btrfscompress=[zlib|lzo|zstd]
This is an optional boot parameter that tells Fatdog64 to enable compression on btrfs-formatted savefile. Both zlib and zstd (the latter since kernel v5.1) can have an optional compression level, zlib 1-9 and zstd 1-15, e.g.: "btrfscompress=zlib:5". Note that if you use this parameter, the specified compression will be enabled on all btrfs devices mounted by init.
key
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:
- key{n}=[wait:]device:dev:path[:crypt]
- key{n}=[wait:]label:label:path[:crypt]
- key{n}=[wait:]uuid:uuid:path[:crypt]
- key{n}=ask
If you specify ask, you will be asked to enter the details at boot time.
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=[wait:]type:device-settings:ip-address-settings
This instructs Fatdog64 to load the basesfs from the specified location. - net=ask
This instructs Fatdog64 to ask for the network details during boot time. At boot time, you can either specify the details you would otherwise specify in the boot parameter itself.
The wait parameter (available from Fatdog 810 onwards) is optional. It just tells Fatdog to pause (requires the user to press Enter key) before the net is processed. This may be useful in case you boot from USB and you want to un-mount the USB before you are connected to network, for example.
The supported types are as follows:
- wired - for wired network
- wpa - for wireless network using WPA security
- wpa2 - for wireless network using WPA2 security
- adhoc - for creating adhoc mesh wireless network
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 - For 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. - For adhoc, you need to specify the ssid:channel
Example: mynet:10
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.sfs). It can be specified in three different ways:
- basesfs=option:location
This instructs Fatdog64 to load the basesfs from the specified location (with the given option, if given). - 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 option:location.
option can be one of the following; they provide the same functionality as base2ram parameter (and takes precedence over it).
- Nothing (no option given)
- direct - which is ignored, for compatibility only (in case you misidentify this option from savefile layer)
- ram - load the basesfs to RAM (same as base2ram=yes)
- expand - load the basesfs to RAM, and expand it (make it run the fastest - same as base2ram=expand)
For details on location, please refer to the savefile here. They are mostly identical, except from Fatdog64 902 onwards, basesfs also supports the additional location type: findimg.
findimg:image-path:path
This is the path to load a basesfs that is located inside an image file, such as an ISO file (or other image type).
- "findimg" is the command, you have to specify it as is. It tells Fatdog64 to search for the given image file on all local devices: harddrives, flash drive, CD/DVD drives, etc.
- "image-path" is the path of the image file to be found. Example: /902/fatdog.iso. Note that Fatdog64 will find the device that contains the exact path. It will not do recursive directory search.
- "path" is the path of the basesfs inside the image-path. This parameter is optional, if not specified, it is assumed to be fd64.sfs. It too has to be specified as an exact path inside the image path.
Notes:
- In many cases, basesfs can reside in the same device as the savefile. But there are two locations where basesfs and savefile cannot reside together, and you absolutely have to specify two different devices for them: when the location is "cifs" or "nbd".
- Also, basesfs does not support the "multi" parameter.
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. This parameter is deprecated, use basesfs's direct/ram options instead.
base2ram=expand
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.
extrasfs
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):
- extrasfs=location,location,location,etc
For details on location, please refer to the savefile here. They are identical, although for now, only device, label, uuid, local, and usb 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.
mergeinitrd
(From Fatdog 720 onwards). The actual name of the parameter is actually mergeinitrd1, mergeinitrd2, mergeinitrd3, etc. These parameters specifies the location of additional initrd which will be loaded and merged during boot process, before basesfs is processed. The main motivation for this function is to have a small initrd, merge with a huge-initrd and obtain the basesfs from that huge-initrd without having to do anything extra. Or it can be used to extend or enhance Fatdog's main initrd with additional / extra functions, that reside in an external/optional initrd.
The parameter is specified as follows: mergeinitrd{n}=[wait:]location:path:[crypt]:[init-func]. For the details on location, please refer to basesfs parameter. This parameter only supports location types of device, label, uuid, local and usb and findimg; it does not support cifs, nbd, and others.
path gives the actual path to the initrd to be merged, 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 initrd 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 additional initrd, and the remove it again.
crypt is an optional parameter that specifies that the device that holds the initrd is encrypted. You can use either crypt or dmcrypt.
init-func is an optional parameter that specifies the initialisation function that will be executed as soon as the merge is done. This function is sourced by the main init function, and therefore cannot fail and cannot exist. It must return once the initialisation is done.
The complete list of options for mergeinitrd{n} is:
- mergeinitrd{n}=[wait:]device:dev:path[:crypt]:[init-func]
- mergeinitrd{n}=[wait:]label:label:path[:crypt]:[init-func]
- mergeinitrd{n}=[wait:]uuid:uuid:path[:crypt]:[init-func]
- mergeinitrd{n}=[wait:]local:path[:crypt]:[init-func]
- mergeinitrd{n}=[wait:]usb:path[:crypt]:[init-func]
- mergeinitrd{n}=ask
If you specify ask, you will be asked to enter the details at boot time.
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.
If a specific configuration is needed, use mergeinitrd boot option to merge and add /etc/lvm/lvm.conf during the boot process. Note that if you do so, please remember that the content of this file is not carried over to the running OS.
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. 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.
If a specific configuration is needed, use mergeinitrd boot option to merge and add /etc/mdadm.conf during the boot process. Note that if you do so, please remember that the content of this file is not carried over to the running OS.
posixovl
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 (except when you use ntfsnoperm parameter, see below).
ntfsnoperm
(From Fatdog 811 onwards) When mounting NTFS (either for savefile usage or by clicking on the drive icon), Fatdog by default uses the full NTFS permission system to map it to the POSIX permission. This enables files and directories in NTFS partition to behave as if they are located in POSIX filesystem (like ext3/ext4). One of the benefit of this, is that you can have savedir on an NTFS partition.
However, this assumes that you do not share this NTFS partition with Windows, because Fatdog will setup an NTFS permission that Windows don't understand (from Windows, the files and directories will be seen as owned by a foreign user). It is possible to map the the Fatdog NTFS user to Windows NTFS user, but the process is a little complicated. You can also choose not to map it, but each time you access these files and directories, you will have to assign yourself access to it.
If this is too troublesome, it is possible to tell Fatdog not to use the the full permission mapping and instead just use the usual uid/guid mapping (which means that all files/directories in the NTFS permission will be owned by a particular uid/guid - as specified in the Fatdog Event Manager). This is what ntfsnoperm parameter is for. Of course, when you do this, then you no longer can use savedir on NTFS. You can, however, always use savefile on an NTFS - with or without this parameter.
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.
loadmodules
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. Originally meant to load modules required to access save devices (the device where the savefiles are located), this command can actually load any modules. (coldplug is now the better and preferred choice to load modules required for accessing savefile, though it may take slightly longer to complete).
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. If both loadmodules and coldplug are specified, in Fatdog64 900, modules specified in loadmodules are loaded before coldplug is executed. In earlier Fatdogs, modules are loaded after coldplug is executed.
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.
bbshell
Just like earlyshell and lateshell, except that you get the shell just before the basesfs parameter is processed. Only useful if you know what you are doing. (bbshell = before-basesfs-shell).
bbhook=/path/to/file
Source /path/to/file just before basesfs parameter is processed. (bbhook = before-basesfs-hook). bbhook is processed before bbshell. Only useful if you know what you are doing.
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.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from boot-options.html on 2024-12-09.
Screen Brightness controls not working
The sven keyboard daemon, which displays its icons in the panel, calls a couple of scripts to control the screen brightness. Unfortunately this varies a bit between computers. There are a couple things that can go wrong with this.
1) Sven might not be configured to use the correct keys for your computer.
2) The two scripts that Sven calls (/usr/bin/brightness-up and /usr/bin/brightness-down) could be using the wrong file in /sys
So the first thing to do is open a terminal and type: brightness-up and then press Enter.
If it changes the screen brightness then it's probably problem 1, and you need to right-click on the sven panel icon and select Preferences. If you get an error about file not found , then it's probably problem 2.
The brightness-up script looks like this:
#!/bin/ash
DEVICE= #radeon_bl0, acpi_video0, etc
DEVPATH=/sys/class/backlight
[ -z $DEVICE ] && DEVICE=$(ls $DEVPATH | head -n 1)
[ -z $DEVICE ] && exit 1
CURRENT=$(cat $DEVPATH/$DEVICE/actual_brightness)
MAX=$(cat $DEVPATH/$DEVICE/max_brightness)
STEP=$((MAX/10))
CURRENT=$(( CURRENT + STEP ))
if [ "$CURRENT" -gt "$MAX" ]; then CURRENT=$MAX; fi
echo $CURRENT > $DEVPATH/$DEVICE/brightness
For problem 2, you'll need to replace the DEVICE with the correct filename. You'll also need to make the corresponding changes to /usr/bin/brightness-down.
For problem 1, you'll need to edit the Brightness down and Brightness up properties in Sven (right click and select Preferences).
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from brightness.html on 2024-12-09.
Broadcom wireless
If your Broadcom wireless card does not work with the driver included with the Linux kernel, Fatdog64 includes the proprietary Broadcom 'wl' driver. To enable this open the Control Panel and click on the System tab. Then click on Manage Servers and Services, and then BC-wl. Click Start to start using this driver now and Enable to use this driver at every boot. After that you will want to right-click on the Wpa-gui icon in the panel and select Restart Connection.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from broadcom.html on 2024-12-09.
Think you've found a bug?
Like all other creations of man, Fatdog64 is not perfect. From time to time you may encounter problems.
If you would like these problems to go away, the best way is to report them to the Fatdog64 threads in the Puppy Linux Discussion Forum. It is best that you file the report in the thread for the same version of Fatdog64 you're using (if you use Fatdog64 900, then report the bug in Fatdog64 900 threads and not in threads for Fatdog64 814).
Bug and problem resolution is done on best effort basis. Do not count on timely bug resolution - we're slow and lazy ☺
Note that at one time, there is only one version of Fatdog that is actively maintained - the current version. If you use older version of Fatdog, the support will depend on the community of Fatdog users who gathers around in Puppy Linux forum. Some times we do look into problems in earlier Fatdogs - but this is rare and very far between, so don't depend on it.
Note: please make sure you read all of the FAQs first before reporting to ensure the problem is genuine.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from bugs.html on 2024-12-09.
Video Noise with Google Chrome full screen
If you have small random lines (noise) while watching full screened videos in Google Chrome, do this:
Go to Settings, Show advanced settings..., and then uncheck the box "Use hardware acceleration when available".
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from chrome.html on 2024-12-09.
Adding application icons to desktop
Fatdog64 features a clean desktop - that is, a desktop which contains only minimal sets of icons. There are no more application icons on the desktop by default (this contrast with earlier Fatdogs and Puppies where the original desktop contains application icons for text editing, drawing, wordprocessing, spreadsheet, etc).
The applications themselves still exist; they are accessible from menu.
If this does not cater to your style, then it is easy to re-create the application icons on the desktop. There are two ways to do it:
- Tear down menu items from the "Fatdog" menu.
Open the Fatdog Menu as usual, click and drag the application from the menu entry that you like to the desktop, and release the mouse button, and voila! You've got yourself an icon. You may need to right-click that icon and choose "Edit item" to change the name of applications etc as needed (primarily to remove the ".desktop" as part of the name).
Doing this will not remove the entry from the "Fatdog" menu. - Use Rox-Filer to drag and drop icons from "/usr/share/applications" folder.
Open ROX-Filer, and point it to "/usr/share/applications". This is the folder that contains most of application entries. Drag and drop one of these to the desktop, and an application icon will be created on the desktop. As above, you may need to "Edit item" to modify the display.
Note: Method #1 can only be used with razor-panel (Fatdog 700) or lxqt-panel (Fatdog 710 onwards) or another EWMH compliant panel. "Lxpanel" (the older panel used in earlier Fatdogs) and panel provided by "jwm" are not compliant and you cannot use this method.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from clean-desktop.html on 2024-12-09.
Slowness after updating Fatdog
In late 2019 / early 2020, a CPU vulnerability was found that supposedly can leak data. You may have heard of it. It is called by its popular name, SPECTRE.
Because this vulnerability happens in the CPU, it cannot be patched and fixed. Instead, it has to be "worked around", that is, software must learn how to not use certain CPU features which supposedly can lead to the vulnerability being exploited.
The software in question is mainly the kernel of the operating system. This also includes Linux kernel, and Linux kernel releases after that have "workarounds" of these kinds; so that vulnerabilities can no longer be exploited.
Problem solved?
Not quite. The CPU features which are supposedly vulnerable, are those that have powered the spectacular compute performance leaps in the last decade or so. Disabling / not using these features is the same as undo-ing all those performance improvements.
How much performance loss are we talking about?
Depending on which features you want to avoid, it could be anything between 1% to 30% - give or take a few percents. To make things worse, after the first CPU vulnerability was found in early 2020, more vulnerabilities of similar nature were found; and "securing" them meant disabling more CPU features or adding awkward program constructs which (guess what) reduce performance by a lot.
But is countering these vulnerabilities worth such performance degradation?
The answer is, of course, it depends (with lots of caveats).
Most CPU vulnerabilities found are weaknesses in terms of "timing attack". By careful timing of certain CPU instructions, one can guess what data are driving those instructions. In theory, this can be used to, say, read a protected region of memory, which perhaps contains a password - and then the password can be stolen.
Is this really a big deal? Well, the answer is, yes or no. It depends. For example, if you are running a server with 100 VM in it, you'd probably be not smart to ignore this (one of the VM could be used to guess the hypervisor password). Or if you know that you're targeted by a national security agency of your country for whatever reasons, perhaps it pays to be paranoid as well.
But otherwise, there are so many ifs before this can happen. Plus, perhaps there is an easier way for people to lose their password (just ask them nicely for it? Many people fall for phishing attacks - e.g. a fake email asking them to reset their password ...)
I won't go further into the merit of why you should or should not ignore these weaknesses, because it obviously depends on your situation.
Instead, I will just say this. Linux prefers to err on the side of caution. And this means that by default, the workarounds - or mitigations as they are called - are ALL enabled by default to protect you from these vulnerabilities, at the cost of lower performance.
Every kernel released after 2020 has mitigations to various degrees, newer kernels obviously have more mitigations and are thus slower.
This is one of the most prominent reasons why newer Fatdogs (which use newer kernels) are slower.
Now, if you like the warm feeling of knowing that you're safe from all the prying eyes; and you don't mind the slowdowns, you can sit back and relax, there is nothing more you need to do.
If you, however, prefer to live on the risky edge and strive for the best performance at the cost of being vulnerable, then you can choose to disable these mitigations and claim back some of the lost performance.
There are many vulnerabilities, and Linux kernel gives you the option of fine-tuning which mitigations you want to enable/disable. You pass these options on the kernel command line (similar to how you pass the boot parameters). For the details you can see them here. Just search for "mitigations" and you will find them.
Alternatively, you can just disable ALL mitigations and get back the most possible performance. This is done by passing mitigations=off into the boot parameters.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from cpu-mitigations.html on 2024-12-09.
How to change programs used as default?
Question: I have installed another web browser. How do I change it so that it is the one used as default?
Answer: Edit /etc/defaultprograms with your favorite text editor and change the entries there. To change default browser from "seamonkey-spot" to firefox (without spot), for example, change the DEF_BROWSER entry in that file and replace the text within quotes. You can do the same for the rest of the applications listed there: draw, html editor, paint, media player, etc.
Since Fatdog64-710 Beta you can also use "Fatdog64 Edit Default Programs" GUI available in Control Panel on "System" tab ("Desktop" tab on older Fatdogs). This method changes the default applications on per-user basis (~/.fatdog/defaultprograms).
Note: Doing this will only change the defaults for programs that honour Puppy-like model of default programs.
Unfortunately there are no single unified way to change the "default" programs unless you run a comprehensive desktop environment like KDE or Gnome. Every program has its own way of keeping track of what it thinks as the default.
XDG-compliant programs, for example SpaceFM, make use of /usr/share/applications/mimeapps.list and /usr/share/applications/defaults.list (see http://standards.freedesktop.org/mime-apps-spec/mime-apps-spec-1.0.html for details). Other file managers like XFE or ROX-Filer has its own way of keeping default programs. You will have consult the documentation of each individual program if the method described above doesn't seem to work.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from defaults.html on 2024-12-09.
Changing desktop icon themes
There are a few ways to change the icon themes, depending on what "icon theme" we're talking about.
- The desktop icons (also applies for some application icons you see on the menus)
There a symlink called /usr/share/pixmaps/midi-icons and /usr/share/pixmaps/mini-icons.
- /usr/share/pixmaps/midi-icons points to /usr/share/pixmaps/themes/puppy48
- /usr/share/pixmaps/mini-icons points to /usr/share/pixmaps/themes/puppy16
You can install other icons in /usr/share/pixmaps/themes and re-symlink /usr/share/pixmaps/midi-icons (or mini-icons) as needed. Example - in the package repository, we have a package called puppy-icon-theme that installs to /usr/share/pixmap/themes/Puppy-Standard. You can re-symlink /usr/share/pixmaps/midi-icons to this directory. Note that puppy-icon-theme package does not have the mini-icons collection, so you will have find that elsewhere.
2. The icons you see inside ROX Filer, they are stored in either $HOME/.icons or /usr/share/icons.
You can change it by right-click in ROX Filer, then choose Options -> Types and then you can change the icon theme.
We have 3 icons themes that installs in /usr/share/icons: puppy-icon-theme, adwaita, and gnome-colors. All of the can be used.
3. Beyond this, we have non-configurable icons, that install themselves in /usr/share/pixmaps or /usr/share/icons.
They're mostly used for application icons (in menus). There is no way to replace them as a group; you will have to replace them individually. These are usually used by applications that pre-date the XDG standards (or could not care less about it).
- And lastly, we have toolkit icon themes - like GTK icon themes, Qt icon themes, etc. These can be configured using the standard configuration mechanism for these toolkit. There are many pre-defined icon theme that you can use. Most of them are just tarballs that you can extract, and then you can edit the appropriate toolkit configuration files (e.g. .gtkrc-2.0 for GTK2, etc).
5. Finally, we have non-configurable icons in private application directories, e.g. the "fatdog" start menu icons for lxqt-panel, the icons you see on the window manager decorations (to close/maximise/minimise windows, etc) from openbox, etc. These applications have their own "theme-ing" method and you just have to use your favourite search engine if you want to learn how change them. Some of the more popular window managers and panels (e.g. openbox) also have many themes you can use. For others, you have to figure out and assemble the themes yourself.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from desktop-icon-themes.html on 2024-12-09.
Kernel thread (kworker) eats 100% of my CPU or my Mac is running super hot while doing nothing
This problem usually happens in MacBook (or MacBook Pro), although it can happen on other machines too.
"kworker" is a placeholder process for kernel worker threads, which perform most of the actual processing for the kernel, especially in cases where there are interrupts, timers, I/O, etc. These typically correspond to the vast majority of any allocated "system" time to running processes. It is not something that can be safely removed from the system in any way. They usually get busy when there are requests from programs to access disks, send network packets, etc.
Sometimes, something can go wrong that the CPU gets interrupted very often (a few hundred or thousands per second). When this happens, kworker gets very busy, the kernel gets very busy, CPU is occupied, and the machine gets hot. All for doing nothing.
When this happens, the solution is to upgrade the kernel in the hope that this particular problem is fixed, or do some workaround to disable the offending interrupt. As far as "upgrade the kernel goes", this as happened since kernel 3.10 onwards and at the time of writing, kernel 4.14 (which is 3.34 if Linus didn't rename 3.20 as 4.0) - the problem still happens.
Fatdog has a built-in script do to this. The script examines the interrupts issued by ACPI, and if the number of interrupts exceeded a given threshold in a given detection time, it will disable it. The name of the script is disable-spurious-gpe.
This script can also be started at boot. Fatdog has the system service configured for this, but it is disabled by default. All you need to do is enable the service from Fatdog Control Panel. If need be, it can be customised too. The init script is called /etc/init.d/99-disable-spurious-gpe.
Please note that ACPI interrupts are there for a reason. If you disable the ACPI interrupts, some functions may stop working. In the case of MacBook, gpe06 and gpe07 are the two known problem case and they don't seem to affect much. On other machines, those interrupts may provide hooks to generate special ACPI event keys (e.g. Fn-F1, Fn-F2, etc); and by disabling that you disable the ability to detect those key combinations as well.
PS: If you run the script and some interrupts gets disabled, you can re-enable them again by giving this command:
echo enable > /sys/firmware/acpi/interrupts/gpeXX
where XX is the interrupt number you want to enable. If you want to disable it instead, use echo disable instead of echo enable.
References:
- https://unix.stackexchange.com/questions/242013/disable-gpe-acpi-interrupts-on-boot#254880
- https://bugzilla.redhat.com/show_bug.cgi?id=1192856
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from disable-gpe.html on 2024-12-09.
How to enlarge my savefile?
You can enlarge the savefile using the "Fatdog Savefile Tool" found in the Control Panel, under the "Install" tab ("System" tab on older Fatdogs).
However, you may only enlarge the savefile when the savefile is not being used.
To do that reboot with the savefile=none boot parameter supplied to the boot command line for the session. Then you can use the savefile resize tool.
Note that the initial size of a btrfs formatted savefile must be at least 256 MB, otherwise the btrfs utility won't be able to enlarge it.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from enlarge-savefile.html on 2024-12-09.
Additional software packages
To install additional packages, open Fatdog64 Control Panel, navigate to the System tab, and from there launch the Gslapt Package Manager. The user interface should be intuitive enough for you to use. Gslapt will automatically install other packages needed ("dependencies").
Alternatively, you can download packages directly from the link given in the home page. When the download is completed, use the file manager (ROX-Filer) to open the folder that contains the downloaded file, right-click on the file and choose 'Install Package'. Do not try to install the package directly from the browser without downloading it first - it will definitely fail. The web browser (Firefox/Seamonkey) doesn't have permission to install packages (as explained in browser security).
Using packages from earlier Fatdog64 series
In general, there are two issues when you try to use software packages designed for earlier Fatdog64 release.
First, the packaging format. Starting from Fatdog64 700 series, Fatdog64 uses Slackware-style TXZ packages, replacing the PET package format commonly used in Puppy Linux derivative, including previous Fatdog64 series (500 and 600). This can easily be overcome - Fatdog64 comes with a tool to convert PET packages into TXZ package format. Just do a right-click on any PET package in ROX-filer and choose Convert to TXZ package menu entry.
Second, library compatibility. This is a general issue when trying to install foreign packages (packages that are not specifically built for the target distro). A package is always built with a certain assumptions: assumptions that specific libraries exist, and are at specific versions; assumption that some files are located in some directories; assumption that some dependent programs exist and they are located in certain locations. These assumptions may or may not be true in the target distro. Packages from previous Fatdogs are counted as "foreign" packages are far as compatibility is concerned; thus there is always a chance of them not working; or worse: they break the system.
To be very safe, you can try installing old packages in the sandbox environment and see if they work - if they do, that's fine, otherwise you can easily recover from bad packages just by exiting the sandbox.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from fd-packages.html on 2024-12-09.
Filesystem structure
Fatdog64 utilizes AUFS to form a stackable filesystem, which enables viewing multiple different filesystem into it is one, big, merged virtual filesystem.
Fatdog64 main file system is compressed into a single read-only file using Squashfs. During boot, the read-only main file system (fd64-600.sfs) is mounted at /aufs/pup_ro. At first shutdown you will be asked if you want to create a savefile (fd64save.ext4). During boot that file, which is really a read-write file system, is mounted at /aufs/pup_save. If you don't have a savefile yet a RAM layer (tmpfs) will be used and that will be mounted at /aufs/pup_rw. Then the init script uses AUFS to merge the main read-only file system with the read-write savefile, and mounts this new virtual file system on / (the root filesystem).
Using the System SFS Loader, found under System in the Control Panel, you can add other SFS files (file extension .sfs) to the virtual file system. This can be done at any time. For example, fd64-devx_600.sfs, which contains gcc, static libraries, headers, kernel source and everything else you need to compile application, could be added into our virtual file system. Just place the fd64-devx_600.sfs file at the root of the partition that contains our savefile (/mnt/home), use the System SFS Loader to add it. That's it. Answer "yes" when asked if you want to keep the chosen layer configuration to survive reboot. These extra SFS files are mounted at /aufs/pup_roX (X is a number starting from 10 for historical reasons); and merged into the rest of the virtual file system which gets mounted at /.
Typical file system mounting:
The layers or branches (pup_rw - pup_roX) are listed in the order of priority. Files on the upper layers take priority than those in the lower layers. For example, if a file exists with the same name and in the same location in the file system tree, in the pup_rw layer and in the pup_ro4 layer, the file in the pup_rw layer will be the one that is visible. When a file is deleted from the virtual file system that really exists in the pup_ro (read-only) layer, a .wh.xxx file is written in pup_rw layer that is only visible in that layer. This file serves as a flag to AUFS that the corresponding file should not be visible in the virtual file system mounted on /.
So what are the advantages to all this? Many, here's a list:
- The original system files are always available in /aufs/pup_ro.
- Changes to the file system can easily be spotted in /aufs/pup_rw or /aufs/pup_save
- The pup_save layer can be easily encrypted. This is an option when you create your save file.
- You can create many save files, which effectively gives you many installs.
- Back-ups only require you to make a copy of one file (fd64save.ext4).
- Since the file systems are a loop back mounted, you can install on non-Linux partitions (FAT, NTFS)
To create another save file you need to boot RAM only. If booting from CD, you would use the boot option fatdog savefile=none. If booting from grub you can edit your menu.lst or hit the e key when the grub screen pops up. Then add savefile=none to the kernel line. Then you'll boot up with out a save file, the pup_rw layer will be in RAM. When you shutdown you will be asked if you want to create a new save file. When you reboot and multiple fd64save files are detected you will be asked which one you want to use. If you encrypted your save file, you will also be asked for your password.
Special note for Puppy Linux veteran
If you have been using Puppy Linux for a while, you would have already known the stackable filesystem structure. Fatdog64 filesystem may look similar (except that /initrd is renamed to /aufs), but the difference is deeper than that. Here are some of them:
- In Puppy Linux, all extra SFS will be loaded under the main filesystem (puppy_xxx.sfs - mounted at /initrd/pup_ro2). Thus in Puppy Linux it is impossible to use extra SFS to replace an existing file in the main filesystem. In Fatdog64, all extra SFS will be loaded above the main filesystem, so it is possible to deliver SFS to upgrade the system libraries located in main filesystem.
- In Puppy Linux, the lowest layer is indeterminate. This is because extra SFS is added at the bottom of the stack - the latest added extra SFS will be at the bottom of the stack. In Fatdog64, the lowest layer is always /aufs/pup_init. This is a read-only copy of the original boot filesystem contained in initrd.
- In Puppy Linux, /initrd/pup_rw is always the top-most writable layer. This writable layer can either points to the RAM layer, or points to the savefile. If RAM layer is used, the savefile is mounted at /initrd/pup_ro1 instead. In Fatdog64, the topmost writable layer is either /aufs/pup_rw (when the RAM layer is used) or /aufs/pup_save. In Fatdog64, /aufs/pup_rw always points to the RAM layer, and /aufs/pup_save always points to the savefile.
- In Puppy Linux, the mount point names are effectively hardcoded - their use is entrenched in so many scripts that it is almost impossible (or arduous at least) to change them without causing any breakage. In Fatdog64, this is not the case. You should always consult /etc/BOOTSTATE to see which layers are being used, and the actual mountpoint names. In fact, do not even hardcode the location /etc/BOOTSTATE, instead depends on the environment $BOOTSTATE_PATH to get to that file.
In both Fatdog64 and Puppy Linux (when running with AUFS instead of unionfs), if you want to know the exact ordering of the layers, the best way to do it by consulting the contents of /sys/fs/aufs/si_xxxxxx/br[0-9]* for the / filesystem (where xxxxx is a random number generated by AUFS, you can get this code by looking at the mount properties for /.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from filesystem.html on 2024-12-09.
Browser runs as restricted user
Firefox, Seamonkey, and Google-Chrome all run as user spot. User spot can only write in a few places, one of these is the Downloads folder on the desktop. If you want to save something from Seamonkey / Firefox send it to the Downloads folder. Each time the browser is opened, the files in Downloads folder are changed to owner spot. So if you need to import bookmarks to the browser, place the bookmarks file in the Downloads folder before you open the browser. Then open the browser and import the file.
Firefox and these other applications which access the Internet run as user spot for security reasons, some see this as being overly cautious. If you want Firefox to run as user root and be able to write anywhere, edit /usr/share/applications/Firefox.desktop (right click and choose Open as Text). Change the line Exec=firefox-spot
to Exec=firefox
(or seamonkey, google-chrome, etc) and save.
Or alternatively, if you want to convert all of these applications to run as root, open the Control Panel, click the "System" tab ("Desktop" tab on older Fatdogs), and you will find an applet called "Convert Spot Apps to Root Apps", and that will do the job.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from firefox-spot.html on 2024-12-09.
Firewall setup
Fatdog 700 features eztables firewall, replacing the pre-historic firewall package used in earlier Fatdogs. Eztables firewall is more sophisticated and offer more features than the previous firewall package, yet the configuration is still simple.
Configuration is done by editing /etc/eztables/eztables.cfg. The default configuration enables you to browse web, do time sync with Internet time servers, and connect to remote servers using SSH. It also enables you to connect to your desktop remotely using SSH (note: SSH service is disabled by default). If this setting is not suitable for you, edit this file first before enabling the firewall.
The detailed documentation on how to edit this is available at /usr/share/doc/eztables but this directory only exists on devx. Alternatively you may want to visit the online documentation (but beware that these always documents the latest version, so they may or may not apply with the version of eztables used in Fatdog):
- https://github.com/louwrentius/eztables/blob/master/MANUAL.md
- https://github.com/louwrentius/eztables/blob/master/EXAMPLES.md
The firewall is disabled by default. To enable it, open Fatdog Control Panel, choose "System" tab, and launch "Manage Services" (or you can do the same by running fatdog-service-manager.sh
), and click "Start" to start the service this one time; or click "Enable" so that it will be enabled at every reboot.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from firewall.html on 2024-12-09.
How to find firmware for your devices
Devices requires two things to work. First is the device drivers, and in Linux, "device drivers" is called as "kernel modules". Some devices, in addition to the drivers, also require what is called as "firmware". This "firmware" is basically the operating system for the microcontroller used in the device. Not all devices require firmware, and some can optionally use a firmware but can work without it.
Fatdog comes with a large collection of firmware, but there are always some specialised devices that we may have not included the firmware for. If you know you have the correct drivers but your devices are still not working, this is probably the case.
To check, open terminal and type "dmesg | grep -i firmware". If you see any indication that a firmware is not found, that's probably it and you need to hunt the firmware.
There are many places for firmware and unfortunately there isn't a single central repository for it. You just need to search for it. And then these links can become stale, disappear, or gets replaced. That's part of the fun, of course.
The links listed below are current as of 1 September 2020.
- Your number one stop should be "linux-firmware". This has the largest collection of firmware (most of it should already be in Fatdog, but we may miss a few). All free-licensed firmware should be here: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
- ALSA firmware: most soundcard doesn't need firmware, but some do. If your card is one of those, you may be able to find it here: https://www.alsa-project.org/main/index.php/Main_Page (look for alsa-firmware).
- Debian also has a lot of collection of non-free firmware blobs: https://packages.debian.org/source/sid/firmware-nonfree and http://deb.debian.org/debian/pool/non-free/f/firmware-nonfree/firmware-nonfree_20200721.orig.tar.xz
- ath10k firmware old and new: https://github.com/kvalo/ath10k-firmware
- Intel Wifi firmware old and new: https://www.intel.com/content/www/us/en/support/articles/000005511/network-and-i-o/wireless.html
- Libertas (Marvell) Wifi firmware: https://packages.debian.org/sid/firmware-libertas
- Netronome LAN / Wifi firmware: https://fedora.pkgs.org/31/fedora-updates-x86_64/netronome-firmware-20200721-110.fc31.noarch.rpm.html
- Silicon Labs Wifi firmware (rs9113_wlan_qspi.rps) https://github.com/SiliconLabs/RS911X-nLink-OSD/tree/master/Firmware
- Some rare firmware for realtek Wifi chips: https://github.com/lwfinger/rtl8723au_bt/
- Firmware for TV Tuner using Siano chips: https://debian.pkgs.org/sid/debian-nonfree-armhf/firmware-siano_20200721-1_all.deb.html
- Other IPTV firmwares: https://packages.debian.org/sid/firmware-ivtv
- xc3028L-v36.fw: http://www.steventoth.net/linux/hvr1400/xc3028L-v36.fw
- xc3028-v27.fw: http://www.steventoth.net/linux/hvr1500/xc3028-v27.fw
- http://www.steventoth.net/linux/ has firmwares for other obscure devices too.
- comedi/jr3pci.idm: http://www.comedi.org/download/comedi-nonfree-firmware-2007.06.22.tar.gz
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from firmware.html on 2024-12-09.
Fatdog64-900 does not include the Flash Player
(It is still in the package repository.)
(Q) When I access my webmail I notice the Seamonkey is complaining about Flash8 or later is not installed. How come?
You did not see that error message in Fatdog64-814 because the version of Seamonkey in Fatdog64 814 (and older) supported Flash, and the Flash plugin was included in the ISO. Neither is true in Fatdog64-900.
If you really want Flash, install Palemoon and the Flash plugin from the repository, and access your webmail using Palemoon.
Adobe terminated Flash update and support by end of 2020. Then web browsers themselves started to drop support for NPAPI plugins, the plugins that Flash depends on, which means that even if you have the Adobe Flash plugin installed, it won't work.
Firefox dropped support for NPAPI plugins many versions ago, and Chrome has never supported NPAPI in the first place (but they had their own Flash player, which they have also dropped many versions ago).
A browser that we know still supports Flash (and hence works with Flash) is Palemoon. It is for this reason we still keep a copy of the final version of the flash player in the Fatdog64-900 Gslapt repository.
Go visit http://embed-swf.org/flash-player-version.php to check if your browser supports Flash.
The bottom line is the Flash player is outdated and not supported by most browsers anymore.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from flash_player.html on 2024-12-09.
Fatdog64 full-install guide
Warning
I need to begin this guide with one notice and two warnings.
First and foremost, Fatdog64 runs best in frugal install mode, because that is what it is designed for.
Second, Fatdog64 officially does not support full install. If you have problem you are most likely on your own.
Third, Fatdog64 is not designed to support full install. Certain advertised features of Fatdog64 depends on its layered filesystem and will not work when you are running Fatdog64 in full-install mode. They will simply do nothing.
If this does not convince you not to run in full install, then nothing will; and in that case may this guide be of help to you in your quest to make Fatdog64 run in full install mode.
But before you do anything, please read this guide until its completion and ensure yourself that you understand what it means and understand what every step does. Don't just follow blindly. These steps contain dangerous data-destroying commands that can easily wipe out your data - even in unrelated places.
YOU HAVE BEEN WARNED. CONTINUE AT YOUR OWN RISK.
Background
Skip background and just show me the steps.
What is "full install" anyway? A "full install" is the traditional way of every other operating system there is installed and running. This includes setting up a dedicated partition that will hold the files that make up the operating system; and then copying over those files to that partition; and finally installing boot loader to start the operating system.
If you install Ubuntu (as opposed to running its LiveCD), then you would have installed in "full-install" mode. If you install Centos, you would have installed in "full-install" mode. If you have Windows installed, it will be in "full-install" mode. Almost every other operating system is installed in "full-install" mode.
Fatdog64, by contrast, runs in what people call as "frugal install". In "frugal install", the operating system files are combined together in one huge file (usually compressed to make is smaller) instead of spread all over in a partition. To perform "frugal install", you basically just need to copy these few files (usually not more than 5, in Fatdog64 it's actually two files only) to an existing partition, and modify an existing bootloader to boot from this compressed file. No dedicated partition is needed - Fatdog can use and share partition with existing operating systems (Windows, other Linux, etc). No dedicated bootloader is needed either - in most cases you can configure your existing bootloader (Windows, Linux, etc) to boot Fatdog.
A "frugal install" is very much like a LiveCD except that the operating system has designed to support this mode of working from the ground-up, designed to permanently run in this mode, and make use of special features you can only get when running in this mode. There are many benefits of running in frugal install. Apart from the fact that you don't need dedicated partition, there are other benefits:
- Easy and very quick to install, even by hand: you only need to copy a handful of files instead of requiring and installer to copy thousand of files which must be copied to the correct places and configured correctly
- The original operating system files are never changed, so you can always restore to a pristine "factory-default" setup in an instant.
- The layered filesystem model used in "frugal install" offers many benefits you cannot in full install - e.g. instant zero-copy sandboxing, ability to install/uninstall packages without altering original OS files (using SFS system), etc.
But full-install is not also without benefit. Firstly, the partition is dedicated to the operating system so it can do what it pleases; it can optimise itself in the way that a frugal install cannot. It uses the minimum amount of resources so it is generally faster (though how much faster is arguable) and it uses less RAM (though how much lesser is also arguable).
Whatever it is, it is worthwhile to repeat again that Fatdog64 does not officially support full install since Fatdog64 600 (Fatdog64 521 and older did support full install). But it does not meant it cannot be done. It means that it is not fully tested, and there is no automated support for installing Fatdog in full-install mode so you will have to install it manually - of which the steps are outlined below.
Layered Full Install
There are two full-install possibilities: Layered Full Install and True Full Install.
1. In Layered Full Install, the stackable filesystem is still active and working.
You still get many of its benefits (with caveats).
2. In True Full Install, the stackable filesystem is not used at all.
In this mode Fatdog runs like any standard Linux distributions (with its associated headaches).
To simplify matters, in this guide I will first show to get Layered Full Install working, and then used that as a base to go with True Full Install.
One last comment before we go: The guide assumes you already have a working bootloader (grub, grub4dos, extlinux, rEFInd, etc) and you know how to configure them to add new OS installs.
Assumptions
1. This guide will not provide details of the bootloader installation or configuration steps; there are plenty of other guides and tutorials for those. If you don't know how to do this then STOP AND DO NOT READ ANY FURTHER. For the rest of this guide, I will use grub4dos as an example but the principle is the same and the instructions should be adaptable to other boot loaders.
2. The guide assumes you are currently running Fatdog in LiveCD mode.
3. You will perform standard installation. That means, one kernel file (vmlinuz) and one initrd file. No small initrd, or other variations.
Steps
1. Create and format the partition where you want to install Fatdog to.
For the sake of illustration, I will assume we're going to install to /dev/sda2. You should replace this with your own where you want to install. You should replace reference to /dev/sda2 and its mountpoint (/mnt/sda2) to the partition and mountpoint of your choosing.
If you don't know understand what this means or you don't know how to create a new partition - STOP AND DO NOT READ ANY FURTHER.
I will also assume that this partition /dev/sda2 is empty. If yours is not empty, please delete all the other files and directories there. Also, for obvious reasons, this partition must be a Linux-compatible partition (ext2, ext3, ext4, or xfs, etc). We recommend to use a self-healing filesystem (filesystem with a journal, such as ext3 or ext4).
2. Use the Fatdog Installer to install Fatdog to the target partition /dev/sda2.
3. Once installed, from with Fatdog desktop, click the sda2 drive icon. Rox will launch and shows a lone boot folder, which contains the vmlinuz and initrd that has just been installed. In addition /dev/sda2 is now also mounted at /mnt/sda2.
4. Click that boot folder to go inside, and then click initrd. It will open and extract the contents of initrd to a temporary location. Please notice among the many files, there will be a file called fd64.sfs.
5. Switching to the Rox folder that contains the initrd's contents, open a terminal with the current directory set to the folder shown by Rox (step: right-click, then choose "Window", then choose "Terminal here").
6. In the terminal, type the following:
unsquashfs -f -d /mnt/sda2 fd64.sfs
Remember to replace /mnt/sda2 with the actual partition mountpoint that you use.
7. When the process is done, close the terminal. Then go back to the folder that contains expanded initrd's content.
8. Delete that fd64.sfs. Then click repack-initrd.
9. The installation is now practically done. Next, you just need to instruct your bootloader to boot Fatdog. The following is an example for grub4dos menu.lst:
title fatdog layered full install
root (hd0,1)
kernel /boot/vmlinuz savefile=direct:device:sda2:/ basesfs=none
initrd /boot/initrd
As usual, replace sda2 with the partition that you actually use. Test it - boot to it now.
After-note
With layered full install, the layer system is still active and thus you can still load SFS just like when you run frugal install. The only catch is - these additional SFS files cannot be located in the same partition of your full install. For example in this guide you cannot have SFS files in /dev/sda2 partition - it won't work. You have to put them elsewhere (sda1, sda3, sdb1 etc, anywhere but sda2).
You can still make use of the sandbox facilities, too.
If you change the direct:device:sda2:/
to ram:device:sda2:/
, you will be running full-install with the RAM layer and you will get the ability to choose whether or not to save changes made during the session. The details on how to configure this is discussed elsewhere.
True Full Install
With true full install, the stackable filesystem is fully de-powered and you will be running Fatdog64 in the traditional way, in every sense of the word.
To be able to perform True Full Install, you must have successfully perform the Layered Full Install as explained above. The following steps picks up where Layered Full Install ends. I continue to use sda2 for illustrative purposes.
1 - 9. Perform Layered Full Install.
10. Boot into the Layered Full Install and check and everything is working well as it should.
11. Now, using drive icons, open sda2 (the device you have your layered full install). There will be tons of folders here now (this is the result of what you did in step 6).
12. Find the boot folder and click it to go inside, and then click initrd. It will open and extract the contents of initrd to a temporary location. Please notice among the many files, there will be a file called kernel-modules.sfs.
13. Switching to the Rox folder that contains the contents of the initrd, open a terminal with the current directory set to the folder shown by Rox (step: right-click, then choose "Window", then choose "Terminal here").
14. In the terminal, type the following:
unsquashfs -f -d / kernel-modules.sfs
and on Fatdog64 721 onwards, also do this:
cp -a kernel /
15. Close the terminal, and also close that Rox folder with initrd's content in it.
Do not click repack-initrd - you don't need to repack it because we haven't changed anything.
NOTE: Step 16 unnecessary for Fatdog64 721 onwards.
16. Open the file /etc/fstab with your favorite editor (e.g geany).
Look at these lines:
# proc /proc proc defaults 0 0 # mounted by /init
# sysfs /sys sysfs defaults 0 0 # mounted by /init
Remove the hash (#) at the beginning, so they look like this:
proc /proc proc defaults 0 0 # mounted by /init
sysfs /sys sysfs defaults 0 0 # mounted by /init
Then save the file.
NOTE: Step 17 unnecessary for Fatdog64 721 onwards.
17. Open the file /aufs/pup_save/etc/BOOTSTATE with your favorite editor.
Delete all the contents inside, and replace it with the following:
NOT_USING_AUFS=true
AUFS_ROOT=/aufs
SAVEFILE_MOUNT=/
18. It's done! Now you only need instruct your bootloader to boot Fatdog properly.
It is best to create a new entry for the True Full Install setup that you have just created, rather than modifying the entry you created for the Layered Full Install while you're testing (because the the Layered Full Install gives you a way out to boot the system in case you have not done these steps correctly; and then "fix" your mistakes):
The entry could look something like this (assuming grub4dos again):
title fatdog true full install
root (hd0,1)
kernel /boot/vmlinuz root=/dev/sda2 rw rootwait
19. Now re-boot and boot into the True Full Install entry you have just created.
If it works, then you can safely delete the "initrd" file in your / directory (and the Layered Full Install boot entry).
If you fail, you can always go back to your layered full install mode and re-do the above.
After-note
With true full install, the layer mode isn't used at all and you cannot use any layer-related functions such as loading SFS, sandbox, etc. There are many posts in the Puppy Linux forum explaining how to do the equivalent of these.
If you don't delete the Layered Full Install boot entry, you can always use it to boot in Layered Full Install mode again. Just remember, if you do that, before you boot into True Full Install again you need to re-do step 17 - edit your /aufs/pup_save/etc/BOOTSTATE and make sure it contains the correct content (NOTE: not necessary for Fatdog64 721 onwards).
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from full-install.html on 2024-12-09.
Where to get rEFInd boot loader
rEFInd is a very nice boot loader / boot manager written by Rod Smith. It's official home page is here.
Fatdog64 uses rEFInd as its primary boot loader; and an official copy of rEFInd is included in Fatdog ISO. You can always find it at /usr/share/refind-bin-xxxx/refind (the "xxx" refers to version number, it's version 0.11.2 as of Fatdog64 720). This is often not the latest version, if you really need the latest version it is available from rEFInd's download page.
Alternatively, you can also use and get the version of rEFInd that is used to boot the Fatdog ISO. This is usually an even older version than what you find above, so it's not recommended - but if you want to, you can get it from efiboot.img. This file is inside the Fatdog ISO. All you need to do is (double-)click it, and a new ROX-Filer window will open.
For older version of Fatdogs (older than 720), here are the steps to do it.
- Make sure there is nothing mounted on /mnt/data
- On ROX Filer, click (or double-click) Fatdog ISO to open its contents.
- Within that ROX-Filer window that shows the ISO contents, right-click and choose "Terminal Here". A new terminal window will open.
- From that terminal: run the command mountpoint /mnt/data to check it. Make sure it says it is **NOT** a mountpoint.
- Mount the efiboot.img read only: run the command mount -o ro efiboot.img /mnt/data. When done, open a ROX-Filter window by running rox /mnt/data.
- The ROX-Filer window on /mnt/data contains rEFInd boot loader. Copy it as necessary.
- When done, close the ROX-Filer /mnt/data.
- From the same terminal in the previous steps, run command umount /mnt/data
- Then close the terminal.
- Close the Fatdog ISO.
Note: If you choose to install refind from efiboot.img, please note "drivers_x64" (or drivers for older Fatdogs) folder is located at the top folder, not inside EFI/Boot. In this case, these drivers are not activated and are not loaded at boot. If you need to use any of these, you will need to move the drivers_x64 and place it inside EFI/Boot.
For more information please refer to refind website. Or, if you have devx loaded, copy of the information is available in /usr/share/doc/refind-xxxx.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from get-refind.html on 2024-12-09.
Installation options
Click here for UEFI (Windows 8 and above) hard drive installation instructions.
Guided Installation
Fatdog64 comes with an installer capable of installing to hard drive and flash drive. It provides step-by-step guidance:
-
To choose which device to install to:
- You can choose hard drive or flash drive.
- You can choose to format the chosen partition (=data loss) or leave it as is.
- You can also run gparted to modify the partition.
- For flash drive, you can install to a partition (e.g. sdb1) or to the entire flash drive, in "superfloppy" mode (e.g. sdb). We recommend you install to a partition.
-
To choose whether you want to install a boot loader:
- Install boot loader to Master Boot Record (MBR)
(unsafe, it can cause an existing operating system to stop booting, but Fatdog64 will still boot) - Install boot loader to the partition where Fatdog64 is installed
(usually safe if Fatdog64 is the only operating system in the partition. If you do this on a partition that holds an existing operating system, that operating system may stop booting) - Use existing Operating System
Only works for Windows 2000/XP/Vista/7. For Linux, please see note below about manual installation. - Do not install boot loader
Note that Fatdog64 will not boot unless you install the boot loader. If you choose not to install a boot loader now, you will need to do it yourself manually.
If you choose to install a boot loader (to MBR or partition), the partition that contains Fatdog64 will also be made the "active" partition, and that one will boot. If you have other operating systems installed in another partition they may no longer boot.
- Install boot loader to Master Boot Record (MBR)
-
To choose installation sources:
- From Fatdog64 CD/DVD
- From ISO file downloaded from the Fatdog64 distribution
The Fatdog64 installer supports installing to VFAT, FAT16, FAT32 (also known as MSDOS partition, usually used for flash drive), ext2/ext3/ext4 (Linux partitions, usually used on hard drive), and NTFS partition (Windows partition).
Note: Fatdog64 Installer is experimental code. It may cause data loss, or other installed operating systems to stop booting. Backup your data before you use it. Use at your own risk.
Manual Installation
Manual installation is good for upgrading an already installed system. All you need to do is to get two files from the Fatdog CD/DVD: vmlinuz and initrd, and copy them to your previous Fatdog64 installation folder, overwriting the previous files.
Note: Grub Legacy and Grub4dos are VERY slow loading files from ext4, you may not have noticed this with a typical 10MB kernel/initrd, but with Fatdog64 that will be closer to 370MB. If you want to use one of these bootloaders, put Fatdog64's kernel/initrd on an ext3 partition.
Manual boot loader configuration
If you already have a boot loader and don't want to bork it, you may choose to install Fatdog64 manually. Simply copy the two files above somewhere in your disk, adjust your boot loader configuration (grub.cfg / menu.lst / extlinux.conf / whatever) to load Fatdog64's vmlinuz kernel and initrd. Some examples below:
Example for menu.lst (GRUB and GRUB4DOS)
title Fatdog64
rootnoverify (hd0,0)
kernel /vmlinuz
initrd /initrd
Example syslinux.cfg (for syslinux, extlinux, pxelinux)
label Fatdog64
kernel vmlinuz
initrd initrd
That (hd0,0) refers to GRUB-style naming of the device and partition. If you're not sure what it means, Google is your friend.
Supported media / operating modes
Fatdog64 can be installed in several types of media and has a few operating modes.
Live CD/DVD
You don't have to install Fatdog64 to use it. You can just use the Fatdog64 CD/DVD as is. When you shutdown, you will be asked where to save your "session" (i.e. your changes, configuration settings, browser bookmarks, etc). You can choose to save in a flash drive, or in your hard drive. The session is saved in a file referred to as the "savefile", its actual name can vary but it's usually called fd64save.ext4. Next time you want to start up the computer, just put the CD (also plug-in the flash drive if you put your savefile there) before you power-up your computer, and Fatdog will find and load up the savefile - your environment will be just the same as it was when you shut down previously.
Note: Fatdog64 loads completely into RAM. It means that after Fatdog64 completes the boot process, you can take out CD/DVD and put something else there (e.g. to listen to music, watch movies). On the downside, this means you need to have enough RAM to load an entire copy of Fatdog64 into memory -- a minimum of 1GB is probably needed.
Harddrive
You can install Fatdog64 to your hard drive. The installation method used by Fatdog64 is known as "frugal install", where instead of occupying a dedicated partition, Fatdog can use *any existing* partition, and share it with existing data and/or operating system files. All this type of installation does is to copy two files: vmlinuz and initrd, and configure the boot loader, if you ask it to.
Operation in Harddrive mode is identical as in Live CD, except that you don't always have to carry the CD with you. The savefile can be in the harddrive or it can be on a flash drive. You can also modify the kernel command line parameters (please refer to Boot Options) to specify exactly where your savefile is so that Fatdog64 does not consume time looking for your savefile.
Flash drive
Also known as thumbdrive, usb stick.
For booting a flash drive on UEFI (Windows 8 and above) hardware click here.
A flash drive install operates exactly like a hard drive one. The flash drive needs to be formatted with VFAT/FAT16/FAT32 (MSDOS filesystem) or NTFS (Windows filesystem) or one of the Linux filesystems ext2/ext3/ext4, before it can be used to install/boot Fatdog64. Other formats are not supported.
A flash drive can be formatted just like a hard disk (i.e. multiple partitions), or it can be operated like one big storage (called "superfloppy" mode in Puppy Linux terms). If you use the installer, you can see the difference as follows: a flash drive formatted like a hard disk will have partitions (e.g. if your flash drive is identified as sdb, then it will have partitions named sdb1 (and possibly sdb2, sdb3 and so on), whereas a flash drive prepared in superfloppy mode does not have partitions.
Fatdog64 supports both, but sometimes your BIOS (the firmware of your computer that controls it before any operating system is loaded) may not. You can try whichever formatting mode that works with your BIOS.
You can use Fatdog64 installer to change your flash drive between hard disk mode or superfloppy mode (warning: data loss). If you want to use standard hard disk partitioning, use Gparted ("Modify Partitions" from the installer) to create a partition in your flash drive, if one does not exist, and then format that partition (usually Gparted will do that for you too). If you want to use superfloppy mode, choose the "disk" device of your flash drive (e.g. sdb, not sdb1) and then format it.
A special concern with flash drives is that there is a limit on the number of writes that can be done on them, usually arount 10,000 for cheap drives. After this many writes, the flash drive will start to fail in unpredictable manners. While you think you may not do 10,000 writes, an operating system operation writes a lot of times behind your back (especially if you use journaling filesystems like ext3/ext4 or NTFS).
Session saving control
Fatdog64 address this by using the RAM layer - writes are stored into memory, and only once every 30 minutes or so (configurable) the changes will actually be flushed and written to the flash drive. This helps to extend the life of flash drives considerably. It also makes operations faster, as a flash drive is a slow device when it comes to writing data to it. In this way, you will only notice the delay during the periodic saving. This is all good stuff but like everything in the world, it has a downside: if you lose power, you can lose up to 30 minutes (or whatever period you set) of your work. If this is not acceptable, don't use a flash drive, get a portable harddrive instead.
Session saving control is available for all savefile operation - not only for flash drives but also for regular drives and network drives. The periodic saving can also be disabled, making you fully in charge of whether or when to save changes. (You can save by clicking the "Save RAM layer" icon on the desktop). You can choose not to save the session at all if you wish - whatever you did during your session will be thrown away and you will start fresh next time you will use your computer.
Unlike Puppy Linux, Fatdog64 does not try to automatically enable RAM layer feature for flash drives. You need to specifically enable RAM layer (please refer to Boot Options).
Multisession DVD+RW / DVD+R / DVD-R
Running Fatdog from Multisession DVD+RW is just like running Fatdog from Live CD/DVD, except that the session can be saved directly to your DVD+RW --- not flash drive or hard drive. During shutdown, your changes will be compressed and written as SFS file to the disc. The SFS will be loaded again the next time you reboot. Note that all the session data is loaded into RAM - so you need to have quite a bit of RAM available. Once the system boots up, you can take out the DVD+RW - just like Live CD/DVD. You will be reminded to put it back in at shutdown time.
When the disc is full, all you need to do is burn another copy of Fatdog64 on a new optical disc, then use this disc when prompted to insert the disc. Fatdog64 will save your old session as well as the new session on the new disc.
Multisession is enabled by passing multi
parameter on the kernel command line parameter.
Note 1: The following optical disc types have been tested and known to work: DVD+RW, DVD+R, DVD-R. CDs are not supported.
Note 2: Multisession DVD+RW is an oxymoron. DVD+RW in fact does not have nor supports "multisession" as it is defined for CD or DVD-R. But the result of running in this mode is similar to running traditional multisession, so we keep this term.
Note 3: At this stage, support for multisession is still rough. There is no warning on whether the disc is full, and when the disc is full, you need to manually burn a new copy of Fatdog64 before saving the session.
Advanced installation options
These will only be discussed briefly. Starting from Fatdog64 600, the following installation options are available:
Copy ISO file directly flash drive
Fatdog64 ISO file is an isohybrid image. In addition to burning it to CD/DVD, it can be imaged directly to a flash drive. When done this way, the flash drive will work exactly like a Live CD.
Savefile encryption
Savefile can be encrypted. This is asked during savefile creation during shutdown. During boot, the system will ask for the password. If the password is wrong the system will continue to boot without the savefile. The cipher used for encryption is AES, in the future it may be configurable.
"Underdog" feature
Fatdog can mount and use another Linux operating system as part of its own filesystem. In this way, Fatdog can use some features of the other operating system as its own. In Puppy Linux terms, this is called using an "underdog" feature. Changed files can either be saved directly to the other system, or to a separate savefile so that the original operating system is unaffected.
Remote savefiles
Savefiles can be stored not only in local devices. They can be stored in remote systems, using either CIFS (aka SAMBA / Windows shares), or NBD (network block device).
Netboot
Fatdog can be booted by pxelinux directly from the ISO file, using memdisk. A simple configuration looks like this:
pxelinux.cfg/default
default fatdog
label fatdog
kernel memdisk
initrd fatdog64.iso
append iso raw
Or you can still use the standard netboot options by extracting vmlinuz and initrd and specifying them directly without using memdisk. Fatdog64 only requires these two files to boot, in Puppy Linux terms, Fatdog64's initrd is called "humongous initrd".
Using memdisk is easy, but using the extracted files is more flexible because you can add configuration options to the kernel command line. With memdisk the kernel line is fixed.
Multisession with harddrive
The multisession feature is available for DVD+RW and also for hard disk. It saves every session as a separate SFS session file (which can be opened and reviewed independently). Unwanted session files can simply be deleted.
Unsupported installation options from previous Fatdog64 versions
Multisession CD
Multisession with CD is not supported. Systems capable of running Fatdog64 usually come with a DVD writer anyway, so usually this is not a concern.
Multisession DVD
Multisession with DVD-R/DVD+R/DVD-RW is not supported. It might work but it is untested.
Full Install
The compressed files from the install CD are expanded and copied to a dedicated partition of the hard disk. This is the normal mode of installation for mainstream Linux system, such as Ubuntu or Fedora. Fatdog64 does not officially support this mode of installation, but see here if you are really inclined to.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from harddrive.html on 2024-12-09.
Humongous initrd
By default, Fatdog uses what is called in Puppy Linux terms "humongous initrd" (see here and here).
Basically what it means is that there are only two (2) files needed to boot Fatdog: vmlinuz and initrd, instead of the usual three (3) (or more): vmlinuz, initrd and base.sfs (puppy.sfs, zdrv.sfs, adrive.sfs etc). The base.sfs file still exists in Fatdog but it is contained within the initrd, thus you can't see it. It also causes initrd's to swell: initrd's size is usually around 3-5 MB but in Fatdog it is about 425-450 MB because it contains the base.sfs - hence the name "humongous".
Why use humongous initrd over Puppy's traditional 3-file setup?
- Faster boot on harddisk frugal install.
- Two-file installation makes is very easy to boot Fatdog remotely using PXE.
- Easier booting on exotic medium - as long as the bootloader can load vmlinuz and initrd (which most Linux bootloader is supposed to do), then Fatdog can run.
Of course, like anything else, the "faster boot" part depends on your BIOS and your hardware. It is generally faster to use humongous initrd on harddisk frugal install but it isn't always so. Humongous initrd may be slower to boot on other kind of setup / install devices, too (though again, not always). You may have other reasons for preferring the standard 3-file setup:
- You're using optical disc multisession, and you find the boot time slow.
- You're booting off from USB flash drive or SD card, and you find the boot time slow
- You cannot install humongous initrd because of limited available space in the boot partition (e.g. UEFI boot partition). In this case, you can put a vmlinuz and small initrd in the UEFI boot partition, and put the base.sfs in elsewhere.
Fatdog supports converting the humongous initrd back to a small initrd, extracting the base.sfs in the process and reverting to the standard 3-file setup:
- You can use Fatdog Installer to install to USB Flash drive. If you have large enough RAM (2 GB or more), it will offer to use either standard initrd or small initrd.
- You can remaster Fatdog to create an ISO with small initrd.
- You can use the command line tool fatdog-split-initrd.sh. Run the command in terminal to see the options.
(In Fatdog versions prior to 904, this command by default will create "micro" initrd, in Fatdog 904 onwards it will create "mini" initrd by default. Please see technical notes below).
Of special note: the tmpdir (temporary directory) used by the tool by default is /tmp, if you have less than 2 GB of RAM and you don't use swap, you'd better specify a different location or Fatdog can lock-up due to running out of memory when doing the splitting. - Or, if you only want to get a smaller version (not the smallest), you can extract only the fd64.sfs by clicking on your installed initrd (this should open it up), moving fd64.sfs outside to a place accessible by the bootloader (perhaps the same location of vmlinuz and initrd itself), and then re-packing the initrd by clicking repack-initrd.sh. (This is the "mini" initrd - see technical notes below).
From Fatdog 813 onwards, fatdog-split-initrd.sh can also create this type of initrd, just pass the -mini option when running it.*
*
If you use last method, please remember to use the basesfs parameter on your bootloader to tell Fatdog where to find the basesfs. Usually setting it to basesfs=local or basesfs=local:/path/to/fd64.sfs will do (or you can specify the actual device location like basesfs=device:sda7:/path/to/fd64.sfs - this will be faster since it means Fatdog doesn't have to search for the basesfs).
Parting words: Will using a small initrd improve boot speed? Perhaps. There is not definite answer. You just need to go a try.
Note: base.sfs is a generic term for Fatdog's system SFS. The actual filename varies with Fatdog versions, it is usually called fd64_xxx.sfs where xxx refers to the version number, e.g. fd64_620.sfs. Starting from Fatdog64 700, the base sfs is simply named as fd64.sfs; there is no version number attached anymore.
Nano Initrd
On Fatdog64 720 onwards, in addition to the standard huge initrd, Fatdog64 also comes with a small initrd that we dub as nano initrd (the actual filename of this initrd in the ISO file is initrd-nano), to save the effort of making a small initrd as explained above.
This small initrd is called "nano" because it is the smallest variant; it is smaller than what can be produced by the above manual methods. It is also the least flexible and has least features and least hardware support: because there is also no additional drivers in it. You can only use this initrd if you're certain that (as far as booting is concerned) your hardware is supported by the kernel without any additional modules.
To work, this nano initrd still needs the huge initrd; in fact, the only thing it does is to find the location of the huge initrd and then load it up. However, because the loading is done by the Linux kernel, this is usually much faster than the bootloader + BIOS combination. The base sfs loaded by nano initrd will stay in the memory just like the normal huge initrd.
In order to nano initrd, you need to do two things:
- In your bootloader configuration, where you usually specify "initrd", use "initrd-nano". But remember to keep "initrd" handy and remember its location.
- In your bootloader configuration, where you specify kernel parameters / boot parameters / boot options, you need to add the option mergeinitrd to tell nano initrd where to find the huge initrd. You can read more details about this parameter here.
Note: nano initrd is relatively new and is not well tested and supported. It works, however, some of Fatdog64 tools (remasters, installers) may not work correctly with it. If you encounter an unexpected behaviours, please report them in the forum and we will do what we can to improve the situation.
Technical notes
Fatdog has 4 types of initrd. Listed in order of decreasing size:
- Standard initrd (the "humongous" initrd) - this is shipped by default.
Size is over 300M. Supports coldplug boot parameter. - "mini" initrd - an initrd that contains the entire set of kernel modules (device drivers) but without the base.sfs.
Size is over 70M. Supports coldplug boot parameter. - "micro" initrd - an initrd that only contains minimum essential modules required to boot, without the base.sfs.
Size is less than 20M. Supports limited version of coldplug boot parameter (it can only load a very small subset of modules that exist in initrd, obviously). - "nano" initrd - an initrd that has nothing, only the boot logic - this is also shipped by default (because, why not, the size is very small and in certain situations it can help to boot faster).
Size is less than 15M. Does not support coldplug boot parameter.
Note: absolute sizes shown were correct at the time of writing. They may changed depending on Fatdog64 versions, however the relative size relationship is always correct, namely standard, mini, micro and nano - going from largest to smallest initd.
Some documentations (including this page), and commands, mention the term "small initrd". What does "small initrd" means? How small is "small" ?
"Small initrd" is an old term (before the mini/micro/nano were coined), and while it can mean any of the items in 2,3 or 4 (mini, micro, or nano), in most cases, "small initrd" is actually equivalent to "micro initrd".
This makes sense as "small initrd", when it was originally coined, meant "an initrd that was as small as it could be while still having enough drivers to boot the system independently of any other files" - which is what "micro" initrd is.
Going forward, however, it is better to drop the usage of "small initrd" altogether, and instead use the more descriptive initrd size names listed above.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from huge-initrd.html on 2024-12-09.
Frequently Asked Questions
Replacing a kernel module in initrd
- Use Rox to find the location of initrd (usually at the root directory where you installed Fatdog64).
- Make a backup of this initrd file, in case you make a mistake.
- Click the initrd file. The initrd will be extracted into a working folder (somewhere under /tmp)
- Inside this folder, there is a file called kernel-modules.sfs
- Open a terminal session from the folder:
- Make sure no files are selected.
- Right-click
- Choose "Window" menu, then choose "Terminal Here"
- From terminal, run the command unsquashfs kernel-modules.sfs
- You will get a new folder created within, called squashfs-root.
- Inside this squashfs-root folder, you can find lib/modules/3.3.2 folder. The version number (3.3.2) may be different for different version of Fatdog64.
- Copy the module you have created in the appropriate location inside the above folder.
- When done, from terminal, run the command depmod -b $(pwd)/squashfs-root -a. This will rebuild the module depedency list.
- Delete the original kernel-modules.sfs. Don't worry, we are going to build a new one.
- From terminal, run the command mksquashfs squashfs-root kernel-modules.sfs -comp xz Make sure you do this after deleting the original kernel-modules.sfs.
- Now remove the squashfs-directory.
- Close your terminal by typing exit, we're done.
- Last step - do this if you feel you have done everything right - click and launch the repack-initrd from Rox. This will re-build the initrd and delete the working folder.
Note 1: If you make a mistake, just close the folder and you can restart again. Nothing is changed until you do the last step (repack-initrd).
Note 2: that you can do the operation from terminal or from Rox, but please ensure:
- Use terminal commands for those that explicitly mentions "from terminal, do XXX".
- In terminal, do not "cd" to anywhere else (if you do, please change to the original directory before you execute the commands - the instructions above assume you do not change the directory).
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from initrd.html on 2024-12-09.
Intel graphics known issues
Missing OpenGL 2.1 Support
From Februrary 2017 onwards, Mesa (the open-source OpenGL library) has dropped OpenGL 2.1 support for certain older and less capable Intel graphic cards.
If you need to run applications that need OpenGL 2.1 (e.g. blender) for these cards, it is possible to retro-fit the the OpenGL 2.1 support.
This is done editing /etc/drirc and adding the following snippets:
<driconf>
...
<device driver="i915">
<application name="Default">
<option name="stub_occlusion_query" value="true" />
<option name="fragment_shader" value="true" />
</application>
</device>
...
</driconf>
References:
- https://www.phoronix.com/scan.php?page=news_item&px=Mesa-i915-OpenGL-2-Drop
- https://www.phoronix.com/scan.php?page=news_item&px=OpenGL-1.4-i915-Now-Default
- https://wiki.archlinux.org/index.php/Intel_graphics#OpenGL_2.1_with_i915_driver
Desktop takes a long time to show up after booting up
On certain machines with old Intel graphic chips, it may take a relatively long time (can be up to a few minutes) for the desktop to show up, after an apparently successful text-mode boot up.
There are many possible causes for this, but one of the most frequent one is because the kernel driver is trying to activate the S-VIDEO interface, which in reality may not even be connected to anything in your machine.
To fix this, you need to tell the kernel to disable S-VIDEO interface. This is done by putting the following boot parameter: video=SVIDEO-1:d
in your boot loader entry.
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=93782
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from intel-graphics.html on 2024-12-09.
Fatdog64 ISO Builder
Introduction
Fatdog64 ISO Builder is a tool to build a customised Fatdog ISO.
There are three ways to make a custom Fatdog ISO.
- Use Fatdog remaster - take a (modified) snapshot of the running copy of Fatdog, and build an ISO out of it.
- Take Fatdog's base.sfs, extract it (unsquash it) to a folder, then add/remove packages from that folder, and re-build/re-create the base.sfs. Optionally, use a software like ISO Master to copy the modified base.sfs back to the Fatdog ISO.
- Use this tool.
What does this tool do? Given a file containing a list of packages, this tool will build Fatdog ISO (and everything else in between that is required to do it). Whatever comes in the ISO is whatever you specify.
Customisation is done by choosing the packages you want to include. But you are not limited to official packages, you can of course create your own packages, which can potentially replace and/or modified base Fatdog files with your own.
You don't have to start with an empty package list either. The Fatdog Team publishes the list of the packages included in the official ISO for every release, so you can use those lists are your starting point.
The ISO Builder is the same tool as used by the Fatdog Team to build the official Fatdog ISO release. Originally release in 2016, at the launch of Fatdog64 702, it has been updated for every single official release onwards. It is not included in the Fatdog ISO, but you can get it from here.
If you are familiar with Puppy Linux and Woof / Woof-CE, the Fatdog64 ISO Builder is Fatdog's version of Woof.
PS: There is another similar builder for FatdogArm, released in 2014. It does not make an ISO, it makes an image file suitable for booting on ARM.
How to use
Note: The Fatdog64 ISO Builder is an advanced tool for advanced users. If you are not comfortable with command line scripting, then this tool is not for you. Please use other tools to customise Fatdog.
Basic ingredients:
- The Fatdog64 ISO Builder from the link given above.
- fatdog-initrd, get it from the latest Fatdog64 official ISO.
- efiboot.img, get it from the latest Fatdog64 official ISO.
- The package list for the Fatdog version you're trying to build, downloadable from the same location as the ISO builder.
Item 2-4 is optional.
- If you forgot to get 2) - you will be gently reminded at boot.
- If you forgot to get 3) - your ISO will not boot on UEFI systems
- If you forget to get 4) - it will use built-in pkglist which builds command-line only minimal ISO.
For further information, you can look at the README.md included in the ISO builder itself, a copy of which is shown below. Note that this copy of README dates back from Fatdog 710 days. Newer version of Fatdogs are bigger and will require more space to build.
Fatdog ISO Builder
==================
This is the Fatdog ISO Builder. This package enables you to build
custom Fatdog ISO from the list of packages that you specified.
The result of this script, when run properly, is an triple-hybrid ISO
that will boot as an ISO, or when `dd`-ed into a USB flash drive, on
BIOS and UEFI systems.
This is the same set of scripts that is used to build the official
Fatdog64 ISO - so if you supply an identical initrd and identical
package list (see below for details) - this script would create an ISO
that is functionally identical with the official Fatdog64 ISO.
This script has been tested to run only on Fatdog64. It relies on
certain tools that is known to exist and work on Fatdog64. It may work
on other systems - but if you do that and you have problems, I don't
want to hear about it.
This tool is a great alternative to remaster. Remaster more or less
does the same thing; this one builds the ISO from the ground-up.
-------------------------------
Main usage
----------
Extract the downloaded tarball to a **Linux** filesystem.
Important: you must use **Linux** filesystem. You cannot use this
on FAT32, NTFS, HFS+, or any other non-Unix, non-Linux filesystem.
The master script is called build-iso.sh. This script drives all other
scripts. You can create a file called `build-iso.conf` and put that in
this directory; that file will be sourced and all variables will be
used instead of the ones specified in the script.
A default `build-iso.conf` is supplied with the default values given.
You can change them to suit your needs.
`build-iso.sh` is capable of producing an ISO, and initrd, or standard
Fatdog SFS-es (base sfs, devx sfs, and nls sfs). For the ISO, you can
choose the standard humongous initrd, or small initrd, or "micro"
initrd.
All the working files will be created in this directory unless you
specify otherwise (via `build-iso.conf`). Thus make sure that you put
this in a filesystem large enough to contain all the downloaded
packages and the final output.
It will use `tmp` as temporary directory by default; so you will also
need plenty of space there. How big the space is needed depends on how
many packages you want to build.
Fatdog64 800 requires at least 2.5GB free in /tmp.
Newer version will require more space.
If you have less than 2.5GB in /tmp, you need to specify directory
location for storing temporary files. They are documented
[here](docs/BUILD-COMMANDS.md).
-------------------------------
Output
------
By default the output will be placed in the `iso` directory.
Inside that directory, there are two scripts - `runiso.sh` and
`runsfs.sh`. Both of these will use qemu-system-x86_64 to run the
ISO (or fd64.sfs) you have created for testing purposes.
-------------------------------
Notes
-----
Five main ingredients are **not** supplied in this packages.
1. There are no actual packages inside. This will be downloaded by the
build scripts.
2. There is no kernel inside. This will be downloaded by the build
scripts.
3. There is no initrd inside. The supplied one is a dummy and must be
replaced from an existing Fatdog ISO: get a recent ISO, extract out
its initrd, put it in a folder called `fatdog-initrd` and use that
folder to replace the one here. Note: use the extracted content,
and do not re-pack it again.
If you forgot to do this you will be gently reminded when you boot
the resulting ISO ☺
Make sure you remove `kernel-modules.sfs` and `fd64.sfs` from the
extracted initrd to save space as they are not used and will be
replaced with by the build process anyway.
4. There is no package list. The supplied package lists are dummy ones.
They will build a CLI-only system with bash and a few common
utilities.
You can start customising your system from here, or you can get
a current Fatdog package list and work your way up from there.
5. `efiboot.img`, Fatdog's UEFI bootloader is not included, because of
its size. Grab it from any recent Fatdog ISO distribution, or from
[here](http://distro.ibiblio.org/fatdog/other/efiboot.img); then
put it inside `fatdog-iso-root` directory.
If you don't have it, you can still build the ISO but it will be
built as standard isohybrid and will only boot on BIOS systems
(or UEFI with legacy support enabled).
The reasons why these are not included is because they change often.
`efiboot.img` is not included because of its size.
-------------------------------
Additional documentation
------------------------
[How to use ISO Builder inside Qemu](docs/BUILD-QEMU.md)
[build-iso.sh parameters](docs/BUILD-COMMANDS.md)
-------------------------------
Copyright (C) 2016, 2017, 2018 - The Fatdog Team.
License: GNU GPL version 2 or later.
Warranty: None. Use it at your own risk.
Tutorial: How to build Fatdog inside Qemu
Note that this copy of README dates back from Fatdog 710 days. References to the ISO builder dates and package list were based on that version. You are encouraged to use the latest version of the builder, as well as the latest package list instead.
Please do remember that newer version of Fatdogs are bigger and will require more space to build. The RAM requirement, however, probably don't differ very much.
This tutorial is based on what I wrote in the forum post here.
Building Fatdog inside QEMU
===========================
------------
Introduction
------------
Inside this script you will find directory `qemu`. It contains two
scripts, `runiso.sh` and `runsfs.sh`. These are simple wrapper scripts
to launch and run Fatdog ISO or SFS under qemu.
Just put fatdog.iso or fd64.sfs under `iso` directory and launch the script,
e.g. `./iso/runiso.sh`. It will launch a 1GB qemu instance.
For this to work, you need to have qemu installed. Qemu comes in `devx.sfs`,
so if you use `devx.sfs` then it's already installed for you.
You can adjust the memory by adding MEM=xxxx env variable before launching
the script, e.g. `MEM=2048 ./runiso.sh` to launch a qemu instance with
2GB RAM.
___________________________________
Virtual Disk in Qemu
--------------------
You can also create a file called `disk.ext3` inside `iso` and this
will be mounted as a virtual disk, which you can then use for savefile
or savedir or whatever have you. With `runiso.sh` this virtual disk
will show in as "sda", with `runsfs.sh` it will show up as "sdd".
To make a 1GB virtual disk:
dd if=/dev/zero of=iso/disk.ext3 bs=1G count=0 seek=1
mkfs.ext3 iso/disk.ext3
___________________________________
Building Fatdog inside QEMU - the Steps
---------------------------------------
If you system is able to run a 2GB qemu instance, and you can create
4GB virtual disk, it is possible to build Fatdog64 using this instance.
1. Get a working Fatdog ISO, name it fatdog.iso and put it under `iso`.
Create 4GB virtual disk.
2. Launch qemu to run Fatdog ISO with 2GB RAM, like this: `MEM=2048 ./iso/runsfs.sh`
Once you have desktop running inside qemu, follow these steps (all of these
are done inside the qemu instance, not on the host).
3. I launched seamonkey and downloaded ISO builder dated 2016.2 from ibiblio.
4. I downloaded package list for 710, also from ibiblio.
5. I mounted the 4GB virtual disk (in my qemu, it showed up as "sda") using Rox -
so the mount point is /mnt/sda
6. I right-click the iso builder tarball and choose extract. I did the same to the
package list tarball.
7. I moved extracted contents of the pkglist tarball (`sfs*list` files) to replace
those files in the extracted iso builder folder. 6 & 7 is done using Rox.
8. I mounted the virtual CDROM drive that contains the Fatdog64 710 ISO. In my qemu
this is "sr0" so it is mounted under /mnt/sr0.
9. From /mnt/sr0 folder, I dragged and dropped (=copying) efiboot.img to
"fatdog-iso-root" inside the extracted iso builder folder.
10. Using rox, I navigated to the "fatdog-initrd" folder inside the extracted
iso builder folder.
11. I deleted everything under that folder (init, and "bin" folder) - still using Rox
12. I launched terminal in that folder, by typing back-quote.
13. In the terminal, I typed "cpio -i < /mnt/sr0/initrd" to extract the initrd from
the Fatdog64 710. I can see that folder was populated with stuff extracted from
initrd.
14. I deleted "fd64.sfs" and "kernel-modules.sfs" using Rox.
15. Now on the terminal I opened in step 12, I typed "cd .." to move up to the root
folder of the iso builder.
16. I typed "geany build-iso.conf" and edited the file. I added:
BASE_ROOTFS_DIR=/mnt/sda/build
WORKDIR=/mnt/sda/build-iso
to the end of the file. And I saved the file, and quit geany.
17. Then in the terminal I typed "mkdir -p /mnt/sda/build". Remember, "/mnt/sda" is
where my virtual disk is mounted.
18. Then I typed "./build-iso.sh iso".
19. It will start downloading files. When all files have been downloaded, it will start
instaling them. When installation is done, it will build fd64.sfs. When the basesfs
is done, it will build the ISO in the "iso" folder.
Note: Go for coffee. Downloading from ibiblio is slow. Doing mksquashfs with XZ
compression is also slow. All these can be configured later using build-iso.conf
(downloading from elsewhere, and changing the compression to use gzip/bzip2/lzo/lz4
etc) once you've got the basic steps right and working.
20. When it is done, shutdown qemu.
21. Loop-mount the virtual disk by clicking it in Rox.
22. I copied over the created fatdog.iso to my physical disk - just the usual Rox
drag and drop.
23. Then I unmounted the virtual disk (clicking it again)
24. I tested booting the resulting fatdog.iso using qemu again
(qemu-system-x86 -enable-kvm -m 1024 -cdrom fatdog.iso).
25. It works.
Note: all done with pristine Fatdog64 710 boot, no savefile needed, no devx needed,
in a machine with 2GB RAM and 4GB free space (Linux filesystem).
Tip: If you need to build again with a new `pkgtlist` file, you can keep folders
`pkgcache` and `kernel` in the fatdog-iso-builder folder to avoid downloading their
contents again. Everything else should start from scratch according tho the steps
above.
Tip2: BASE_ROOTFS_DIR and WORKDIR cannot be located anywhere inside /root/Downloads.
Final Notes
Please don't expect too much support on this. It's targeted at people who know what they are doing, although everyone is welcome to try. You are encouraged to look into the scripts to figure out how it works, and please feel free to edit it to suit your own needs.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from iso-builder.html on 2024-12-09.
How to build a kernel for Fatdog
This is an example for building/compiling a kernel for Fatdog from scratch. It assumes you already know your way around Fatdog and Linux in general.
This however is neither a tutorial nor a comprehensive instructions to build the kernel which ships with Fatdog. This is only an example, and it covers only the minimal steps you need to do create, and package, the most basic kernel that is capable of booting Fatdog. There are additional steps not explained here (e.g. building aufs utilities, or external / third party kernel modules) because they only cause distraction and do not add to the pedagogical value of this example. Building an additional external kernel module for example is covered here.
In this example, we will build the 4.19.319 kernel. At the time of writing, 4.19.319 is the most recent version of the 4.19 LTS (long-term-supported) kernel. It is also the kernel line with the longest longevitiy, which makes it an ideal example as this kernel line would probably continue long after this document is written. Nevertheless, the same principles are applicable for all kernels, either older or newer. The only thing to be careful is to adjust the aufs patches to use(different kernel versons may have different patches to use).
Preparations
- The most important step of the process: Obtain the known-good kernel configuration file from the kernel version nearest to the one that you want to build.
The kernel configuration file is known as .config file, or in Puppy's terms, the DOTconfig.
In Fatdog, this file can be obtained in two ways:
a) from the running kernel, by running the command zcat /proc/config.gz > DOTconfig
b) from kernel-source-X.Y.Z.sfs; this file is located in /usr/src/linux-X.Y.Z/.config
For this example I will take the .config from kernel-source-4.19.92.sfs (from here: http://distro.ibiblio.org/fatdog/sfs/800/) - Obtain the known-good firmware collection for a kernel version which is nearest to the one that you're building.
This is normally located in kernel-modules.sfs, located in /lib/firmware. If you're being lazy, then just download one of the tarballs from here: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git, but that file will be huge (linux-firmware-20240811.tar.gz for example is 555 MB) as it will include firmware from all kernel versions back to version 2.6 onwards. The point of using existing firmware collection is to include only the firmware that you need, to make the size smaller.
For this example I will use the firmware from kernel-modules.sfs-4.19.92 (from here: http://distro.ibiblio.org/fatdog/kernels/800/) - Have a Linux partition ready. Building kernel requires a lot of space which probably won't fit into your RAM, or your savefile/savefolder, so do it in an external Linux partition (it has to be a Linux partition, not FAT32, NTFS or anything like that).
For this example, I will use /mnt/sdc1 as the location (/mnt/sdc1 is the mountpoint of /dev/sdc1, which is my external USB drive containing an ext4 partition).
The rest of the steps will be shown one line at a time, and without commentaries except when it is absolutely necessary (comments are prefixed by #).
Steps
cd /mnt/sdc1
# get and unpack kernel sources
wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.19.319.tar.xz
tar -xvf linux-4.19.319.tar.xz
cd linux-4.19.319
# get aufs and apply aufs patches
git clone https://github.com/sfjro/aufs4-standalone
cd aufs4-standalone
git checkout aufs4.19.63+
cp -r Documentation/ fs/ ..
cp include/uapi/linux/aufs_type.h ../include/uapi/linux/
cd ..
patch -Np1 -i aufs4-standalone/aufs4-kbuild.patch
patch -Np1 -i aufs4-standalone/aufs4-base.patch
patch -Np1 -i aufs4-standalone/aufs4-mmap.patch
patch -Np1 -i aufs4-standalone/aufs4-loopback.patch
patch -Np1 -i aufs4-standalone/vfs-ino.patch
patch -Np1 -i aufs4-standalone/tmpfs-idr.patch
patch -Np1 -i aufs4-standalone/proc_mounts.patch
# get .config
mount /path/to/kernel-source-4.19.92.sfs /mnt/data
cp /mnt/data/usr/src/linux-4.19.92/.config .config
umount /mnt/data
# apply .config
yes "" | make oldconfig
# if you want to, you can adjust your kernel configuration by running:
# make menuconfig
# go for coffee
make -j4 bzImage modules
# install and prepare modules
make modules_install INSTALL_MOD_PATH=modules
depmod -a -b modules 4.19.319
# create kernel-source links for dkms
ln -s /usr/src/linux-4.19.319 modules/lib/modules/4.19.319/build
ln -s /usr/src/linux-4.19.319 modules/lib/modules/4.19.319/source
# copy firmware
mkdir -p modules/lib/firmware
mount /path/to/kernel-modules.sfs-4.19.92 /mnt/data
cp -a /mnt/data/lib/firmware/* modules/lib/firmware
umount /mnt/data
# package kernel-modules.sfs and vmlinuz
mksquashfs modules kernel-modules.sfs -noappend -comp xz
cp arch/x86/boot/bzImage vmlinuz
The vmlinuz and kernel-modules.sfs will be in your kernel build directory. In this example, it will be in /mnt/sdc1/linux-4.19.319.
This document was originally posted The Puppy Linux Forum.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from kernel-build.html on 2024-12-09.
How to compile kernel module for Fatdog64
If you want to rebuild a kernel module because you need to add a patch to it, or maybe it was not built with the rest of the modules, this is how to do it. Here is an example. Lets say I found a patch for the kernel module named appletouch that fixes some problem I have.
- You need to have the fd64-devx_xxx.sfs file installed and the kernel-source-x.x.x.sfs installed*
- cd to /usr/src/linux-x.x.x/drivers/input/mouse
- Apply the patch.
- make -C /lib/modules/`uname -r`/build M=`pwd` appletouch.ko
- Replace /lib/modules/x.x.x/kernel/drivers/input/mouse/appletouch.ko with the one just built.
If you just need to compile a driver that you downloaded, all you need to do is have the devx sfs file installed and follow the directions that came with that driver.
*) To do that place the fd64-devx_xxx.sfs and kernel-source-x.x.x in /mnt/home, then use the System SFS Loader to load them. Note that xxx in fd64-devx_xxx should be replaced with version of Fatdog64 you are running and the x.x.x in kernel-source-x.x.x corresponds to the kernel version you are running. To find your current kernel version open a terminal and type uname -r
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from kernel-module.html on 2024-12-09.
How to use a different kernel
This instruction is for using one of the pre-packaged Fatdog kernels, replacing the current one that comes with your version of Fatdog. If instead, you just want to add some additional kernel modules you've built yourself; or if you compile a totally new kernel, please follow the instructions in here to rebuild and replace the kernel-modules.sfs in initrd.
There a a couple ways to use a different kernel. First go here and download vmlinuz-x.x.x and kernel-modules.sfs-x.x.x, where x.x.x is the kernel version that you want. Vmlinuz is the actual kernel and kernel-modules.sfs contains the kernel modules (drivers) that are built to work with it.
Preferred method - Replace the original kernel-modules.sfs in the initrd with the one you downloaded:
1) Click on your initrd file. After a while the initrd will be extracted into a working folder and a new ROX window will open.
2) Replace the kernel-modules.sfs with the one you downloaded. Make sure it's named "kernel-modules.sfs".
3) Click on repack-initrd and the initrd will be updated.
4) Replace the original vmlinuz with the one you downloaded.
Alternate method - Using hard drive install booting with grub:
1) Copy vmlinuz-x.x.x to the same place as your original vmlinuz.
2) Rename kernel-modules.sfs-x.x.x to kernel-modules.sfs then click on it to mount it. A ROX file browser window will pop up.
3) From the mounted kernel-modules.sfs copy lib/modules/x.x.x to your system /lib/modules/.
4) Then you can add a new entry for grub in menu.lst, just like your current entry but with the kernel named vmlinuz-x.x.x.
5) Reboot using your new kernel.
You can also compile a new kernel by downloading the source from here , installing the devx sfs, and compiling. There is an example of how to do that here.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from kernel.html on 2024-12-09.
Basic keyboard shortcuts
A complete list of keyboard and mouse shortcuts can be viewed from the "Fatdog64 Keyboard Mouse Shortcuts" applet located in the "System" tab ("Desktop" tab on older Fatdogs) of the Fatdog64 Control Panel.
Ctrl-Alt-Backspace
This will kill the X windows server and you'll be at a terminal prompt. To restart the X server type xwin
.
Ctrl-c
This kills a script that is running in a terminal.
Ctrl-d
Signal that we want to terminate input.
Ctrl-Alt-F1 to F7
This will swich you to different virtual terminals. F4 or F7 is the X server's terminal.
`
The "backtick" key will start a terminal window in the currently open folder.
Shift-Delete
This copies text in the terminal.
Shift-Insert
This pastes text in the terminal.
Shift-PrintScreen
Wait 5 seconds and then capture snapshot of screen. Result is saved in $HOME.
PrintScreen
Toggle screen-capture mode. Right click to size capture area, release button to capture.
Alt-F1
Open window manager menus.
Alt-F2
Open command launcher.
Alt-F4
Close currently active application.
Win-e
Open ROX file manager as root - opens root's home (/root)
Win-g
Open ROX file manager as spot - opens spots home (/home/spot)
Win-t
Open Terminal.
Win-k
Kill process. The cursor will change to a skull; click the cursor on the window of the program you want to stop.
Win-s
Open application launcher Findnrun.
More shortcuts can be configured using Sven multimedia daemon.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from keys.html on 2024-12-09.
Table of Contents
- name
- synopsis
- note
- description
- configuration details
- supported properties
- button mapping
- button drag lock
- tablet tool pressurecurve
- tablet tool area ratio
- scroll pixel distance
- bugs
- authors
- see also
LIBINPUT(4) Kernel Interfaces Manual LIBINPUT(4)
NAME
libinput - libinput-based X.Org input driver
SYNOPSIS
Section "InputDevice"
Identifier "devname"
Driver "libinput"
Option "Device" "devpath"
...
EndSection
NOTE
This is the man page for the X input driver. If you are looking for the
library documentation, go to http://wayland.freedesktop.org/libinput/doc/
DESCRIPTION
libinput is an Xorg input driver based on libinput. It therefore
supports all input devices that libinput can handle, including most mice,
keyboards, tablets and touchscreens.
It is recommended that libinput devices are configured through the
InputClass directive (refer to xorg.conf(5)) instead of manual per-device
configuration. Devices configured in the xorg.conf(5) are not hot-plug
capable.
CONFIGURATION DETAILS
Please refer to xorg.conf(5) for general configuration details and for
options that can be used with all input drivers. This section only
covers configuration details specific to this driver.
The following driver Options are supported:
Option "AccelProfile" "string"
Sets the pointer acceleration profile to the given profile.
Permitted values are adaptive, flat, custom. Not all devices
support this option or all profiles. If a profile is unsupported,
the default profile for this device is used. For a description on
the profiles and their behavior, see the libinput documentation.
Option "AccelSpeed" "float"
Sets the pointer acceleration speed within the range [-1, 1].
This only applies to the flat or adaptive profile. Option
ccelPointsFallback" "string" Sets the points of the Fallback
acceleration function, (see the libinput documentation). The
string must be a space-separated list of floating point non-
negative numbers, e.g. "0.0 1.0 2.4 2.5". This only applies to
the custom profile. Option ccelStepFallback" "float" Sets the
step between the points of the Fallback acceleration function,
(see the libinput documentation). When a step of 0.0 is provided,
libinput's default Fallback acceleration function is used. This
only applies to the custom profile. Option ccelPointsMotion"
"string" Equivalent to AccelPointsFallback but applies to the
Motion acceleration function. Option ccelStepMotion" "float"
Equivalent to AccelStepFallback but applies to the Motion
acceleration function. Option ccelPointsScroll" "string"
Equivalent to AccelPointsFallback but applies to the Scroll
acceleration function. Option ccelStepScroll" "float" Equivalent
to AccelStepFallback but applies to the Scroll acceleration
function.
Option "ButtonMapping" "string"
Sets the logical button mapping for this device, see
XSetPointerMapping(3). The string must be a space-separated list
of button mappings in the order of the logical buttons on the
device, starting with button 1. The default mapping is "1 2 3 ...
32". A mapping of 0 deactivates the button. Multiple buttons can
have the same mapping. Invalid mapping strings are discarded and
the default mapping is used for all buttons. Buttons not specified
in the user's mapping use the default mapping. See section BUTTON
MAPPING for more details.
Option "CalibrationMatrix" "string"
A string of 9 space-separated floating point numbers, in the order
"a b c d e f g h i". Sets the calibration matrix to the 3x3
matrix where the first row is (abc), the second row is (def) and
the third row is (ghi).
Option "ClickMethod" "string"
Enables a click method. Permitted values are none, buttonareas,
clickfinger. Not all devices support all methods, if an option is
unsupported, the default click method for this device is used.
Option "DisableWhileTyping" "bool"
Indicates if the touchpad should be disabled while typing on the
keyboard (this does not apply to modifier keys such as Ctrl or
Alt).
Option "Device" "string"
Specifies the device through which the device can be accessed.
This will generally be of the form "/dev/input/eventX", where X is
some integer. When using InputClass directives, this option is
set by the server. The mapping from device node to hardware is
system-dependent. Property: "Device Node" (read-only).
Option "DragLockButtons" "L1 B1 L2 B2 ..."
Sets "drag lock buttons" that simulate a button logically down
even when it has been physically released. To logically release a
locked button, a second click of the same button is required.
If the option is a single button number, that button acts as the
"meta" locking button for the next button number. See section
BUTTON DRAG LOCK for details.
If the option is a list of button number pairs, the first number
of each number pair is the lock button, the second number the
logical button number to be locked. See section BUTTON DRAG LOCK
for details.
For both meta and button pair configuration, the button numbers
are device button numbers, i.e. the ButtonMapping applies after
drag lock.
Option "HighResolutionWheelScrolling" "bool"
Disables high-resolution wheel scroll events, enabled by default.
When enabled, the driver forwards only high-resolution wheel
scroll events from libinput. When disabled, the driver forwards
legacy wheel scroll events instead.
Option "HorizontalScrolling" "bool"
Enables or disables horizontal scrolling. When disabled, this
driver will discard any horizontal scroll events from libinput.
This does not disable horizontal scroll events from libinput; it
merely discards the horizontal axis from any scroll events.
Default is enabled.
Option "LeftHanded" "bool"
Enables left-handed button orientation, i.e. swapping left and
right buttons.
Option "MiddleEmulation" "bool"
Enables middle button emulation. When enabled, pressing the left
and right buttons simultaneously produces a middle mouse button
click.
Option "NaturalScrolling" "bool"
Enables or disables natural scrolling behavior.
Option "RotationAngle" "float"
Sets the rotation angle of the device to the given angle, in
degrees clockwise. The angle must be between 0.0 (inclusive) and
360.0 (exclusive).
Option "ScrollButton" "int"
Designates a button as scroll button. If the ScrollMethod is
button and the button is logically down, x/y axis movement is
converted into scroll events.
Option "ScrollButtonLock" "bool"
Enables or disables the scroll button lock. If enabled, the
ScrollButton is considered logically down after the first click
and remains down until the second click of that button. If
disabled (the default), the ScrollButton button is considered
logically down while held down and up once physically released.
Option "ScrollMethod" "string"
Enables a scroll method. Permitted values are none, twofinger,
edge, button. Not all devices support all options, if an option
is unsupported, the default scroll option for this device is used.
Option "ScrollPixelDistance" "int"
Sets the movement distance, in "pixels", required to trigger one
logical wheel click. This option only applies to the scroll
methods twofinger, edge, button. See section SCROLL PIXEL
DISTANCE for more details.
Option "SendEventsMode" "(disabled|enabled|disabled-on-external-mouse)"
Sets the send events mode to disabled, enabled, or "disable when
an external mouse is connected".
Option "TabletToolPressureCurve" "x0/y0 x1/y1 x2/y2 x3/y3"
Set the pressure curve for a tablet stylus to the bezier formed by
the four points. The respective x/y coordinate must be in the
[0.0, 1.0] range. For more information see section TABLET STYLUS
PRESSURE CURVE.
Option "TabletToolAreaRatio" "w:h"
Sets the area ratio for a tablet tool. The area always starts at
the origin (0/0) and expands to the largest available area with
the specified aspect ratio. Events outside this area are cropped
to the area. The special value "default" is used for the default
mapping (i.e. the device-native mapping). For more information see
section TABLET TOOL AREA RATIO.
Option "Tapping" "bool"
Enables or disables tap-to-click behavior.
Option "TappingButtonMap" "(lrm|lmr)"
Set the button mapping for 1/2/3-finger taps to left/right/middle
or left/middle/right, respectively.
Option "TappingDrag" "bool"
Enables or disables drag during tapping behavior ("tap-and-drag").
When enabled, a tap followed by a finger held down causes a single
button down only, all motions of that finger thus translate into
dragging motion. Tap-and-drag requires option Tapping to be
enabled.
Option "TappingDragLock" "bool"
Enables or disables drag lock during tapping behavior. When
enabled, a finger up during tap-and-drag will not immediately
release the button. If the finger is set down again within the
timeout, the dragging process continues.
For all options, the options are only parsed if the device supports that
configuration option. For all options, the default value is the one used
by libinput. On configuration failure, the default value is applied.
SUPPORTED PROPERTIES
libinput exports runtime-configurable options as properties. If a
property listed below is not available, the matching configuration option
is not available on the device. This however does not imply that the
feature is not available on the device. The following properties are
provided by the libinput driver.
libinput Accel Profiles Available
2 boolean values (8 bit, 0 or 1), in order "adaptive", "flat".
Indicates which acceleration profiles are available on this
device.
libinput Accel Profile Enabled
2 boolean values (8 bit, 0 or 1), in order "adaptive", "flat".
Indicates which acceleration profile is currently enabled on this
device.
libinput Accel Speed
1 32-bit float value, defines the pointer speed. Value range -1, 1
libinput Button Scrolling Button
1 32-bit value. Sets the button number to use for button
scrolling. This setting is independent of the scroll method, to
enable button scrolling the method must be set to button-scrolling
and a valid button must be set.
libinput Button Scrolling Button Lock Enabled
1 boolean value. If true, the scroll button lock is enabled. This
setting is independent of the scroll method or the scroll button,
to enable button scrolling the method must be set to button-
scrolling and a valid button must be set.
libinput Calibration Matrix
9 32-bit float values, representing a 3x3 calibration matrix,
order is row 1, row 2, row 3
libinput Click Methods Available
2 boolean values (8 bit, 0 or 1), in order "buttonareas",
"clickfinger". Indicates which click methods are available on
this device.
libinput Click Methods Enabled
2 boolean values (8 bit, 0 or 1), in order "buttonareas",
"clickfinger". Indicates which click methods are enabled on this
device.
libinput Drag Lock Buttons
Either one 8-bit value specifying the meta drag lock button, or a
list of button pairs. See section BUTTON DRAG LOCK for details.
libinput High Resolution Wheel Scroll Enabled
1 boolean value (8 bit, 0 or 1). Indicates whether high-resolution
wheel scroll events are enabled or not.
libinput Horizontal Scroll Enabled
1 boolean value (8 bit, 0 or 1). Indicates whether horizontal
scrolling events are enabled or not.
libinput Left Handed Enabled
1 boolean value (8 bit, 0 or 1). Indicates if left-handed mode is
enabled or disabled.
libinput Middle Emulation Enabled
1 boolean value (8 bit, 0 or 1). Indicates if middle emulation is
enabled or disabled.
libinput Natural Scrolling Enabled
1 boolean value (8 bit, 0 or 1). 1 enables natural scrolling
libinput Rotation Angle
1 32-bit float value [0.0 to 360.0). Sets the rotation angle of
the device, clockwise of its natural neutral position.
libinput Scroll Methods Available
3 boolean values (8 bit, 0 or 1), in order "two-finger", "edge",
"button". Indicates which scroll methods are available on this
device.
libinput Scroll Method Enabled
3 boolean values (8 bit, 0 or 1), in order "two-finger", "edge",
"button". Indicates which scroll method is currently enabled on
this device.
libinput Scroll Pixel Distance
1 32-bit value (nonzero, with additional implementation-defined
range checks). Changes the movement distance required to trigger
one logical wheel click.
libinput Send Events Modes Available
2 boolean values (8 bit, 0 or 1), in order "disabled" and
"disabled-on-external-mouse". Indicates which send-event modes are
available on this device.
libinput Send Events Mode Enabled
2 boolean values (8 bit, 0 or 1), in order "disabled" and
"disabled-on-external-mouse". Indicates which send-event modes is
currently enabled on this device.
libinput Tablet Tool Pressurecurve
4 32-bit float values [0.0 to 1.0]. See section TABLET TOOL
PRESSURE CURVE
libinput Tablet Tool Area Ratio
2 32-bit values, corresponding to width and height. Special value
0, 0 resets to the default ratio. See section TABLET TOOL AREA
RATIO for more information.
libinput Tapping Enabled
1 boolean value (8 bit, 0 or 1). 1 enables tapping
libinput Tapping Button Mapping Enabled
2 boolean value (8 bit, 0 or 1), in order "lrm" and "lmr".
Indicates which button mapping is currently enabled on this
device.
libinput Tapping Drag Lock Enabled
1 boolean value (8 bit, 0 or 1). 1 enables drag lock during
tapping
libinput Disable While Typing Enabled
1 boolean value (8 bit, 0 or 1). Indicates if disable while typing
is enabled or disabled.
Most properties have a libinput <property name> Default equivalent that
indicates the default value for this setting on this device.
BUTTON MAPPING
X clients receive events with logical button numbers, where 1, 2, 3 are
usually interpreted as left, middle, right and logical buttons 4, 5, 6, 7
are usually interpreted as scroll up, down, left, right. The fourth and
fifth physical buttons on a device will thus send logical buttons 8 and
9. The ButtonMapping option adjusts the logical button mapping, it does
not affect how a physical button is mapped to a logical button.
Traditionally, a device was set to left-handed button mode by applying a
button mapping of "3 2 1 ..." On systems using the libinput Xorg input
driver it is recommended to use the LeftHanded option instead.
The libinput Xorg input driver does not use the button mapping after
setup. Use XSetPointerMapping(3) to modify the button mapping at
runtime.
BUTTON DRAG LOCK
Button drag lock holds a button logically down even when the button
itself has been physically released since. Button drag lock comes in two
modes.
If in "meta" mode, a meta button click activates drag lock for the next
button press of any other button. A button click in the future will keep
that button held logically down until a subsequent click of that same
button. The meta button events themselves are discarded. A separate meta
button click is required each time a drag lock should be activated for a
button in the future.
If in "pairs" mode, each button can be assigned a target locking button.
On button click, the target lock button is held logically down until the
next click of the same button. The button events themselves are discarded
and only the target button events are sent.
This feature is provided by this driver, not by libinput.
TABLET TOOL PRESSURECURVE
The pressure curve affects how stylus pressure is reported. By default,
the hardware pressure is reported as-is. By setting a pressure curve, the
feel of the stylus can be adjusted to be more like e.g. a pencil or a
brush.
The pressure curve is a cubic Bezier curve, drawn within a normalized
range of 0.0 to 1.0 between the four points provided. This normalized
range is applied to the tablet's pressure input so that the highest
pressure maps to 1.0. The points must have increasing x coordinates, if
x0 is larger than 0.0 all pressure values lower than x0 are equivalent to
y0. If x3 is less than 1.0, all pressure values higher than x3 are
equivalent to y3.
The input for a linear curve (default) is "0.0/0.0 0.0/0.0 1.0/1.0
1.0/1.0"; a slightly depressed curve (firmer) might be "0.0/0.0 0.05/0.0
1.0/0.95 1.0/1.0"; a slightly raised curve (softer) might be "0.0/0.0
0.0/0.05 0.95/1.0 1.0/1.0".
This feature is provided by this driver, not by libinput.
TABLET TOOL AREA RATIO
By default, a tablet tool can access the whole sensor area and the tablet
area is mapped to the available screen area. For external tablets like
the Wacom Intuos series, the height:width ratio of the tablet may be
different to that of the monitor, causing the skew of input data.
To avoid this skew of input data, an area ratio may be set to match the
ratio of the screen device. For example, a ratio of 4:3 will reduce the
available area of the tablet to the largest available area with a ratio
of 4:3. Events within this area will scale to the tablet's announced axis
range, the area ratio is thus transparent to the X server. Any events
outside this area will send events equal to the maximum value of that
axis. The area always starts at the device's origin in it's current
rotation, i.e. it takes left-handed-ness into account.
This feature is provided by this driver, not by libinput.
SCROLL PIXEL DISTANCE
The X server does not support per-pixel scrolling but it does support
smooth scrolling. All scroll events however are based around a logical
unit of scrolling (traditionally corresponding to a wheel click). It is
thus not possible to scroll by 10 pixels, but it is possible for a driver
to scroll by 1/10th of a logical wheel click.
libinput provides scroll data in pixels. The ScrollPixelDistance option
defines the amount of movement equivalent to one wheel click. For
example, a value of 50 means the user has to move a finger by 50 pixels
to generate one logical click event and each pixel is 1/50th of a wheel
click.
BUGS
This driver does not work with Option "Device" set to an event node in
/dev/input/by-id and /dev/input/by-path. This can be usually be worked by
using Section "InputClass" with an appropriate Match* statement in the
xorg.conf(5).
AUTHORS
Peter Hutterer
SEE ALSO
Xorg(1), xorg.conf(5), Xserver(1), X(7)
1.3.0 xf86-input-libinput LIBINPUT(4)
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from libinput.html.html on 2024-12-09.
Resources and additional information
Links
Firmware --- If you are looking for firmware that is not in Fatdog64, you will want to try here and the manufacturer's web site.
Barry's Blog --- Barry Kauler, the creator of Puppy Linux, has a blog here.
Puppylinux.com --- Barry's web site.
jamesbond3142's blog --- Blog from one of Fatdog64 maintainer.
Linux From Scratch (LFS) --- Fatdog64 is built following LFS principles and build recipes.
cateee.net --- If your compiling a kernel and need to know what a config option means look here.
Phoronix --- Linux and hardware news.
Games
Urban Terror --- This is a first person shooter (FPS). Best free one I've seen.
Open Arena --- A FPS game, similar to Quake 3, this one is actually GPLed.
Smokin Guns --- A FPS game set in the wild west of the 1800s.
Linux Game Database --- I haven't actually used this much, but it looks good.
The games listed above require no installation, just unzip and play. They are quite large, in the 500MB to 700MB range. They all use the GPLed Quake 3 engine so they can run on modest hardware.
ATI and Intel hardware acceleration is supported by Fatdog64 with the included open source drivers, but you'll get better performance from the propritary ATI driver if it supports your card. Make sure you check to see if the version in the pet repository supports your card before installing. For Nvidia you'll need the Nvidia package or SFS installed.
There are a few games in the package repository too.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from links.html on 2024-12-09.
Why am I logged in as root?
Fatdog is a 64-bit desktop operating system targeted for home desktop computer owners. It aims to give full control of the home computer to its users, without restriction.
As such, the primary user is "root". User logins as root. By default, not even a password is required - the system autologins as root upon boot-up. Logging in as root offers unparalleled convenience for the home users, so it is and always be the default mode of operation for Fatdog.
Before you say that logging in as root is "unsafe", please ask yourself - "unsafe" from who? Remember this is a home desktop computer we are talking about, not a shared server in large networked environments. In this context, logging in as non-privileged user only protects you from one person - yourself (ie from your own mistakes). It also protects you from doing exactly one thing: destroying the system.
But consider this:
- restoring Fatdog operating system is a 5 seconds job assuming you have Fatdog CD/DVD/USB around, and
- logging in as unprivileged user does not protect you from mistakes in wiping out your own data.
What is more important and irreplaceable - your data, or the operating system files?
Question: But what about network programs? How about security holes in them? Especially, how do I ensure that whenever I use web browser / email / chat program / etc (insert your favorite network program name here), if there are security holes in them, they won't able to infect my system?"
Answer: Fatdog answer to this question is the same way that Android (yes, that Android) answers the question: Network security should not be equal to local security.
In Fatdog, most network programs runs as "spot", which is an non-privileged user. "spot" only have access to very limited places. If there are security holes in that network program that allow remote attacker to gain access to the system, they will only be able to access stuff which "spot" can access - which is not much. (Android goes even further - every process, not only network processes, is run by a separate randomised users).
How is this any different from standard non-privileged user login?
Consider this - let's say you log-in as your regular non-privileged user ("regular" means the user id you use for day-to-day work, so this is the user id that owns your home directory, owns your data, etc) and run network programs as that user too. This is how typical Linux distros do it. Now let's assume that there is a security hole in the network program that enables a remote attacker to gain access to your system. When a remote attacker manages to do this, he/she will gain access as your regular user id (because this is the user id used to run the network program, remember?).
What can the remote attacker not do? Among other things:
- he/she cannot delete operating system files.
- he/she cannot read certain operating system passwords.
- he/she cannot modify operating system files (e.g. to implant a system-wide keylogger to monitor every user in the system).
Big deal. Lets see what the remote attacker can do (among other things):
- he/she can delete your data
- he/she can read all of your data, including your passwords, your credit card numbers, your tax returns, etc
- he/she can modify and install programs executed by you at every startup - such as installing a keylogger to monitor everything you type.
Thus - what exactly does logging in as non-privileged user protect? What is more important and irreplaceable - your data, or the operating system files?
For further discussions of of why logging in as root is not a problem and is in fact safer than what you think, please visit the following:
Question: But a computer, even though it is used in a home context, may have multiple users (e.g. families sharing one computer). How to ensure that they does not interfere with one another, when each is logging in as root with full access to the system?
Answer: Fatdog, which was originally derived from Puppy, continues to use Puppy paradigm for supporting multiple users: By using multiple savefiles --- encrypted if necessary. Every user has his/her own savefile to store the computer state (not only data, but entire computer state). Within his/her own savefile, the user runs as root; he/she has the full access of the computer, while safely avoiding stepping on other users' toes. Switching into another user's personality is accomplished by rebooting the system and choosing another savefile.
Question: But this does not protect one user from deleting another user's savefile!
Answer: Surprise !! None of the big branded OS does, too! That is an illusion. If you have physical access to the computer - you can always boot from a Live CD (any Live-CD) or Live-USB stick, run as root from there, and do anything you wish - including wiping out the disk of the computer, no matter what OS is installed there (in fact, this is what OS installers do).
Question: But I heard that Fatdog supports multiuser.
Answer: Yes. There are several perfectly good reasons for multiuser operation, though not for what is typically claimed (as explained above).
With Fatdog, one can:
- Create additional users
- Auto-login as users other than the default "root"
- Run multiple X desktops at the same time, each for different users
- Remote X desktop using SSH X11 forwarding
All these capabilities (except the last one) are accessible through the User Manager in Control Panel.
Note: Fatdog multiuser capability is still considered experimental.
Question: How to create additional users?
Answer:
- Open Fatdog Control Panel.
- Choose the "System" tab.
- There is an icon called "User Manager". Launch it by selecting it and pressing Enter.
- Click "Add".
- Enter the name of the new user. Only use alphabetical characters.
- Note that the newly created user is assigned "/home/$USER" as home directory and "woofwoof" as default password.
Question: How to delete users?
Answer:
- Open Fatdog Control Panel.
- Choose the "System" tab.
- There is an icon called "User Manager". Launch it by selecting it and pressing Enter.
- Highlight the user you want to delete.
- Click "Delete".
Question: How to set it up so that at next boot I will login as a particular user instead of "root"?
Answer:
- Open Fatdog Control Panel.
- Choose the "System" tab.
- There is an icon called "User Manager". Launch it by selecting it and pressing Enter.
- Highlight the user you want to use.
- Click "Autologin as user".
When you do this, at next boot you will be logged in as this (non-privileged) user and boots straight to desktop. You will no longer run as root, and many operations that require privileged access will now ask you for the root password. You can change to login automatically as root by following the same process as above, choosing "root" as the user.
Note: "Autologin as user" button is only available when your log-in mode is "autologin" (which is the default, unless you change it).
Question: How to launch a secondary desktop?
Answer:
- Open Fatdog Control Panel.
- Choose the "System" tab.
- There is an icon called "User Manager". Launch it by selecting it and pressing Enter.
- Highlight the user you want to use.
- Click "Launch desktop as user".
When you do this, a new X server with its associated desktop are launched and created. You can switch between your original desktop and the new desktop using Ctrl-Alt-Fx (where x=4,5,6 etc). Your original desktop would most likely be associated with Ctrl-Alt-F4, while the new desktop will be at Ctrl-Alt-F5. You can launch multiple secondary desktops if your computer has the resources to do so, but each desktop must be associated with a different user.
Exit any secondary desktop(s) by choosing "Quit X Server" from the menu, or just press Ctrl-Alt-Backspace. If you wish, you can also terminate the original desktop and use a secondary desktop exclusively until you shutdown the system.
Question: But the system still logins automatically. I don't want auto-login - I want the system to ask for user id and password at every boot.
Answer:
- Open Fatdog Control Panel.
- Choose the "System" tab.
- There is an icon called "Login Manager". Launch it by selecting it and pressing Enter.
- Choose the login mode you want. There are three choices:
- Autologin - this is the default login mode, the system will login automatically at boot. No password is required.
- Graphical - this enables graphical login. The system will display a graphical login screen and ask for user id and password.
- Console - this enables console login. The system will display a console login screen, and ask for user id and password.
In any case, when login is successful, Fatdog will proceed to run the graphical desktop, even when you enable "console login". If you want to say in console mode, please specify "pfix=nox" boot parameter. Note: If graphical login is enabled, "pfix=nox" is ignored and Fatdog will always start the graphical desktop.
Very Important Note: Before you enable any of the login modes, make sure you either remember Fatdog default root password (=woofwoof) or better yet, change it to your own password. Otherwise you will not be able to gain root access ever again without ditching your savefile.
Fatdog permissions model
Permissions
- Device node permissions are controlled by udev. The udev rule file is /etc/udev/rules.d/54-fatdog-permission.rules
- /aufs/devsave and /aufs/devbase are set to root:users, permission is 775/002 in /sbin/system-init
- mount-helper mounts drive with this permission: root:$USER, permission is 770/007
- /var/run/wpa_supplicant access is set to GROUP=users
- The following binaries are setuid: su, gtksu, passwd, Xorg, fusermount and crontab.
Users must be put into the following groups:
- their own group (because Desktop drive icons are mounted with the user's group ID)
- the
users
group audio
, if they are to access sound (youtube etc)video
, if they are to access video devices (camera webcam etc)tty
, if they are to access terminals / command linelp
/lpadmin
, if they are to access/manager printers
Other Notes
- Fatdog uses a privilege escalation program called gtksu.
- gtksu is called whenever an application running in non-privileged mode requires root access.
- gtksu asks for root's password, not for the user's
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from login.html on 2024-12-09.
Miscellaneous known issues
This page documents all the known issues that does not fit into other categories. Some of the issues have workarounds to make it work, some don't.
-
Guvcview crash when attempting to capture video.
Cause: portaudio library (used by guvcview) has incompatibilities with recent version of ALSA libraries included in Fatdog64 800.
Workaround: Before capturing video, click the "Audio Controls" tab and change the "Input Device" from default, or sysdefault to something else. -
ROX crashes often. At the time or writing, have unexplained ROX crash on certain systems using radeon hardware.
Cause: Unknown, possible various reasons.
Workaround: Open terminal, and re-launch ROX, using the following commands (note: case is important, type them as you see them here):killall -9 ROX-Filer rox-desktop
-
Printing problem. My printer requires the vendor driver, and with great difficulty I have installed it. But it still does not print.
Cause: There are a great many reasons why it fails to work.
Workaround: Your best bet is to jump to the Puppy Linux forum and ask there. But before you do that, one of the possible cases is that your printer driver requires ghostscript. So fire up the package manager, and install ghostscript; and try printing again. Most of the time you don't even need to reboot. If that still fails, report the the Puppy Linux forum as above (and keep ghostscript installed, do not uninstall it again). -
Sometimes, on certain systems (and on certain video adapters), after closing VLC (the media player), the VLC icon stays on the panel and cannot be removed, killed. The only way to remove it is by doing a hard-kill on it ("killall -9 vlc"). This is a known issue (see: https://forum.manjaro.org/t/zombie-vlc-processes/51744), but it can be avoided by going into VLC's preference settings and change the Video Output preferences from "Auto" to "Xvideo output (XCB)" or closing VLC using CTRL+q shortcut.
Note: as of version 3.0.13 it has been fixed upstream.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from misc.html on 2024-12-09.
mtrack - Xorg multitouch trackpad driver
Configuration
The following is a minimal working InputClass section for xorg.conf:
Section "InputClass"
MatchIsTouchpad "on"
Identifier "Touchpads"
Driver "mtrack"
EndSection
Configuration options may be defined inside the InputClass section to configure the driver. Available options and their defaults are as follows.
TrackpadDisable - Disables trackpad touch input. A value of 0 will enable the trackpad. A value of 1 will disable tapping and gestures but not movement. A value of 2 will disable all input. A value of 3 will also disable physical buttons. Integer. Default is 0.
Sensitivity - Adjusts the sensitivity (movement speed) of the touchpad. This is a real number greater than or equal to zero. Default is 1. A value of 0 will disable pointer movement.
FingerHigh - Defines the pressure at which a finger is detected as a touch. This is a percentage represented as an integer. Default is 5.
FingerLow - Defines the pressure at which a finger is detected as a release. This is a percentage represented as an integer. Default is 5.
IgnoreThumb - Whether or not to ignore touches that are determined to be thumbs. Boolean value. Defaults to false.
IgnorePalm - Whether or not to ignore touches that are determined to be palms. Boolean value. Defaults to false.
DisableOnThumb - Whether or not to disable the entire trackpad when a thumb is touching. Boolean value. Defaults to false.
DisableOnPalm - Whether or not to disable the entire trackpad when a palm is touching. Boolean value. Defaults to false.
ThumbRatio - The width/length ratio of what's considered a thumb. It is expected that a thumb is longer than it is wide. This tells the driver how much longer. Percentage represented by an integer. Defaults to 70.
ThumbSize - The minimum size of what's considered a thumb. It is expected that a thumb will be larger than other fingers. This is represented as a percentage of the maximum touch value and is dependent on the trackpad hardware. Integer value. Defaults to 25.
PalmSize - The minimum size of what's considered a palm. Palms are expected to be very large on the trackpad. This is represented as a percentage of the maximum touch value and is dependent on the trackpad hardware. Integer value. Defaults to 40.
BottomEdge - The size of an area at the bottom of the trackpad where new touches are ignored (fingers traveling into this area from above will still be tracked). This is represented as a percentage of the total trackpad height. Defaults to 10.
ButtonEnable - Whether or not to enable the physical buttons on or near the trackpad. Boolean value. Defaults to true.
ButtonIntegrated - Whether or not the physical buttons are integrated with the trackpad. If you have a one-piece trackpad like on newer MacBooks, this should be set to true. Button emulation depends on this value being correct. Boolean value. Defaults to true.
ButtonMoveEmulate Whether or not to count the moving finger when emulating button clicks. Useful to disable if you use two hands on trackpad. Boolean value. Defaults to true.
ButtonZonesEnable - Whether or not to enable button zones. If button zones are enabled then the trackpad will be split into one, two, or three vertical zones. Clicking the integrated button in one of these zones will send the button event for ClickFinger1, ClickFinger2, or ClickFinger3. The driver will only add zones for those ClickFinger values that are enabled. So setting ClickFinger1 to 0 and enabling the other two will create two zones, one for ClickFinger2 and one for ClickFinger3. Boolean value. Defaults to false.
ButtonTouchExpire - How long (in ms) to consider a touching finger as part of button emulation. A value of 0 will not expire touches. Integer value. Defaults to 100.
ClickFinger1 - Which button to emulate when one finger is touching the trackpad during a click. Integer value. A value of 0 disables one-touch emulation. Defaults to 3.
ClickFinger2 - Which button to emulate when two fingers are touching the trackpad during a click. Integer value. A value of 0 disabled one-touch emulation. Defaults to 2.
ClickFinger3 - Which button to emulate when three fingers are touching the trackpad during a click. Integer value. A value of 0 disabled one-touch emulation. Defaults to 0.
TapButton1 - Which button to emulate for one-finger tapping. Integer value. A value of 0 disables one-finger tapping. Defaults to 1.
TapButton2 - Which button to emulate for two-finger tapping. Integer value. A value of 0 disables two-finger tapping. Defaults to 3.
TapButton3 - Which button to emulate for three-finger tapping. Integer value. A value of 0 disables three-finger tapping. Defaults to 2.
TapButton4 - Which button to emulate for four-finger tapping. Integer value. A value of 0 disables three-finger tapping. Defaults to 0.
ClickTime - When tapping, how much time to hold down the emulated button. Integer value representing milliseconds. Defaults to 50.
MaxTapTime - The amount of time to wait for a tap to release before counting it as a move. Integer value representing milliseconds. Defaults to 120.
MaxTapMove - How far a touch is allowed to move before counting it is no longer considered a tap. Integer value. Defaults to 400.
GestureClickTime - When a gesture triggers a click, how much time to hold down the emulated button. Integer value representing milliseconds. Defaults to 10.
GestureWaitTime - Touches are allowed to transition from one gesture to another. For example, you may go from scrolling to swiping without releasing your fingers from the pad. This value is the amount of time you must be performing the new gesture before it is triggered. This prevents accidental touches from triggering other gestures. Integer value representing milliseconds. Defaults to 100.
ScrollDistance - For two finger scrolling. How far you must move your fingers before a button click is triggered. Integer value. Defaults to 150.
ScrollUpButton - For two finger scrolling. The button that is triggered by scrolling up. Integer value. A value of 0 disables scrolling up. Defaults to 4.
ScrollDownButton - For two finger scrolling. The button that is triggered by scrolling down. Integer value. A value of 0 disables scrolling down. Defaults to 5.
ScrollLeftButton - For two finger scrolling. The button that is triggered by scrolling left. Integer value. A value of 0 disables scrolling left. Defaults to 6.
ScrollRightButton - For two finger scrolling. The button that is triggered by scrolling right. Integer value. A value of 0 disables scrolling right. Defaults to 7.
SwipeDistance - For three finger swiping. How far you must move your fingers before a button click is triggered. Integer value. Defaults to 700.
SwipeUpButton - For three finger swiping. The button that is triggered by swiping up. Integer value. A value of 0 disables swiping up. Defaults to 8.
SwipeDownButton - For three finger swiping. The button that is triggered by swiping down. Integer value. A value of 0 disables swiping down. Defaults to 9.
SwipeLeftButton - For three finger swiping. The button that is triggered by swiping left. Integer value. A value of 0 disables swiping left. Defaults to 10.
SwipeRightButton - For three finger swiping. The button that is triggered by swiping right. Integer value. A value of 0 disables swiping right. Defaults to 11.
Swipe4Distance - For four finger swiping. How far you must move your fingers before a button click is triggered. Integer value. Defaults to 700.
Swipe4UpButton - For four finger swiping. The button that is triggered by swiping up. Integer value. A value of 0 disables swiping up. Defaults to 8.
Swipe4DownButton - For four finger swiping. The button that is triggered by swiping down. Integer value. A value of 0 disables swiping down. Defaults to 9.
Swipe4LeftButton - For four finger swiping. The button that is triggered by swiping left. Integer value. A value of 0 disables swiping left. Defaults to 10.
Swipe4RightButton - For four finger swiping. The button that is triggered by swiping right. Integer value. A value of 0 disables swiping right. Defaults to 11.
ScaleDistance - For pinch scaling. How far you must move your fingers before a button click is triggered. Integer value. Defaults to 150.
ScaleUpButton - For pinch scaling. The button that is triggered by scaling up. Integer value. A value of 0 disables scaling up. Defaults to 12.
ScaleDownButton - For pinch scaling. The button that is triggered by scaling down. Integer value. A value of 0 disables scaling down. Defaults to 13.
RotateDistance - For two finger rotation. How far you must move your fingers before a button click is triggered. Integer value. Defaults to 150.
RotateLeftButton - For two finger rotation. The button that is triggered by rotating left. Integer value. A value of 0 disables rotation left. Defaults to 14.
RotateRightButton - For two finger rotation. The button that is triggered by rotating right. Integer value. A value of 0 disables rotation right. Defaults to 15.
TapDragEnable - Whether or not to enable tap-to-drag functionality. Boolean value. Defaults to true.
TapDragTime - The tap-to-drag timeout. This is how long the driver will wait after a single tap for a movement event before sending the click. Integer value representing milliseconds. Defaults to 350.
TapDragWait How long after detecting movement to trigger a button down event. During this time pointer movement will be disabled. Increase this value if you find you're draggin when you don't wish it. Integer value representing milliseconds. Defaults to 40.
TapDragDist How far the finger is allowed to move during drag wait time. If the finger moves farther than this distance during the wait time then dragging will be canceled and pointer movement will resume. Integer value. Defaults to 200.
AxisXInvert Whether or not to invert the X axis. Boolean value. Defaults to false.
AxisYInvert Whether or not to invert the Y axis. Boolean value. Defaults to false.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from mtrack.html on 2024-12-09.
Netflix
To use Netflix you will need to install the Google Chrome browser. You'll find Google-Chrome in the menu, and if it's not installed it will ask to download it for you.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from netflix.html on 2024-12-09.
Why does Fatdog not use my savefile?
Usually there are two reasons for that.
- Fatdog cannot find the device on which the savefile is located.
- Fatdog cannot find the savefile itself.
Problem #1 can have three potential causes.
A) The most common one is because the savefile is located in a "slow" device, like USB-connected drive (flash drive, portable harddisk, portable SSD ...). In this case, Fatdog boots so fast that when the device is finally ready for use, Fatdog has already completed its boot process and missed the device altogether.
The solution to this is simple, use the waitdev=n boot parameter to slow down Fatdog and tell it to wait a number of n seconds before continuing. Usually 3 or 5 seconds is enough for most devices. Slower devices may need more.
B) The driver for the device that contains the savefile is not built into the kernel, and you need to load its driver (=module) first; otherwise the kernel cannot see the device and hence it will never see the savefile on it.
The solution to this is to use the coldplug parameter, to force the kernel to load drivers for all supported devices. See a similar problem when your keyboard is not detected at boot time.
C) This is especially true for newer devices using SATA devices combined with Intel Optane technology. Many devices are configured with Intel Optane technology (=basically an on-board DRAM cache for harddisk) to "improve" their performance. In this mode, all access to the devices will have to go through a Storage Management Controller called Intel RST (Rapid Store Technology) and cannot be accessed directly.
Unfortunately Linux doesn't talk Intel RST protocols (except in very few exceptions) and thus cannot recognise the presence of the disk behind it. For Linux to be able to access the disk, you need configure your system to bypass Intel RST/Optane and access the disk directly.
This needs to be done in BIOS. The relevant setting is usually called "SATA Mode" or something like that; and the choices are usually "RST" and "AHCI". You don't want "RST", what you want is "AHCI" (Advanced Host Controller Interface - this is the standard SATA controller bypassing RST/Optane).
On some BIOSes, these settings are hidden and are only shown after pressing certain "secret" keys (different BIOSes have different secret keys).
BUT BEWARE!!! BEFORE YOU DO THIS, PLEASE READ ON!!!
If you have Windows on that disk, you don't want to do this without preparation. Apparently Windows is configured to boot from either RST, or AHCI, but not both. If you change the BIOS settings behind Windows' back, it will not be happy and will FAIL TO BOOT the next time you try to boot it.
So what's the proper way to tell Windows that you're about to change the SATA mode settings? The way is of course version specific, but here is the settings that I know work with Windows 8, 8.1, 10, and 11 (at time of writing, 2022), which may change in the future - so if you are from the future and are reading this, you may want to consult your favourite search engine for the updated details instead).
The steps are:
- Boot to Windows.
- Configure Windows to enter "Safe Mode" on the next boot (there are many ways to do this - using "msconfig", or other ways). Make sure you know how to do this and make sure that the way to enter "safe mode" works. In fact, you may want to test this one to make sure you can enter safe mode.
- After that, you can go and enter BIOS settings, and change the SATA mode. Don't forget to save the BIOS settings after you change that.
- Boot Windows. In "Safe Mode", Windows will be able to boot in either RST mode or in AHCI mode; and it will re-configure itself.
- Then reboot Windows to leave "safe mode" and return back to Normal mode; to confirm that Windows works after the SATA mode change.
You can change between RST and AHCI and vice versa using the same method as above.
Note that (A), (B), (C) are not independent of each other and could (in theory) happen at the same time; so depending on your luck, you may have to try all of the solutions given above.
Problem #2 usually happens if you renamed the savefile and/or put the savefile in a sub-directory, when you created the savefile. It is important to know that by default, Fatdog only scans for savefiles in the top directory of devices, and then only looks for the default filename of the savefile (without the extension).
The default filename is fd64save.ext4, which means that Fatdog will only find savefiles named fd64save.ext4
, fd64save.3fs
, fd64save-old.ext2
, fd64save-backup.sfs
, etc. and only if they are located in the root directory.
It is possible to tell Fatdog to search deeper into sub-directories using the search boot parameter, but this is not recommended as searching is slow. The better way is to tell Fatdog exactly where your savefile is and what its name is, using the savefile boot parameter. Doing this stops Fatdog from doing any search at all, instead it will use the given device and given directory and given filename as its savefile. If this fails, it will simply boot without a savefile.
To make this easier, there is an applet in the Fatdog64 Control Panel > Install, named Savefile Argument Builder, that will walk you through the steps to set up the needed boot parameter correctly.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from no-savefile.html on 2024-12-09.
Crashing, tearing or freezing with Nouveau
Nouveau is a driver for Nvidia graphics cards, created by information gleaned from reverse-engineering. As such, the driver is based on incomplete information or worse. Thus there is a lot of problems with this driver - the newer the cards, the more problem you'd probably get. If you can help it, the recommended solution is to use the proprietary Nvidia graphics driver.
If running proprietary driver is not an option, here are some solutions that you can try, depending on the problem you encounter.
- One of the known outstanding driver is the infamous "multithread bug". Suffice to say that this causes apps that perform heavy concurrent GPU activities to crash randomly. This happens for example with BibleTime which uses QtWebEngine; if you scroll too fast, it would probably crash. May also happens on Chrome / Chromium browser and derivative.
Solution: Force the application to use software rendering instead of the GPU, by exporting the environment variable LIBGL_ALWAYS_SOFTWARE=1 before launching the app. Another environment variable which might be useful to force usage of software rendering for Qt-based software is QT_XCB_FORCE_SOFTWARE_OPENGL=1. This for example works for R Studio.
Please note that this cause the application to slow down.
More Mesa related environment variables here. - Screen tearing when watching video.
Solution: Run a composite screen manager ("compton"). Often this is enough to stop tearing, but if it doesn't, compton comes with additional options to configure that. Lookup the --vsync options - you can try whichever one that works. Also lookup the configuration below.
The file /usr/share/X11/xorg.conf.d/20-nouveau.conf contains some configuration workarounds for the nouveau driver. They are commented by default (that is, they are all prefixed by the hash (#) character), which means they are not active. To activate them, you need to remove the hashes.
The configuration comes in blocks or sections. A section starts with "Section" and ends with "EndSection". You must remove (to activate) or add (to de-activate) hashes for a complete section, not only to a part of them.
The file above contains multiple sections, one for each workaround. Each workaround address a different problem. Please ensure that you only activate one of them. If you enable multiple sections, the result will be unpredictable.
The first workaround (the first section in the file) is to address tearing - activate this section, restart X, then run compton, and see if there is any improvement.
The second workaround (the second section in the file) is to address freeze, locks-up, or screen artifacts. Note that enabling this section can actually cause artifacts to become worse, so you need to give it a try.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from nouveau.html on 2024-12-09.
NVIDIA Optimus
NVIDIA Optimus is a technology that allows an Intel integrated GPU (iGPU) and discrete NVIDIA GPU (dGPU) to be built into and accessed by a laptop. It is also often called "hybrid graphics", and its main feature is that the iGPU controls all aspects of displaying the video output, while the dGPU is mainly used for computing 3D-intensive sceneries but is not able to perform output on its own.
For many years the only way to get these to work is by using only open source driver. You can choose to use only the iGPU using either "i915" or "modesetting" driver, or you can using both using DRI PRIME, but only if the NVIDIA dGPU is driven by the open source nouveau driver. The nouveau driver however has left a lot of things to be desired, the main problem being its lack of features, lack of performance, and its on-going multi-threading bugs.
NVIDIA proprietary driver would offer a much better performance and experience, however, setting it up was extremely complicated and hacky. Two of the most prominent methods is "Bumblebee" and "vga switcheroo".
All this has changed since 2016. NVIDIA finally found a way to integrate their proprietary driver with the same PRIME method that is used by the open source driver. (It was never a technical problem to do that, the problem was legal: how to do it in a way that satisfy both NVIDIA proprietariness and Linux kernel GPL license). However, back then it was still too early because it required a version of Xorg server which wasn't released yet.
Time has passed and things are a lot more stable now. This documentation will show you how to use proprietary NVIDIA driver with PRIME so you can get maximum performance from you NVIDIA card in an Optimus-equipped laptop.
Before we begin, it is important that with this method, the NVIDIA GPU will be active at all times. It is not possible at this time to dynamically switch the dGPU on or off. This may cause some concern for battery life, so it you do, then you'd better stick with the usual iGPU-only method (or the older and more complicated method like Bumblebee).
This note is meant for Fatdog64 801 onwards. It is possible to do this with Fatdog64 800 but the steps needs to be changed because Fatdog64 800 graphic subsystem does not have the necessary hook to make it work, but you can do that yourself.
Basically there are two steps that you need to do.
First, you need to create an Xorg configuration that will configure NVIDIA with PRIME support.
Then, on the second step, you need to add the scripts that will activate this configuration just before the graphic subsystem starts.
Step 0 - get the NVIDIA driver
The very first thing you have to check is to confirm that your laptop supports Optimus. Older laptops with dual graphics may not support this (they use a configuration where both iGPU and dGPU are capable of displaying the output, and they use a "mux" instead). The method listed here can only work on true Optimus-based laptops, not the older mux-based technologies. Laptops from 2015 onwards usually comes with Optimus instead of mux.
The next thing, is obviously you need to obtain a copy of the NVIDIA driver, either as an installable package, or as an SFS package. The final version of Fatdog64 usually ships with suitable NVIDIA driver, however there are so many variants of NVIDIA graphics card that NVIDIA itself has decided to publish different drivers for each card. You need to review NVIDIA website to verify that your card is indeed supported by the version of the driver that you have on hand. If your card is not supported, then you need to obtain the version that does, or you need to make it yourself (or ask someone else in the forum to make it for you).
If you are adventurous enough, here is one way of doing it.
Step 1 - creating Xorg configuration for Optimus
Traditionally the Xorg configuration is created in /etc/X11/xorg.conf.d/20-gpudriver.conf
You will need to create this file yourself, because xorgwizard does not support it. If you have an existing 20-gpudrive.conf file, you may want to back it up before proceeding.
First, you need to know the Bus ID of your NVIDIA card. You can do this by opening a terminal and then running the command:
lspci | egrep "NVIDIA"
Then notice the output you see. For example, in my system it will show:
04:00.0 3D controller: NVIDIA Corporation GK208M [GeForce GT 740M] (rev a1)
The Bus ID is the number 04:00.0. This needs to be translated into 4:0:0, which is what Xorg wants.
Once done, create the file /etc/X11/xorg.conf.d/20-gpudriver.conf with the following contents:
Section "Module"
Load "modesetting"
EndSection
Section "Device"
Identifier "nvidia"
Driver "nvidia"
BusID "PCI:4:0:0"
Option "AllowEmptyInitialConfiguration"
EndSection
Obviously replace the BusID parameter with your own Bus ID that you found previously.
Congratulations, this step is done!
Update Jan 2020: An alternate /etc/X11/xorg.conf.d/20-gpudriver.conf which does not require you to find BusID is the following.
Please use this, or the above - but not both!
Section "OutputClass"
Identifier "intel"
MatchDriver "i915"
Driver "modesetting"
EndSection
Section "OutputClass"
Identifier "nvidia"
MatchDriver "nvidia-drm"
Driver "nvidia"
Option "AllowEmptyInitialConfiguration"
Option "PrimaryGPU" "yes"
EndSection
Step 2 - creating activation scripts
You will now need to create two files, /etc/X11/xsetup and /etc/X11/xsetup-slim. The contents of these two files are going to be identical, so if you know enough about symlinks, you can even create one file only and symlink the other one to it. But in case you don't know what a symlink is, just create two files with the same content.
You need to put the following contents to both files:
#!/bin/dash
xrandr --setprovideroutputsource modesetting NVIDIA-0
xrandr --auto
After you make these two files, make sure that both of them are executable, by running chmod +x /etc/X11/xsetup-slim /etc/X11/xsetup
.
Fatdog64 800 does not support /etc/X11/xsetup so you will need to edit /etc/X11/xinitrc directly and add this to it.
That's it!
Update Jan 2020: Switchable Hybrid Graphics
Apparently it is now possible to use PRIME offload with the proprietary NVIDIA driver if you have the driver from version 435 onwards.
"modesetting" driver is always supported as the integrated GPU driver, "amdgpu" is supported since 450.57, and "intel" is supported since 455.38
Unfortunately, my hardware only supports drivers up to 418, so I am not able to test and confirm this this.
That being said, the process to do this one is quite simple: basically the same as when setting up PRIME configuration for nouveau driver (or any other open-source Xorg drivers).
Step 1:
Create the following /etc/X11/xorg.conf.d/20-gpudriver.conf snippet:
Section "Device"
Identifier "iGPU"
Driver "modesetting"
#BusID "PCI:0:2:0" # maybe necessary
EndSection
Section "Screen"
Identifier "iGPU"
Device "iGPU"
EndSection
Section "Device"
Identifier "dGPU"
Driver "nvidia"
#BusID "PCI:4:0:0" # maybe necessary
Options "AllowEmptyInitialConfiguration"
EndSection
Step 2:
Run the command
xrandr --setprovideroffloadsink nvidia Intel
Step 3:
Then, for program that you want to use the NVIDIA GPU, export DRI_PRIME=1 before lauching it, like the following:
DRI_PRIME=1 glxinfo | grep "OpenGL renderer"
References:
1. NVIDIA PRIME and PRIME synchronization
2. Arch Linux wiki entry for NVIDIA Optimus
3. NVIDIA Driver README: PRIME render offload
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from optimus.html on 2024-12-09.
Primer for Puppy Linux users
So you are a Puppy Linux user who wants to give Fatdog Linux a try. First of all, welcome!
Fatdog is different from Puppy. While many concepts behind both are the same, the commands they each use are different. Some behaviour is also slightly different.
Fatdog was born in 2008→ as a derivative of Puppy Linux. Since then it has grown to become an independent 64-bit Linux distribution that maintains the Puppy spirit but is not Puppy. Your valuable Puppy knowledge is still valued. However, some of your Puppy tricks are not going to work with Fatdog. Some could even be counterproductive. So, read this help document to avoid some common pitfalls for Puppy users, and enjoy your Fatdog ride.
Document Navigation Tip
This primer is written as a single file with lots of hyperlinks to the details. Due to limitations of the document viewer, hyperlinks can only jump to the top of a linked document - the middle or any other location is not possible. Therefore, we use the following formatting convention; a link label that starts with character "▶" spells out the actual heading of the target section/paragraph you are supposed to read. So, after clicking such a link scroll down to the heading that matches the label then start reading.
The "→" character at the end of a link label indicates an external link.
When we refer you to use the Fatdog64 Control Panel click the icon in the desktop panel to start the control panel. Think of Fatdog's Control Panel as Puppy's first-run wizard plus a bunch of other setup and system tools grouped in the following categories: Localisation, Appearance, Display, Sound, Network, Disk, Install, System and Third-party Software Installers (on older Fatdogs, the categories were Localisation, Desktop, Sound, Network, System, Utilities and Updates.)
Getting Started - Possible Issues
Boot
Fatdog's boot options differ from Puppy's→: only pkeys
and pfix=nox
carry over from Puppy to Fatdog. The others either do not apply to Fatdog or have been expanded and renamed to avoid collisions. Some cheatcodes:
pfix=ram
issavefile=none
The Fatdog ISO includes two initrd files, namely, initrd
and initrd-nano
. Initrd embeds the Fatdog system SFS file and is huge. Initrd-nano is much smaller for a reason.
If Fatdog boots slowly on your machine (or it does not boot, or the cursor just blinks), boot with
initrd-nano
and addmergeinitrd1=local:/path/to/initrd
to the boot options ▶mergeinitrd{n}. Here's a grub4dos boot entry template for this case (you need to adjust this template to suit your setup).title Fatdog find --ignore-floppies --set-root /fatdog-directory/vmlinuz kernel /fatdog-directory/vmlinuz mergeinitrd1=local:/fatdog-directory/initrd initrd /fatdog-directory/initrd-nano
Fatdog regards any system with less than 2GB RAM a low-RAM system.
If your low-RAM system does not boot or the kernel panics while booting add
rootfstype=ramfs
to the boot options.
After the kernel boots and before Fatdog kicks in, the system is initialized by Bulldog - in itself a specialized mini-OS that leaves the stage when Fatdog is fully initialized.
If boot fails showing "bulldog login", and
initrd-nano
is used, and boot files are located on USB media, addwaitdev=5
to the boot options.
Installation
Fatdog has many installers! We have BIOS installers, UEFI installers, manual installation steps, contributed scripts on the forum, and so on. Use one of the supported methods to install the system, including for a frugal installation:
- frugal ▶Harddrive
- frugal ▶Hard drive (frugal) installation of Fatdog64 on a computer with UEFI and secure boot
- BIOS installer ▶Guided Installation
- UEFI to a flash drive
- UEFI to a flash drive (alternative method)
- UEFI to a harddisk when UEFI firmware supports multiple boot loaders
- UEFI to a harddisk when UEFI firmware does not support multiple boot loaders→
- UEFI and BIOS for Windows-only: LICK installer
The BIOS and UEFI installers can be started from the Fatdog64 Control Panel's Install tab ("Utilities" tab for older Fatdogs):
- Fatdog64 Installer for BIOS computers
- Fatdog64 UEFI Installer
Note that Fatdog installers do not write an entry in your bootloader's configuration file. We do not because if it fails your whole system will not be bootable. The installer will output a skeleton grub
entry that you can cut and paste to your existing grub configuration file. We also provide the following tools to assist you in constructing the correct boot entry:
- Savefile Argument Builder in Fatdog64 Control Panel Install ("Utilities" in older Fatdogs)
- Grub4dos bootloader config in Fatdog64 Control Panel Install ("Utilities" in older Fatdogs)
Installing Your Own Way
If you prefer to use your Puppy and Linux tricks to install Fatdog read the following FAQs first.
Q: I don't trust installers. I already have a boot loader in my disk/USB stick. I install puppies by opening the ISO and copying the files to a subdirectory and editing menu.lst
or grub.cfg
myself. Can I do that with Fatdog?
A: Sure.
- You only need two files:
vmlinuz
andinitrd
, and optionally a third file,initrd-nano
(explained above) if you experience slow boot issues. - Your usual puppy boot cheatcodes will not work, however, so make sure you read above the common pitfalls when you install in this way.
Q: I want to install Fatdog as a full install.
A: It is not supported but it is possible. See ▶Unsupported installation options from previous Fatdog64 versions.
Savefile and Savedir
Fatdog fully supports savefile and savedir, a.k.a. savefolder. To save to a folder make sure to select that option when you go through the savefile creation dialog at the end of your first session.
So you installed Fatdog by copying the ISO to a USB stick with dd
and now you can't create a savefile on the USB stick (Fatdog complains about write errors)? This happens because the ISO filesystem is a read-only file system so dd
created a read-only partition on the USB stick.
Use
fix-usb.sh
located in the ISO
You created a savefile and no matter what you do now you can't make Fatdog load it - even if you do specify pmedia
, psubdir
, pdev1
, psavemark
, etc. all to no effect?
Fatdog uses different boot codes. Specifying Puppy boot codes is harmless but has no effect.
Use boot option ▶savefile instead to specify the savefile location.
Or use the Savefile Argument Builder in Fatdog64 Control Panel Install ("Utilities" in older Fatdogs).
Or the Fatdog64 Savefile Tool in Fatdog64 Control Panel Install ("System" in older Fatdogs).
Or tell Fatdog to look at directories more deeply with
search=2
(2 directories deep) orsearch=3
. By default Fatdog looks at top directories only (1-level deep).
You did the above but Fatdog still can't find the savefile?
If the savefile is on USB add
waitdev=5
to the boot options.
You did the above but Fatdog still can't find the savefile?
If you renamed the savefile/savedir away from the default name
fd64save.ext4
, then you need to use thesavefile
boot option. See above.But if you renamed the savefile as
fd64save.backup
then Fatdog will find it and ask you to load either your backup or the correct savefile. This happens because Fatdog recognises all the names that start withfd64save.
.Rename your backup as
backup-fd64save.ext4
instead so Fatdog will not recognise it and will load the main savefile.
If none of the above remedies worked, head to the forum and post a help request in the Fatdog sub-forum or support thread.
First-Time Setup
You ask, where is the first-run wizard? How can I setup anything without it?
Use the Fatdog64 Control Panel to configure most aspects of the system. Start the control panel from the Fatdog menu » Setup entry or click the
icon in the desktop panel.
You can't find how to connect to the Internet. You expected to be greeted by a network connection wizard.
Fatdog has Network Tool a unified tool to establish and manage wireless and wired connections. Puppy's tools SNS, Frisbee and Network Setup are not available.
Network Tool is automatically started and its icon can be found in the panel. Click the icon to access it. The icon may look like this - when no connection is active (no network) - or like this
- when a connection is active.
Network Tool is explained here.
GOTCHA Fatdog64 Control Panel Network includes a Network Setup applet. This is not the Network Tool. It is a different tool with a text-based user interface. It is useful in some special cases but we do not discuss it here.
So, click the Network Tool icon and proceed to configure your wireless and/or wired adapter.
If you plug in a wireless adapter (dongle) after the system has booted, you need to restart the connection before that adapter can be used.
Right-click the network tool icon and select "Restart Connection".
If your system has two or more wireless adapters use Wireless Antenna to switch between multiple adapters.
Wireless Antenna can be found in Fatdog64 Control Panel Network.
If you have a Broadcom network adapter and in Puppy Linux you have to use the proprietary "wl" driver to connect, it will be the same in Fatdog Linux.
To enable the "wl" driver start Fatdog64 Control Panel, click the System tab, double-click the "Manage Servers and Services" icon to start the Fatdog64 Service Manager; when the Service Manager window opens, scroll down the list to the service named "BC-wl", click its name to select/highlight its row, and click the "Enable" button, then close the dialog and reboot your system.
Using the System - Possible Issues
SFS Files
If you are looking for:
- the SFS equivalent to
pup_xxx.sfs
- it is namedfd64.sfs
; it is insideinitrd
by default - the
zdrv.sfs
- it is namedkernel-modules.sfs
; it too is insideinitrd
by default adrv
,ydrv
,zdrv
- we do not have them; these names carry no special consideration in Fatdog.
If you try renaming an existing SFS of yours to adrv.sfs
or ydrv.sfs
to get it automatically loaded at boot time, it will be ignored.
Load it with the ▶extrasfs boot option or use System SFS Loader started either from the Fatdog64 Control Panel System tab or from a console/terminal shell by entering the command
load_sfs.sh
.
System SFS Loader is the equivalent of Puppy's SFS Load. Unlike the latter, System SFS Loader does not setup menus, add symbolic links, launch programs automatically, and so on. It just loads/unloads an SFS.
Fatdog supports running an "install script" when an SFS file is loaded. The install script is embedded inside the SFS. Ask on the forum about this feature if you need to use it.
Whether you use boot option extrasfs
or you use the System SFS Loader, Fatdog loads all SFS files above the base SFS details. Fatdog's fd64.sfs
, the base SFS, is always at the bottom.
By contrast, Puppy loads adrv
, ydrv
etc. above pup.sfs
, the base SFS in Puppy, and all other SFS files below pup.sfs
.
Packages
Puppy's Package Manager (PPM) is called Gslapt Package Manager in Fatdog. You can find it in Fatdog64 Control Panel System. It taps into the Fatdog package repository allowing you to download and install/uninstall packages and their dependencies.
In the same tab you will also find the SFS Manager, which can be used to download and load various SFS files, including the DEVX, NLS, kernel sources, and many others.
So you can't find the package you need in Fatdog repositories. What are your options?
You can try converting a
pet
package. This is Puppy's native format. Fatdog's own package format is calledtxz
. To convert a pet package to txz format right-click the pet package icon in ROX-Filer and select "Convert to New Package Format". This will create a txz package alongside the pet package. Give the conversion process enough time to finish then install the package with right-menu click "Install Package". There is no guarantee that the converted package will run on Fatdog. Some dependencies could be missing, etc.You can try converting a
deb
package. This is Debian's/Ubuntu's native format. After downloading the right package right-click "Convert to Fatdog Package Format", the rest is the same as thepet
package case. To convert a pet package to txz format right-click the pet package icon in ROX-Filer and select "Convert to New Package Format". There is no guarantee that the converted package will run on Fatdog. Some dependencies could be missing, etc.
Q: I see that Fatdog uses TXZ packages. Will I have more luck using Slackware packages instead?
A: Maybe. Fatdog uses the same TXZ format as Slackware, but it is not a Slackware derivative. It does not re-use Slackware packages. We build all our packages ourselves (with very minor exceptions). Slackware packages are considered as foreign packages, just like Ubuntu's, etc. Slackware packages may work in Fatdog but again, your mileages may vary.
You can try asking the developers or someone on the forum to compile a package for you.
There is a a long thread→ of contributed Fatdog packages in the old Puppy Forum, and a Fatdog Software sub-forum→ in the new Puppy Forum.
Finally, you could compile a package yourself. This is how the 4000+ packages in the Fatdog repository are created. Fatdog uses its own build system called pkgbuild to create reproducible recipes for each package and compile them. Pkgbuild can be found in
/usr/src/pkgbuild
when the DEVX SFS is loaded.
Spot
Fatdog is a true multi-user system, so you can add different user accounts from the Fatdog64 Control Panel. By default Fatdog starts as user root
, exactly like Puppy. User spot
is the other default user account. Spot is a "restricted" user, who can't change root's or the system's files. By default Fatdog runs most network applications - notably Internet browsers - as user spot. This provides some level of protection from malware but at a small cost. Since spot can't change root's files, a browser running as spot can't download directly into root's folder.
We recommend running network applications as user spot, but provide the flexibility to change them to user root as explained in the above linked page.
To simplify dealing with up/downloads when the browser runs as spot, we use spot's home folder as a sort of in/out basket. Drag a file in/out of that folder from/to the browser poses no access restrictions.
To quickly open spot's home folder press the Windows
key, keep it down, and press/release the g
key.
Touchpad
Some Puppies have the tapping for the touch pad enabled by default, Fatdog64 does not.
Go to the Fatdog64 Control Panel Display tab ("Desktop" tab on older Fatdogs) and double-click Adjust Touch Pad then enable the tap-to-click check box. touchpad
20200909C
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from p4p-index.html on 2024-12-09.
Panel icons
A - This is the menu icon.
B - This is desktop number 1.
C - This is desktop number 2.
D - This opens the default internet browser.
E - This opens a terminal window.
F - This opens the ROX file browser.
G - This is the Control Panel, system settings and utilities are found here.
H - This minimizes all windows.
I - This is Glipper, use this when you cut and paste.
J - This displays battery charge.
K - This displays the amount of free space in your save-file / save-folder or RAM disk if booting for the first time.
L - This is Sven the multimedia daemon. Right click to set your preferences.
M - This is Network Tool, the network manager, historically referred to as wpa_gui. Use this to connect to a network. See Networking for more information.
N - These are the bluetooth controls (also look in the control panel).
O - This controls the main volume level, click on "Mixer" to adjust all levels.
P - This displays CPU load.
Q - This is the clock. Left click on it to show / hide the calendar. Right click on it and then click "Configure" and then "Set date and time" to change date and time. For timezone setting look in the Control Panel.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from panel-icons.html on 2024-12-09.
How to make packages for Fatdog64
Making a package for Fatdog64 consists of 3 (three) steps.
- Building the binaries.
- Collecting the files that will (or would) be installed.
- Combining all of these files into a package file.
Step 1 - Building the binaries
You first need to download the source code that you want to compile, and read any README or INSTALL text files for information on how to compile.
Typically it looks like this for autoconf-based build system:
./configure --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc --localstatedir=/var
make
Or for cmake build system:
mkdir build && cd build
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DLIBDIR=/usr/lib64
make
In both systems, the usual next step, usually mentioned in a package's README is "make install
" (or "sudo make install
") but don't do it yet. Doing this will immediately install the application to your system, but does not package it in a format that you can re-use later (e.g. installing it in another machine).
Instead, what you want is to collect the files that would be installed, and turn these loose files into a package. This is step 2.
Step 2 - Collecting install files
There are a few ways of doing so.
- Traditional autoconf method, using make install DESTDIR=/tmp/xxx
- Traditional Puppy method, using new2dir
- Using paco -lp and paco2pkg
- Using Fatdog sandbox
- Using Fatdog native pkgbuild system
The FAQ will only discuss the first three; the last two will be touched upon briefly. Since there are so many options and it can be confusing, this is explained last. For now, assuming you have collected the files, it is a simple matter to turn them into a package in step 3.
Step 3 - Making a package out of loose files
Let's say you have already collected all the files, with the correct hierachy, in a directory called "/tmp/xxx" (using one of the methods in step 2). That is, your new application "abiword" binary has been placed in "/tmp/xxx/usr/bin/abiword", its desktop menu file is located in "/tmp/xxx/usr/share/applications/abiword.desktop", its icon in "/tmp/xxx/usr/share/pixmaps/abiword.png", etc.
Then to make the package, all you need to do is run makepkg like this:
cd /tmp/xxx
makepkg -c n -l n /path/to/where/you/want/to/keep/the/package-version-x86_64-num.txz
The filename package-version-x86_64-1.txz is a standard that you need to follow; it comprises of 4 components all separated by the "-" (dash, minus) character.
- "package" can be anything, e.g. "abiword". This is the name of the package. Package name can have "-" in it as long as the rest of the components are given correctly.
- "version" must be something that starts with a number, e.g. "3.0.0" or "2.8.6patched" or "2014.09git". This identifies the version of the package.
- "x86_64" is the architecture name. For Fatdog64 it must be
x86_64
. For FatdogArm, it would be armhf for hardfloat binaries, armel for softfloat binaries, and armeb for big-endian ARM systems (rare). For 32-bit binaries, you have the choice of i386, i486, i586, i686, or x86 depending which flavour of x86 you compiled the package for.
If the package is non-architecture specific (e.g. shell or Perl scripts which will work equally well in 32-bit/64-bit/ARM etc), use "noarch". - num is the build number. It is usually "1", but it can be "2", or "700", or "PET", or anything really. It identifies the build number. An identical package can recur with multiple build numbers (because the first build is buggy, the second build you forgot to include a desktop file, the 3rd build is good, the 4th build is special because it is only for Chromebooks, etc). Fatdog64 official packages usually have the build number as "1" but it can be updated as time passes.
An example of a valid package name is "abiword-3.0.0-x86_64-1.txz." Another valid example is: "abiword-docs-3.0.0-noarch-1.txz".
You can actually use "tbz" and "tgz" too (the package will be compressed with bzip2 and gzip respectively, instead of "xz"), but there is little incentive to do so in modern days.
That's it! After packaging is completed, you have your package.
If you want to get a little fancy, you can add "descriptions" to your package. You can also add an install and uninstall script (like "pinstall.sh" / "puninstall.sh" for those familiar with PET packages) - both scripts are optional. An install script can be added as follows, do this before you run makepkg.
cd /tmp/xxx
mkdir install
slackdesc "package" "version" "short summary" "long description" "source URL" | tee install/slack-desc
cp /your/prepared/install-script install/doinst.sh
cp /your/prepared/un-install-script install/slack-uninstall.sh
makepkg -c n -l n /path/to/where/you/want/to/keep/the/package-version-x86_64-num.txz
1. Note for slackdesc: "package" must match the package name you used in makepkg, exactly (sans the other 3 components); "version" must match the version you use in makepkg exactly. All other components are optional.
2. Note for doinst.sh: this script is identical to pinstall.sh; if you have an existing pinstall.sh you can use it right away. Note that this script is run in the installation directory (which isn't always root "/"), so you must always refer to directories by their relative names, e.g. use "./usr/share/applications" (note the dot at the beginning) instead of "/usr/share/applications". This is actually required for pinstall.sh scripts in PET packages too.
3. Note for uninstall script: Standard Slackware packages don't support an uninstall script, but Fatdog packages do. The name of the script is slack-uninstall.sh, located in the same location as doinst.sh. It has the same requirements as doinst.sh above - you must refer to directories by their relative names (puninstall.sh in PET packages has the same stipulation too).
4. Note for smaller packages: It is a good idea to strip all of the binaries and any libraries to make them smaller. Sometimes this is already done by the build system, but most of the time it isn't. To do this, you cd to the directory that contains any binaries or libraries (*.so files) and run:
strip --strip-unneeded *
before you run makepkg. Afterwards, you can also delete anything else that is not needed (e.g. locale directories if you're going for English-only package, templates, documentations, etc). makepkg does not automatically create DEV or NLS package like dir2pet, it will just make a tarball of the entire contents of the directory it is in.
Step 2 Revisited - Collecting install files
To recap, there are a few ways of doing so:
- Traditional autoconf method, using make install DESTDIR=/tmp/xxx
- Traditional Puppy method, using new2dir
- Using paco -lp and paco2pkg
- Using Fatdog sandbox
- Using Fatdog native pkgbuild system
Method 1 - Using "make install
" with DESTDIR
This is a method which is usually supported by many applications that are configured using GNU autoconf and cmake build system.
Instead of running "make install
", you run "make install
DESTDIR=/tmp/xxx
".
Adding "DESTDIR=/tmp/xxx
" to "make install
" simply tells the build system to install the files with their correct hierachy to "/tmp/xxx
" location instead of the usual root "/
" location. Thus, for example, a file that will usually be installed to "/usr/bin/myprogram"
will instead be installed to "/tmp/xxx
/usr/bin/myprogram"
.
The end result - all the program installed files will be collected under "/tmp/xxx
".
When "make install DESTDIR=/tmp/xxx
" finishes you're ready for step 3 above.
This is a popular method to collect installed files. The downside of this approach is that not all packages supports the DESTDIR method, and some that claim they do sometimes behave weirdly if you install them using DESTDIR.
Method 2 - Using new2dir
This is the traditional Puppy method to collect files to be installed: use new2dir make install
instead of just "make install
". Once you have run this, two things will happen:
- The program will be installed as usual
- The files that are installed are also copied to a directory usually called ../<app name>-x86_64.
After new2dir has finished, you can cd to that <appname>-x86_64 directory and continue with step 3.
This method has the benefit that it will work with a larger number of applications; and it will not have the oddities that DESTDIR sometimes does. But this method is not fool-proof - some installed files may not be captured correctly by new2dir. This is rare, but usually happens for e.g. python programs.
This method has the disadvantage that the program you are trying to package is actually installed to your system.
Method 3 - Using paco -lp
and paco2pkg
paco is program to perform installation file capture, just like new2dir. (The website for paco used to be here, but unfortunately when the author of paco deprecated paco in favour of a new program called "porg" that is identical in purpose to paco, he also took down the website. With very minor changes, however, information for porg is also applicable for paco).
To use paco, you run "paco -lp package-version -- make install" instead of just "make install".
After paco finishes, the package will be installed as normal but paco will keep a record of what files have been installed. The next step is to ensure you have a directory called "/archive/repo" as the output of the package will be stored there; then you just need to run "paco2pkg package-version" which will create the "/archive/repo/package-version-x86_64-1paco.txz" - ready for use.
Using paco has the benefit that it works with even more packages (even for programs where new2dir traditionally fails), and even though you still have to install the program when you try to package it, paco has the ability to uninstall the package that it installed during packaging method (use "paco -r package-version" command). Of course, uninstall this after you create the package, not before.
paco is a very versatile tool. It has a lot more features that what can be covered here. For example, it can create pacoballs (using the pacoball command) which is a complete package on its own; these pacoballs can be installed or uninstalled on demand. Paco can actually function as a full-fledged package manager by itself.
Note: Using this method, it isn't obvious how you can add the equivalent of slack-desc and doinst.sh script, as the packaging is done by paco2pkg instead of makepkg; but it can be done. Run "paco2pkg --help" for more details. This method is meant for batch creation of packages; where the doinst.sh and slack-desc files for multiple packages are pre-created in advance.
Method 4 overview - Using Fatdog sandbox
The idea is to build the packages inside Fatdog sandbox, and then install as usual (with "make install"). All the installed files (new or modified files) will be kept in the sandbox, after which you can use "sb2dir.sh" to extract them to the /tmp directory. From within this extraction directory, you can run "makepkg" as usual. Obviously you need to remove unneeded files first (the source tarball, etc).
When you're done, just leave the sandbox - and your base system is unchanged.
Method 5 overview - Using the Fatdog native pkgbuild system
Fatdog's pkgbuild system expands on the idea of Fatdog sandbox above, to download, compile, build and assemble packages, but doing it automatically. This is called "native" as all Fatdog base packages are built using this system.
The system is "recipe" driven, you need to give the pkgbuild system a "recipe" - a set of instructions for how to build the package. A "recipe" is actually a shell script containing the commands that you usually use to build a package, e.g. the "configure" and "make" and "make install"; it also must include commands for where to download the source tarball.
The build system will execute the recipe (building the package as it goes), and automatically collect the files, strip them, and package the result into a nice Fatdog package at the end of it. Package description (slack-desc) and install script (doinst.sh) are packaged together if they are defined inside the recipe. As a bonus, the recipe itself is also included in the resulting package so you always know how to rebuild the package again, in exactly the same manner, in the future.
The Fatdog pkgbuild system is located in /usr/src/pkgbuild (when Fatdog devx is loaded). It comes with samples. Put your own recipe script (named "recipe") in a subfolder you create in the "pkg" directory (e.g. "/usr/src/pkgbuild/pkg/abiword"), then run the build-pkg.sh command, as follows:
cd /usr/src/pkgbuild
build-pkg.sh name-of-created-subfolder
E.g."build-pkg.sh abiword".
The finished package will be stored in "output" directory. "src" directory will contain the downloaded source tarball.
The "source" directory contains the recipes used to create installed Fatdog packages.
Final Note: Fatdog64 600 and earlier use PET package format, the same format used by Puppy Linux. To make pet packages, the steps are all the same, except that instead of "makepkg" you use "dir2pet". Fatdog64 700 switches to TXZ packages, and dir2pet is no longer supported, although you can still convert existing PET packages to TXZ using "pet2txz" command.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from pet-package.html on 2024-12-09.
Printing and printers
Overview
Fatdog64 comes with CUPS printing system which is mostly standard nowadays. Internally, the printing workflow looks as the following:
There are four components:
- Queue: this is the (logical) place that holds the print job. CUPS will print whatever documents (print jobs) in here, unless they are being "suspended" (e.g. due to printer error).
- Filters: these are programs that transform one data format to another, from the one that got submitted by frontends, to the one that can be understood by the backend. There can be many of these filters, and different documents may be processed by different filters, but the most important one is the last one, the one just before the backend.
- Backend: this is the program that actually take the data from the filter and send it to the printer using various interfaces (USB, serial, parallel, network, bluetooth, etc).
- Frontends: these are the programs and libraries that can put documents into the queue for printing. The frontend can be command line (e.g. lp, lpr), or GUI (e.g. gtklp), or included in programs capable of printing (e.g. libreoffice, evince PDF viewer, etc).
Each printer will have its own workflow, although the frontends are usually shared.
CUPS provides many of these components. Some of these components are generic and work for all printers, some are not. The device-dependent components are what is normally known as "printer drivers". In general, printer drivers consist of:
- The final filter (the one that will pre-process the document before it gets sent to the backend), and
- The backend itself.
CUPS comes with many drivers for common printers; and it also has generic drivers that can work for many printers. If you cannot get a vendor-specific driver to work, it is worthwhile to try these CUPS-provided generic drivers first.
Generic drivers
CUPS provides 4 (four) kinds of generic drivers that can work with most printers. If your printers qualify with one of these, it is guaranteed that you can print, even though it may not be to your satisfaction (in terms of crispiness (a.k.a print density), colours matching, etc; but you can certainly print. So when shopping for a new printer, it is worthwhile to look for one of them.
- Postscript printers. Originally developed by Adobe, Postscript is a generic type-setting language. It was (and is) commonly used on high-end printers due to high-resource requirements for its implementation. It used to be the lingua-franca for laser printers, and even today most high-end printers still come with Postscript support.
- PCL printers. Originally developed HP, PCL was an alternative (competitor) to Postscript. It is simpler and requires less resources to implement, so today it is mostly found in mid-range printers, both laser printers and inkjets.
- PDF printers. Originally developed by Adobe, PDF is descended from Postscript, and was optimised for printing. It was simpler and easier to implement, yet more versatile, incorporating years of experience that Adobe gained from Postscropt. Many modern high-end printers now support PDF as their printer language, allowing direct printing of PDF files.
- IPP Everywhere printers. This is also known as the "AirPrint" printers, or "driverless" printers because they don't need any vendor-specific drivers (in reality, of course, it only means that the drivers are already included by CUPS). They are available on a lot more models including lower-end model because these are raster printers; most of the processing is done by the host (computer).
When you add a new printer in the CUPS web interface, and you were asked for the "make" (or model of the printer), you can choose "Generic" and from there choose the most appropriate generic drivers. Modern printers sometimes supports more than one: in this case, test printing with a few drivers and decide on which one delivers the best result.
Note: Postscript printers require Ghostscript to be installed. Ghostscript is available in Fatdog but is not installed by default, you need to install it from the repository. Please see note 6 below.
Model-specific drivers
Obviously not all printers can be supported by the generic drivers, and even those that do, may provide better performance (=better control of printing parameters e.g. dpi, duplexing control, etc). CUPS comes with a set of model-specific drivers. More model-specific drivers are available from gutenprint package (which is installed by default), and from foomatic and foo2zjs packages (which are available in the repo).
They should be your next attempt if your printer does not support generic drivers or if the generic drivers perform poorly. Many brands are supported: HP, Epson, Canon, etc, generally if the printers have been on the market for several years, it may be supported. Furthermore, even if you cannot find the exact model of your printer, often a "close enough" model will make it print.
Manufacturer-provided drivers
The last attempt would be to attempt manufacturer-provided drivers. This should be the last attempt if everything else fails; or if you need the most precise control from your printers.
Most manufacturer only provides the final "filter" as the drivers, although more complex printers requires both filter and backend.
You can download these drivers from the manufacturer website, often after specifying your model. If the manufacturer provides a choice, here are the list of packaging that you should choose, in order of preference:
- Slackware package
- Generic tarball (often ends with .tar.gz extension)
- Debian/Ubuntu packages (ends with .deb)
- Anything else
If possible, find drivers for 64-bit Linux. If they only have 32-bit drivers, that's ok but remember you need to use 32-bit compatibility SFS each time you need to print.
Also, note that many manufacturer packages assumes that Ghostscript is installed. So the first thing you do when you need to install 3rd party driver, is to install Ghostscript from Fatdog repository. Please see note 6 below.
The method to install the drivers vary, depending on how the packages are supported. It is way too diverse to explain here. It is best that you raise the issue on the forum and ask for people explain how to install the drivers; or even better, ask them to package a given driver into Fatdog-compatible packaging.
Network printers
Setting up network printers is very similar to setting up a wired printer. The difficult part is to find the "device URI" in order to print it. In order to setup one, the network printer must have been connected into the network - this is very printer specific and this document simply assumes that you have done this (if not, please consult the user's manual for your printer).
There are two steps to configure network printer:
- To find ("discover") the printer on the network.
- To configure the "device URI" in order actually print to that printer using the network protocol that the printer supports.
Printer discovery
Printer discover enables CUPS to find the printers in the network, and hopefully, configure it automatically (including the device URI). If your printer has full discovery support that Fatdog supports, then step (1) and (2) above is very easy and is done automatically. You just need to install the printer driver.
Most modern printers (especially branded as "AirPrint" capable) use ZeroConf or DNS-SD discovery protocol. Fatdog fully supports this and it will be able to find the printers and configure automatically. Some printers support more than one network protocol, so you may see multiple entries for the same printer. You can pick and choose, try and use the one that gives you the most consistent printing experience.
Older printers may support SNMP discovery. This is also supported by Fatdog CUPS, so you should be able to find the printer and the device URI should be pre-filled, but you may still need to edit it (replace a logical name with an IP address) to make it successfully print.
Others may only support LLMNR protocol (Microsoft clone of ZeroConf, not widely used outside Microsoft products); this isn't supported by Fatdog.
If Fatdog cannot find the printer, all is not lost. First thing, you need to know the IP address of the printer (it is best if the printer can be configured to use a fixed IP address in this case), and secondly, you need to know the network protocol supported by the printer, and finally the device URI.
Device URI and Network Protocol
In order to be able to print to the network printer, CUPS needs to know where the printer is (its IP address) and what network protocol that it supports. If the printer supports DNS-SD, this is not an issue because DNS-SD can be used to translate a logical name to an IP address; but otherwise you really need to know the IP address. You can find this out from the printer itself, if you cannot, then, you need to perform some sort of "port scanning" to find it, unfortunately.
As for the network protocols, there are generally 3 (three) network printing protocols. CUPS supports all of them.
- HP JetDirect protocol. Also known as the "socket" protocol, this was originally created by HP for its line of network printers. It is considered to be the simplest, fastest, and generally most reliable. Due to its simplicity it has been reverse-engineered and is now used by many other printers and print servers. Virtually every network printer will support this.
All that you need to know in order to print to a printer that uses this protocol is its IP address, and its printing port. Most printers uses 9100 as the port number as this was originally the port number used by HP printers. - LPR/LPD protocol. This is original network printing protocol. It is simpler and less featureful than JetDirect protocol; however it is also widely available.
In order to be able to print to this printer, you need to know 3 (three) things: its IP address, its printing port, and its queue name. The most commonly used printing port is 515. The queue name, unfortunately, differ from printer to printer and you really need to find out by reading its documentation (if the printer isn't discoverable). - IPP protocol. (IPP stands for Internet Printing Protocol). This is the newest and most feature-ful printing protocol. It is the "newest" but not exactly new, OS such as Windows XP from 2003 already support this protocol. If a printer supports it, this is the protocol to use.
In order to print to this printer, you need to know its URL (or device URI). The protocol is called either "ipp://" or "http://" (they're equivalent), and may or many not implement SSL. You also need to know the printer's IP address, port number, and its resource. The commonly used port number is 631; however for the resource name, you need to find it out from the printer documentation.
If you have a choice, IPP would be the best to use. Otherwise, you can use either JetDirect or LPR/LPD protocol with preference given to JetDirect. Once you know all the information needed, you can form the "device URI" when you add the printer to CUPS. The syntax of these URIs are given in CUPS "add printer" page.
Sharing printers and using shared printers
Sharing CUPS printer and/or printing to a remote shared CUPS printer is very similar to printing to network printer as above. But firstly, before we can print to a shared printer, we must share the printer first.
How to share a printer in CUPS for others to use
- Firstly, you need to configure CUPS to enable sharing. This is commonly found in the CUPS Administration page.
- Secondly, you need to enable individual printer for sharing. This is done on per-printer basis. First, go to "Manage Printers" page, find the printer that you want to share, then choose "Modify Printer" menu and share it.
How to discover CUPS shared printer
- In Fatdog, open Control Panel --> System --> Manage Server and Services.
- Then find "cups-browsed" service. Then "Start" it. If you want to make a permanent sharing, sort of, you can click "Enable" too which will make the service automatically restarted at next boot.
That's all you need to do! If you now go to CUPS' "Printers" page, you should now be seeing printers that are shared from other CUPS servers. Note: for this automatically shared printers, if you turn off the "cups-browsed" service, they will disappear if you turn off ("stop") the service. If you want something which is more permanent, you need to configure it manually, as below.
How to configure CUPS printer manually
Some CUPS does not properly advertise their shared printers. There are many reasons for this. You have shared the printer, but CUPS still cannot find it. In this case, we can set it up manually.
You may also setup a permanent sharing, because as noted above "cups-browsed" shared printers will automatically disappear when you turn off the service.
- Visit the CUPS server that owns the printer. Check it's "Printers" page and get the "queue name" of the printer that you want to use. While you're at it, make sure that that printer is shared, and the CUPS has enabled for sharing. Oh, and take note of it's IP address too.
- Then launch the CUPS webpage where you're going to use the shared printer. Go to "Administration" page, choose "IPP" protocol. You will be asked to present the "device URI". The device URI will look like this:
ipp://ip-address:631/printers/queue-name
where the ip-address is the IP address you get from (1), and the queue-name is the queue-name you get from (1) too. - When asked for the make/model, choose "Generic" and then choose "IPP Everywhere".
That's it!
Other notes and loose ends
1. Some printers are "IPP Everywhere" printers but they only have USB interface (this is rare, I have yet to find one, but theoretically possible). You can use these printers by using "ippusbxd" package. Please read the document that comes with that package in order to set it up.
2. Some printers are multi function devices (MFP), which not only can print, but also can scan (and sometimes fax too). This page only covers the printing part of the device. The scanning part, unfortunately, is much less standardised and will most likely require proprietary drivers to make it work.
3. Printers advertised as "AirPrint" or being advertised as "mobile printers" (as in, you can use your mobile phone / smartphone to print to it directly) is most likely a "IPP Everywhere" / "driverless" printer.
4. Printing in Fatdog64 used to be supported by forum member rcrsn51, in Puppy Linux forum thread here: http://oldforum.puppylinux.com/viewtopic.php?p=628636#628636. In May 2017, he has decided to retire his support. We sincerely thank him for all the help he has provided for many years prior. Although the main post of that thread is now gone, the thread may still contain useful information and helpful advices that can still be applied (suitably modified) on modern Fatdog, so it is still worth checking out when you have problems.
You can also still view an older copy of the thread, before its deletion, here: https://web.archive.org/web/20150905152737/murga-linux.com/puppy/viewtopic.php?t=78464
5. This document is meant for Fatdog 801 and newer. Older Fatdog may support some of the features, but for example "cups-browsed" did not exist so you will need to use the "manual method" to do it.
6. Note from Fatdog 810 onwards.
On Fatdogs without built-in ghostscript, the default CUPS rasterisation is pdftoraster, because this is the only engine available. After you have installed ghostscript, you have another engine, called gstoraster. Some people claims that gstoraster renders better than pdftoraster (and vice versa). You can see this for yourself. If you want to change the engine from pdftoraster to gstoraster, please edit /usr/share/cups/mime/cupsfilters-poppler.convs and change the line that says
application/vnd.cups-pdf application/vnd.cups-raster 98 pdftoraster
to
application/vnd.cups-pdf application/vnd.cups-raster 100 pdftoraster
Note 1: If the value is 100, gstoraster is used, if it is 98, then pdftoraster will be used. If you don't like gstoraster, you can always change it back.
Note 2: Important: You can only use gstoraster after you install ghostscript, otherwise you will end up with printing failure.
On Fatdogs with included ghostscript, the default rasterisation engine is already set to gstoraster. You can change it to use pdftoraster if you wish, following the same step above.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from printing.html on 2024-12-09.
Bad 2D performance, tearing or freezing with Radeon
The file /usr/share/X11/xorg.conf.d/20-radeon.conf contains some configuration workarounds for the radeon driver. They are commented by default (that is, they are all prefixed by the hash (#) character), which means they are not active. To activate them, you need to remove the hashes.
The configuration comes in blocks or sections. A section starts with "Section" and ends with "EndSection". You must remove (to activate) or add (to de-activate) hashes for a complete section, not only to a part of them.
The file above contains multiple sections, one for each workaround. Each workaround address a different problem. Please ensure that you only activate one of them. If you enable multiple sections, the result will be unpredictable.
The first workaround (the first section in the file) is to address tearing or overall poor 2D performance.
The second workaround (the second section in the file) is to address freeze or locks-up when powering down the machine, or when launching Xlock screen locking, or small 2D graphics glitches.
The third one only attempts to prevent screen tearing when during video playback, when running a composite manager (e.g. compton). Note that workaround #1 include tearing prevention also.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from radeon.html on 2024-12-09.
Fatdog64 Sandbox Environment
Introduction
Fatdog (since version 520) comes with a sandbox tool built-in. The tool is activated through terminal - there is no menu or GUI for this. The commands are:
- sandbox.sh
- rw-sandbox.sh
- sb2dir.sh
sandbox.sh and rw-sandbox.sh are identical, except that sandbox.sh stores the content of the sandbox session in tmpfs (therefore it's not persistent), while rw-sandbox.sh stores the session in a file. An analogy with running Fatdog would be:
- running sandbox.sh is analog to running with savefile=none
- running rw-sandbox.sh is analog to running with a savefile.
In the following description, all references to sandbox.sh also means rw-sandbox.sh except when noted.
Intended Purposes
The sandbox is meant for:
- Testing foreign packages
- Creating new packages
- Isolate well-behaved applications
1. Testing Foreign Packages
When a new package is installed, it will install its files into the system. Other than package integrity, there is no checks done on what files are inside. If a package modifies system files and libraries (overwriting libraries with bad ones, or deleting necessary system files), the system could stop working (which could be "fixed" by rebooting without savefile and then create a new savefile, but it is still an unnecessary hassle).
Sandbox is the solution to this. The sandbox creates an environment which is similar to the currently running system, but is safely separated from it. Any changes made to the files inside the sandbox (with few exceptions) will not affect anything outside. One can thus start the sandbox, install any number of packages in it, test them, and when done, leave the sandbox - and everything will be restored.
2. Creating New Package
Most packages can be created by using the standard recipe of:
- configure & build the packages
- install the package, capturing the output on the way so that we can package it later.
The usual steps for packages that uses autoconf are:
- extract the source tarball
- ./configure && make && make DESTDIR=/tmp/pkgname install
- dir2pet /tmp/pkgname
Or
- extract the source tarball
- ./configure && make
- new2dir make install
But this has obvious limitations. For one, it only works with packages that uses autoconf as its build system. Secondly, not all packages act kindly with new2dir - they don't always work. For example, python packages can't be captured this way. Other build systems (cmake, jam, etc) also can't be captured this way.
Sandbox provides a solution to this. A package can be configured, built and installed in the sandbox - without any use of Puppy's specific tools. Once this is done and the package is confirmed to work, all that is left to do is to scrape the files that were changed and installed - and the sandbox makes this super easy. In fact, the third command in the sandbox package (sb2dir.sh - sandbox-to-directory) will do this automatically. Supply it with a directory name and it will look for all the changed files from the sandbox, copy them over to "/tmp/dir-name-that-you-give". All you need to do afterwards is to check the files inside, once you are happy with it, just run makepkg inside on that directory.
3. Isolate well-behaved applications
Application installation usually places files in many places in the filesystem. After the application is run, it also creates configuration and other files, in a way. If you need to install many applications, but they are only used very rarely, it is easy to grow your savefile to become very large and cluttered with all these applications. Some applications offer "portable" versions and can be installed in one directory, but many are not. Is there a way around this?
Or you may want to install an application but run it with different or multiple configurations, which isn't supported natively. You can switch config files back and forth to do this, but is there an easier way?
Of course: use the sandbox! Starting from version 622 onwards, multiple sandboxes can be run at the same time, making it an ideal way to isolate applications. Create an rw-sandbox for every application you want to isolate. Install the application from within the sandbox, and then run it. When you're done, close the sandbox. This way, you can have a rw-sandbox for each application. You can even have multiple sandboxes for the same application, each with different configuration. Need to configure and keep different versions of the same application? No problem too!
Note: This only works for "well-behaved" application - that is application which do not pose security risk to your system. The sandbox is not a security tool. It is still possible for malicious apps to create havoc on the system. It is possible for malicious application to "escape" from the sandbox. If you need to secure yourself from these, you need a stronger sandboxing: consider using Linux Container sandbox or User Mode Linux or other virtualisation solutions such as Qemu (with/without KVM), VirtualBox, or others.
Usage
Starting the sandbox
Start the sandbox by running sandbox.sh. A dialog box will be shown, showing all the currently mounted SFS (this includes Fatdog's save file, Fatdog's main sfs, and any other SFS currently mounted). One can choose which SFS will be loaded into the sandbox. If the SFS is not chosen, they won't be loaded and won't be visible. For example, for testing packages in pristine conditions, one can choose not to load the currently used save-file. The sandbox environment will then be almost identical to running Fatdog with savefile=none.
rw-sandbox.sh behaves identically - except that, first, it will ask the user where to store the permanent session file (="the savefile"). You can also pass the path to the "savefile" as the first parameter to rw-sandbox.
From Fatdog64 720 onwards, you can pass the command to be executed in sandbox by as an argument to sandbox.sh or rw-sandbox.sh.
Inside the sandbox
Once inside the sandbox, one can do almost everything that one can do in the system itself. Running terminal commands obviously work. Running GUI programs will work.
In addition, the sandbox comes with a full desktop emulation environment - this can be started by typing xwin inside sandbox. A nested Xorg server (Xephyr), complete with its own instance of openbox, rox and lxpanel will launch.
Note: if one wishes to run "rox" without the full desktop emulation environment, one has to use "-n" parameter to start it, like this: rox -n.
Leaving the sandbox
Once done, type "exit" inside the terminal that contains the sandbox. If one uses the full desktop emulation, close the window that contains the emulated Xorg or choose Exit to Terminal or Restart X server from inside the sandbox's desktop.
Advanced notes
The sandbox is implemented using stackable union file system, aufs, just like the main Fatdog. All the files modified in sandbox is visible in /mnt/sb/sandbox (this mountpoint only exist when sandbox is running, it is also the sandbox-path you need to pass to sb2dir.sh). The sandbox's fake root, i.e. the top of the union seen from within the sandbox itself is mounted as /mnt/sb/fakeroot. If you run multiple sandboxes, the sandbox and the fakeroot will be /mnt/sb/sandbox.XXXXXX and /mnt/sb/fakeroot.XXXXXXX respectively, where XXXXXXX is a random string.
Important Note: Sandbox is not a security tool
The sandbox is not a security tool, and is never intended to be. Some of the files changed in the sandbox do propagate to the system outside. For example, /tmp directory from the system is mapped to the sandbox. Any changes made to /tmp will be visible and have direct effect to the system outside.
The same can be said for /proc and /sys - thus all process currently running in the system can be seen within the sandbox. Running "wmreboot" from within the sandbox will shutdown the entire system, not just the sandbox (this is no longer true in version 622 onwards, but only because "wmreboot" script is overwritten. Running "reboot" will still reboot the entire system).
It is quite easy to "escape" from the sandbox, this document from 2002 shows how and it still works even today because that is what UNIX standard says (a somewhat cleare explanation is here).
Improvements on Fatdog64 622 over previous versions:
- In older versions, sb2dir.sh was previously known as pet4sand.sh and it will automatically run dir2pet for you. This was annoying because most of the time you still want to check whether the files are all right before running dir2pet/makepkg. Thus the changes. Also, sb2dir.sh is now capable of extracting files from multiple sandbox by passing the sandbox-path as the second parameter.
- In previous versions, only one sandbox can run at one time (regardless of sandbox.sh or rw-sandbox.sh). In version 622 and newer, Fatdog64 can run multiple sandboxes at the same time and sb2dir.sh has been enhanced to allow selection of the sandbox to use.
- Due to this, the location of sandbox and fakeroot mounts have changed. In previous versions they were located in /mnt/sandbox and /mnt/fakeroot; now they are located in /mnt/sb/sandbox and /mnt/sb/fakeroot.
- In previous versions, one cannot use Exit to Terminal or Restart X server command from sandbox desktop - it would have shutdown the system's desktop instead. In version 622 onwards, this is the preferred method (although closing the Xephyr window will work, too).
- From version 622 onwards, Fatdog64 also comes with Linux Container sandbox described below.
Linux Container sandbox (sandbox-lxc)
Standard sandbox uses chroot as its isolation mechanism. sandbox-lxc is a sandbox that uses Linux Container instead of chroot. Linux Container (LXC) a process isolation mechanism, similar to FreeBSD jail (and Virtuozzo, OpenVZ (open-source version of Virtuozzo), as well as Linux-VServer). From Fatdog64 700 on-wards, suitable kernel is provided and the necessary CLI tools are included in the distribution. Older Fatdogs requires installation of supporting utilities and specially configured kernel.
sandbox-lxc provides more isolation than standard sandbox :
- Applications in sandbox-lxc can only interact with themselves, and cannot affect not anything in the system (or in other sandboxes)
- sandbox-lxc has its own hostname and network and do not share the system's IP address and hostname and thus by default has no network access.
- If you don't enable desktop emulation, there is no shared writable directory with the system (if you *do*, then /tmp is shared from the system).
- By default all character devices from the system is accessible in the sandbox, but none of the block devices. You can fine tune this after the sandbox has been running using lxc-cgroup.
- By default the memory and CPU usage are not restricted. If you wish you can limit the maximum allowable memory and CPU that a sandbox can use. This is also done using lxc-cgroup. Look here for more details of what can be managed and controlled.
- If your kernel supports it (from 3.9 onwards), you can optionally run with user namespaces separation - that is, "root" in the sandbox is just actually just a regular user in the system.
Differences from usage perspective:
- use sandbox-lxc.sh instead of sandbox.sh
- use rw-sandbox-lxc.sh instead of rw-sandbox.sh
- sb2dir.sh works with both standard and sandbox-lxc.
- Since Fatdog 801, you can have networking setup for you via proxy ARP as an option. On previous versions networking must be setup manually (both inside and outside the sandbox) either by using bridging, or NAT, or proxy ARP.
- /sys is not mounted by default.
- Use poweroff command to leave sandbox, instead of exit.
- If you detach the console from the sandbox accidentally (by pressing "Ctrl-G q"), you can re-attach by running lxc-console -e g -n XXXX where XXXX is the sandbox-lxc id (shown when you started the sandbox initially). If you don't know what it is, it would be in the form of sb.lxc.XXXXXX where XXXXXX would be the random string you see in /mnt/sb/sandbox.XXXXXX.
- To run sandbox-lxc with user namespaces, add environment variable IDMAP=yes before starting sandbox, e.g. IDMAP=yes sandbox-lxc.sh. When started this way, sandbox's "root" user is actually a user with uid of 10000 in the system.
- If for whatever reason you think you've lost control of the container, you can always stop is by running lxc-stop --name XXXX where XXXX is the sandbox-lxc id (shown when you started the sandbox).
Please note that LXC is still in active development and there may be issues that affect isolation. If you really need even tighter security controls then please consider User Mode Linux or KVM/Qemu or other full-system virtualisation solution.
From Fatdog64 720 onwards, sandbox-lxc also supports running one-time command by passing the command as sandbox-lxc (and rw-sandbox-lxc) arguments. Unlike the normal sandbox, however, which runs the command and then quit, in sandbox-lxc the command is executed (after rc.sysinit.lxc has been executed) and then it returns to sandbox shell. If you want to explicitly terminate sandbox-lxc afterward, you must issue "poweroff" as one of the command sequence.
From Fatdog64 811 onwards, rw-sandbox and rw-sandbox-lxc can run "operating system image" files, that is, an image of a complete operating system, somewhat like "docker" and the like. The key is to pass the environment variable OS_IMAGE=1 before launching either.
For rw-sandbox, it will mount the image and setup the proper tmpfs/procfs/sysfs mount and then starts /bin/sh.
For rw-sandbox-lxc, it will mount the image and starts /sbin/init, as if booting the real operating system.
From Fatdog64 811 onwards, rw-sandbox and rw-sandbox-lxc can operate on a directory instead of an image. You can consider this as if the directory is the equivalent of a "savedir" or "savefolder"; the changes are stored into the directory instead of to an image file. For this to work, the directory you want to use must be outside the aufs root (that is, in a mounted partition), and the partition must run a Linux-compatible filesystem.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from sandbox.html on 2024-12-09.
Display problems
Background
Fatdog64 by default uses KMS (Kernel Mode Setting), a recent development in Linux kernel where control of display resolution and bit depth (=number of available colours) are managed inside the kernel instead of Xorg graphics driver.
As a consequence of KMS, these things happen:
- The KMS kernel driver will take over the graphics early in the boot process.
- This driver will change the video mode from text mode into its highest-available-resolution graphics mode.
- As such, there is no more text console. It is replaced by framebuffer console.
- More often than not, this framebuffer console will display smaller fonts and provides more rows and column than a standard text console (80x25).
Not all graphic cards/drivers support KMS. The ones that notably support them are:
- Intel (will not work without KMS)
- Nvidia (nouveau driver requires KMS, older nv does not support KMS)
- Radeon (will not work without KMS)
Those cards/drivers that do not support KMS will continue to work as they were. In addition, it is possible to turn off KMS as well. When KMS is turned off, you have two choices:
- If the driver supports non-KMS mode, you can continue to use that driver
- If the driver does not support non-KMS mode, you will have to use vesa driver.
Note: AMD/ATI/NVidia proprietary drivers do not support KMS at the time of writing, and requires that KMS be turned off. The package installer for these driver packages will do this automatically for you.
Common Problems
Display drivers, especially for advanced GPUs, are very complex. Add that to the fact that some GPU vendors are less open the others: people who write open-source drivers often do not have enough information on how the cards behave and end up having to make guesses. Combine that with card releases: new GPUs (at least new display cards) are released every year, sometimes with only subtle differences of behaviour from the earlier versions. You should be surprised that it works at all ☺.
But it does, most of the time. When it doesn't, though, you will see these sorts of problems:
- Blank screen (or white screen, or a uniform-coloured screen of some sorts, or stripes ...)
- The screen shows "unsupported frequency" or "mode not supported" or something like that.
- The text displayed on the screen is vanishingly small.
- And others.
Rather than going through the list of all possible problems, here we will show some solutions you can try if you encounter any of these problems.
Turning off KMS
In the most extreme cases (especially when you have a blank screen or otherwise odd/unusual patterns), you may want to turn off KMS.
KMS can be turned off by putting nomodeset on the kernel boot parameters (click to see more details). This will turn off KMS entirely. You can also turn off KMS for a specific driver by putting the driver name in front, e.g. radeon.nomodeset=1 for the radeon driver.
Note that certain drivers absolutely require KMS in order to work; if you turn off KMS you may not be able to use the optimum resolution settings. Most recent GPU-specific drivers won't work without KMS nowadays, and your best bet is to use vesa driver for BIOS-based systems or fbdev for UEFI-based systems.
You may want to combine turning off KMS with telling Xorg to use a specific GPU driver and/or resolution, outlined below.
Tell KMS to use a specific resolution and frequency
Instead of turning off KMS entirely, you may want to try to tell KMS to use a specific resolution and refresh frequency instead - most probably lower than the default one chosen by KMS. This is useful in cases where your monitor gives out a message that says the resolution/frequency chosen by video card is too high.
Resolution and frequency can be set by using video option (click to see more details).
Make the console text bigger
If the display is right but it's just that the text on the console is too small to see (this is possible if you use a high-resolution monitor with small physical dimensions), you can use a larger font to make the screen more intelligible.
This isn't usually required as most people don't work on the console directly (most people use the graphical desktop and use the terminal emulators (e.g. xterm / urxvt) inside the graphical desktop), but it may be useful if for some reason you can't get the graphical desktop to start and you're troubleshooting it.
Fatdog64 comes with a size 16x32 Terminus font, called as big and bbig (stands for "bold and big") to make them easier to remember. To make use of this font, all you need to do is type this at the console: setfont big or setfont bbig
Note: You must use the setfont command at the linux console, not from the terminal emulator on your graphical desktop.
Tell Xorg to use a specific driver and resolution
So far what has been discussed explains what can be done to improve the situation at the console. The graphical desktop (managed by Xorg) has its own settings. Unless these setting are changed, Xorg by default will automatically load the most suitable GPU driver, then choose the highest supported resolution, bit depth and refresh frequency (just like KMS).
Usually this is what you want, but in case it is not, you can override the automatic settings by running the command xorgwizard. This command allows override of the driver, resolution and bit depth (but not frequency - Xorg will still choose the highest supported frequency given the other parameters).
This command can be run from the console, from from within terminal emulator in the graphical desktop. We recommend that you run it from the console because then you have the option of testing the driver / resolution / bit-depth. If you run it from terminal emulator where Xorg is already running, you can still have the settings you want but you can't validate that your chosen settings are right.
The settings is stored in /etc/X11/xorg.conf.d/20-gpudriver.conf; in case you want to revert to the automatic default settings, just remove this file.
Note: If a card-specific driver does not work for you, you may want to try to use a generic driver instead. There are three generic drivers you can try: the modesetting driver (works when KMS is enabled - which is by default), the fbdev driver (works for when KMS is enabled or you are using UEFI-based systems), and the vesa driver (only for older computer with BIOS systems, and will work regardless of KMS settings). xorgwizard indicates which driver requires KMS.
Tell Xorg to display a larger font
The setfont command does not work within the graphical environment (it will screw up your screen instead). Changing the font size (or font family, for that matter) for the terminal emulator depends on which terminal emulator you use. For urxvt, the default terminal emulator included in fatdog, create a file called .Xdefaults in your home directory and put the command URxvt.font: xft:mono:pixelsize=14:autohint=true inside it. Change "14" to whatever size you want, in pixels.
Changing font size used by other applications is similarly done through the interfaces or configuration used by them; and this is dependent and different from one application to another.
If you want to change the font size for all applications, though, the best way to do that is by changing the so-called "Global Font Size". This setting is stored in a file called .Xresources (located in your home directory), in a line that starts with Xft.dpi. You can edit this manually and then re-start the X server, or you can use a comfortable GUI to change that. This GUI is accessible from Control Panel > "Appearance" ("Desktop" on older Fatdogs) > Set Global Font Size. It gives you the option to change the size from 54 to 108 (the default is 78). If you need to set values beyond this range, edit the file manually.
Useful links about KMS
Here are some links about KMS. Please note that while they are useful as a reference and background information, not all of the commands discussed there will be directly applicable to Fatdog64.
Arch Linux KMS documentation
Debian KMS documentation
Freedesktop Nouveau KMS documentation
ModeDB - details on the video kernel parameter
Older version of ModeDB, only applicable for non-KMS system
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from screen.html on 2024-12-09.
Booting with Secure-Boot
This document describes booting Fatdog64 from a USB flash drive on a computer with UEFI and secure boot enabled. All Windows 8 computers onwards come with secure boot enabled by default. Secure boot can be disabled if you like in UEFI setup, and Windows will still boot normally.
At the time of this writing the UEFI implementations vary a lot. Some are easy to configure, some are not. Some only accept keys that are added though the UEFI setup menu. Some are really just broken and won't recognize the keys that are added. Fortunately these are few and hopefully soon to be fixed.
Step 1: For most systems pressing F2 when the computer starts to boot will take you to the UEFI setup menu. Plug in your flash drive that has Fatdog64 installed, turn on the computer and press the F2 key to enter UEFI setup.
Go to the boot tab and move your USB drive to the top of the boot list so that the computer will try to boot from it first. Exit setup and save your changes. (Usually F10). On some UEFI implementations you won't have this option, but you will have an option to manually add a boot option. Some have both. If you need to manually add a boot option, you'll need to browse to /EFI/boot/bootx64.efi on the USB drive.
Step 2: When the computer reboots you should see a screen like this if it booted off the flash drive with secure boot enabled.
Press Enter key to go to the screen, and when the next screen shows up, press any key perform the "MOK Key Management" within the next 10 seconds.
If you fail to press a key in the next ten seconds, the boot will fail and you will have to power-down your computer and try again.
If you do it correctly, you will eventually see this screen. Use the arrow keys to move the selection bar and highlight "Enroll key from disk" and then press Enter.
Step 3: Use the arrow keys to select the device/partition that contains the key and press Enter. It should be the one with 'USB' in it. The example screenshot below does not show anything with 'usb' in its name because it was taken from an emulator, but on a real machine you should see one that has it.
Step 4: Use the arrow keys to move the highlight bar to the 'keys' folder and press Enter. If you don't see a 'keys' folder you probably selected the wrong partition, press Esc to return to the previous screen and select a different partition.
Step 5: Use the arrow keys to move the highlight bar to select 'fatdog64-2041.cer'. This is the Fatdog64 key. Then press Enter.
Step 6: The Next screen should look like below. Use arrow keys to move the highlight to "Continue" and then press Enter.
Step 7: On the Next screen move the highlight to "Yes" and press Enter.
Then choose "Reboot" and press Enter.
Step 8: If everything is successful, the computer will be reboot and you will see Fatdog boot screen after it comes back. If it does not automatically reboot, you can just power it off manually, or press Ctrl-Alt-Del to reboot.
Final Note: Once the keys have been installed you won't be asked for them again. If for some reason you want to remove the Fatdog64 key, you can delete all the added keys (MOKs) by booting to the UEFI shell from rEFInd and typing dmpstore -d MokList
Final Note 2: Secure Boot is a fickle thing. It does not always work. For example, on a Dell 14z with a 3rd generation I5, the boot would hang after the Grub2 boot selection. For this laptop I disabled secure boot then followed the UEFI hard drive install instructions. Then I re-enabled secure boot and it would boot fine from the hard drive install.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from secure-boot.html on 2024-12-09.
How to make SFS packages for Fatdog64
Firstly, make a standard package as described in "How to make a package for Fatdog64".
Once you have done that and have a package file:
-
Extract the package into a temporary location, say /tmp/mypackage.
-
Run the following command:
mksquashfs /tmp/mypackage /path/to/where/you/want/to/keep/the/result.sfs -noappend -comp xz -Xbcj x86
-
And then you can delete /tmp/mypackage.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from sfs-package.html on 2024-12-09.
File sharing
There are a number of ways to share files with other computers using Fatdog64. They are:
- FTP -- File transfer protocol.
- HTTP --- Web server.
- Samba --- aka SMB, server message block. (This is what Windows uses.)
- SSHFS --- File sharing over SSH
FTP
FTP is a good choice if you want to move single files, not whole folders. Files must be moved one at a time with FTP, so if you want to do a folder it's best to zip the folder up into one file. To start the FTP server go to Control Panel, click on the System tab, and then Manage Servers and Services. Click on ftpd and then click Start to run the service. Click enable if you want the ftpd server to run at each boot . To connect from another computer you'll need the IP address of the computer running the FTP server. Open a terminal and type ifconfig, it will look something like this:
# ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
wlan0 Link encap:Ethernet HWaddr 00:23:14:DC:48:B8
inet addr:192.168.254.42 Bcast:192.168.254.255
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:48110 errors:0 dropped:0 overruns:0 frame:0
TX packets:8953 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:17773416 (16.9 MiB) TX bytes:1027903 (1003.8 KiB)
#
In this example our IP address is 192.168.254.42. The other piece of information we need is a login name and password. To login as root the default password is woofwoof. When you made your save file, you where given the opportunity to change it. To change the root password, open a terminal and at the # prompt type:
passwd
You'll be prompted for a new password. Then from the other computer open Firefox and in the address box type ftp://192.168.254.42. That's for the example above; substitute your IP address. You'll be prompted for a user name and password. You can also connect using gFTP, which is found under Network in the main menu. You can make this available over the internet too. To do that you'll need to login to your router and forward port 21 to the IP address of the computer running the FTP server.
HTTP web server
Http can be a good choice if you want others to be able to download files, but not upload. To start the web server go to Control Panel, click on the System tab, and then Manage Servers and Services. Click on civetweb and then click Start to run the service. Click enable if you want the http server to run at each boot . The Civetweb web server forks itself to run as user webuser. The server's root is located at /var/lib/www. Files or links placed there will be visible to users of the web server. To connect open a web browser and enter your IP address. The configuration file for the server is located at /etc/civetweb.conf. You can make this available over the internet too. To do that you'll need to log-in to your router and forward port 80 to the IP address of the computer running the HTTP server.
Note: You can also run civetweb as a "user" server and serve any directories you want. Open a terminal, and then type "civetweb". It will then serve the files from the current directory. To stop it, just press Ctrl-C.
Samba
If you want to share files with other computers on your local network, including Windows computers, this is the way to go. To start the Samba server go to Control Panel, click on the System tab, and then Manage Servers and Services. Click on samba and then click Start to run the service. Click enable if you want the Samba server to run at each boot . This will share your Downloads folder as user spot. To connect from another computer running Fatdog64, open the Shared folder on the desktop and click on Scan. This will create icons for the shared folders found on your network. Then click on those icons to mount the shared folder, right click to unmount. From Windows go to "Network Neighborhood" or "Places". You might have to click refresh a few times for it to show up. Clients connecting to Fatdog64 will only be able to write files in folders that user spot has permission.
SSHFS
Caution. If ssh is open to external systems then it will be attacked. SSHFS is best used behind a firewall, on a local LAN only.
Preparation
Edit /etc/ssh/sshd_conf to uncomment/set
PermitRootLogin yes
PasswordAuthentication yes
Then from Control Panel --> System tab --> Manage Servers and Services, select/tick the SSHD option and enable it.
If Fatdogs firewall (eztables) is on, then you may prefer to disable it (alternatively reconfigure it to permit ssh connections).
Accessing from Linux :
mkdir sshfs-dir
sshfs root@192.168.1.4:/home/example_user sshfs-dir
(change the 192.168.1.4 IP used here to the IP of your file server box)
Accessing from Windows :
SSHFS-Win makes it easy to mount a directory from a remote Linux computer on your local Windows computer.
Install the latest stable installer of WinFSP.
Install the latest stable installer of SSHFS-Win.
Open File Explorer, right-click on This PC and choose Map network drive. Choose a drive to mount at and in the Folder field enter:
\\sshfs\root@192.168.1.4
(change the 192.168.1.4 IP used here to the IP of your file server box)
By default, Windows will use your Windows password or credentials for the remote computer. Most likely the password and credentials will be different on the remote computer in which case choose the Connect using different credentials option.
Windows will ask for your password at the remote computer (you have changed it from the default password haven't you!). After that the home directory from your remote computer will be mounted at the Windows drive you chose.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from sharing.html on 2024-12-09.
SMB Browser Help
A network share is a resource on a local network that can be accessed by other networked computers, typically a folder on a PC, Mac, or NAS server, allowing contained files and folders to be shared over the local network. It is also known as a network drive.
Fatdog64 can provide network shares -- acting as a so-called SMB or samba server or host. It can also connect to network shares provided by other computers -- acting as a so-called client. Either way, connections are secured by specific credentials, typically passwords, configured by the host.
The SMB browser application discovers network shares that might be active in the local network, sets up connections with such shares, and activates the file manager on the shared folders. Therefore, the SMB Browser facilitates the client role.
If instead you are looking for assistance in setting up Fatdog64 as a samba server, turn to the Fatdog64 Folder Sharing Manager in control panel.
Connecting to Windows 7 network shares
Windows 7 automatically starts up in "Public" network mode, which disables all network shares; so before SMB browser can successfully discover Windows 7 shares, the network share feature must be enabled in the Windows 7 host.
Windows 7 Sharing Options include "password-protected" sharing and "no-password" sharing. This can be very misleading, because in reality whatever option you choose, you will still need to have valid Windows 7 credentials (win7-username and password) to connect to the share. The difference between the two options is in browsing results, as we will see.
So to create a share for a folder make sure to assign a win7-username to the folder permission (note: not the share permission, it's the folder permission).
Now start SMB Browser to browse for shares. With Windows 7 "no-password" sharing (password-protected off), SMB Browser will find the share, ask for win7-username and password, and report the browsing results in a window, ready to create the local folder icon when you press OK. Before you do, change "vers=1.0" to "vers=2.1" in the MountOptions column (right-click to edit the cell) otherwise the share will not connect when you click its local folder icon.
With Windows 7 "password-protected" sharing on, SMB Browser will not find the share in the first place, unless the correct username/password is given in the very first prompt. If the correct username/password is given, then everything proceeds normally as before (you still need to change "vers=1.0" to "vers=2.1" in column MountOptions).
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from smb-browser.html on 2024-12-09.
Sound problems?
If your sound is not working, it could be that Fatdog64 just doesn't have a driver for it. Or more likely, the volume is muted or the wrong sound card has been chosen as the default. Even if you only have one sound card, often that card will have several functions driven by different drivers, so it looks like multiple sound cards to Fatdog64.
The volume icon in the task bar only adjusts the Master volume, not any other channels. To adjust the other volume settings, open AlsaMixer, found under Sound in the Control Panel or by clicking on the sound icon in the panel and selecting "Mixer". This application does not use the mouse. You'll need to use the arrow keys to move and adjust the volumes.
The m key mutes and unmutes a channel. Note that you can turn the volume up on a channel and still have it muted, so make sure that mute is off if you want a setting to be in effect. At the bottom of each channel it should show 00, if it shows MM it's muted.
Headphones and external speakers: Also in AlsaMixer, the Auto-Mute column allows you to choose what happens when headphones or other speakers are plugged in: whether the built-in speakers will be muted or still play. Use the up and down arrows to select.
To select the default sound card start the Fatdog Default Soundcard Wizard, found in Sound in the Control Panel. Select the device to use as the default and then use AlsaMixer again to make sure everything is turned up and unmuted. You also use the same wizard to send audio to a bluetooth device.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from sound.html on 2024-12-09.
Spot's home directory moved (Fatdog64 720 onwards)
Overview
Most network programs in Fatdog64 runs as the special user "spot". "spot" is a root-surrogate, which means that it is doing things on behalf of root, but at reduced permission level. This is especially useful for network programs: in case those programs have security vulnerabilities, a remote attacker can only gain the privilege and access level of the user "spot" instead of "root" (and let's hope the machine doesn't have privilege-escalation kernel vulnerabilities that enables an attacker to become "root" from "spot" ... but we digress).
To make the restriction of "spot" effective, "spot" user only has access to a few places (otherwise, then there is no point in using spot at all). One of the few places that spot can access is, of course, its home directory. In all earlier Fatdog64, spot's home directory was /root/spot. Why /root/spot? The reasons are buried in the mist of history. Let's just say that Fatdog64 inherited that location in its earliest days from Puppy Linux and carried forward this heritage until 720 was released.
The /root/spot location of spot's home directory did indeed make matters very awkward.
The main thing that we want to protect is the contents of /root, but /root/spot is inside /root, which means, in order to access /root/spot, "spot" needs access to /root too, which negates the whole protection story we painted above. Or does it not? As it turns out, no, not really. Unix permissions can be set to allow spot to traverse /root and get access to /root/spot, without allowing spot to read anything else inside /root. This is because Unix has a separate control to allow whether a user can read contents of a directory, or just traverse it. Previous versions of Fatdog64 allowed spot to traverse /root to get to /root/spot, but disallowed spot to list or read any files in /root.
It works, but this is not perfect. The permission control of whether a file can be read (or not), is set on the file itself - not on the directory that contains the file. This means: although you cannot see the directory contents, you may still be able to read the files in it, provided that:
a) You know the name of the file
b) The permission of the file allow it
c) You have the traverse permission to the containing directories
We need something better.
The only way to ensure that programs under user "spot" can never be able to read stuff in /root, is to close the access of /root to spot, which means to revoke spot all access. But this means "spot" cannot access /root/spot anymore, and thus spot cannot have its home directory located here. It has to be moved somewhere.
Spot's shiny new home directory is /home/spot.
Effect of this change
You can no longer download stuff to /root/spot. The correct place is now /home/spot.
You can no longer upload stuff from /root directly, just by giving a permissive enough permission to the file; because now spot are not allowed to traverse /root at all.
You cannot view HTML files you keep in /root or its subfolders, because browsers (by default) run as spot so they cannot read the files anymore.
In order to help you to ease the transitions, we have done the following:
- The /root/Downloads symlink still exists and works, but now it points to /home/spot/Downloads
- /root/spot still exist, but it is now a symlink to /home/spot.
- A new shortcut Win+G shortcut now opens ROX-Filer in spot's home
- All programs that uses spot's home directory have been updated to use the new location.
So what has not changed?
Spot still has access to the Downloads folder. When running as root (e.g. from ROX-Filer), dropping files to /root/spot will still drop it it to spot's new home directory (thanks of the symlink), which spot has access to.
In the process, in order to upload stuff using the browser, the recommended way is to copy those files to the Downloads folder, and then upload from there; removing the files when upload is completed. This still works.
Some people may do the same but using /root/spot for their temporary transit - this still works too.
(Historical only) Note for existing Fatdog users
The changes above will apply for those who start with fresh savefile on Fatdog64 720.
How about those who migrated to Fatdog64 720 with existing savefile from previous Fatdog versions? They still have contents in /root/spot. Spot's home still pointing to /root/spot. How to ensure that they, too, enjoy the benefit of this better security?
While we don't officially support carrying savefile from older Fatdogs into the new one, we have provided a script which will help you. The script is called /root/make-spot-more-secure.
Launch this script (either from Terminal or from Rox), and it will guide you step-by-step to secure spot. It will create /home/spot with the proper structure, copy the files from /root/spot to /home/spot, and replace it with a symlink. You can do this yourself, but the script makes it easier. Please feel free to examine the script before running it if you feel uncomfortable.
The script is designed so that you can safely run multiple times. It will detect there is no further need for migration if it has been completed; and will do nothing in that case. Feel free to delete this script after you've completed the migration.
Note: The script /root/make-spot-more-secure has been removed from Fatdog64 900 Beta onwards. If you think that you still need this script, what you need is to start a new savefile/savedir instead.
Some other caveats and side-effects of the migration
1. "spot" is now its own user group. It is not part of the "users" group. The reason for this change is the same as above - spot should be as restricted and unrelated to any other users in the system. Thus, it is highly **NOT** recommended to run the desktop as "spot". If you want to run as non-privileged user, instead of using spot, please make a new user (fido, etc) and use that to run the desktop. (You can do this from Control Panel's User Manager or mkuser.sh from terminal).
Note: From Fatdog 800 onwards, if you enable "Move Downloads Folder" when saving the session, "spot" will be added back to "users" group when the session is saved. This is because, if your savedevice is on a FAT partition, it can only be accessed by members of "users" group. If "spot" isn't in the group then the "Downloads" folder will not be accessible. If you know that your savedevice is not FAT, then you can remove "spot" again from "users" for better security by running the command "busybox delgroup spot users".
2. While the make-spot-more-secure program helps to relocate spot's home to its new place, it does not (and cannot) help to migrate the myriad of programs that may think that spot's home is still in the old location. This is not a problem for a fresh installation, but it may be a problem from existing installation (=as in, re-using the savefile from older Fatdogs). Two prominent programs comes to mind:
a) The browser. Older package have been configured to download and print-to-PDF to /root/Downloads. This will **NOT** work anymore. You need to explicitly set a new download folder (it's in /home/spot/Downloads), and also a new target folder for print-to-pdf (also /home/spot/Downloads). If you don't, everything will seem to succeed but you will find that your files are mysteriously missing (hint: they don't, they just never get saved there in the first place because the browser cannot access /root/Downloads).
b) Samba. It's public share folder, for older configuration, is still /root/spot. You will need to edit /etc/samba/smb.conf yourself and change it to /home/spot.
But I don't want these hassles!
Of course, all these seems to be a lot of hassle. It does. If you really don't care about this, and have a strong belief that Linux is secure and impenetrable, or just prefer convenience, there are two things you can do:
a) Edit desktop files in /usr/share/applications and change their Exec= line. If you see anything with "-spot" in it, drop it (e.g. replace firefox-spot with firefox). This will make them as user root and bypass all these "spot" issues.
b) If you can't event be bothered with that, you can always open the access to /root folder, using the command "chmod permission-code /root".
The older Fatdogs had their permissions code set to 711 (open access for "root", traverse access for all), in Fatdog64 720 its permission is now 700 (open access for "root" only).
In order of more convenience (and lesser security), you can change its permission to:
- 711 (back to older Fatdog's way), or
- not-recommended: 755 (open access for "root", traverse and list contents access for all), or
- highly not recommended: 777 (open access for all)
But before you do this, please know what you're doing.
We make all these changes for a reason; that reason is to put your security above everything else.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from spot.html on 2024-12-09.
How to suspend and hibernate
Terminology
"suspend" aka "suspend-to-RAM" aka "STR" aka "sleep" --> store everything to RAM and stop CPU, harddisk, screen, etc. Machine still on, power still required although usage is small. Pressing (usually) the power button will wake up the CPU, which will restore its state from RAM, and continues. Fatdog64 has supported suspend since its early days.
"hibernate" aka "suspend-to-Disk" aka "STD" aka "hibernate" --> store everything to Disk, then power off. Pressing (usually) the power button will start-up the machine, run the bootloader, load and run kernel as usual, but the kernel will recognise that it is "waking up" from "hibernation" and will restore its state from Disk instead of the usual power-up. Support for hibernation starts with Fatdog64 721. On older Fatdogs you can also do hibernation if you update to the latest kernel.
How to perform suspend
- On terminal, type "echo mem > /sys/power/state".
- Alternative, if you're on a laptop, just close the lid.
Where are these controlled?
/etc/acpi/events/lid is where lid-closing will trigger suspend script.
/etc/acpi/actions/suspend.sh is the actual suspend script, which will suspend the machine.
Troubleshooting: Suspend usually works. Most the problem is "failure to wake up" which can be fatal (e.g. screen fails to wake up: blank screen), or annoying (e.g. wifi fails to wake-up, requiring restart of network connection). Usually the problem is bad module. Identify that, and remove that module before suspend, and then reload (modprobe) that module again after waking up. See the suspend script above for examples. Or kill some process and re-start them again upon wake-up. If you still have problems, you're SOL: suspend is not for you.
How to perform hibernation
Firstly, make sure suspend works. If you can't even make suspend to work then forget hibernation.
Secondly, you need to have a swap. Either swap partition or swap file will do. To be safe, make sure that swap partition/swap file is at least the size of your RAM.
Third, you need to prepare. Waking up from hibernation requires support the bootloader, so you must be comfortable of editing boot entries and adding boot parameter.
Fourth, make sure your disk that contains swap partition/swap file is a disk that can be accessed by the kernel without need for additional kernel modules or firmware. Don't attempt to do from LVM disks.
If you have a swap partition, take a note of your swap partition. For example assume it's /dev/sda7. Then in your boot loader entry, add a new parameter "resume=/dev/sda7" and you're good to go.
If you have a swap file, take a note of the partition that contains your swap file (e.g. /dev/sda5), and then run "filefrag -v /path/to/your/swapfile". You will get an output something like below:
# filefrag -v /mnt/sda5/fd64-swap
Filesystem type is: ef53
File size of /mnt/sda5/fd64-swap is 8589934592 (2097152 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 32767: 36864.. 69631: 32768:
1: 32768.. 61439: 69632.. 98303: 28672:
2: 61440.. 94207: 100352.. 133119: 32768: 98304:
Pay attention to the first row (row 0), and read the physical_offset. In this example, it's 36864.
Then in your boot loader entry, add the following two parameters: "resume=/dev/sda5 resume_offset=36864". Then re-boot. This reboot is required for swap file; for swap partition you don't need to reboot first. If you don't reboot, the hibernation will fail.
Once rebooted, on terminal you can do this: "echo disk > /sys/power/state"
Additional Tips
- Resuming from hibernation doesn't require loading the initrd; because everything (including the initrd) is already stored in the hibernation (swap) file. If you want faster "resume" from hibernation, instead of adding the above boot parameters to an existing boot entry that loads both the kernel and initrd, consider creating a new boot entry that only loads the kernel with the given parameter, e.g. (grub2 example: linux /vmlinuz resume=/dev/sda5 resume_offset=36864). When resuming, choose this entry so your boot loader only loads the kernel (and not initrd). Of course, if your bootloader and disk is fast, you can ignore this.
- If you use multiple swap files, on console type "cat /proc/swaps" and perform the "filefrag" command on the first swap file. Your first swap file must be at least the same size as the RAM.
- If you don't like swap or don't usually use swap, but you want to hibernate, well then create a new swapfile and do all the above preparation. Before suspending, run the command in terminal "swapon /path/to/your/swapfile/or/device" and then hibernate. Upon wake-up, run this: "swapoff /path/to/swapfile/or/device" to turn off the swapfile usage.
FAQS
Q1. I heard there is this feature called "hybrid suspend" where the state is copied to both RAM and Disk; and the the machine goes to suspend. If power is not lost during the suspend, it will wake up from RAM which is fast. But if power is lost, it will wake up from disk just like hibernation. This is good and cool because I can suspend to RAM and not worry about power lost.
A1. Not supported.
Q2. What about compressing the data used for hibernation?
A2. Not supported.
Q3. Hibernation is scary because kernel data is stored to disk, directly. Somebody could steal the disk and do a scan for password on the hibernation file. I heard you can encrypt the hibernation file?
A3. Not supported.
All the above features require an advanced suspend module (aka "userspace suspend") - which currently isn't implemented in Fatdog.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from suspend.html on 2024-12-09.
Table of Contents
- name
- synopsis
- description
- configuration options
- configuration details
- device properties
- notes
- removed options
- see also
SYNAPTICS(4) Kernel Interfaces Manual SYNAPTICS(4)
NAME
synaptics - touchpad input driver
SYNOPSIS
Section "InputDevice"
Identifier "devname"
Driver "synaptics"
Option "Device" "devpath"
Option "Path" "path"
...
EndSection
DESCRIPTION
synaptics is an Xorg input driver for touchpads. Even though touchpads
can be handled by the normal evdev or mouse drivers, this driver allows
more advanced features of the touchpad to become available. Some benefits
would be:
• Movement with adjustable, non-linear acceleration and speed.
• Button events through short touching of the touchpad.
• Double-Button events through double short touching of the touchpad.
• Dragging through short touching and holding down the finger on the
touchpad (tap-and-drag gesture).
• Middle and right button events on the upper and lower corner of the
touchpad.
• Vertical scrolling (button four and five events) through moving the
finger on the right side of the touchpad.
• The up/down button sends button four/five events.
• Horizontal scrolling (button six and seven events) through moving the
finger on the lower side of the touchpad.
• The multi-buttons send button four/five events for vertical scrolling
and button six/seven events for horizontal scrolling.
• Adjustable finger detection.
• Multifinger taps: two finger for right button and three finger for
middle button events. (Needs hardware support. Not all models
implement this feature.)
• Pressure-dependent motion speed.
Note that depending on the touchpad firmware, some of these features
might be available even without using the synaptics driver. Note also
that some functions are not available on all touchpad models, because
they need support from the touchpad hardware/firmware. (Multifinger taps
for example.)
The name "synaptics" is historical and the driver still provides the
synaptics protocol parsing code. Under Linux however, the hardware-
specifics are handled by the kernel and this driver will work for any
touchpad that has a working kernel driver. If your device is recognized
as "PS/2 Mouse" or similar, the kernel driver does not support your
device and this driver will only provide limited functionality.
CONFIGURATION OPTIONS
Please refer to xorg.conf(5) for general configuration details and for
options that can be used with all input drivers. This section only
covers configuration details specific to this driver.
The following driver Options are supported:
Option "Device" "string"
This option specifies the device file in your "/dev" directory
which will be used to access the physical device. Normally you
should use something like "/dev/input/eventX", where X is some
integer.
Option "Protocol" "string"
Specifies which kernel driver will be used by this driver. This is
the list of supported drivers and their default use scenarios.
auto-dev automatic, default (recommend)
event Linux 2.6 kernel events
psaux raw device access (Linux 2.4)
psm FreeBSD psm driver
Option "LeftEdge" "integer"
X coordinate for left edge. Property: "Synaptics Edges"
Option "RightEdge" "integer"
X coordinate for right edge. Property: "Synaptics Edges"
Option "TopEdge" "integer"
Y coordinate for top edge. Property: "Synaptics Edges"
Option "BottomEdge" "integer"
Y coordinate for bottom edge. Property: "Synaptics Edges"
Option "FingerLow" "integer"
When finger pressure drops below this value, the driver counts it
as a release. Property: "Synaptics Finger"
Option "FingerHigh" "integer"
When finger pressure goes above this value, the driver counts it
as a touch. Property: "Synaptics Finger"
Option "MaxTapTime" "integer"
Maximum time (in milliseconds) for detecting a tap. Property:
"Synaptics Tap Durations"
Option "MaxTapMove" "integer"
Maximum movement of the finger for detecting a tap. Property:
"Synaptics Tap Move"
Option "MaxDoubleTapTime" "integer"
Maximum time (in milliseconds) for detecting a double tap.
Property: "Synaptics Tap Durations"
Option "ClickTime" "integer"
The duration of the mouse click generated by tapping. Property:
"Synaptics Tap Durations"
Option "ClickPad" "boolean"
Whether the device is a click pad. See ClickPad support for more
details. Property: "Synaptics ClickPad"
Option "VertEdgeScroll" "boolean"
Enable vertical scrolling when dragging along the right edge.
Property: "Synaptics Edge Scrolling"
Option "HorizEdgeScroll" "boolean"
Enable horizontal scrolling when dragging along the bottom edge.
Property: "Synaptics Edge Scrolling"
Option "CornerCoasting" "boolean"
Enable edge scrolling to continue while the finger stays in an
edge corner. Property: "Synaptics Edge Scrolling"
Option "VertTwoFingerScroll" "boolean"
Enable vertical scrolling when dragging with two fingers anywhere
on the touchpad. Property: "Synaptics Two-Finger Scrolling"
Option "HorizTwoFingerScroll" "boolean"
Enable horizontal scrolling when dragging with two fingers
anywhere on the touchpad. Property: "Synaptics Two-Finger
Scrolling"
Option "VertScrollDelta" "integer"
Move distance of the finger for a scroll event. Property:
"Synaptics Scrolling Distance"
Option "HorizScrollDelta" "integer"
Move distance of the finger for a scroll event. Property:
"Synaptics Scrolling Distance"
Option "MinSpeed" "float"
Minimum speed factor. Property: "Synaptics Move Speed"
Option "MaxSpeed" "float"
Maximum speed factor. Property: "Synaptics Move Speed"
Option "AccelFactor" "float"
Acceleration factor for normal pointer movements. Property:
"Synaptics Move Speed"
Option "PressureMotionMinZ" "integer"
Finger pressure at which minimum pressure motion factor is
applied. Property: "Synaptics Pressure Motion"
Option "PressureMotionMaxZ" "integer"
Finger pressure at which maximum pressure motion factor is
applied. Property: "Synaptics Pressure Motion"
Option "PressureMotionMinFactor" "integer"
Lowest setting for pressure motion factor. Property: "Synaptics
Pressure Motion Factor"
Option "PressureMotionMaxFactor" "integer"
Greatest setting for pressure motion factor. Property: "Synaptics
Pressure Motion Factor"
Option "HorizHysteresis" "integer"
The minimum horizontal HW distance required to generate motion
events. Can be specified as a percentage. Increase if noise motion
is a problem for you. Zero is disabled. Default: 0.5 percent of
the diagonal or (in case of evdev) the appropriate "fuzz" as
advertised by the device.
Option "VertHysteresis" "integer"
The minimum vertical HW distance required to generate motion
events. See HorizHysteresis.
Option "UpDownScrolling" "boolean"
If on, the up/down buttons generate button 4/5 events. If off,
the up button generates a double click and the down button
generates a button 2 event. This option is only available for
touchpads with physical scroll buttons. Property: "Synaptics
Button Scrolling"
Option "LeftRightScrolling" "boolean"
If on, the left/right buttons generate button 6/7 events. If off,
the left/right buttons both generate button 2 events. This option
is only available for touchpads with physical scroll buttons.
Property: "Synaptics Button Scrolling"
Option "UpDownScrollRepeat" "boolean"
If on, and the up/down buttons are used for scrolling
(UpDownScrolling), these buttons will send auto-repeating 4/5
events, with the delay between repeats determined by
ScrollButtonRepeat. This option is only available for touchpads
with physical scroll buttons. Property: "Synaptics Button
Scrolling Repeat"
Option "LeftRightScrollRepeat" "boolean"
If on, and the left/right buttons are used for scrolling
(LeftRightScrolling), these buttons will send auto-repeating 6/7
events, with the delay between repeats determined by
ScrollButtonRepeat. This option is only available for touchpads
with physical scroll buttons. Property: "Synaptics Button
Scrolling Repeat"
Option "ScrollButtonRepeat" "integer"
The number of milliseconds between repeats of button events 4-7
from the up/down/left/right scroll buttons. This option is only
available for touchpads with physical scroll buttons. Property:
"Synaptics Button Scrolling Time"
Option "EmulateMidButtonTime" "integer"
Maximum time (in milliseconds) for middle button emulation.
Property: "Synaptics Middle Button Timeout"
Option "EmulateTwoFingerMinZ" "integer"
For touchpads not capable of detecting multiple fingers but are
capable of detecting finger pressure and width, this sets the Z
pressure threshold. When both Z pressure and W width thresholds
are crossed, a two finger press will be emulated. This defaults to
a value that disables emulation on touchpads with real two-finger
detection and defaults to a value that enables emulation on
remaining touchpads that support pressure and width support.
Property: "Synaptics Two-Finger Pressure"
Option "EmulateTwoFingerMinW" "integer"
For touchpads not capable of detecting multiple fingers but are
capable of detecting finger width and pressure, this sets the W
width threshold. When both W width and Z pressure thresholds are
crossed, a two finger press will be emulated. This feature works
best with (PalmDetect) off. Property: "Synaptics Two-Finger Width"
Option "TouchpadOff" "integer"
Switch off the touchpad. Valid values are:
0 Touchpad is enabled
1 Touchpad is switched off (physical clicks still work)
2 Only tapping and scrolling is switched off
When the touchpad is switched off, button events caused by a
physical button press are still interpreted. On a ClickPad, this
includes software-emulated middle and right buttons as defined by
the SoftButtonAreas setting.
Property: "Synaptics Off"
Option "LockedDrags" "boolean"
If off, a tap-and-drag gesture ends when you release the finger.
If on, the gesture is active until you tap a second time, or until
LockedDragTimeout expires. Property: "Synaptics Locked Drags"
Option "LockedDragTimeout" "integer"
This parameter specifies how long it takes (in milliseconds) for
the LockedDrags mode to be automatically turned off after the
finger is released from the touchpad. Property: "Synaptics Locked
Drags Timeout"
Option "RTCornerButton" "integer"
Which mouse button is reported on a right top corner tap. Set to
0 to disable. Property: "Synaptics Tap Action"
Option "RBCornerButton" "integer"
Which mouse button is reported on a right bottom corner tap. Set
to 0 to disable. Property: "Synaptics Tap Action"
Option "LTCornerButton" "integer"
Which mouse button is reported on a left top corner tap. Set to 0
to disable. Property: "Synaptics Tap Action"
Option "LBCornerButton" "integer"
Which mouse button is reported on a left bottom corner tap. Set
to 0 to disable. Property: "Synaptics Tap Action"
Option "TapButton1" "integer"
Which mouse button is reported on a non-corner one-finger tap.
Set to 0 to disable. Property: "Synaptics Tap Action"
Option "TapButton2" "integer"
Which mouse button is reported on a non-corner two-finger tap.
Set to 0 to disable. Property: "Synaptics Tap Action"
Option "TapButton3" "integer"
Which mouse button is reported on a non-corner three-finger tap.
Set to 0 to disable. Property: "Synaptics Tap Action"
Option "ClickFinger1" "integer"
Which mouse button is reported when left-clicking with one finger.
Set to 0 to disable. Property: "Synaptics Click Action"
Option "ClickFinger2" "integer"
Which mouse button is reported when left-clicking with two
fingers. Set to 0 to disable. Property: "Synaptics Click Action"
Option "ClickFinger3" "integer"
Which mouse button is reported when left-clicking with three
fingers. Set to 0 to disable. Property: "Synaptics Click Action"
Option "CircularScrolling" "boolean"
If on, circular scrolling is used. Property: "Synaptics Circular
Scrolling"
Option "CircScrollDelta" "float"
Move angle (radians) of finger to generate a scroll event.
Property: "Synaptics Circular Scrolling Distance"
Option "CircScrollTrigger" "integer"
Trigger region on the touchpad to start circular scrolling
0 All Edges
1 Top Edge
2 Top Right Corner
3 Right Edge
4 Bottom Right Corner
5 Bottom Edge
6 Bottom Left Corner
7 Left Edge
8 Top Left Corner
Property: "Synaptics Circular Scrolling Trigger"
Option "CircularPad" "boolean"
Instead of being a rectangle, the edge is the ellipse enclosed by
the Left/Right/Top/BottomEdge parameters. For circular touchpads.
Property: "Synaptics Circular Pad"
Option "PalmDetect" "boolean"
If palm detection should be enabled. Note that this also requires
hardware/firmware support from the touchpad. Property: "Synaptics
Palm Detection"
Option "PalmMinWidth" "integer"
Minimum finger width at which touch is considered a palm.
Property: "Synaptics Palm Dimensions"
Option "PalmMinZ" "integer"
Minimum finger pressure at which touch is considered a palm.
Property: "Synaptics Palm Dimensions"
Option "CoastingSpeed" "float"
Your finger needs to produce this many scrolls per second in order
to start coasting. The default is 20 which should prevent you
from starting coasting unintentionally. 0 disables coasting.
Property: "Synaptics Coasting Speed"
Option "CoastingFriction" "float"
Number of scrolls/second² to decrease the coasting speed. Default
is 50. Property: "Synaptics Coasting Speed"
Option "SingleTapTimeout" "integer"
Timeout after a tap to recognize it as a single tap. Property:
"Synaptics Tap Durations"
Option "GrabEventDevice" "boolean"
If GrabEventDevice is true, the driver will grab the event device
for exclusive use when using the linux 2.6 event protocol. When
using other protocols, this option has no effect. Grabbing the
event device means that no other user space or kernel space
program sees the touchpad events. This is desirable if the X
config file includes /dev/input/mice as an input device, but is
undesirable if you want to monitor the device from user space.
When changing this parameter with the synclient program, the
change will not take effect until the synaptics driver is disabled
and re-enabled. This can be achieved by switching to a text
console and then switching back to X.
Option "TapAndDragGesture" "boolean"
Switch on/off the tap-and-drag gesture. This gesture is an
alternative way of dragging. It is performed by tapping (touching
and releasing the finger), then touching again and moving the
finger on the touchpad. The gesture is enabled by default and can
be disabled by setting the TapAndDragGesture option to false.
Property: "Synaptics Gestures"
Option "VertResolution" "integer"
Resolution of X coordinates in units/millimeter. The value is used
together with HorizResolution to compensate unequal vertical and
horizontal sensitivity. Setting VertResolution and HorizResolution
equal values means no compensation. Default value is read from the
touchpad or set to 1 if value could not be read. Property:
"Synaptics Pad Resolution"
Option "HorizResolution" "integer"
Resolution of Y coordinates in units/millimeter. The value is used
together with VertResolution to compensate unequal vertical and
horizontal sensitivity. Setting VertResolution and HorizResolution
equal values means no compensation. Default value is read from the
touchpad or set to 1 if value could not be read. Property:
"Synaptics Pad Resolution"
Option "AreaLeftEdge" "integer"
Ignore movements, scrolling and tapping which start left of this
edge. The option is disabled by default and can be enabled by
setting the AreaLeftEdge option to any integer value other than
zero. If supported by the server (version 1.9 and later), the edge
may be specified in percent of the total width of the touchpad.
Property: "Synaptics Area"
Option "AreaRightEdge" "integer"
Ignore movements, scrolling and tapping which start right of this
edge. The option is disabled by default and can be enabled by
setting the AreaRightEdge option to any integer value other than
zero. If supported by the server (version 1.9 and later), the edge
may be specified in percent of the total width of the touchpad.
Property: "Synaptics Area"
Option "AreaTopEdge" "integer"
Ignore movements, scrolling and tapping which start above this
edge. The option is disabled by default and can be enabled by
setting the AreaTopEdge option to any integer value other than
zero. If supported by the server (version 1.9 and later), the edge
may be specified in percent of the total height of the touchpad.
Property: "Synaptics Area"
Option "AreaBottomEdge" "integer"
Ignore movements, scrolling and tapping which start below this
edge. The option is disabled by default and can be enabled by
setting the AreaBottomEdge option to any integer value other than
zero. If supported by the server (version 1.9 and later), the edge
may be specified in percent of the total height of the touchpad.
Property: "Synaptics Area"
Option "SoftButtonAreas" "RBL RBR RBT RBB MBL MBR MBT MBB"
This option is only available on ClickPad devices. Enable soft
button click area support on ClickPad devices. The first four
parameters are the left, right, top, bottom edge of the right
button, respectively, the second four parameters are the left,
right, top, bottom edge of the middle button, respectively. Any of
the values may be given as percentage of the touchpad width or
height, whichever applies. If any edge is set to 0 (not 0%), the
button is assumed to extend to infinity in the given direction.
Setting all values to 0 (not 0%) disables soft button areas.
Button areas may not overlap, however it is permitted for two
buttons to share an edge value. Property: "Synaptics Soft Button
Areas"
Option "HasSecondarySoftButtons" "boolean"
This option is only available on ClickPad devices. Enable the
secondary software button area support. The exact area must be set
in option "SecondarySoftButtonAreas". See ClickPad support for
more details.
Option "SecondarySoftButtonAreas" "RBL RBR RBT RBB MBL MBR MBT MBB"
This option is only available on ClickPad devices and only if
Option "HasSecondarySoftButtons" is enabled. Define the secondary
soft button click areas on ClickPad devices (usually on top of the
device). For the allowed values for this option, see Option
"SoftButtonAreas". Primary and secondary soft button areas must
not overlap each other. If they do, the behavior of the driver is
undefined. Property: "Synaptics Secondary Soft Button Areas".
This property is only initialized if Option
"HasSecondarySoftButtons" is enabled and this option is set in the
xorg.conf(5).
CONFIGURATION DETAILS
Area handling
The LeftEdge, RightEdge, TopEdge and BottomEdge parameters are used to
define the edge and corner areas of the touchpad. The parameters split
the touchpad area in 9 pieces, like this:
│ │
│ LeftEdge │ RightEdge
┌─────└─────────────└───┐ Physical top edge
│ 1 │ 2 │ 3 │
└─────└─────────────└───┘ TopEdge
│ │ │ │
│ 4 │ 5 │ 6 │
│ │ │ │
└─────└─────────────└───┘ BottomEdge
│ 7 │ 8 │ 9 │
└─────└─────────────└───┘ Physical bottom edge
│Physical left edge │ Physical right edge
Coordinates to the left of LeftEdge are part of the left edge (areas 1, 4
and 7), coordinates to the left of LeftEdge and above TopEdge (area 1)
are part of the upper left corner, etc.
A good way to find appropriate edge parameters is to use evtest(1) on the
device to see the x/y coordinates corresponding to different positions on
the touchpad.
The perceived physical edges may be adjusted with the AreaLeftEdge,
AreaRightEdge, AreaTopEdge, and AreaBottomEdge options. If these values
are set to something other than the physical edges, input that starts in
the space between the area edge and the respective physical edge is
ignored. Note that this reduces the available space on the touchpad to
start motions in.
Tapping
A tap event happens when the finger is touched and released in a time
interval shorter than MaxTapTime, and the touch and release coordinates
are less than MaxTapMove units apart. A "touch" event happens when the Z
value goes above FingerHigh, and an "untouch" event happens when the Z
value goes below FingerLow.
The MaxDoubleTapTime parameter has the same function as the MaxTapTime
parameter, but for the second, third, etc tap in a tap sequence. If you
can't perform double clicks fast enough (for example, xmms depends on
fast double clicks), try reducing this parameter. If you can't get word
selection to work in xterm (ie button down, button up, button down, move
mouse), try increasing this parameter.
The ClickTime parameter controls the delay between the button down and
button up X events generated in response to a tap event. A too long
value can cause undesirable autorepeat in scroll bars and a too small
value means that visual feedback from the gui application you are
interacting with is harder to see.
Acceleration
The MinSpeed, MaxSpeed and AccelFactor parameters control the pointer
motion speed. The speed value defines the scaling between touchpad
coordinates and screen coordinates. When moving the finger very slowly,
the MinSpeed value is used, when moving very fast the MaxSpeed value is
used. When moving the finger at moderate speed, you get a pointer motion
speed somewhere between MinSpeed and MaxSpeed. If you don't want any
acceleration, set MinSpeed and MaxSpeed to the same value.
The MinSpeed, MaxSpeed and AccelFactor parameters don't have any effect
on scrolling speed. Scrolling speed is determined solely from the
VertScrollDelta and HorizScrollDelta parameters. To invert the direction
of vertical or horizontal scrolling, set VertScrollDelta or
HorizScrollDelta to a negative value.
Acceleration is mostly handled outside the driver, thus the driver will
translate MinSpeed into constant deceleration and adapt MaxSpeed at
startup time. This ensures you can user the other acceleration profiles,
albeit without pressure motion. However the numbers at runtime will
likely be different from any options you may have set.
Pressure motion
When pressure motion is activated, the cursor motion speed depends on the
pressure exerted on the touchpad (the more pressure exerted on the
touchpad, the faster the pointer). More precisely the speed is first
calculated according to MinSpeed, MaxSpeed and AccelFactor, and then is
multiplied by a sensitivity factor.
The sensitivity factor can be adjusted using the PressureMotion
parameters. If the pressure is below PressureMotionMinZ,
PressureMotionMinFactor is used, and if the pressure is greater than
PressureMotionMaxZ, PressureMotionMaxFactor is used. For a pressure
value between PressureMotionMinZ and PressureMotionMaxZ, the factor is
increased linearly.
Middle button emulation
Since most synaptics touchpad models don't have a button that corresponds
to the middle button on a mouse, the driver can emulate middle mouse
button events. If you press both the left and right mouse buttons at
almost the same time (no more than EmulateMidButtonTime milliseconds
apart) the driver generates a middle mouse button event.
Circular scrolling
Circular scrolling acts like a scrolling wheel on the touchpad.
Scrolling is engaged when a drag starts in the given CircScrollTrigger
region, which can be all edges, a particular side, or a particular
corner. Once scrolling is engaged, moving your finger in clockwise
circles around the center of the touchpad will generate scroll down
events and counter clockwise motion will generate scroll up events.
Lifting your finger will disengage circular scrolling. Use tight circles
near the center of the pad for fast scrolling and large circles for
better control. When used together with vertical scrolling, hitting the
upper or lower right corner will seamlessly switch over from vertical to
circular scrolling.
Coasting
Coasting is enabled by setting the CoastingSpeed parameter to a non-zero
value. Coasting comes in two flavors: conventional (finger off)
coasting, and corner (finger on) coasting.
Conventional coasting is enabled when coasting is enabled, and
CornerCoasting is set to false. When conventional coasting is enabled,
horizontal/vertical scrolling can continue after the finger is released
from the lower/right edge of the touchpad. The driver computes the
scrolling speed corresponding to the finger speed immediately before the
finger leaves the touchpad. If this scrolling speed is larger than the
CoastingSpeed parameter (measured in scroll events per second), the
scrolling will continue with the same speed in the same direction until
the finger touches the touchpad again.
Corner coasting is enabled when coasting is enabled, and CornerCoasting
is set to true. When corner coasting is enabled, edge scrolling can
continue as long as the finger stays in a corner. Coasting begins when
the finger enters the corner, and continues until the finger leaves the
corner. CornerCoasting takes precedence over the seamless switch from
edge scrolling to circular scrolling. That is, if CornerCoasting is
active, scrolling will stop, and circular scrolling will not start, when
the finger leaves the corner.
Noise cancellation
The synaptics has a built-in noise cancellation based on hysteresis. This
means that incoming coordinates actually shift a box of predefined
dimensions such that it covers the incoming coordinate, and only the
boxes own center is used as input. Obviously, the smaller the box the
better, but the likelihood of noise motion coming through also increases.
ClickPad support
A click pad device has button(s) integrated into the touchpad surface.
The user must press downward on the touchpad in order to generated a
button press. ClickPad support is enabled if the option ClickPad is set
or the property is set at runtime. On some platforms, this option will be
set automatically if the kernel detects a matching device. On Linux, the
device must have the INPUT_PROP_BUTTONPAD property set.
ClickPads do not support middle mouse button emulation. If enabling
ClickPad support at runime, the user must also set the middle mouse
button timeout to 0. If auto-detected, middle mouse button emulation is
disabled by the driver.
ClickPads provide software emulated buttons through Option
"SoftButtonAreas". These buttons enable areas on the touchpad to perform
as right or middle mouse button. When the user performs a click within a
defined soft button area, a right or middle click is performed.
Some laptops, most notably the Lenovo T440, T540 and x240 series, provide
a pointing stick without physical buttons. On those laptops, the top of
the touchpad acts as software-emulated button area. This area can be
enabled with Option "HasSecondarySoftButtons" and configured with Option
"SecondarySoftButtonAreas". On some platforms, this option will be set
automatically if the kernel detects a matching device. On Linux, the
device must have the INPUT_PROP_TOPBUTTONPAD property set.
DEVICE PROPERTIES
Synaptics 1.0 and higher support input device properties if the driver is
running on X server 1.6 or higher. The synclient tool shipped with
synaptics version 1.1 uses input device properties by default.
Properties supported:
Synaptics Edges
32 bit, 4 values, left, right, top, bottom.
Synaptics Finger
32 bit, 3 values, low, high, press.
Synaptics Tap Time
32 bit.
Synaptics Tap Move
32 bit.
Synaptics Tap Durations
32 bit, 3 values, single touch timeout, max tapping time for
double taps, duration of a single click.
Synaptics ClickPad
8 bit (Bool).
Synaptics Middle Button Timeout
32 bit.
Synaptics Two-Finger Pressure
32 bit.
Synaptics Two-Finger Width
32 bit.
Synaptics Scrolling Distance
32 bit, 2 values, vert, horiz.
Synaptics Edge Scrolling
8 bit (BOOL), 3 values, vertical, horizontal, corner.
Synaptics Two-Finger Scrolling
8 bit (BOOL), 2 values, vertical, horizontal.
Synaptics Move Speed
FLOAT, 4 values, min, max, accel, <deprecated>
Synaptics Button Scrolling
8 bit (BOOL), 2 values, updown, leftright.
Synaptics Button Scrolling Repeat
8 bit (BOOL), 2 values, updown, leftright.
Synaptics Button Scrolling Time
32 bit.
Synaptics Off
8 bit, valid values (0, 1, 2).
Synaptics Locked Drags
8 bit (BOOL).
Synaptics Locked Drags Timeout
32 bit.
Synaptics Tap Action
8 bit, up to MAX_TAP values (see synaptics.h), 0 disables an
element. order: RT, RB, LT, LB, F1, F2, F3.
Synaptics Click Action
8 bit, up to MAX_CLICK values (see synaptics.h), 0 disables an
element. order: Finger 1, 2, 3.
Synaptics Circular Scrolling
8 bit (BOOL).
Synaptics Circular Scrolling Distance
FLOAT.
Synaptics Circular Scrolling Trigger
8 bit, valid values 0..8 (inclusive) order: any edge, top, top +
right, right, right + bottom, bottom, bottom + left, left, left +
top.
Synaptics Circular Pad
8 bit (BOOL).
Synaptics Palm Detection
8 bit (BOOL).
Synaptics Palm Dimensions
32 bit, 2 values, width, z.
Synaptics Coasting Speed
FLOAT, 2 values, speed, friction.
Synaptics Pressure Motion
32 bit, 2 values, min, max.
Synaptics Pressure Motion Factor
FLOAT, 2 values, min, max.
Synaptics Grab Event Device
8 bit (BOOL).
Synaptics Gestures
8 bit (BOOL), 1 value, tap-and-drag.
Synaptics Area
The AreaLeftEdge, AreaRightEdge, AreaTopEdge and AreaBottomEdge
parameters are used to define the edges of the active area of the
touchpad. All movements, scrolling and tapping which take place
outside of this area will be ignored. This property is disabled by
default.
32 bit, 4 values, left, right, top, bottom. 0 disables an element.
Synaptics Soft Button Areas
This property is only available on ClickPad devices. The Right
and middle soft button areas are used to support right and middle
click actions on a ClickPad device. Providing 0 for all values of
a given button disables the button area.
32 bit, 8 values, RBL, RBR, RBT, RBB, MBL, MBR, MBT, MBB.
Synaptics Capabilities
This read-only property expresses the physical capability of the
touchpad, most notably whether the touchpad hardware supports
multi-finger tapping and scrolling.
8 bit (BOOL), 7 values (read-only), has left button, has middle
button, has right button, two-finger detection, three-finger
detection, pressure detection, and finger/palm width detection.
Synaptics Pad Resolution
32 bit unsigned, 2 values (read-only), vertical, horizontal in
units/millimeter.
NOTES
Configuration through InputClass sections is recommended in X servers 1.8
and later. See xorg.conf.d(5) for more details. An example xorg.conf.d
snippet is provided in ${sourcecode}/conf/70-synaptics.conf
Configuration through hal fdi files is recommended in X servers 1.5, 1.6
and 1.7. An example hal policy file is provided in
${sourcecode}/conf/11-x11-synaptics.fdi
If either of Protocol "auto-dev" (default) or Protocol "event" is used,
the driver initializes defaults based on the capabilities reported by the
kernel driver. Acceleration, edges and resolution are based on the
dimensions reported by the kernel. If the kernel reports multi-finger
detection, two-finger vertical scrolling is enabled, horizontal two-
finger scrolling is disabled and edge scrolling is disabled. If no multi-
finger capabilities are reported, edge scrolling is enabled for both
horizontal and vertical scrolling. Tapping is disabled by default for
touchpads with one or more physical buttons. To enable it you need to
map tap actions to buttons. See the "TapButton1", "TapButton2" and
"TapButton3" options.
Button mapping for physical buttons is handled in the server. If the
device is switched to left-handed (an in-server mapping of physical
buttons 1, 2, 3 to the logical buttons 3, 2, 1, respectively), both
physical and TapButtons are affected. To counteract this, the TapButtons
need to be set up in reverse order (TapButton1=3, TapButton2=1).
REMOVED OPTIONS
The following options are no longer part of the driver configuration:
Option "Repeater" "string"
Option "HistorySize" "integer"
Option "SpecialScrollAreaRight" "boolean"
Option "GuestMouseOff" "boolean"
Option "SHMConfig" "boolean"
Option "FingerPress" "integer"
Option "TrackstickSpeed" "float"
Option "EdgeMotionMinZ" "integer"
Option "EdgeMotionMaxZ" "integer"
Option "EdgeMotionMinSpeed" "integer"
Option "EdgeMotionMaxSpeed" "integer"
Option "EdgeMotionUseAlways" "boolean"
AUTHORS
Peter Osterlund <petero2@telia.com> and many others.
SEE ALSO
Xorg(1), xorg.conf(5), Xserver(1), X(7), synclient(1), syndaemon(1)
X Version 11 xf86-input-synaptics 1.9.2 SYNAPTICS(4)
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from synaptics.html.html on 2024-12-09.
How to temporarily boot with a different kernel
If you want to permanently replace the kernel please see here.
First go here and download vmlinuz-x.x.x and kernel-modules.sfs-x.x.x, where x.x.x is the kernel version that you want. Vmlinuz is the actual kernel and kernel-modules.sfs contains the kernel modules (drivers) that are built to work with it. Keep the names, you don't have to rename it (although you can if you want to).
Then, in in your bootloader (say grub), add an entry that point to that new kernel.
Also, as part of your boot parameters, specify extrasfs parameter that points out to the downloaded kernel modules.
Example (for grub2, please modify it to suit your own bootloader if you use something else):
menuentry "Fatdog64 5.4.60" {
linux /vmlinuz-5.4.60 rootfstype=ramfs extrasfs=ram:device:sda5:/kernel-modules.sfs-5.4.60
initrd /initrd
}
Then boot. It's that simple. If you only want to do this one time, you can enter into grub during booting stage, and edit the grub lines yourself. Nothing is changed, and on next boot you will get back to your usual kernel.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from temp-boot-kernel.html on 2024-12-09.
Touchpad problems?
To change the behavior of the Synaptics / Alps touch pad, use Control Panel - Display (or "Desktop" on older Fatdogs) - Adjust Touch Pad. If Adjust Touch Pad errors when you launch it, your touch pad is probably not supported yet, see synaptics below.
By default "tap-to-click" is disabled as some touchpads are overly sensitive, making the system impossible to use if it is left on. To turn it back on:
- Open Adjust Touchpad control from within Control Panel (under Display tab ("Desktop" tab on older Fatdogs))
- Check the checkbox next to "Enable tap-to-click".
- Then click apply.
Vertical scrolling is by default enabled, using "two finger" method (touch the touchpad with one finger, then use another finger to touch and move on the touchpad). This of course requires multi-touch touchpad; and if you don't have one you need to use another method for scrolling. To change it, open Adjust Touchpad as above, and then look at the dropdown list for "Scroll Method" and choose another one which is suitable. Don't forget to click apply.
Control Panel - Display (or "Desktop" on older Fatdogs) - Adjust Touch Pad doesn't offer the option you want to adjust, you can do it manually by copying 50-touchpad-gui.conf to /etc/X11/xorg.conf.d/60-touchpad-override.conf. Renaming it with numbers starting with "60" means that whatever setting you specify here will override the settings you set with the "Adjust Touchpad" settings, so beware.
Initially this file (after the copy) will contain the following settings:
#DO NOT EDIT! Used by touchpad settings app.
Section "InputClass"
Identifier "libinput"
Driver "libinput"
MatchDevicePath "/dev/input/event*"
Option "AccelSpeed" "0.00"
Option "DisableWhileTyping" "false"
Option "HorizontalScrolling" "false"
Option "LeftHanded" "false"
Option "MiddleEmulation" "false"
Option "NaturalScrolling" "false"
Option "ScrollMethod" "twofinger"
Option "Tapping" "false"
Option "ClickMethod" "buttonareas"
EndSection
First order of business is to change the identifier from "libinput" to "libinput-override". You can remove the comment on the first line too since we're editing a copy (not the original file) so that warning is not applicable.
Then you can change any other properties and settings. After editing, save the file, and you must restart the X server for changes to take effect.
Here's a couple popular options to adjust :
-
Option "Tapping" "false" This option sets the tap-to-click behavior. Setting this to "false" disables tap-to-click behaviour (which is the default). If you want tap-to-click, change this to "true" to start with and adjust as needed.
-
Option "AccelSpeed" "0.00" This option sets how fast the mouse moves as you drag your finger across the pad. A smaller number is slower, a bigger number is faster. Ranges from -1 to 1.
If you need more configuration options, take a look at the man page for xf86-input-libinput.
Synaptics Driver
If libinput doesn't support your touchpad, use the Gslapt package manager to install xf86-input-synaptics and flSynclient then restart X. Synaptics is an older driver for touchpad and may not work properly for newer devices; however if your hardware is old it may support it better than libinput (or not - you just have to try). It also has a lot more options. Use flSynclient to control its settings. If you don't like it, you can always uninstall it and Xorg will automatically revert to using libinput.
Synaptics can also be configured using a configuration file like above. You can find the details for synaptics driver here.
Mtrack Driver
If libinput or synaptics doesn't support your touchpad properly, use the Gslapt package manager to install xf86-input-mtrack and then restart X. Mtrack is an alternative driver that uses Linux kernel multitouch driver directly. Some touchpad works better with mtrack than libinput, some worse. Just like synaptic, you will just have to try to see if it works. There are reports that it works better for multitouch gestures (two- and three-finger gestures), but of course YMMV. If you don't like it, you can always uninstall it and Xorg will automatically revert to using libinput.
Mtrack has a lot of options, but it does not have a GUI configuration to change these. You have to manually do it. To do so, copy the file /usr/share/X11/xorg.conf.d/55-mtrack.conf to /etc/X11/xorg.conf.d/55-mtrack.conf and then edit this copy. All the available options as listed (as comments) inside that file. Remember you need to restart X in order for the change to take effect. Alternatively, you can make the changes using the xinput program, but these changes will only last until you reboot the system.
Note 1: if you uninstall mtrack, remember to delete the copy of the configuration file /etc/X11/xorg.conf.d/55-mtrack.conf or otherwise your touchpad will stop working altogether as Xorg tries to use a non-existent driver for your touchpad.
Note 2: If you install both mtrack and synaptics driver, the synaptics driver will take precedence and be used instead of mtrack. So if you want to try mtrack and have previously installed synaptics, remember to uninstall synaptics first.
You can find the details about for the mtrack driver here.
Other driver
Yet another driver is xf86-input-mtev but this is a very old driver that was originally meant for multi-touch touchscreen, not touchpad. It may or may not work for you. In fact, most probably it won't. So don't try it unless you are absolutely desperate. Try all other options first. That being said, in order to use it, install it from Gslapt, then create a file called /etc/X11/xorg.conf.d/60-mtev.conf which contains the following:
Section "InputClass"
MatchIsTouchpad "true"
Identifier "Multitouch Touchpad"
Driver "mtrack"
EndSection
As usual, if you decide to uninstall it, don't forget to remove the configuration file.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from touchpad.html on 2024-12-09.
Installing Fatdog64 on a flash drive for UEFI and BIOS booting
Note 1: If you only want to boot on computers with BIOS then use the Fatdog64 installer found in the Control Panel.
Note 2: If you only want to boot on computers with UEFI then use Fatdog64 UEFI installer found in the Control Panel.
Note 3: The method given below will create a read-only filesystems for the boot files. You cannot modify boot configuration (isolinux.cfg or grub.cfg). It will also completely erase your flash drive. If you don't like this limitation or prefer a more flexible solution for UEFI-only booting, please refer to this alternative installation method.
Note 4: There is also another alternative solution if you need to boot on BIOS and UEFI.
The Fatdog64 ISO file is a dual-hybrid ISO file. To install it to a USB flash drive, all you have to do is dd the file on to it. Keep in mind that all files on the flash drive will be destroyed. The flash drive will have two partition tables on it, and Gparted cannot handle adding or modifying partitions correctly.
Please read all of the following steps carefully before actually doing anythig:
1) Plug in the flash drive you want to use. When it appears on the desktop note it's device name. For example "sdb".
2) In the directory that contains the Fatdog64 iso file open a terminal and type this:
dd if=./«Name of iso file» of=/dev/«Flash drive device name» bs=4M
Replace «Name of iso file» with the real name of the iso file and replace «Flash drive device name» with your flash drive's device name from step 1. The 'if' stands for input file, the 'of' stands for output file, and 'bs' stands for block size. The './' means to look in the current directory.
For example if I wanted to dd the Fatdog64-620.iso file on to my flash drive which is identified as sdb. I would do this:
dd if=./Fatdog64-620.iso of=/dev/sdb bs=4M
Make sure that you have the correct device name for you flash drive. If you use the wrong one you could erase you hard drive!
Some flash drives might show desktop icons for sdb and sdb1, and maybe for more partitions. For your device name, use the device name without a number.
3) If you flash drive was bigger than 256MB you can add another partition to use the remaining space for storage. Gparted will have problems with this, fdisk can do it if you're careful not to overlap your new partition. Better yet, you can use the fix-usb.sh script to do it for you. In the terminal type:
./fix-usb.sh /dev/«Flash drive device name»
Then follow the instructions fix-usb.sh gives you.
Note: The fix-usb.sh script is also in the root of the iso in case you're using another Linux distribution.
4) If you have any doubt about what you're doing stop now before you start anything!
Removing Fatdog64 Installation on USB Flashdrive
An USB flashdrive on which the Fatdog.iso has been written following the steps above, cannot be re-partitioned with Gparted anymore because Fatdog's hybrid partitions (combining ISO partition, GPT and MBR partitions) confuse Gparted, regardless of whether it is treated with fix-usb.sh
or not. It will boot, it will work, and it will work very well with Linux on BIOS and UEFI system, but yo cannot re-partition it again with Gparted because it thinks that the flashdrive has invalid partitions.
If you ever need to re-partition the flash drive again, you need to be aware of two things:
a) Doing so will delete all data on the flash drive, so please back up your data first.
b) It will remove Fatdog installation permanently
And to do this, just do
dd if=/dev/zero of=/dev/«Flash drive device name» bs=1M count=1
After doing this Gparted will regard you flash drive as completely empty and will offer to create a new MS-DOS partition table - which you should accept.
Make sure that you have the correct device name for you flash drive. If you use the wrong one you could erase you hard drive!
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from uefi-flashdrive.html on 2024-12-09.
Alternative Flash-drive Installation Method for UEFI Boot
This page explains the method and steps to make a bootable flashdrive suitable for booting on UEFI systems. It assumes that you have booted into Fatdog and you have a copy of the ISO file handy, or you have followed a simplified installation method (in other words, you have a copy of the files from Fatdog distribution).
Firstly you must ensure that you have access to the Fatdog installation files. They are:
- efiboot.img
- vmlinuz
- initrd
- grub.cfg
- fatdog.png
You can find these files inside Fatdog ISO distribution file; you can get access to these files by:
- Burning the ISO to a CD/DVD and you can access them by inserting it to you CD/DVD reader
- Opening the ISO file directly from inside Fatdog (click or double-click on it)
- dd-ing the ISO file to a flash drive using simplified installation and inserting the flash drive to your USB port.
The steps
1) Make sure your flash drive has a FAT32 partition, and it is large enough (512M or more) to hold copies of Fatdog files. Some UEFI firmware accepts FAT16 too but the official standard requires FAT32. Most flash drives today ship with FAT32 factory-formatted so you usually don't even need to do this, but it is always good to check and confirm.
2) Name your partition as "FATDOG_LIVE". Use dosfslabel from terminal to do this.
3) Most UEFI firmware will accept any partition type if you use MBR partition. Some stricter ones don't; and in this case you need to set the partition type to type EF.
If you find that your flash drive is not listed ignored or not recognised by the UEFI firmware boot menu, this may be the case: use fdisk from terminal to do change the partition type as above.
Note: If you use GPT partition then the partition type must be set to EF00. Use gdisk to do this.
4) Do the previous steps above while your partition is *not* mounted. When done, mount your FAT32 partition (just click the drive icon from your desktop).
5) Copy vmlinuz, initrd, grub.cfg and fatdog.png from Fatdog ISO/CD/DVD/flash drive to this FAT32 partition.
6) Open terminal and cd to the path that contains the file efiboot.img. Then type "filemnt efiboot.img". A Rox window will appear. Do not close the terminal window.
7) Copy all the files from this window to your FAT32 partition.
8) Type "filemnt efiboot.img" once again on the same terminal that you did step 6. The rox window should close.
That's it! Unmount your flash drive and you're ready to boot. If you're feeling adventurous, you can go on and create additional partitions (e.g. ext4 or f2fs) on your flash drive for you to put your savefile/savedir there. You can also edit grub.cfg to meet your needs (e.g. adding boot parameters, removing unnecessary entries, etc).
Yet another alternate method
If you feel that the above steps are too complicated, Puppy Linux forum member Ted Dog has prepared a ZIP file that contains pre-packaged boot files extracted from efiboot.img.
All you need to do is: download the ZIP file, extract the content of the ZIP file to that your flash drive, and copy over Fatdog64 ISO file there too. The complete steps and the links to the ZIP file can be found here. The same method can be re-used to boot other Puppy Linux variants too.
Forum member cat&dog has alternate instructions based on Ted Dog's method that works for him, here.
Note 1: If you follow these methods, you do not need to run fix-usb.sh; in fact doing so will ruin your flash drive partitioning; so don't do that.
Note 2: All the configuration files produced by this method is editable. Actually all files are editable.
Note 3: Since this uses standard partition table, Gparted should be able to modify it as usual.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from uefi-flashdrive2.html on 2024-12-09.
Hard drive (frugal) installation of Fatdog64 on a computer with UEFI and secure boot
*Please read this entire process before doing anything.
- This document describes installing Fatdog64 on a computer with UEFI, with or without secure boot. All Windows 8 and newer computers come with secure boot enabled by default.
First you should make sure Fatdog64 boots and works well on your computer. This can be done by booting from a CD/DVD you burned after downloading the iso or by making a bootable flash drive. If your computer is running Windows 8 or newer with secure boot on, see the Booting with secure boot page.
Secondly, please take a look at step 5 and see if you can do that on your computer before proceeding. If you cannot (you cannot add a new bootloader entry inside your EFI BIOS), there is no point in proceeding. You may want to check this page instead: Install to a harddisk when UEFI firmware does not support multiple boot loaders →, or use the LICK Installer.
Do not use the same fat32 partition that Windows uses for its boot, usually sda1 labeled "ESP". Windows uses "Fast boot" aka hibernation by default, and if you write to that partition while Windows is hibernated, when Windows resumes it will corrupt the ESP's filesystem. It is always a good idea to make a backup of the files on the Windows ESP, just in case you do something stupid.
Step 1)
You will need some space on your hard drive to create a couple of new partitions.
Boot into Windows and then:
Right click on My Computer
Select Manage
Click Storage --> Disk Management
Right Click on the drive and click Shrink Volume
Then select the amount of space you want shrink your C: drive.
Minimum would be about 2Gb, more is always better.
In the example below the C: drive is being shrunk by 40GB.
Step 2)
Boot into Fatdog64 from your CD/DVD/Flash drive.
If you booted from a flash drive, remove it after booting.
Then:
Open the Control Panel
Click on the Disk Tab ("Utilities" tab for older Fatdogs)
Double click on Gparted partition editor.
Above: Typical Gparted window with fat32 and ext4 partitions added. The Create new Partition window is opened for demonstration.
Right click on the 'unallocated' partition.
This should be the same size that you shrunk your C: drive in Windows.
Select 'New', the Create new Partition window will pop up.
On the File system pull-down menu select 'fat32'.
For 'New size (MiB):' enter 1000. That makes 1GB.
Enter a Label for the new partition, then click Add.
Right click on the 'unallocated' partition again.
Select 'New', the Create new Partition window will pop up.
On the File system pull-down menu select 'ext4'
For 'New size (MiB):' enter what ever space is left.
Enter a Label for the new partition, then click Add.
After you're done adding partitions click Apply. When Gparted gets done you can close it.
Step 3)
From the panel menu, click on 'Restart X server'.
Click on the new fat32 partition you made to mount it.
Make a EFI/Boot folder inside this partition, and copy the files
from /usr/share/refind-bin-0.11.2/refind to your new fat32 partition.
Rename EFI/Boot/refind_x64.efi to EFI/Boot/bootx64.efi
Copy vmlinuz and initrd from your bootable CD/DVD/Flash drive to your new fat32 partition.
You new fat32 partition should look something like this:
Note: 0.11.2 is the version of rEFInd. It may be different on your installation.
More details on how to find rEFInd here.
For more information on refind, check its documentation page, refind website.
If you have dexv loaded the same information is available in /usr/share/doc/refind-0.11.2
Step 4)
On your new fat32 partition, rename EFI/boot/refind.conf-sample to refind.conf.
Right click on refind.conf and select Edit With Geany.
The refind.conf file should contain this:
#
# refind.conf
# Configuration file for the rEFInd boot menu
# See the refind.conf-sample file for full details.
timeout 10
banner fatdog.png
scanfor manual
menuentry "Fatdog64 Linux" {
icon /EFI/boot/icons/os_fatdog.png
loader vmlinuz
initrd initrd
options "savefile=direct:device:sda7:/fd64save"
(Change sda7 above to whatever your new ext4 partition is.
See boot options for more info.)
}
menuentry "Fatdog64 without savefile" {
icon /EFI/boot/icons/os_fatdog.png
loader vmlinuz
initrd initrd
options "savefile=none"
}
menuentry "Windows 8" {
volume ESP
(Change ESP above to whatever your normal boot partition is.
Usually it's sda1 labeled "ESP".)
loader \EFI\Microsoft\Boot\bootmgfw.efi
}
Click on the new ext4 partition you made to mount it. Then create a new directory named fd64save. You can skip this step if you want to use a save file instead of a save directory, just modify the options in your refind.conf file to reflect whatever you want to name your save file.
If you have problems with refind not finding the ESP partiton when booting, it may show an error like "bootmgfw.efi not found". You can try changing volume from ESP to 0:
(That's a zero and a colon. The zero represents the first partition. If the normal boot partition is on sda2, then you would want "volume 1:".)
If refind still can't find the volume (partition) that the Windows boot loader is on, you can install refind and Fatdog64's kernel and initrd directly to the ESP, if it has the space available. If you do this you must disable hibernation as administrator in Windows, and type powercfg -h off
. The reason for this is that Windows mounts the ESP and when it hibernates it doesn't sync or unmount it. So if you boot another OS, shutdown, and then un-hibernate (Fast boot) Windows, the ESP's VFAT filesystem becomes corrupted.
Step 5)
Now reboot your computer and press f2 to enter UEFI setup (Some computers use a different key to enter setup). Then add your new fat32 partition as a boot option. Unfortunately this process varies quite a bit. Here's the screen a Dell laptop presents:
For this particular laptop you have to disable secure boot to use the "File Browser Add Boot Option", then re-enable it when your done. Again this process varies a lot. Generally on the boot tab you will find some way to add a new boot option. After you find the button to to add a boot option, you will be asked to select a partition. This is kind of cryptic as well, and might take some guessing. Then you will be asked to browse to a bootable EFI application, this will be EFI/boot/bootx64.efi on your new fat32 partition. If you can't browse to that path or you can't see the files that you put in your fat32 partition under EFI/boot/, you probably picked the wrong partition. After you have added your new boot option, move that new boot option to the top of the boot order. Again, this will vary with different UEFI implementations. Then save and reboot.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from uefi-harddrive.html on 2024-12-09.
LICK installer
Overview
LICK is a Windows-based Puppy Linux installer, which fortunately supports Fatdog too.
It install (Puppy/Fatdog) Linux to an existing Windows machine, non-destructively. After installation, you will be able to choose which operating system you want to use - the original Windows, or the newly installed Linux. In other words, it creates a dual-boot installation, which is probably what most of us are after.
It runs from within Windows, read Puppy or Fatdog ISO, copies the files, and modifies Windows bootloader appropriately. It supports Windows 95, 98, ME, 2000, XP, Vista, 7, 8, 8.1 and 10, 32-bit or 64-bit - basically all version of Windows in the last 20-odd years or so, up to the very latest one (as of this writing).
LICK supports installing to both BIOS and UEFI machines, both with or without Secure Boot.
Before you use LICK, please read this entire document. LICK installs to an existing Windows installation and make changes to it, so it is important that you know what you're doing; and where to find help if you get into trouble.
Installation with LICK
You can find LICK inside Fatdog ISO, it will be on its own "lick" subdirectory. The included copy is stored in compressed form to make the size smaller. Run it first to install LICK, and from there you can access LICK form the Administrator's menu.
LICK is easy to use. You just need to have a copy of the ISO image of the (Puppy/Fatdog) Linux you want to install, and that's it. All you need to do is to:
a) Drop and drag the ISO image you want to use
b) GIve an "id" for your-to-be-installed Fatdog (don't include spaces)
c) Give a "name" for the your-to-be-installed Fatdog (anything reasonable goes here)
d) Which drive to install (C:, D:, etc)
And then click "Install". LICK will do the rest.
Notes
LICK is home-grown project from long-time Puppy Linux user and enthusiast, Lukas Lorimer (Puppy Linux forum name noryb009). It is an open-source project with MIT license.
This is LICK forum thread→ on Puppy Linux forum. It is where new releases are announced, and it is also the appropriate thread to ask questions and help. And this is its github→ home, to get both the source and the binaries.
LICK introduction on the forum thread says:
LICK is a Puppy Linux installer for Windows. It configures Windows and Puppy Linux to create a dual-boot environment in just a few clicks. This makes it perfect if you want to try out Linux without the hassle of installing.
LICK is versatile: it can be run on almost any version of Windows, from Windows 95 to Windows 10, on BIOS or UEFI.
LICK is easy to use: It does not require a CD to be burnt or a USB drive to run. Download a Puppy Linux ISO and select it in the program to install it.
LICK is developer-friendly: If you want to bring the power of LICK to your application or distribution, a command line utility and a library are available. LICK is licensed under the MIT license, so feel free to use it however you like.
LICK README on github says:
LICK is a free program to install Linux from Windows without burning a CD or using a USB. It is as simple as installing and running LICK, selecting a Linux ISO image, and clicking install. A few seconds later, you can reboot into Linux. Currently only Puppy Linux-based distributions are supported.
LICK runs on any Windows version, from Windows 95 to Windows 10. Check below for any special notes on your Windows version type.
Download
You can download the latest version of LICK from Github.
Windows Version Notes
Windows 8, 8.1 and 10
Windows 8 and up have a feature called 'Fast Startup'. This cannot be enabled if LICK is installed. LICK disables Fast Startup upon installation.
UEFI Systems with Secure Boot
LICK supports secure boot, but requires a manual step during the first reboot.
- On the first reboot, if you see a blue screen with writing, press enter to select OK.
- Press enter again to select Enroll Hash.
- Use the up and down arrow keys to highlight loader.efi, and press enter.
- Press the down arrow to select Yes, then press enter.
- Use the down arrow to highlight Exit, then press enter.
On subsequent reboots, these steps will not need to be taken.
Windows ME
By default, Windows ME does not have all dependencies LICK requires. To fix this, install Me2Dos. You can also read the README.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from uefi-lick.html on 2024-12-09.
Fatdog64 User Mode Linux (UML) Environment
Introduction
According to User Mode Linux website, User Mode Linux (UML for short) is:
User-Mode Linux is a safe, secure way of running Linux versions and Linux processes. Run buggy software, experiment with new Linux kernels or distributions, and poke around in the internals of Linux, all without risking your main Linux setup.
User-Mode Linux gives you a virtual machine that may have more hardware and software virtual resources than your actual, physical computer. Disk storage for the virtual machine is entirely contained inside a single file on your physical machine. You can assign your virtual machine only the hardware access you want it to have. With properly limited access, nothing you do on the virtual machine can change or damage your real computer, or its software.
UML is one of the earliest attempt at Linux virtualisation (the other one being lguest, which is even lighter than UML but unfortunately only runs on 32-bit kernel). It has been largely superseded by more advanced technologies Kernel-mode Virtual Machine (KVM) and Linux Containers (lxc), and is probably considered to be of only academic interest these days, however it still has life left in it. For example it can be used to provide relatively easy and safe, secure sandboxing of untrusted applications.
Fatdog (since version 620) comes with User Mode Linux (UML) environment. All you need to do to use it, is to install linux_uml and uml_utilities packages, from the Package Manager.
Note for Fatdog64 700 users: if you are familiar with UML operation in Fatdog64 600 series, please read on. The way UML is configured has changed.
Usage
Starting up
To start using if, after installing the packages, all you need is open a Terminal (there is no GUI for this), and type start-uml.sh. This will start a "throwaway" UML VM (or UML "guest") with 256MB of RAM. A window will open with the UML desktop in it.
Shutting down
You can shutdown the UML VM by:
- Use the "shutdown" menu from within the UML desktop
- Run the command "poweroff" from UML console
- If you accidentally close the terminal that runs UML console, run "killall vmlinux" from your host terminal.
It is "throwaway" because as soon as you stop the UML VM, all the information in it is gone - there will be no traces left. In this way, UML is very useful for testing purposes.
Persistent UML
To run a persistent UML session (i.e., to be able to the states between UML shutdown and restart), do the following:
- Make an empty directory to contain the UML session. This directory must be large enough to contain UML's "savefile".
- Start UML like this: start-uml.sh /path/to/session/directory
Once UML has run for the first time in this way, it will create a "config" file in that session directory; which you can edit later. A 128MB savefile is also automatically created for you; if you need anything bigger, just delete that savefile and edit the config to specify a larger value - the savefile will be re-created when you restart UML next time. See below for the details of the config file.
Launching UML without graphical desktop
By default, UML will start with a graphical desktop. If you don't want the graphical desktop, start it like this:
- start-uml.sh "" pfix=nox for throwaway session, or
- start-uml.sh /path/to/session/directory pfix=nox, or
- Edit the config file by putting pfix=nox into BOOT_OPTIONS variable and then start UML the usual way.
The Xephyr window will still open (so that you can type "xwin" to launch a graphical desktop later). If you don't need it, just close it after it opens.
UML session config options
You can put a file named config in the session directory to configure UML's behaviour. This file is automatically created (with default values) if it doesn't exist, or you can create it yourself before you start UML for the first time.
The file contains configuration variables, as follows. Any of these settings can be "blanked" by not specifying the value, e.g. you can blank RAM_SIZE by putting RAM_SIZE= inside the config file.
-
RAM_SIZE (default: 256M)
Determines the size of the RAM allocated to the VM. By default start-uml.sh will assign 256 MB of RAM to the VM. This is a reasonable size for most graphical applications. If you don't run any GUI or other memory intensive applications, you can lower this number. UML itself will happily start with 32MB of RAM (although what you probably can't do much with it).
Note: the letter 'M' is required, it specifies "megabytes". -
SAVEFILE_SIZE (default: 128) and SAVEFILE_FS (default: ext2)
SAVEFILE_SIZE determines the size (in megabytes) of the savefile to be created if it doesn't exist. SAVEFILE_FS determines the filesystem used when the savefile is created (you can specify ext2, ext3 or ext4). If you leave SAVEFILE_SIZE blank, no savefile will be created if it doesn't exist. These variables are ignored if you already have an existing savefile.
Note: Do not append 'M' for SAVEFILE_SIZE, just specify the numbers. -
SAVEFILE_PATH (default: /savefile.ext2)
The location of the savefile, relative to the location of the session directory. Set to blank if you don't want to use a savefile at all (e.g, run a "throwaway" session). Unlike the real Fatdog, if you run without savefile, you will not be prompted to create savefile at the end of the UML session - the session is simply gone after you shut it down. -
HOST_IP (default: blank) and HOST_ADAPTER (default: blank) and UML_IP (default: blank)
These settings control the IP address assignments on the host and the UML "guest". All of these can be left blank, and start-uml.sh will provide reasonable values for them. You can set them manually if you require some special configuration or if the automatic values do not work.- UML_IP sets the address that will be assigned inside the UML "guest" itself. Unless you want to use masquerading, this address must be on the same subnet as the physical network that the host is attached to.
- HOST_IP sets the address that will be used as the "gateway" on the host. It is not really used, but must be assigned, and it has to be on the same subnet as the UML_IP (thus, it has to be on the same subnet as the physical network as well, unless you want to use masquerading).
- HOST_ADAPTER is only used if HOST_IP is blank.
If HOST_IP is blank, it will be set to the IP address of HOST_ADAPTER. If HOST_ADAPTER is blank, then the first active network adapter with an IP address (other than the loopback interface) will be used.
If UML_IP is blank, it will be set to the HOST_IP but with the last component increased by 100 (mod 255). E.g. If your HOST_IP is 10.0.0.5 then UML_IP will be 10.0.0.105; if your HOST_IP is 10.0.0.250 then your UML_IP will be 10.0.0.95 (that is, (250+100) mod 255).
If you leave this parameter blank, it will be set to 100 + IP address from the HOST_ADAPTER will be used. If HOST_ADAPTER is blank, then the first non-local IP address will be used. E.g. if you have both eth0 (IP: 10.0.0.50) and wlan0 (192.168.1.5) and both variables are set to blank, the HOST_IP will be set to 10.0.0.150 and the UML IP will be set to 10.0.0.149.
Note: UML supports sophisticated routing, if you wish you can create network bridges with iptables masquerade etc but these are complex things beyond the purpose of start-uml.sh. If you need to do this you probably want to write your own UML script wrapper, using start-uml.sh as a baseline. -
NAME_SERVER (default: 8.8.8.8)
The DNS server which will be used by UML VM (this is the value that get set inside /etc/resolv.conf) to resolve host names. By default the value is 8.8.8.8, which is Google's DNS server. -
START_CMD (default: blank)
Specifies the command to be automatically executed when UML starts. You can set this to run your own programs directly inside UML; it will be executed in the "root" login context as the last stage of rc.sysinit. -
WINDOW_SIZE (default: 1024x700)
Sets the window size of graphical desktop of the virtual X server (Xephyr). If you leave it blank, no virtual X server will be started and you cannot launch graphical applications. -
NICE_CMD (default: blank)
Specifies the nice command for use when running the UML kernel. It is used to lower down the process priority used by the UML kernel, if you're running as root then it can be used to make UML run faster too by giving it more priority. -
BOOT_OPTIONS (default: blank)
Specifies additional boot options that you want to pass to the UML Linux kernel. For example if you want to load additional SFS or additional disk images, you need to pass the ubdxxx parameters; specify them here. For the full set of available boot options, run /usr/lib64/uml/vmlinux from the terminal.
If you have custom startup script, you can also pass parameters here which can be read by your startup script by inspecting /proc/cmdline.
Note: A few of the variables you define in the config file can be overridden by putting them into the command line when you start UML, for example when starting UML without graphical desktop as above.
Questions and Answers
Question: Why UML, why not KVM or even VirtualBox?
Answer: UML is much smaller, use less resources, makes use of your existing Fatdog installation (no need for separate ISO files), and easier to setup. You can run UML with only 32MB (for text-mode applications) - you can't do that with KVM or VirtualBox.
Question: Fatdog already has sandbox, so what is this UML for?
Answer: Fatdog's sandbox isn't meant for security. It was originally devised for testing foreign packages, so while it can be used for other purposes, there is information leakages to/from the sandbox; and this is intentional - otherwise you'll face problems when testing. For example sandbox and the host shares the same "/tmp" directory. Fatdog's UML however, doesn't suffer from such problem - host and UML guest is completely separate. E.g. If you choose "shutdown" from sandbox's desktop, you will shutdown your entire system (not only the sandbox). Not so with UML. Choosing "shutdown" from UML's desktop will just shutdown UML VM.
Question: What can the UML VM do?
Answer: Almost everything the host system can do. Browse internet, run network applications (servers), etc. Probably not good enough to watch videos, though - there is no video acceleration in UML.
Question: I understand that the UML is isolated, but is there a way to pass data to/from the the UML? Otherwise how can I ever do anything worthwhile with UML?
Answer: Of course there is. The point is, these data sharing is completely under your control.
- You can setup a "savefile", which can be opened while the VM is offline; from there you can copy data to/from it.
- You can copy data using the network (e.g. using samba rox app / yassm, netcat, ssh, rsync, etc).
- You can create additional disk images which can be mounted both by the host and by the UML (using ubdxxx parameter - see below). You can open these disk images from host when they are not mounted from UML VM; and when done you can mount them and access the data from the inside the VM.
Question: UML only loads Fatdog's base sfs. Is there a way to load additional SFS too?
Answer: Yes. Specify additional SFS like this (assuming you want to use a throwaway session):
start-uml.sh "" ubd1rc=/path/to/your/sfs ubd2rc=/path/to/your/sfs, etc
where udb1rc will show up as /dev/udbb inside the UML VM, udb2rc will show up as /dev/udbc, and so on.
Then to load these SFS, once you're inside the UML VM, open terminal and type:
load_sfs.sh /dev/udbb
load_sfs.sh /dev/udbc
and so on. If you're using persistence then replace "" with path to your session directory.
Question: Does running UML require root access?
Answer: No. You can run UML even if you're not root. Inside UML, however, you are root ☺
Question: How do I quit the UML properly?
Answer: Choose "Shutdown" from the desktop menu if you run UML with the desktop (default). If you start UML without the desktop, terminate UML by running poweroff the console window.
-
Do not close the Xephyr window unless you have no plan to run graphical applications. Closing Xephyr window does not stop the UML session (it will terminate all the graphical applications, but not the UML itself).
-
Do not close the terminal window you use to start the UML. Closing this terminal does not stop the UML itself. If you accidentally close the terminal, run killall vmlinux on your host to stop the UML.
Question: OK, now that I can use console only stuff, I need more consoles. How do I get that?
Answer: Run this: setsid getty 38400 tty1 inside the UML VM. An xterm window will be opened that represents your new "console".
Replace tty1 with tty2, tty3, etc as many as you need.
Warning: Once the xterm windows are opened, do not close them; closing them will cause UML to hang. These xterms will automatically be closed when you stop your UML session.
Question: UML is slow!
Answer: Unlike other virtualisation solutions, UML does not create demand on CPU - it will simply use whatever idle power which has been given. The default CPU frequency scaling governor in Fatdog is "ondemand", which means that the CPU power will be controlled by "demand" - if the CPU power is not needed then the frequency of the CPU will lowered to save power and lower down the temperature too. If it detects that there is a "demand" or need for it, it will then increase the frequency to make the CPU more powerful so that it can do its job faster.
UML does not create this demand (even though in reality it is running slow), so the "ondemand" governor does not think it necessary to make the CPU go faster. To fix this, temporarily change the default CPU frequency scaling governor from the default "ondemand" to "performance" (which means run the CPU at full power at all times) while running UML. There is a commented script of how to do so in /etc/rc.d/rc.local.
Alternatively, you can use NICE_CMD configuration options (or run renice if you have already started the UML session) so that the UML kernel will get more priority. This can only be done when you run UML as root.
Further information
- UML's web page here: http://user-mode-linux.sourceforge.net/old/
- See what kernel options are available by opening terminal and running this (on the host): /usr/lib64/uml/vmlinux --help
- Look at start-uml.sh and uml-init scripts source code in /usr/lib64/uml
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from uml.html on 2024-12-09.
Updating browsers
In the Control Panel under the Updates tab you will find utilities for downloading, packaging, and installing the latest versions Firefox, Google Chrome and, for Fatdog64 prior version 900, the Adobe Flash player plugin. These can also be found in the Gslapt package manager. The ones in the package manager have been tested and are known to work with Fatdog64. There is a chance that the lastest ones may not. At the time of this writing the latest versions do work.
Flash Player
The included Flash Player plugin is version 11.x which supports DRM (Digital Rights Management), which is needed for sites with protected video (Hulu). The newer versions of Flash Player for Linux do not support DRM. If you need a current Flash player AND you need DRM, then you will need to install Google Chrome which includes it's own up to date Flash player.
See also Flash in Fatdog64-900.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from updates.html on 2024-12-09.
urxvt (rxvt-unicode) tips
Introduction
urxvt (aka rxvt-unicode) is is a fork of the well known terminal emulator rxvt, with unicode support. It aims to be small (smaller than xterm in terms of memory usage), fast, and complete.
Known issues
Some characters look funny
There can be many causes for why this happens. A common reason is that the font in use does not include the referenced character. This should be fixed by using a more complete font or a fallback font.
Note: the default font, "DejaVu Sans", is very complete.
Powerline fonts
Fatdog sets urxvt's X resource URxvt*letterSpace: -1 to reduce the inter-letter spacing of the default monospace font (DejaVu Sans Mono), so it displays nice and tight, not wasting screen width. However, this spacing can be too small for Powerline fonts, and makes urxvt display boxes. Try changing -1 to 0 or even 1 to help urxvt display the special characters correctly. This will make the terminal window wider. Note: This setting is defined in /etc/X11/app-defaults/URxvt (which you can override by creating an entry in file in ~/.Xdefaults or ~/.Xresources).
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from urxvt.html on 2024-12-09.
Bootable USB Installation
Foreword
This is an alternative installation to install Fatdog64 to a USB flash drive. It will work for both BIOS and (U)EFI machines.
The installation process will destroy the existing content of the flash drive, so either do this on a new USB flash drive or use one that you don't mind erasing.
The installation process requires the use of "dd" command (equivalent on Windows is Win32DiskImager or similar). If you are not familiar with "dd" command, then stop now because the wrong usage of "dd" can cause data loss of your system. (There is a reason why "dd" is sometimes called as "disk destroyer").
This installation will work from Fatdog64 811 onwards. It requires some files which is only distributed in Fatdog64 ISO from version 811 onwards. It would also work on older Fatdogs if you get the necessary files from newer Fatdogs.
Installation
The installation files required for this method can be found in the "usb-boot" folder on the Fatdog ISO.
There are two files: README, and boot-images.tar.xz. It is the latter which is important.
boot-image.tar.xz contains two files, called
- usb-boot-mbr.img (for USB flash drive less than 2TB in size, using MBR partition), and
- usb-boot-gpt.img (for any size, not limited to 2TB, uses GPT partition).
Each one of them expands to about 530MB when extracted. They work identically so this guide will explain how to use the MBR variant. To use the GPT variant, read the supplied README.
First, extract the usb-boot-mbr.img.
Then, use dd
or Win32DiskImager or similar tools, and write it to your USB flash drive. In Linux this can be done as
dd if=usb-boot-mbr.img of=/dev/sdd bs=4k
Assuming that your USB flash drive is at /dev/sdd.
Note: Choosing the wrong target can destroy your harddisk and causes data loss, if you are not sure where the USB flash drive is located, then STOP NOW AND DO NOT CONTINUE WITH THIS PROCESS.
Note that you need to write to the USB disk itself, not its partition, i.e. you need to write to /dev/sdd and not to /dev/sdd1, for example.
Once the "dd" is done, you will end up with two partitions on the USB flash drive. Ignore the first partition (16 MB FAT partition labelled "ESP"), and only look at the second partition (labelled "OS").
The second partition will have the size of 512MB and is formatted as ext4. There are already files stored in this partition, but they are examples only to get your started.
To boot Fatdog, you just need to copy the following files from Fatdog ISO:
- vmlinuz
- initrd
- initrd-nano (optional, only if you have slow BIOS, usually if you run ancient motherboard)
And that's it.
FAQ
Q: But 512MB is too small!
A: Sure. Grab the files, resize the partition using gparted or your other favourite partition tool and copy the files back.
Q: I don't like ext4.
A: Sure. Grab the files, re-format the partition with the filesystem that you like, and copy the files back.
Q: There are only two partitions?
A: Yes. Feel free to create the 3rd, 4th and other partitions as you wish.
Q: Can I edit the example files? For example, can I edit grub.cfg to add other entries?
A: Definitely. Keep a copy in case you mess up, though.
Q: Can I boot other Puppies with this too? Multiple puppies?
A: Sure, if you know the command line parameters that you need to pass, and if you know how to edit grub.cfg to do that.
Q: There are multiple configuration files! I see menu.lst on the "ESP" partition. Which one I should edit?
A: You only need to edit grub.cfg on the "OS" partition. Do not touch anything else. The primary boot loader is grub2.
Q: Can I put OS files in other partition other than "OS"? E.g. Can I create a 3rd partition and put multiple versions of Fatdogs there?
A: Yes you can, but it's better that you re-size "OS" to make it fit to contain all the OS you want to put. Leave the 3rd partition for your data.
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from usb-boot.html on 2024-12-09.
NetBIOS name resolution
If you work often with Samba shares, you know that Samba hostnames (also known as the NetBIOS names) cannot be accessed with the usual tools like ping, mount, etc (will end up with unknown host error) while specialised Samba tools like smbclient apparently can find these servers.
This is because specialised Samba tools uses libraries enabling them to map these NetBIOS names to IP address, and then use the IP address internally. The usual network tools uses DNS for name resolution, and NetBIOS names uses a different mechanism, so it doesn't work.
However, the hostname resolver in glibc is extensible and it is possible to add NetBIOS name resolution mechanism into it, so the from network tools point of view, it looks very similar.
This is done by installing special libraries, a server software (winbindd - which is part of Samba), and editing /etc/nsswitch.conf. This special libraries etc are packaged in a package called samba4-winbindd. Install this package, and then start the winbindd service (you can start manually or configure it to start every time at boot), and magically all your Samba hostnames can be ping-ed, and mounting will not require you to specify IP address, etc.
Note: samba4-winbindd package works with samba4-cutdown package. If you install the FULL samba4 package, these libraries and server are already included; you don't need to install it again. All you need to do is edit /etc/nsswitch.conf and append "wins" to the end of the line that starts with "hosts:"
Fatdog64 | FAQ index | FAQ files | Fatdog64 online | FAQ online
This page was automatically converted from winbindd.html on 2024-12-09.