Ubuntu Server Guide Changes, errors and bugs

Configuration
In addition to local dump, it is now possible to use the remote dump functionality to send the kernel crash
dump to a remote server, using either the SSH or NFS protocols.
Local Kernel Crash Dumps
Local dumps are configured automatically and will remain in use unless a remote protocol is chosen. Many
configuration options exist and are thoroughly documented in the /etc/default/kdump−tools file.
Remote Kernel Crash Dumps using the SSH protocol
To enable remote dumps using the SSH protocol, the /etc/default/kdump−tools must be modified in the
following manner :
# −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
# Remote dump f a c i l i t i e s :
# SSH − username and hostname o f t h e remote s e r v e r t h a t w i l l r e c e i v e t h e dump
#
and dmesg f i l e s .
18

# SSH_KEY − F u l l path o f t h e s s h p r i v a t e key t o be used t o l o g i n t o t h e remote
#
s e r v e r . u s e kdump−c o n f i g p r o p a g a t e t o send t h e p u b l i c key t o t h e
#
remote s e r v e r
# HOSTTAG − S e l e c t i f hostname o f IP a d d r e s s w i l l be used a s a p r e f i x t o t h e
#
timestamped d i r e c t o r y when s e n d i n g f i l e s t o t h e remote s e r v e r .
#
’ ip ’ i s t h e d e f a u l t .
SSH=”ubuntu@kdump−n e t c r a s h ”
The only mandatory variable to define is SSH. It must contain the username and hostname of the remote
server using the format {username}@{remote server}.
SSH_KEY may be used to provide an existing private key to be used. Otherwise, the kdump−config
propagate command will create a new keypair. The HOSTTAG variable may be used to use the hostname
of the system as a prefix to the remote directory to be created instead of the IP address.
The following example shows how kdump−config propagate is used to create and propagate a new keypair
to the remote server :
sudo kdump−c o n f i g p r o p a g a t e
Need t o g e n e r a t e a new s s h key . . .
The a u t h e n t i c i t y o f h o s t ’ kdump−n e t c r a s h ( 1 9 2 . 1 6 8 . 1 . 7 4 ) ’ can ’ t be e s t a b l i s h e d .
ECDSA key f i n g e r p r i n t i s SHA256 : iMp+5Y28qhbd+tevFCWrEXykDd4dI3yN4OVlu3CBBQ4 .
Are you s u r e you want t o c o n t i n u e c o n n e c t i n g ( y e s /no ) ? y e s
ubuntu@kdump−n e t c r a s h ’ s password :
pr o pa g at e d s s h key / r o o t / . s s h /kdump_id_rsa t o s e r v e r ubuntu@kdump−n e t c r a s h
The password of the account used on the remote server will be required in order to successfully send the
public key to the server
The kdump−config show command can be used to confirm that kdump is correctly configured to use the
SSH protocol :
kdump−c o n f i g show
DUMP_MODE:
kdump
USE_KDUMP:
1
KDUMP_SYSCTL:
k e r n e l . panic_on_oops=1
KDUMP_COREDIR:
/ var / c r a s h
c r a s h k e r n e l addr : 0 x2c000000
/ var / l i b /kdump/ vmlinuz : s y m b o l i c l i n k t o / boot / vmlinuz −4.4.0−10− g e n e r i c
kdump i n i t r d :
/ var / l i b /kdump/ i n i t r d . img : s y m b o l i c l i n k t o / var / l i b /kdump/ i n i t r d . img
−4.4.0−10− g e n e r i c
SSH :
ubuntu@kdump−n e t c r a s h
SSH_KEY:
/ r o o t / . s s h /kdump_id_rsa
HOSTTAG:
i p
c u r r e n t s t a t e :
ready t o kdump
Remote Kernel Crash Dumps using the NFS protocol
To enable remote dumps using the NFS protocol, the /etc/default/kdump−tools must be modified in the
following manner :
# NFS −
Hostname and mount p o i n t o f t h e NFS s e r v e r c o n f i g u r e d t o r e c e i v e
#
t h e c r a s h dump . The s y nt a x must be {HOSTNAME} : {MOUNTPOINT}
#
( e . g . remote : / var / c r a s h )
#
NFS=”kdump−n e t c r a s h : / var / c r a s h ”
19

As with the SSH protocol, the HOSTTAG variable can be used to replace the IP address by the hostname
as the prefix of the remote directory.
The kdump−config show command can be used to confirm that kdump is correctly configured to use the
NFS protocol :
kdump−c o n f i g show
DUMP_MODE:
kdump
USE_KDUMP:
1
KDUMP_SYSCTL:
k e r n e l . panic_on_oops=1
KDUMP_COREDIR:
/ var / c r a s h
c r a s h k e r n e l addr : 0 x2c000000
/ var / l i b /kdump/ vmlinuz : s y m b o l i c l i n k t o / boot / vmlinuz −4.4.0−10− g e n e r i c
kdump i n i t r d :
/ var / l i b /kdump/ i n i t r d . img : s y m b o l i c l i n k t o / var / l i b /kdump/ i n i t r d . img
−4.4.0−10− g e n e r i c
NFS :
kdump−n e t c r a s h : / var / c r a s h
HOSTTAG:
hostname
c u r r e n t s t a t e :
ready t o kdump
Verification
To confirm that the kernel dump mechanism is enabled, there are a few things to verify. First, confirm that
the crashkernel boot parameter is present (note: The following line has been split into two to fit the format
of this document:
c a t / p r o c / c m d l i n e
BOOT_IMAGE=/vmlinuz −3.2.0−17− s e r v e r r o o t=/dev /mapper/ P r e c i s e S −r o o t r o
c r a s h k e r n e l =384M−2G: 6 4M, 2G−:128M
The crashkernel parameter has the following syntax:
c r a s h k e r n e l=:< s i z e 1 >[,< range2 >:< s i z e 2 > , . . . ] [ @ o f f s e t ]
r a n g e=s t a r t −[ end ] ’ s t a r t ’ i s i n c l u s i v e and ’ end ’ i s e x c l u s i v e .
So for the crashkernel parameter found in /proc/cmdline we would have :
c r a s h k e r n e l =384M−2G: 6 4M, 2G−:128M
The above value means:
• if the RAM is smaller than 384M, then don’t reserve anything (this is the “rescue” case)
• if the RAM size is between 386M and 2G (exclusive), then reserve 64M
• if the RAM size is larger than 2G, then reserve 128M
Second, verify that the kernel has reserved the requested memory area for the kdump kernel by doing:
dmesg | g r e p − i c r a s h
. . .
[
0 . 0 0 0 0 0 0 ] R e s e r v i n g 64MB o f memory a t 800MB f o r c r a s h k e r n e l ( System RAM:
1023MB)
Finally, as seen previously, the kdump−config show command displays the current status of the kdump-tools
configuration :
20

kdump−c o n f i g show
DUMP_MODE:
kdump
USE_KDUMP:
1
KDUMP_SYSCTL:
k e r n e l . panic_on_oops=1
KDUMP_COREDIR:
/ var / c r a s h
c r a s h k e r n e l addr : 0 x2c000000
/ var / l i b /kdump/ vmlinuz : s y m b o l i c l i n k t o / boot / vmlinuz −4.4.0−10− g e n e r i c
kdump i n i t r d :
/ var / l i b /kdump/ i n i t r d . img : s y m b o l i c l i n k t o / var / l i b /kdump/ i n i t r d . img
−4.4.0−10− g e n e r i c
c u r r e n t s t a t e :
ready t o kdump
k e x e c command :
/ s b i n / k e x e c −p −−command−l i n e =”BOOT_IMAGE=/vmlinuz −4.4.0−10− g e n e r i c r o o t
=/dev /mapper/ VividS−−vg−r o o t r o debug break=i n i t c o n s o l e=ttyS0
, 1 1 5 2 0 0 i r q p o l l maxcpus=1 nousb systemd . u n i t=kdump−t o o l s . s e r v i c e ” −−
i n i t r d =/var / l i b /kdump/ i n i t r d . img / var / l i b /kdump/ vmlinuz
Testing the Crash Dump Mechanism
Warning
Testing the Crash Dump Mechanism will cause a system reboot. In certain situations, this can
cause data loss if the system is under heavy load. If you want to test the mechanism, make sure
that the system is idle or under very light load.
Verify that the SysRQ mechanism is enabled by looking at the value of the /proc/sys/kernel/sysrq kernel
parameter :
c a t / p r o c / s y s / k e r n e l / s y s r q
If a value of 0 is returned the dump and then reboot feature is disabled. A value greater than 1 indicates that
a sub-set of sysrq features is enabled. See /etc/ sysctl .d/10−magic−sysrq.conf for a detailed description of
the options and the default value. Enable dump then reboot testing with the following command :
sudo s y s c t l −w k e r n e l . s y s r q =1
Once this is done, you must become root, as just using sudo will not be sufficient. As the root user, you will
have to issue the command echo c > /proc/sysrq−trigger. If you are using a network connection, you will
lose contact with the system. This is why it is better to do the test while being connected to the system
console. This has the advantage of making the kernel dump process visible.
A typical test output should look like the following :
sudo −s
[ sudo ] password f o r ubuntu :
# echo c > / p r o c / s y s r q −t r i g g e r
[
3 1 . 6 5 9 0 0 2 ] SysRq : T r i g g e r a c r a s h
[
3 1 . 6 5 9 7 4 9 ] BUG: u n a b l e t o h a n d l e k e r n e l NULL p o i n t e r d e r e f e r e n c e a t
( n u l l )
[
3 1 . 6 6 2 6 6 8 ] IP : [< f f f f f f f f 8 1 3 9 f 1 6 6 >] sys rq_handl e_c rash+0x16 /0 x20
[
3 1 . 6 6 2 6 6 8 ] PGD 3 bfb9067 PUD 368 a7067 PMD 0
[
3 1 . 6 6 2 6 6 8 ] Oops : 0002 [ # 1 ] SMP
[
3 1 . 6 6 2 6 6 8 ] CPU 1
. . . .
21

The rest of the output is truncated, but you should see the system rebooting and somewhere in the log, you
will see the following line :
Begin : Saving vmcore from k e r n e l c r a s h . . .
Once completed, the system will reboot to its normal operational mode. You will then find the Kernel Crash
Dump file, and related subdirectories, in the /var/crash directory :
l s / var / c r a s h
201809240744
kexec_cmd
l i n u x −image −4.15.0 −34 − g e n e r i c −201809240744. c r a s h
If the dump does not work due to OOM (Out Of Memory) error, then try increasing the amount of reserved
memory by editing /etc/default/grub.d/kdump−tools.cfg. For example, to reserve 512 megabytes :
GRUB_CMDLINE_LINUX_DEFAULT=”$GRUB_CMDLINE_LINUX_DEFAULT c r a s h k e r n e l =384M−:512M
”
run sudo update−grub and then reboot afterwards, and then test again.
Resources
Kernel Crash Dump is a vast topic that requires good knowledge of the linux kernel. You can find more
information on the topic here :
• Kdump kernel documentation.
• The crash tool
• Analyzing Linux Kernel Crash (Based on Fedora, it still gives a good walkthrough of kernel dump
analysis)
Reporting Bugs in Ubuntu Server
The Ubuntu Project, and thus Ubuntu Server, uses Launchpad as its bug tracker. In order to file a bug, you
will need a Launchpad account. Create one here if necessary.
Reporting Bugs With apport-cli
The preferred way to report a bug is with the apport-cli command. It must be invoked on the machine
affected by the bug because it collects information from the system on which it is being run and publishes
it to the bug report on Launchpad. Getting that information to Launchpad can, therefore, be a challenge if
the system is not running a desktop environment in order to use a browser (common with servers) or if it
does not have Internet access. The steps to take in these situations are described below.
Note
The commands apport-cli and ubuntu-bug should give the same results on a CLI server. The
latter is actually a symlink to apport-bug which is intelligent enough to know whether a desktop
environment is in use and will choose apport-cli if not. Since server systems tend to be CLI-only
apport-cli was chosen from the outset in this guide.
Bug reports in Ubuntu need to be filed against a specific software package, so the name of the package
(source package or program name/path) affected by the bug needs to be supplied to apport-cli:
apport− c l i PACKAGENAME
22

Once apport-cli has finished gathering information you will be asked what to do with it. For instance, to
report a bug in vim:
$ apport− c l i vim
*** C o l l e c t i n g problem i n f o r m a t i o n
The c o l l e c t e d i n f o r m a t i o n can be s e n t t o t h e d e v e l o p e r s t o improve t h e
a p p l i c a t i o n . This might t a k e a few minutes .
. . .
*** Send problem r e p o r t t o t h e d e v e l o p e r s ?
A f t e r t h e problem r e p o r t has been s e n t , p l e a s e f i l l out t h e form i n t h e
a u t o m a t i c a l l y opened web bro ws er .
What would you l i k e t o do ? Your o p t i o n s a r e :
S : Send r e p o r t ( 2 . 8 KB)
V: View r e p o r t
K: Keep r e p o r t f i l e f o r s e n d i n g l a t e r o r c o p y i n g t o somewhere e l s e
I : Cancel and i g n o r e f u t u r e c r a s h e s o f t h i s program v e r s i o n
C: Cancel
P l e a s e c h o o s e ( S/V/K/ I /C) :
The first three options are described below:
• Send: submits the collected information to Launchpad as part of the process of filing a new bug report.
You will be given the opportunity to describe the bug in your own words.
*** Uploading problem i n f o r m a t i o n
The c o l l e c t e d i n f o r m a t i o n i s b e i n g s e n t t o t h e bug t r a c k i n g system .
This might t a k e a few minutes .
94%
*** To c o n t i n u e , you must v i s i t t h e f o l l o w i n g URL:
h t t p s : / / bugs . launchpad . n e t / ubuntu/+s o u r c e /vim/+ f i l e b u g /09 b2495a−e2ab −11
e3 −879b−68b5996a96c8 ?
You can l a u n c h a br ows er now , o r copy t h i s URL i n t o a b r ow s e r on a n o t h e r
computer .
C h o i c e s :
1 : Launch a br ow se r now
C : Cancel
P l e a s e c h o o s e ( 1 /C) :
1
The browser that will be used when choosing ‘1’ will be the one known on the system as www-browser
via the Debian alternatives system. Examples of text-based browsers to install include links, elinks,
lynx, and w3m. You can also manually point an existing browser at the given URL.
• View: displays the collected information on the screen for review. This can be a lot of information.
Press ‘Enter’ to scroll by a screenful. Press ‘q’ to quit and return to the choice menu.
23

• Keep: writes the collected information to disk. The resulting file can be later used to file the bug
report, typically after transferring it to another Ubuntu system.
What would you l i k e t o do ? Your o p t i o n s a r e :
S : Send r e p o r t ( 2 . 8 KB)
V: View r e p o r t
K: Keep r e p o r t f i l e f o r s e n d i n g l a t e r o r c o p y i n g t o somewhere e l s e
I : Cancel and i g n o r e f u t u r e c r a s h e s o f t h i s program v e r s i o n
C : Cancel
P l e a s e c h o o s e ( S/V/K/ I /C) : k
Problem r e p o r t f i l e : /tmp/ a p p o r t . vim . 1 pg92p02 . a p p o r t
To report the bug, get the file onto an Internet-enabled Ubuntu system and apply apport-cli to it. This
will cause the menu to appear immediately (the information is already collected). You should then
press ‘s’ to send:
apport− c l i a p p o r t . vim . 1 pg92p02 . a p p o r t
To directly save a report to disk (without menus) you can do:
apport− c l i vim −−s a v e a p p o r t . vim . t e s t . a p p o r t
Report names should end in .apport.
Note
If this Internet-enabled system is non-Ubuntu/Debian, apport-cli is not available so the bug
will need to be created manually. An apport report is also not to be included as an attachment
to a bug either so it is completely useless in this scenario.
Reporting Application Crashes
The software package that provides the apport-cli utility, apport, can be configured to automatically capture
the state of a crashed application. This is enabled by default (in /etc/default/apport).
After an application crashes, if enabled, apport will store a crash report under /var/crash:
−rw−r−−−−− 1 p e t e r
whoopsie 150K J u l 24 1 6 : 1 7 _usr_lib_x86_64−l i n u x −
gnu_libmenu−cache2_libexec_menu−cached . 1 0 0 0 . c r a s h
Use the apport-cli command without arguments to process any pending crash reports. It will offer to report
them one by one.
apport− c l i
*** Send problem r e p o r t t o t h e d e v e l o p e r s ?
A f t e r t h e problem r e p o r t has been s e n t , p l e a s e f i l l out t h e form i n t h e
a u t o m a t i c a l l y opened web bro ws er .
What would you l i k e t o do ? Your o p t i o n s a r e :
S : Send r e p o r t ( 1 5 3 . 0 KB)
V: View r e p o r t
K: Keep r e p o r t f i l e f o r s e n d i n g l a t e r o r c o p y i n g t o somewhere e l s e
I : Cancel and i g n o r e f u t u r e c r a s h e s o f t h i s program v e r s i o n
C: Cancel
P l e a s e c h o o s e ( S/V/K/ I /C) : s
24

If you send the report, as was done above, the prompt will be returned immediately and the /var/crash
directory will then contain 2 extra files:
−rw−r−−−−− 1 p e t e r
whoopsie 150K J u l 24 1 6 : 1 7 _usr_lib_x86_64−l i n u x −
gnu_libmenu−cache2_libexec_menu−cached . 1 0 0 0 . c r a s h
−rw−rw−r−− 1 p e t e r
whoopsie
0 J u l 24 1 6 : 3 7 _usr_lib_x86_64−l i n u x −
gnu_libmenu−cache2_libexec_menu−cached . 1 0 0 0 . upload
−rw−−−−−−− 1 whoopsie whoopsie
0 J u l 24 1 6 : 3 7 _usr_lib_x86_64−l i n u x −
gnu_libmenu−cache2_libexec_menu−cached . 1 0 0 0 . uploaded
Sending in a crash report like this will not immediately result in the creation of a new public bug. The report
will be made private on Launchpad, meaning that it will be visible to only a limited set of bug triagers. These
triagers will then scan the report for possible private data before creating a public bug.
Resources
• See the Reporting Bugs Ubuntu wiki page.
• Also, the Apport page has some useful information. Though some of it pertains to using a GUI.
Upgrading
There are several ways to upgrade from one Ubuntu release to another. This section gives an overview of
the recommended upgrade method.
do-release-upgrade
The recommended way to upgrade a Server Edition installation is to use the do-release-upgrade utility. Part
of the update-manager-core package, it does not have any graphical dependencies and is installed by default.
Debian based systems can also be upgraded by using apt dist−upgrade. However, using do-release-upgrade
is recommended because it has the ability to handle system configuration changes sometimes needed between
releases.
To upgrade to a newer release, from a terminal prompt enter:
do−r e l e a s e −upgrade
It is also possible to use do-release-upgrade to upgrade to a development version of Ubuntu. To accomplish
this use the -d switch:
do−r e l e a s e −upgrade −d
Warning
Upgrading to a development release is not recommended for production environments.
For further stability of an LTS release, there is a slight change in behaviour if you are currently running an
LTS version. LTS systems are only automatically considered for an upgrade to the next LTS via do-release-
upgrade with the first point release. So for example 18.04 will only upgrade once 20.04.1 is released. If you
want to update before, e.g. on a subset of machines to evaluate the LTS upgrade for your setup the same
argument as an upgrade to a dev release has to be used via the -d switch.
25

Device Mapper Multipathing - Introduction
Device Mapper Multipath will be referred here as multipath only.
Multipath allows you to configure multiple I/O paths between server nodes and storage arrays into a single
device. These I/O paths are physical SAN connections that can include separate cables, switches, and
controllers.
Multipathing aggregates the I/O paths, creating a new device that consists of the aggregated paths. This
chapter provides an introduction and a high-level overview of multipath.
Overview
Multipath can be used to provide:
• Redundancy
multipath can provide failover in an active/passive configuration. In an active/passive
configuration, only half the paths are used at any time for I/O. If any element of an I/O path (the
cable, switch, or controller) fails, multipath switches to an alternate path.
• Improved Performance Multipath can be configured in active/active mode, where I/O is spread over
the paths in a round-robin fashion. In some configurations, multipath can detect loading on the I/O
paths and dynamically re-balance the load.
Storage Array Overview
It is a very good idea to consult your storage vendor installation guide for the recommended multipath
configuration variables for your storage model. The default configuration will probably work but will likely
need adjustments based on your storage setup.
Multipath Components
| Component
| Description | | - | - | | dm_multipath kernel module | Reroutes
I/O and supports failover for paths and path groups. | | multipath command | Lists and configures
multipath devices. Normally started up with /etc/rc. sysinit , it can also be started up by a udev program
whenever a block device is added or it can be run by the initramfs file system. | | multipathd daemon |
Monitors paths; as paths fail and come back, it may initiate path group switches. Provides for interactive
changes to multipath devices. This daemon must be restarted for any changes to the /etc/multipath.conf
file to take effect. | | kpartx command | Creates device mapper devices for the partitions on a device It is
necessary to use this command for DOS-based partitions with multipath. The kpartx is provided in its own
package, but the multipath-tools package depends on it. |
Multipath Setup Overview
multipath includes compiled-in default settings that are suitable for common multipath configurations.
Setting up multipath is often a simple procedure. The basic procedure for configuring your system with
multipath is as follows:
1. Install the multipath-tools and multipath-tools-boot packages
2. Create an empty config file called /etc/multipath.conf
3. Edit the multipath.conf file to modify default values and save the updated file.
4. Start the multipath daemon
26

5. Update initial ramdisk
For detailed setup instructions for multipath configuration see DM-Multipath Configuration and DM-
Multipath Setup.
Multipath Devices
Without multipath, each path from a server node to a storage controller is treated by the system as a
separate device, even when the I/O path connects the same server node to the same storage controller.
Multipath provides a way of organizing the I/O paths logically, by creating a single device on top of the
underlying paths.