Package: lvm2; Maintainer for lvm2 is Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>; Source for lvm2 is src:lvm2 (PTS, buildd, popcon).
Reported by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Date: Thu, 9 Jul 2015 03:21:02 UTC
Severity: grave
Merged with 774082, 782793, 782865, 792002
Found in versions lvm2/2.02.122-2, lvm2/2.02.111-2.2, lvm2/2.02.126-2, lvm2/2.02.122-1
Fixed in versions lvm2/2.02.126-3, 1.02.126-3
Done: Bastian Blank <waldi@debian.org>
Bug is archived. No further changes may be made.
View this report as an mbox folder, status mbox, maintainer mbox
Report forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Thu, 09 Jul 2015 03:21:05 GMT) (full text, mbox, link).
Acknowledgement sent
to Stefan Lippers-Hollmann <s.l-h@gmx.de>:
New Bug report received and forwarded. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Thu, 09 Jul 2015 03:21:06 GMT) (full text, mbox, link).
Message #5 received at submit@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Package: lvm2 Version: 2.02.122-1 Severity: serious Hi Upgrading src:lvm2 from 2.02.111-2.2 to 2.02.122-1 breaks booting due to a new systemd unit dependency failures regarding lvmetad when mounting non-rootfs logical volumes. Jumping to the emergency shell and invoking "vgchange -ay" and "mount -a" allows booting to finish. Reverting all src:lvm2 packages to 2.02.111-2.2 from testing avoids the problem, re-upgrading results in the same error condition again. I can reproduce the problem on several distinct systems, which share a similar fstab structure for the basic system paths; in all cases all fstab devices exist and can be auto-mounted with src:lvm2 2.02.111-2.2. I have attached the logs for "journalctl -xb" (gzipped) and the fstab. Regards Stefan Lippers-Hollmann -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.1.0-1.slh.3-aptosid-amd64 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lvm2 depends on: ii dmeventd 2:1.02.99-1 ii dmsetup 2:1.02.99-1 ii init-system-helpers 1.23 ii initscripts 2.88dsf-59.2 ii libc6 2.19-18 ii libdevmapper-event1.02.1 2:1.02.99-1 ii libdevmapper1.02.1 2:1.02.99-1 ii libreadline5 5.2+dfsg-3 ii libudev1 222-1 ii lsb-base 4.1+Debian13+nmu1 lvm2 recommends no packages. Versions of packages lvm2 suggests: pn thin-provisioning-tools <none> -- no debconf information
[fstab (application/octet-stream, attachment)]
[journalctl-xb.log.gz (application/gzip, attachment)]
[Message part 4 (application/pgp-signature, inline)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Thu, 09 Jul 2015 17:45:34 GMT) (full text, mbox, link).
Acknowledgement sent
to Marcelo Santana <marcelo@msantana.eng.br>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Thu, 09 Jul 2015 17:45:35 GMT) (full text, mbox, link).
Message #10 received at 791869@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Package: lvm2 Version: 2.02.122-1 Hi there, I've got the same bug and I've had to downgrade the lvm2 packages too. Note: My partitions are encrypted. Regards, Marcelo --- System information. --- Architecture: amd64 Kernel: Linux 4.0.0-2-amd64 Debian Release: stretch/sid 40 experimental ftp.br.debian.org 100 unstable ftp.br.debian.org --- Package information. --- Depends (Version) | Installed ==============================================-+-================== libc6 (>= 2.15) | libdevmapper-event1.02.1 (>= 2:1.02.74) | libdevmapper1.02.1 (>= 2:1.02.85) | libreadline5 (>= 5.2) | libudev1 (>= 183) | init-system-helpers (>= 1.18~) | lsb-base | dmsetup (>> 2:1.02.47) | initscripts (>= 2.88dsf-13.3) | Package's Recommends field is empty. Suggests (Version) | Installed ======================================-+-=========== thin-provisioning-tools |
[Message part 2 (application/pgp-signature, inline)]
Severity set to 'grave' from 'serious'
Request was from Bastian Blank <waldi@debian.org>
to control@bugs.debian.org.
(Sat, 11 Jul 2015 19:48:10 GMT) (full text, mbox, link).
Merged 791869 792002
Request was from Bastian Blank <waldi@debian.org>
to control@bugs.debian.org.
(Sat, 11 Jul 2015 19:48:11 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, achim_schaefer@gmx.de, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Thu, 16 Jul 2015 05:24:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Achim Schaefer <achim_schaefer@gmx.de>:
Extra info received and forwarded to list. Copy sent to achim_schaefer@gmx.de, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Thu, 16 Jul 2015 05:24:04 GMT) (full text, mbox, link).
Message #19 received at 791869@bugs.debian.org (full text, mbox, reply):
Package: lvm2
Version: 2.02.122-2
Followup-For: Bug #791869
Dear Maintainer,
just to confirm, this bug is still in the latest version
Regards
Achim
-- System Information:
Debian Release: stretch/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages lvm2 depends on:
ii dmeventd 2:1.02.99-2
ii dmsetup 2:1.02.99-2
ii init-system-helpers 1.23
ii initscripts 2.88dsf-59.2
ii libc6 2.19-19
ii libdevmapper-event1.02.1 2:1.02.99-2
ii libdevmapper1.02.1 2:1.02.99-2
ii liblvm2app2.2 2.02.122-2
ii libreadline5 5.2+dfsg-3
ii libudev1 222-2
ii lsb-base 4.1+Debian13+nmu1
lvm2 recommends no packages.
Versions of packages lvm2 suggests:
pn thin-provisioning-tools <none>
-- Configuration Files:
/etc/lvm/lvm.conf changed:
config {
# Configuration option config/checks.
# If enabled, any LVM configuration mismatch is reported.
# This implies checking that the configuration key is understood
# by LVM and that the value of the key is the proper type.
# If disabled, any configuration mismatch is ignored and the default
# value is used without any warning (a message about the
# configuration key not being found is issued in verbose mode only).
checks = 1
# Configuration option config/abort_on_errors.
# Abort the LVM process if a configuration mismatch is found.
abort_on_errors = 0
# Configuration option config/profile_dir.
# Directory where LVM looks for configuration profiles.
profile_dir = "/etc/lvm/profile"
}
devices {
# Configuration option devices/dir.
# Directory in which to create volume group device nodes.
# Commands also accept this as a prefix on volume group names.
# This configuration option is advanced.
dir = "/dev"
# Configuration option devices/scan.
# Directories containing device nodes to use with LVM.
# This configuration option is advanced.
scan = [ "/dev" ]
# Configuration option devices/obtain_device_list_from_udev.
# Obtain the list of available devices from udev.
# This avoids opening or using any inapplicable non-block
# devices or subdirectories found in the udev directory.
# Any device node or symlink not managed by udev in the udev
# directory is ignored. This setting applies only to the
# udev-managed device directory; other directories will be
# scanned fully. LVM needs to be compiled with udev support
# for this setting to apply.
obtain_device_list_from_udev = 1
# Configuration option devices/external_device_info_source.
# Select an external device information source.
# Some information may already be available in the system and
# LVM can use this information to determine the exact type
# or use of devices it processes. Using an existing external
# device information source can speed up device processing
# as LVM does not need to run its own native routines to acquire
# this information. For example, this information is used to
# drive LVM filtering like MD component detection, multipath
# component detection, partition detection and others.
# Possible options are: none, udev.
# none - No external device information source is used.
# udev - Reuse existing udev database records. Applicable
# only if LVM is compiled with udev support.
external_device_info_source = "none"
# Configuration option devices/preferred_names.
# Select which path name to display for a block device.
# If multiple path names exist for a block device,
# and LVM needs to display a name for the device,
# the path names are matched against each item in
# this list of regular expressions. The first match is used.
# Try to avoid using undescriptive /dev/dm-N names, if present.
# If no preferred name matches, or if preferred_names are not
# defined, built-in rules are used until one produces a preference.
# Rule 1 checks path prefixes and gives preference in this order:
# /dev/mapper, /dev/disk, /dev/dm-*, /dev/block (/dev from devices/dev)
# Rule 2 prefers the path with the least slashes.
# Rule 3 prefers a symlink.
# Rule 4 prefers the path with least value in lexicographical order.
# Example:
# preferred_names = [ "^/dev/mpath/", "^/dev/mapper/mpath", "^/dev/[hs]d" ]
# This configuration option does not have a default value defined.
# preferred_names=[]
# Configuration option devices/filter.
# Limit the block devices that are used by LVM commands.
# This is a list of regular expressions used to accept or
# reject block device path names. Each regex is delimited
# by a vertical bar '|' (or any character) and is preceded
# by 'a' to accept the path, or by 'r' to reject the path.
# The first regex in the list to match the path is used,
# producing the 'a' or 'r' result for the device.
# When multiple path names exist for a block device, if any
# path name matches an 'a' pattern before an 'r' pattern,
# then the device is accepted. If all the path names match
# an 'r' pattern first, then the device is rejected.
# Unmatching path names do not affect the accept or reject
# decision. If no path names for a device match a pattern,
# then the device is accepted.
# Be careful mixing 'a' and 'r' patterns, as the combination
# might produce unexpected results (test any changes.)
# Run vgscan after changing the filter to regenerate the cache.
# See the use_lvmetad comment for a special case regarding filters.
# Example:
# Accept every block device.
# filter = [ "a|.*/|" ]
# Example:
# Reject the cdrom drive.
# filter = [ "r|/dev/cdrom|" ]
# Example:
# Work with just loopback devices, e.g. for testing.
# filter = [ "a|loop|", "r|.*|" ]
# Example:
# Accept all loop devices and ide drives except hdc.
# filter = [ "a|loop|", "r|/dev/hdc|", "a|/dev/ide|", "r|.*|" ]
# Example:
# Use anchors to be very specific.
# filter = [ "a|^/dev/hda8$|", "r|.*/|" ]
# This configuration option does not have a default value defined.
# filter = []
# Configuration option devices/global_filter.
# Limit the block devices that are used by LVM system components.
# Because devices/filter may be overridden from the command line,
# it is not suitable for system-wide device filtering, e.g. udev
# and lvmetad. Use global_filter to hide devices from these LVM
# system components. The syntax is the same as devices/filter.
# Devices rejected by global_filter are not opened by LVM.
# This configuration option does not have a default value defined.
# global_filter = []
# Configuration option devices/cache_dir.
# Directory in which to store the device cache file.
# The results of filtering are cached on disk to avoid
# rescanning dud devices (which can take a very long time).
# By default this cache is stored in a file named .cache.
# It is safe to delete this file; the tools regenerate it.
# If obtain_device_list_from_udev is enabled, the list of devices
# is obtained from udev and any existing .cache file is removed.
cache_dir = "/run/lvm"
# Configuration option devices/cache_file_prefix.
# A prefix used before the .cache file name. See devices/cache_dir.
cache_file_prefix = ""
# Configuration option devices/write_cache_state.
# Enable/disable writing the cache file. See devices/cache_dir.
write_cache_state = 1
# Configuration option devices/types.
# List of additional acceptable block device types.
# These are of device type names from /proc/devices,
# followed by the maximum number of partitions.
# Example:
# types = [ "fd", 16 ]
# This configuration option is advanced.
# This configuration option does not have a default value defined.
# types = []
# Configuration option devices/sysfs_scan.
# Restrict device scanning to block devices appearing in sysfs.
# This is a quick way of filtering out block devices that are
# not present on the system. sysfs must be part of the kernel
# and mounted.)
sysfs_scan = 1
# Configuration option devices/multipath_component_detection.
# Ignore devices that are components of DM multipath devices.
multipath_component_detection = 1
# Configuration option devices/md_component_detection.
# Ignore devices that are components of software RAID (md) devices.
md_component_detection = 1
# Configuration option devices/fw_raid_component_detection.
# Ignore devices that are components of firmware RAID devices.
# LVM must use an external_device_info_source other than none
# for this detection to execute.
fw_raid_component_detection = 0
# Configuration option devices/md_chunk_alignment.
# Align PV data blocks with md device's stripe-width.
# This applies if a PV is placed directly on an md device.
md_chunk_alignment = 1
# Configuration option devices/default_data_alignment.
# Default alignment of the start of a PV data area in MB.
# If set to 0, a value of 64KB will be used.
# Set to 1 for 1MiB, 2 for 2MiB, etc.
# default_data_alignment = 1
# Configuration option devices/data_alignment_detection.
# Detect PV data alignment based on sysfs device information.
# The start of a PV data area will be a multiple of
# minimum_io_size or optimal_io_size exposed in sysfs.
# minimum_io_size is the smallest request the device can perform
# without incurring a read-modify-write penalty, e.g. MD chunk size.
# optimal_io_size is the device's preferred unit of receiving I/O,
# e.g. MD stripe width.
# minimum_io_size is used if optimal_io_size is undefined (0).
# If md_chunk_alignment is enabled, that detects the optimal_io_size.
# This setting takes precedence over md_chunk_alignment.
data_alignment_detection = 1
# Configuration option devices/data_alignment.
# Alignment of the start of a PV data area in KB.
# If a PV is placed directly on an md device and
# md_chunk_alignment or data_alignment_detection are enabled,
# then this setting is ignored. Otherwise, md_chunk_alignment
# and data_alignment_detection are disabled if this is set.
# Set to 0 to use the default alignment or the page size, if larger.
data_alignment = 0
# Configuration option devices/data_alignment_offset_detection.
# Detect PV data alignment offset based on sysfs device information.
# The start of a PV aligned data area will be shifted by the
# alignment_offset exposed in sysfs. This offset is often 0, but
# may be non-zero. Certain 4KB sector drives that compensate for
# windows partitioning will have an alignment_offset of 3584 bytes
# (sector 7 is the lowest aligned logical block, the 4KB sectors start
# at LBA -1, and consequently sector 63 is aligned on a 4KB boundary).
# pvcreate --dataalignmentoffset will skip this detection.
data_alignment_offset_detection = 1
# Configuration option devices/ignore_suspended_devices.
# Ignore DM devices that have I/O suspended while scanning devices.
# Otherwise, LVM waits for a suspended device to become accessible.
# This should only be needed in recovery situations.
ignore_suspended_devices = 0
# Configuration option devices/ignore_lvm_mirrors.
# Do not scan 'mirror' LVs to avoid possible deadlocks.
# This avoids possible deadlocks when using the 'mirror'
# segment type. This setting determines whether logical volumes
# using the 'mirror' segment type are scanned for LVM labels.
# This affects the ability of mirrors to be used as physical volumes.
# If this setting is enabled, it becomes impossible to create VGs
# on top of mirror LVs, i.e. to stack VGs on mirror LVs.
# If this setting is disabled, allowing mirror LVs to be scanned,
# it may cause LVM processes and I/O to the mirror to become blocked.
# This is due to the way that the mirror segment type handles failures.
# In order for the hang to occur, an LVM command must be run just after
# a failure and before the automatic LVM repair process takes place,
# or there must be failures in multiple mirrors in the same VG at the
# same time with write failures occurring moments before a scan of the
# mirror's labels.
# The 'mirror' scanning problems do not apply to LVM RAID types like
# 'raid1' which handle failures in a different way, making them a
# better choice for VG stacking.
ignore_lvm_mirrors = 1
# Configuration option devices/disable_after_error_count.
# Number of I/O errors after which a device is skipped.
# During each LVM operation, errors received from each device
# are counted. If the counter of a device exceeds the limit set
# here, no further I/O is sent to that device for the remainder
# of the operation.
# Setting this to 0 disables the counters altogether.
disable_after_error_count = 0
# Configuration option devices/require_restorefile_with_uuid.
# Allow use of pvcreate --uuid without requiring --restorefile.
require_restorefile_with_uuid = 1
# Configuration option devices/pv_min_size.
# Minimum size (in KB) of block devices which can be used as PVs.
# In a clustered environment all nodes must use the same value.
# Any value smaller than 512KB is ignored. The previous built-in
# value was 512.
pv_min_size = 2048
# Configuration option devices/issue_discards.
# Issue discards to PVs that are no longer used by an LV.
# Discards are sent to an LV's underlying physical volumes when
# the LV is no longer using the physical volumes' space, e.g.
# lvremove, lvreduce. Discards inform the storage that a region
# is no longer used. Storage that supports discards advertise
# the protocol-specific way discards should be issued by the
# kernel (TRIM, UNMAP, or WRITE SAME with UNMAP bit set).
# Not all storage will support or benefit from discards, but SSDs
# and thinly provisioned LUNs generally do. If enabled, discards
# will only be issued if both the storage and kernel provide support.
issue_discards = 0
}
allocation {
# Configuration option allocation/cling_tag_list.
# Advise LVM which PVs to use when searching for new space.
# When searching for free space to extend an LV, the 'cling'
# allocation policy will choose space on the same PVs as the last
# segment of the existing LV. If there is insufficient space and a
# list of tags is defined here, it will check whether any of them are
# attached to the PVs concerned and then seek to match those PV tags
# between existing extents and new extents.
# Example:
# Use the special tag "@*" as a wildcard to match any PV tag.
# cling_tag_list = [ "@*" ]
# Example:
# LVs are mirrored between two sites within a single VG.
# PVs are tagged with either @site1 or @site2 to indicate where
# they are situated.
# cling_tag_list = [ "@site1", "@site2" ]
# This configuration option does not have a default value defined.
# cling_tag_list = []
# Configuration option allocation/maximise_cling.
# Use a previous allocation algorithm.
# Changes made in version 2.02.85 extended the reach of the 'cling'
# policies to detect more situations where data can be grouped onto
# the same disks. This setting can be used to disable the changes
# and revert to the previous algorithm.
maximise_cling = 1
# Configuration option allocation/use_blkid_wiping.
# Use blkid to detect existing signatures on new PVs and LVs.
# The blkid library can detect more signatures than the
# native LVM detection code, but may take longer.
# LVM needs to be compiled with blkid wiping support for
# this setting to apply.
# LVM native detection code is currently able to recognize:
# MD device signatures, swap signature, and LUKS signatures.
# To see the list of signatures recognized by blkid, check the
# output of the 'blkid -k' command.
use_blkid_wiping = 1
# Configuration option allocation/wipe_signatures_when_zeroing_new_lvs.
# Look for and erase any signatures while zeroing a new LV.
# Zeroing is controlled by the -Z/--zero option, and if not
# specified, zeroing is used by default if possible.
# Zeroing simply overwrites the first 4 KiB of a new LV
# with zeroes and does no signature detection or wiping.
# Signature wiping goes beyond zeroing and detects exact
# types and positions of signatures within the whole LV.
# It provides a cleaner LV after creation as all known
# signatures are wiped. The LV is not claimed incorrectly
# by other tools because of old signatures from previous use.
# The number of signatures that LVM can detect depends on the
# detection code that is selected (see use_blkid_wiping.)
# Wiping each detected signature must be confirmed.
# The command line option -W/--wipesignatures takes precedence
# over this setting.
# When this setting is disabled, signatures on new LVs are
# not detected or erased unless the -W/--wipesignatures y
# option is used directly.
wipe_signatures_when_zeroing_new_lvs = 1
# Configuration option allocation/mirror_logs_require_separate_pvs.
# Mirror logs and images will always use different PVs.
# The default setting changed in version 2.02.85.
mirror_logs_require_separate_pvs = 0
# Configuration option allocation/cache_pool_metadata_require_separate_pvs.
# Cache pool metadata and data will always use different PVs.
cache_pool_metadata_require_separate_pvs = 0
# Configuration option allocation/cache_pool_cachemode.
# The default cache mode used for new cache pools.
# Possible options are: writethrough, writeback.
# writethrough - Data blocks are immediately written from
# the cache to disk.
# writeback - Data blocks are written from the cache back
# to disk after some delay to improve performance.
# cache_pool_cachemode = "writethrough"
# Configuration option allocation/cache_pool_chunk_size.
# The minimal chunk size (in kiB) for cache pool volumes.
# Using a chunk_size that is too large can result in wasteful
# use of the cache, where small reads and writes can cause
# large sections of an LV to be mapped into the cache. However,
# choosing a chunk_size that is too small can result in more
# overhead trying to manage the numerous chunks that become mapped
# into the cache. The former is more of a problem than the latter
# in most cases, so we default to a value that is on the smaller
# end of the spectrum. Supported values range from 32(kiB) to
# 1048576 in multiples of 32.
# This configuration option does not have a default value defined.
# cache_pool_chunk_size = 128
# Configuration option allocation/thin_pool_metadata_require_separate_pvs.
# Thin pool metdata and data will always use different PVs.
thin_pool_metadata_require_separate_pvs = 0
# Configuration option allocation/thin_pool_zero.
# Thin pool data chunks are zeroed before they are first used.
# Zeroing with a larger thin pool chunk size reduces performance.
# thin_pool_zero = 1
# Configuration option allocation/thin_pool_discards.
# The discards behaviour of thin pool volumes.
# Possible options are: ignore, nopassdown, passdown.
# thin_pool_discards = "passdown"
# Configuration option allocation/thin_pool_chunk_size_policy.
# The chunk size calculation policy for thin pool volumes.
# Possible options are: generic, performance.
# generic - If thin_pool_chunk_size is defined, use it.
# Otherwise, calculate the chunk size based on estimation and
# device hints exposed in sysfs - the minimum_io_size.
# The chunk size is always at least 64KiB.
# performance - If thin_pool_chunk_size is defined, use it.
# Otherwise, calculate the chunk size for performance based on
# device hints exposed in sysfs - the optimal_io_size.
# The chunk size is always at least 512KiB.
# thin_pool_chunk_size_policy = "generic"
# Configuration option allocation/thin_pool_chunk_size.
# The minimal chunk size (in KB) for thin pool volumes.
# Larger chunk sizes may improve performance for plain
# thin volumes, however using them for snapshot volumes
# is less efficient, as it consumes more space and takes
# extra time for copying. When unset, lvm tries to estimate
# chunk size starting from 64KB. Supported values are in
# the range 64 to 1048576.
# This configuration option does not have a default value defined.
# thin_pool_chunk_size = 128
# Configuration option allocation/physical_extent_size.
# Default physical extent size to use for new VGs (in KB).
# physical_extent_size = 4096
}
log {
# Configuration option log/verbose.
# Controls the messages sent to stdout or stderr.
verbose = 0
# Configuration option log/silent.
# Suppress all non-essential messages from stdout.
# This has the same effect as -qq.
# When enabled, the following commands still produce output:
# dumpconfig, lvdisplay, lvmdiskscan, lvs, pvck, pvdisplay,
# pvs, version, vgcfgrestore -l, vgdisplay, vgs.
# Non-essential messages are shifted from log level 4 to log level 5
# for syslog and lvm2_log_fn purposes.
# Any 'yes' or 'no' questions not overridden by other arguments
# are suppressed and default to 'no'.
silent = 0
# Configuration option log/syslog.
# Send log messages through syslog.
syslog = 1
# Configuration option log/file.
# Write error and debug log messages to a file specified here.
# This configuration option does not have a default value defined.
# file = ""
# Configuration option log/overwrite.
# Overwrite the log file each time the program is run.
overwrite = 0
# Configuration option log/level.
# The level of log messages that are sent to the log file or syslog.
# There are 6 syslog-like log levels currently in use: 2 to 7 inclusive.
# 7 is the most verbose (LOG_DEBUG).
level = 7
# Configuration option log/indent.
# Indent messages according to their severity.
indent = 1
# Configuration option log/command_names.
# Display the command name on each line of output.
command_names = 0
# Configuration option log/prefix.
# A prefix to use before the log message text.
# (After the command name, if selected).
# Two spaces allows you to see/grep the severity of each message.
# To make the messages look similar to the original LVM tools use:
# indent = 0, command_names = 1, prefix = " -- "
prefix = " "
# Configuration option log/activation.
# Log messages during activation.
# Don't use this in low memory situations (can deadlock).
# activation = 1
# Configuration option log/debug_classes.
# Select log messages by class.
# Some debugging messages are assigned to a class
# and only appear in debug output if the class is
# listed here. Classes currently available:
# memory, devices, activation, allocation,
# lvmetad, metadata, cache, locking, lvmpolld.
# Use "all" to see everything.
debug_classes = ["memory", "devices", "activation", "allocation",
"lvmetad", "metadata", "cache", "locking", "lvmpolld"]
}
backup {
# Configuration option backup/backup.
# Maintain a backup of the current metadata configuration.
# Think very hard before turning this off!
backup = 1
# Configuration option backup/backup_dir.
# Location of the metadata backup files.
# Remember to back up this directory regularly!
backup_dir = "/etc/lvm/backup"
# Configuration option backup/archive.
# Maintain an archive of old metadata configurations.
# Think very hard before turning this off.
archive = 1
# Configuration option backup/archive_dir.
# Location of the metdata archive files.
# Remember to back up this directory regularly!
archive_dir = "/etc/lvm/archive"
# Configuration option backup/retain_min.
# Minimum number of archives to keep.
retain_min = 10
# Configuration option backup/retain_days.
# Minimum number of days to keep archive files.
retain_days = 30
}
shell {
# Configuration option shell/history_size.
# Number of lines of history to store in ~/.lvm_history.
history_size = 100
}
global {
# Configuration option global/umask.
# The file creation mask for any files and directories created.
# Interpreted as octal if the first digit is zero.
umask = 077
# Configuration option global/test.
# No on-disk metadata changes will be made in test mode.
# Equivalent to having the -t option on every command.
test = 0
# Configuration option global/units.
# Default value for --units argument.
units = "h"
# Configuration option global/si_unit_consistency.
# Distinguish between powers of 1024 and 1000 bytes.
# The LVM commands distinguish between powers of 1024 bytes,
# e.g. KiB, MiB, GiB, and powers of 1000 bytes, e.g. KB, MB, GB.
# If scripts depend on the old behaviour, disable
# this setting temporarily until they are updated.
si_unit_consistency = 1
# Configuration option global/suffix.
# Display unit suffix for sizes.
# This setting has no effect if the units are in human-readable
# form (global/units = "h") in which case the suffix is always
# displayed.
suffix = 1
# Configuration option global/activation.
# Enable/disable communication with the kernel device-mapper.
# Disable to use the tools to manipulate LVM metadata without
# activating any logical volumes. If the device-mapper driver
# is not present in the kernel, disabling this should suppress
# the error messages.
activation = 1
# Configuration option global/fallback_to_lvm1.
# Try running LVM1 tools if LVM cannot communicate with DM.
# This option only applies to 2.4 kernels and is provided to
# help switch between device-mapper kernels and LVM1 kernels.
# The LVM1 tools need to be installed with .lvm1 suffices,
# e.g. vgscan.lvm1. They will stop working once the lvm2
# on-disk metadata format is used.
# fallback_to_lvm1 = 0
# Configuration option global/format.
# The default metadata format that commands should use.
# "lvm1" or "lvm2".
# The command line override is -M1 or -M2.
# format = "lvm2"
# Configuration option global/format_libraries.
# Shared libraries that process different metadata formats.
# If support for LVM1 metadata was compiled as a shared library use
# format_libraries = "liblvm2format1.so"
# This configuration option does not have a default value defined.
# format_libraries = []
# Configuration option global/segment_libraries.
# This configuration option does not have a default value defined.
# segment_libraries = []
# Configuration option global/proc.
# Location of proc filesystem.
# This configuration option is advanced.
proc = "/proc"
# Configuration option global/etc.
# Location of /etc system configuration directory.
etc = "${exec_prefix}/etc"
# Configuration option global/locking_type.
# Type of locking to use.
# Type 0: turns off locking. Warning: this risks metadata
# corruption if commands run concurrently.
# Type 1: uses local file-based locking, the standard mode.
# Type 2: uses the external shared library locking_library.
# Type 3: uses built-in clustered locking with clvmd.
# This is incompatible with lvmetad. If use_lvmetad is enabled,
# lvm prints a warning and disables lvmetad use.
# Type 4: uses read-only locking which forbids any operations
# that might change metadata.
# Type 5: offers dummy locking for tools that do not need any locks.
# You should not need to set this directly; the tools will select
# when to use it instead of the configured locking_type.
# Do not use lvmetad or the kernel device-mapper driver with this
# locking type. It is used by the --readonly option that offers
# read-only access to Volume Group metadata that cannot be locked
# safely because it belongs to an inaccessible domain and might be
# in use, for example a virtual machine image or a disk that is
# shared by a clustered machine.
locking_type = 1
# Configuration option global/wait_for_locks.
# When disabled, fail if a lock request would block.
wait_for_locks = 1
# Configuration option global/fallback_to_clustered_locking.
# Attempt to use built-in cluster locking if locking_type 2 fails.
# If using external locking (type 2) and initialisation fails,
# with this enabled, an attempt will be made to use the built-in
# clustered locking.
# If you are using a customised locking_library you should disable this.
fallback_to_clustered_locking = 1
# Configuration option global/fallback_to_local_locking.
# Use locking_type 1 (local) if locking_type 2 or 3 fail.
# If an attempt to initialise type 2 or type 3 locking failed,
# perhaps because cluster components such as clvmd are not
# running, with this enabled, an attempt will be made to use
# local file-based locking (type 1). If this succeeds, only
# commands against local volume groups will proceed.
# Volume Groups marked as clustered will be ignored.
fallback_to_local_locking = 1
# Configuration option global/locking_dir.
# Directory to use for LVM command file locks.
# Local non-LV directory that holds file-based locks
# while commands are in progress. A directory like
# /tmp that may get wiped on reboot is OK.
locking_dir = "/run/lock/lvm"
# Configuration option global/prioritise_write_locks.
# Allow quicker VG write access during high volume read access.
# When there are competing read-only and read-write access
# requests for a volume group's metadata, instead of always
# granting the read-only requests immediately, delay them to
# allow the read-write requests to be serviced. Without this
# setting, write access may be stalled by a high volume of
# read-only requests.
# This option only affects locking_type 1 viz.
# local file-based locking.
prioritise_write_locks = 1
# Configuration option global/library_dir.
# Search this directory first for shared libraries.
# This configuration option does not have a default value defined.
# library_dir = ""
# Configuration option global/locking_library.
# The external locking library to use for locking_type 2.
# locking_library = "liblvm2clusterlock.so"
# Configuration option global/abort_on_internal_errors.
# Abort a command that encounters an internal error.
# Treat any internal errors as fatal errors, aborting
# the process that encountered the internal error.
# Please only enable for debugging.
abort_on_internal_errors = 0
# Configuration option global/detect_internal_vg_cache_corruption.
# Internal verification of VG structures.
# Check if CRC matches when a parsed VG is
# used multiple times. This is useful to catch
# unexpected changes to cached VG structures.
# Please only enable for debugging.
detect_internal_vg_cache_corruption = 0
# Configuration option global/metadata_read_only.
# No operations that change on-disk metadata are permitted.
# Additionally, read-only commands that encounter metadata
# in need of repair will still be allowed to proceed exactly
# as if the repair had been performed (except for the unchanged
# vg_seqno). Inappropriate use could mess up your system,
# so seek advice first!
metadata_read_only = 0
# Configuration option global/mirror_segtype_default.
# The segment type used by the short mirroring option -m.
# Possible options are: mirror, raid1.
# mirror - the original RAID1 implementation from LVM/DM.
# It is characterized by a flexible log solution (core,
# disk, mirrored), and by the necessity to block I/O while
# handling a failure.
# There is an inherent race in the dmeventd failure
# handling logic with snapshots of devices using this
# type of RAID1 that in the worst case could cause a
# deadlock. (Also see devices/ignore_lvm_mirrors.)
# raid1 - a newer RAID1 implementation using the MD RAID1
# personality through device-mapper. It is characterized
# by a lack of log options. (A log is always allocated for
# every device and they are placed on the same device as the
# image - no separate devices are required.) This mirror
# implementation does not require I/O to be blocked while
# handling a failure. This mirror implementation is not
# cluster-aware and cannot be used in a shared (active/active)
# fashion in a cluster.
# The '--type mirror|raid1' option overrides this setting.
mirror_segtype_default = "raid1"
# Configuration option global/raid10_segtype_default.
# The segment type used by the -i -m combination.
# The --stripes/-i and --mirrors/-m options can both
# be specified during the creation of a logical volume
# to use both striping and mirroring for the LV.
# There are two different implementations.
# Possible options are: raid10, mirror.
# raid10 - LVM uses MD's RAID10 personality through DM.
# mirror - LVM layers the 'mirror' and 'stripe' segment types.
# The layering is done by creating a mirror LV on top of
# striped sub-LVs, effectively creating a RAID 0+1 array.
# The layering is suboptimal in terms of providing redundancy
# and performance. The 'raid10' option is perferred.
# The '--type raid10|mirror' option overrides this setting.
raid10_segtype_default = "raid10"
# Configuration option global/sparse_segtype_default.
# The segment type used by the -V -L combination.
# The combination of -V and -L options creates a
# sparse LV. There are two different implementations.
# Possible options are: snapshot, thin.
# snapshot - The original snapshot implementation from LVM/DM.
# It uses an old snapshot that mixes data and metadata within
# a single COW storage volume and performs poorly when the
# size of stored data passes hundreds of MB.
# thin - A newer implementation that uses thin provisioning.
# It has a bigger minimal chunk size (64KiB) and uses a separate
# volume for metadata. It has better performance, especially
# when more data is used. It also supports full snapshots.
# The '--type snapshot|thin' option overrides this setting.
sparse_segtype_default = "thin"
# Configuration option global/lvdisplay_shows_full_device_path.
# The default format for displaying LV names in lvdisplay was changed
# in version 2.02.89 to show the LV name and path separately.
# Previously this was always shown as /dev/vgname/lvname even when that
# was never a valid path in the /dev filesystem.
# Enable this option to reinstate the previous format.
# lvdisplay_shows_full_device_path = 0
# Configuration option global/use_lvmetad.
# Use lvmetad to cache metadata and reduce disk scanning.
# When enabled (and running), lvmetad provides LVM commands
# with VG metadata and PV state. LVM commands then avoid
# reading this information from disks which can be slow.
# When disabled (or not running), LVM commands fall back to
# scanning disks to obtain VG metadata.
# lvmetad is kept updated via udev rules which must be set
# up for LVM to work correctly. (The udev rules should be
# installed by default.) Without a proper udev setup, changes
# in the system's block device configuration will be unknown
# to LVM, and ignored until a manual 'pvscan --cache' is run.
# If lvmetad was running while use_lvmetad was disabled,
# it must be stopped, use_lvmetad enabled, and then started.
# When using lvmetad, LV activation is switched to an automatic,
# event-based mode. In this mode, LVs are activated based on
# incoming udev events that inform lvmetad when PVs appear on
# the system. When a VG is complete (all PVs present), it is
# auto-activated. The auto_activation_volume_list setting
# controls which LVs are auto-activated (all by default.)
# When lvmetad is updated (automatically by udev events, or
# directly by pvscan --cache), devices/filter is ignored and
# all devices are scanned by default. lvmetad always keeps
# unfiltered information which is provided to LVM commands.
# Each LVM command then filters based on devices/filter.
# This does not apply to other, non-regexp, filtering settings:
# component filters such as multipath and MD are checked
# during pvscan --cache.
# To filter a device and prevent scanning from the LVM system
# entirely, including lvmetad, use devices/global_filter.
# lvmetad is not compatible with locking_type 3 (clustering).
# LVM prints warnings and ignores lvmetad if this combination
# is seen.
use_lvmetad = 1
# Configuration option global/thin_check_executable.
# The full path to the thin_check command.
# LVM uses this command to check that a thin metadata
# device is in a usable state.
# When a thin pool is activated and after it is deactivated,
# this command is run. Activation will only proceed if the
# command has an exit status of 0.
# Set to "" to skip this check. (Not recommended.)
# Also see thin_check_options.
# The thin tools are available from the package
# device-mapper-persistent-data.
# thin_check_executable = "/usr/sbin/thin_check"
# Configuration option global/thin_dump_executable.
# The full path to the thin_dump command.
# LVM uses this command to dump thin pool metadata.
# (For thin tools, see thin_check_executable.)
# thin_dump_executable = "/usr/sbin/thin_dump"
# Configuration option global/thin_repair_executable.
# The full path to the thin_repair command.
# LVM uses this command to repair a thin metadata device
# if it is in an unusable state.
# Also see thin_repair_options.
# (For thin tools, see thin_check_executable.)
# thin_repair_executable = "/usr/sbin/thin_repair"
# Configuration option global/thin_check_options.
# List of options passed to the thin_check command.
# With thin_check version 2.1 or newer you can add
# --ignore-non-fatal-errors to let it pass through
# ignorable errors and fix them later.
# With thin_check version 3.2 or newer you should add
# --clear-needs-check-flag.
# thin_check_options = ["-q", "--clear-needs-check-flag"]
# Configuration option global/thin_repair_options.
# List of options passed to the thin_repair command.
# This configuration option does not have a default value defined.
# thin_repair_options = ""
# Configuration option global/thin_disabled_features.
# Features to not use in the thin driver.
# This can be helpful for testing, or to avoid
# using a feature that is causing problems.
# Features: block_size, discards, discards_non_power_2,
# external_origin, metadata_resize, external_origin_extend,
# error_if_no_space.
# Example:
# thin_disabled_features = [ "discards", "block_size" ]
# This configuration option does not have a default value defined.
# thin_disabled_features = []
# Configuration option global/cache_check_executable.
# The full path to the cache_check command.
# LVM uses this command to check that a cache metadata
# device is in a usable state.
# When a cached LV is activated and after it is deactivated,
# this command is run. Activation will only proceed if the
# command has an exit status of 0.
# Set to "" to skip this check. (Not recommended.)
# Also see cache_check_options.
# The cache tools are available from the package
# device-mapper-persistent-data.
# cache_check_executable = "/usr/sbin/cache_check"
# Configuration option global/cache_dump_executable.
# The full path to the cache_dump command.
# LVM uses this command to dump cache pool metadata.
# (For cache tools, see cache_check_executable.)
# cache_dump_executable = "/usr/sbin/cache_dump"
# Configuration option global/cache_repair_executable.
# The full path to the cache_repair command.
# LVM uses this command to repair a cache metadata device
# if it is in an unusable state.
# Also see cache_repair_options.
# (For cache tools, see cache_check_executable.)
# cache_repair_executable = "/usr/sbin/cache_repair"
# Configuration option global/cache_check_options.
# List of options passed to the cache_check command.
# cache_check_options = "-q"
# Configuration option global/cache_repair_options.
# List of options passed to the cache_repair command.
# This configuration option does not have a default value defined.
# cache_repair_options = ""
# Configuration option global/system_id_source.
# The method LVM uses to set the local system ID.
# Volume Groups can also be given a system ID (by
# vgcreate, vgchange, or vgimport.)
# A VG on shared storage devices is accessible only
# to the host with a matching system ID.
# See 'man lvmsystemid' for information on limitations
# and correct usage.
# Possible options are: none, lvmlocal, uname, machineid, file.
# none - The host has no system ID.
# lvmlocal - Obtain the system ID from the system_id setting in the
# 'local' section of an lvm configuration file, e.g. lvmlocal.conf.
# uname - Set the system ID from the hostname (uname) of the system.
# System IDs beginning localhost are not permitted.
# machineid - Use the contents of the file ${exec_prefix}/etc/machine-id to set the
# system ID. Some systems create this file at installation time.
# See 'man machine-id'.
# file - Use the contents of another file (system_id_file) to set
# the system ID.
# system_id_source = "none"
# Configuration option global/system_id_file.
# The full path to the file containing a system ID.
# This is used when system_id_source is set to 'file'.
# Comments starting with the character # are ignored.
# This configuration option does not have a default value defined.
# system_id_file = ""
# Use lvmpolld to supervise long running LVM commands.
# When enabled, control of long running LVM commands is transferred
# from the original LVM command to the lvmpolld daemon. This allows
# the operation to continue independent of the original LVM command.
# After lvmpolld takes over, the LVM command displays the progress
# of the ongoing operation. lvmpolld itself runs LVM commands to manage
# the progress of ongoing operations. lvmpolld can be used as a native
# systemd service, which allows it to be started on demand, and to use
# its own control group. When this option is disabled, LVM commands will
# supervise long running operations by forking themselves.
use_lvmpolld = 1
}
activation {
# Configuration option activation/checks.
# Perform internal checks of libdevmapper operations.
# Useful for debugging problems with activation.
# Some of the checks may be expensive, so it's best to use
# this only when there seems to be a problem.
checks = 0
# Configuration option activation/udev_sync.
# Use udev notifications to synchronize udev and LVM.
# When disabled, LVM commands will not wait for notifications
# from udev, but continue irrespective of any possible udev
# processing in the background. Only use this if udev is not
# running or has rules that ignore the devices LVM creates.
# If enabled when udev is not running, and LVM processes
# are waiting for udev, run 'dmsetup udevcomplete_all' to
# wake them up.
# The '--nodevsync' option overrides this setting.
udev_sync = 1
# Configuration option activation/udev_rules.
# Use udev rules to manage LV device nodes and symlinks.
# When disabled, LVM will manage the device nodes and
# symlinks for active LVs itself.
# Manual intervention may be required if this setting is
# changed while LVs are active.
udev_rules = 1
# Configuration option activation/verify_udev_operations.
# Use extra checks in LVM to verify udev operations.
# This enables additional checks (and if necessary,
# repairs) on entries in the device directory after
# udev has completed processing its events.
# Useful for diagnosing problems with LVM/udev interactions.
verify_udev_operations = 0
# Configuration option activation/retry_deactivation.
# Retry failed LV deactivation.
# If LV deactivation fails, LVM will retry for a few
# seconds before failing. This may happen because a
# process run from a quick udev rule temporarily opened
# the device.
retry_deactivation = 1
# Configuration option activation/missing_stripe_filler.
# Method to fill missing stripes when activating an incomplete LV.
# Using 'error' will make inaccessible parts of the device return
# I/O errors on access. You can instead use a device path, in which
# case, that device will be used in place of missing stripes.
# Using anything other than 'error' with mirrored or snapshotted
# volumes is likely to result in data corruption.
# This configuration option is advanced.
missing_stripe_filler = "error"
# Configuration option activation/use_linear_target.
# Use the linear target to optimize single stripe LVs.
# When disabled, the striped target is used. The linear
# target is an optimised version of the striped target
# that only handles a single stripe.
use_linear_target = 1
# Configuration option activation/reserved_stack.
# Stack size in KB to reserve for use while devices are suspended.
# Insufficent reserve risks I/O deadlock during device suspension.
reserved_stack = 64
# Configuration option activation/reserved_memory.
# Memory size in KB to reserve for use while devices are suspended.
# Insufficent reserve risks I/O deadlock during device suspension.
reserved_memory = 8192
# Configuration option activation/process_priority.
# Nice value used while devices are suspended.
# Use a high priority so that LVs are suspended
# for the shortest possible time.
process_priority = -18
# Configuration option activation/volume_list.
# Only LVs selected by this list are activated.
# If this list is defined, an LV is only activated
# if it matches an entry in this list.
# If this list is undefined, it imposes no limits
# on LV activation (all are allowed).
# Possible options are: vgname, vgname/lvname, @tag, @*
# vgname is matched exactly and selects all LVs in the VG.
# vgname/lvname is matched exactly and selects the LV.
# @tag selects if tag matches a tag set on the LV or VG.
# @* selects if a tag defined on the host is also set on
# the LV or VG. See tags/hosttags.
# If any host tags exist but volume_list is not defined,
# a default single-entry list containing '@*' is assumed.
# Example:
# volume_list = [ "vg1", "vg2/lvol1", "@tag1", "@*" ]
# This configuration option does not have a default value defined.
# volume_list = []
# Configuration option activation/auto_activation_volume_list.
# Only LVs selected by this list are auto-activated.
# This list works like volume_list, but it is used
# only by auto-activation commands. It does not apply
# to direct activation commands.
# If this list is defined, an LV is only auto-activated
# if it matches an entry in this list.
# If this list is undefined, it imposes no limits
# on LV auto-activation (all are allowed.)
# If this list is defined and empty, i.e. "[]",
# then no LVs are selected for auto-activation.
# An LV that is selected by this list for
# auto-activation, must also be selected by
# volume_list (if defined) before it is activated.
# Auto-activation is an activation command that
# includes the 'a' argument: --activate ay or -a ay,
# e.g. vgchange -a ay, or lvchange -a ay vgname/lvname.
# The 'a' (auto) argument for auto-activation is
# meant to be used by activation commands that are
# run automatically by the system, as opposed to
# LVM commands run directly by a user. A user may
# also use the 'a' flag directly to perform auto-
# activation.
# An example of a system-generated auto-activation
# command is 'pvscan --cache -aay' which is generated
# when udev and lvmetad detect a new VG has appeared
# on the system, and want LVs in it to be auto-activated.
# Possible options are: vgname, vgname/lvname, @tag, @*
# See volume_list for how these options are matched to LVs.
# This configuration option does not have a default value defined.
# auto_activation_volume_list = []
# Configuration option activation/read_only_volume_list.
# LVs in this list are activated in read-only mode.
# If this list is defined, each LV that is to be activated
# is checked against this list, and if it matches, it is
# activated in read-only mode.
# This overrides the permission setting stored in the
# metadata, e.g. from --permission rw.
# Possible options are: vgname, vgname/lvname, @tag, @*
# See volume_list for how these options are matched to LVs.
# This configuration option does not have a default value defined.
# read_only_volume_list = []
# Configuration option activation/raid_region_size.
# Size in KiB of each raid or mirror synchronization region.
# For raid or mirror segment types, this is the amount of
# data that is copied at once when initializing, or moved
# at once by pvmove.
raid_region_size = 512
# Configuration option activation/error_when_full.
# Return errors if a thin pool runs out of space.
# When enabled, writes to thin LVs immediately return
# an error if the thin pool is out of data space.
# When disabled, writes to thin LVs are queued if the
# thin pool is out of space, and processed when the
# thin pool data space is extended.
# New thin pools are assigned the behavior defined here.
# The '--errorwhenfull y|n' option overrides this setting.
# error_when_full = 0
# Configuration option activation/readahead.
# Setting to use when there is no readahead setting in metadata.
# Possible options are: none, auto.
# none - Disable readahead.
# auto - Use default value chosen by kernel.
readahead = "auto"
# Configuration option activation/raid_fault_policy.
# Defines how a device failure in a RAID LV is handled.
# This includes LVs that have the following segment types:
# raid1, raid4, raid5*, and raid6*.
# If a device in the LV fails, the policy determines the
# steps perfomed by dmeventd automatically, and the steps
# perfomed by 'lvconvert --repair --use-policies' run manually.
# Automatic handling requires dmeventd to be monitoring the LV.
# Possible options are: warn, allocate.
# warn - Use the system log to warn the user that a device
# in the RAID LV has failed. It is left to the user to run
# 'lvconvert --repair' manually to remove or replace the failed
# device. As long as the number of failed devices does not
# exceed the redundancy of the logical volume (1 device for
# raid4/5, 2 for raid6, etc) the LV will remain usable.
# allocate - Attempt to use any extra physical volumes in the
# volume group as spares and replace faulty devices.
raid_fault_policy = "warn"
# Configuration option activation/mirror_image_fault_policy.
# Defines how a device failure in a 'mirror' LV is handled.
# An LV with the 'mirror' segment type is composed of mirror
# images (copies) and a mirror log.
# A disk log ensures that a mirror LV does not need to be
# re-synced (all copies made the same) every time a machine
# reboots or crashes.
# If a device in the LV fails, this policy determines the
# steps perfomed by dmeventd automatically, and the steps
# performed by 'lvconvert --repair --use-policies' run manually.
# Automatic handling requires dmeventd to be monitoring the LV.
# Possible options are: remove, allocate, allocate_anywhere.
# remove - Simply remove the faulty device and run without it.
# If the log device fails, the mirror would convert to using
# an in-memory log. This means the mirror will not
# remember its sync status across crashes/reboots and
# the entire mirror will be re-synced.
# If a mirror image fails, the mirror will convert to a
# non-mirrored device if there is only one remaining good copy.
# allocate - Remove the faulty device and try to allocate space
# on a new device to be a replacement for the failed device.
# Using this policy for the log is fast and maintains the
# ability to remember sync state through crashes/reboots.
# Using this policy for a mirror device is slow, as it
# requires the mirror to resynchronize the devices, but it
# will preserve the mirror characteristic of the device.
# This policy acts like 'remove' if no suitable device and
# space can be allocated for the replacement.
# allocate_anywhere - Not yet implemented. Useful to place
# the log device temporarily on the same physical volume as
# one of the mirror images. This policy is not recommended
# for mirror devices since it would break the redundant nature
# of the mirror. This policy acts like 'remove' if no suitable
# device and space can be allocated for the replacement.
mirror_image_fault_policy = "remove"
# Configuration option activation/mirror_log_fault_policy.
# Defines how a device failure in a 'mirror' log LV is handled.
# The mirror_image_fault_policy description for mirrored LVs
# also applies to mirrored log LVs.
mirror_log_fault_policy = "allocate"
# Configuration option activation/snapshot_autoextend_threshold.
# Auto-extend a snapshot when its usage exceeds this percent.
# Setting this to 100 disables automatic extension.
# The minimum value is 50 (a smaller value is treated as 50.)
# Also see snapshot_autoextend_percent.
# Automatic extension requires dmeventd to be monitoring the LV.
# Example:
# With snapshot_autoextend_threshold 70 and
# snapshot_autoextend_percent 20, whenever a snapshot
# exceeds 70% usage, it will be extended by another 20%.
# For a 1G snapshot, using 700M will trigger a resize to 1.2G.
# When the usage exceeds 840M, the snapshot will be extended
# to 1.44G, and so on.
snapshot_autoextend_threshold = 100
# Configuration option activation/snapshot_autoextend_percent.
# Auto-extending a snapshot adds this percent extra space.
# The amount of additional space added to a snapshot is this
# percent of its current size.
# Also see snapshot_autoextend_threshold.
snapshot_autoextend_percent = 20
# Configuration option activation/thin_pool_autoextend_threshold.
# Auto-extend a thin pool when its usage exceeds this percent.
# Setting this to 100 disables automatic extension.
# The minimum value is 50 (a smaller value is treated as 50.)
# Also see thin_pool_autoextend_percent.
# Automatic extension requires dmeventd to be monitoring the LV.
# Example:
# With thin_pool_autoextend_threshold 70 and
# thin_pool_autoextend_percent 20, whenever a thin pool
# exceeds 70% usage, it will be extended by another 20%.
# For a 1G thin pool, using up 700M will trigger a resize to 1.2G.
# When the usage exceeds 840M, the thin pool will be extended
# to 1.44G, and so on.
thin_pool_autoextend_threshold = 100
# Configuration option activation/thin_pool_autoextend_percent.
# Auto-extending a thin pool adds this percent extra space.
# The amount of additional space added to a thin pool is this
# percent of its current size.
thin_pool_autoextend_percent=20
# Configuration option activation/mlock_filter.
# Do not mlock these memory areas.
# While activating devices, I/O to devices being
# (re)configured is suspended. As a precaution against
# deadlocks, LVM pins memory it is using so it is not
# paged out, and will not require I/O to reread.
# Groups of pages that are known not to be accessed during
# activation do not need to be pinned into memory.
# Each string listed in this setting is compared against
# each line in /proc/self/maps, and the pages corresponding
# to lines that match are not pinned. On some systems,
# locale-archive was found to make up over 80% of the memory
# used by the process.
# Example:
# mlock_filter = [ "locale/locale-archive", "gconv/gconv-modules.cache" ]
# This configuration option is advanced.
# This configuration option does not have a default value defined.
# mlock_filter = []
# Configuration option activation/use_mlockall.
# Use the old behavior of mlockall to pin all memory.
# Prior to version 2.02.62, LVM used mlockall() to pin
# the whole process's memory while activating devices.
use_mlockall = 0
# Configuration option activation/monitoring.
# Monitor LVs that are activated.
# When enabled, LVM will ask dmeventd to monitor LVs
# that are activated.
# The '--ignoremonitoring' option overrides this setting.
monitoring = 1
# Configuration option activation/polling_interval.
# Check pvmove or lvconvert progress at this interval (seconds)
# When pvmove or lvconvert must wait for the kernel to finish
# synchronising or merging data, they check and report progress
# at intervals of this number of seconds.
# If this is set to 0 and there is only one thing to wait for,
# there are no progress reports, but the process is awoken
# immediately once the operation is complete.
polling_interval = 15
# Configuration option activation/auto_set_activation_skip.
# Set the activation skip flag on new thin snapshot LVs.
# An LV can have a persistent 'activation skip' flag.
# The flag causes the LV to be skipped during normal activation.
# The lvchange/vgchange -K option is required to activate LVs
# that have the activation skip flag set.
# When this setting is enabled, the activation skip flag is
# set on new thin snapshot LVs.
# The '--setactivationskip y|n' option overrides this setting.
# auto_set_activation_skip = 1
# Configuration option activation/activation_mode.
# How LVs with missing devices are activated.
# Possible options are: complete, degraded, partial.
# complete - Only allow activation of an LV if all of
# the Physical Volumes it uses are present. Other PVs
# in the Volume Group may be missing.
# degraded - Like complete, but additionally RAID LVs of
# segment type raid1, raid4, raid5, radid6 and raid10 will
# be activated if there is no data loss, i.e. they have
# sufficient redundancy to present the entire addressable
# range of the Logical Volume.
# partial - Allows the activation of any LV even if a
# missing or failed PV could cause data loss with a
# portion of the Logical Volume inaccessible.
# This setting should not normally be used, but may
# sometimes assist with data recovery.
# The '--activationmode' option overrides this setting.
activation_mode = "degraded"
}
# Configuration option metadata/pvmetadatacopies.
# Number of copies of metadata to store on each PV.
# Possible options are: 0, 1, 2.
# If set to 2, two copies of the VG metadata are stored on
# the PV, one at the front of the PV, and one at the end.
# If set to 1, one copy is stored at the front of the PV.
# If set to 0, no copies are stored on the PV. This may
# be useful with VGs containing large numbers of PVs.
# The '--pvmetadatacopies' option overrides this setting.
# This configuration option is advanced.
# pvmetadatacopies = 1
# Configuration option metadata/vgmetadatacopies.
# Number of copies of metadata to maintain for each VG.
# If set to a non-zero value, LVM automatically chooses which of
# the available metadata areas to use to achieve the requested
# number of copies of the VG metadata. If you set a value larger
# than the the total number of metadata areas available, then
# metadata is stored in them all.
# The value 0 (unmanaged) disables this automatic management
# and allows you to control which metadata areas are used at
# the individual PV level using 'pvchange --metadataignore y|n'.
# The '--vgmetadatacopies' option overrides this setting.
# vgmetadatacopies = 0
# Configuration option metadata/pvmetadatasize.
# Approximate number of sectors to use for each metadata copy.
# VGs with large numbers of PVs or LVs, or VGs containing
# complex LV structures, may need additional space for VG
# metadata. The metadata areas are treated as circular buffers,
# so unused space becomes filled with an archive of the most
# recent previous versions of the metadata.
# pvmetadatasize = 255
# Configuration option metadata/pvmetadataignore.
# Ignore metadata areas on a new PV.
# If metadata areas on a PV are ignored, LVM will not store
# metadata in them.
# The '--metadataignore' option overrides this setting.
# This configuration option is advanced.
# pvmetadataignore = 0
# Configuration option metadata/stripesize.
# This configuration option is advanced.
# stripesize = 64
# Configuration option metadata/dirs.
# Directories holding live copies of text format metadata.
# These directories must not be on logical volumes!
# It's possible to use LVM with a couple of directories here,
# preferably on different (non-LV) filesystems, and with no other
# on-disk metadata (pvmetadatacopies = 0). Or this can be in
# addition to on-disk metadata areas.
# The feature was originally added to simplify testing and is not
# supported under low memory situations - the machine could lock up.
# Never edit any files in these directories by hand unless you
# you are absolutely sure you know what you are doing! Use
# the supplied toolset to make changes (e.g. vgcfgrestore).
# Example:
# dirs = [ "/etc/lvm/metadata", "/mnt/disk2/lvm/metadata2" ]
# This configuration option is advanced.
# This configuration option does not have a default value defined.
# dirs = []
# Configuration option report/compact_output.
# Do not print empty report fields.
# Fields that don't have a value set for any of the rows
# reported are skipped and not printed. Compact output is
# applicable only if report/buffered is enabled.
# compact_output = 0
# Configuration option report/aligned.
# Align columns in report output.
# aligned = 1
# Configuration option report/buffered.
# Buffer report output.
# When buffered reporting is used, the report's content is appended
# incrementally to include each object being reported until the report
# is flushed to output which normally happens at the end of command
# execution. Otherwise, if buffering is not used, each object is
# reported as soon as its processing is finished.
# buffered = 1
# Configuration option report/headings.
# Show headings for columns on report.
# headings = 1
# Configuration option report/separator.
# A separator to use on report after each field.
# separator = " "
# Configuration option report/list_item_separator.
# A separator to use for list items when reported.
# list_item_separator = ","
# Configuration option report/prefixes.
# Use a field name prefix for each field reported.
# prefixes = 0
# Configuration option report/quoted.
# Quote field values when using field name prefixes.
# quoted = 1
# Configuration option report/colums_as_rows.
# Output each column as a row.
# If set, this also implies report/prefixes = 1.
# colums_as_rows = 0
# Configuration option report/binary_values_as_numeric.
# Use binary values 0 or 1 instead of descriptive literal values.
# For columns that have exactly two valid values to report
# (not counting the 'unknown' value which denotes that the
# value could not be determined).
# binary_values_as_numeric = 0
# Configuration option report/devtypes_sort.
# List of columns to sort by when reporting 'lvm devtypes' command.
# See 'lvm devtypes -o help' for the list of possible fields.
# devtypes_sort = "devtype_name"
# Configuration option report/devtypes_cols.
# List of columns to report for 'lvm devtypes' command.
# See 'lvm devtypes -o help' for the list of possible fields.
# devtypes_cols = "devtype_name,devtype_max_partitions,devtype_description"
# Configuration option report/devtypes_cols_verbose.
# List of columns to report for 'lvm devtypes' command in verbose mode.
# See 'lvm devtypes -o help' for the list of possible fields.
# devtypes_cols_verbose = "devtype_name,devtype_max_partitions,devtype_description"
# Configuration option report/lvs_sort.
# List of columns to sort by when reporting 'lvs' command.
# See 'lvs -o help' for the list of possible fields.
# lvs_sort = "vg_name,lv_name"
# Configuration option report/lvs_cols.
# List of columns to report for 'lvs' command.
# See 'lvs -o help' for the list of possible fields.
# lvs_cols = "lv_name,vg_name,lv_attr,lv_size,pool_lv,origin,data_percent,metadata_percent,move_pv,mirror_log,copy_percent,convert_lv"
# Configuration option report/lvs_cols_verbose.
# List of columns to report for 'lvs' command in verbose mode.
# See 'lvs -o help' for the list of possible fields.
# lvs_cols_verbose = "lv_name,vg_name,seg_count,lv_attr,lv_size,lv_major,lv_minor,lv_kernel_major,lv_kernel_minor,pool_lv,origin,data_percent,metadata_percent,move_pv,copy_percent,mirror_log,convert_lv,lv_uuid,lv_profile"
# Configuration option report/vgs_sort.
# List of columns to sort by when reporting 'vgs' command.
# See 'vgs -o help' for the list of possible fields.
# vgs_sort = "vg_name"
# Configuration option report/vgs_cols.
# List of columns to report for 'vgs' command.
# See 'vgs -o help' for the list of possible fields.
# vgs_cols = "vg_name,pv_count,lv_count,snap_count,vg_attr,vg_size,vg_free"
# Configuration option report/vgs_cols_verbose.
# List of columns to report for 'vgs' command in verbose mode.
# See 'vgs -o help' for the list of possible fields.
# vgs_cols_verbose = "vg_name,vg_attr,vg_extent_size,pv_count,lv_count,snap_count,vg_size,vg_free,vg_uuid,vg_profile"
# Configuration option report/pvs_sort.
# List of columns to sort by when reporting 'pvs' command.
# See 'pvs -o help' for the list of possible fields.
# pvs_sort = "pv_name"
# Configuration option report/pvs_cols.
# List of columns to report for 'pvs' command.
# See 'pvs -o help' for the list of possible fields.
# pvs_cols = "pv_name,vg_name,pv_fmt,pv_attr,pv_size,pv_free"
# Configuration option report/pvs_cols_verbose.
# List of columns to report for 'pvs' command in verbose mode.
# See 'pvs -o help' for the list of possible fields.
# pvs_cols_verbose = "pv_name,vg_name,pv_fmt,pv_attr,pv_size,pv_free,dev_size,pv_uuid"
# Configuration option report/segs_sort.
# List of columns to sort by when reporting 'lvs --segments' command.
# See 'lvs --segments -o help' for the list of possible fields.
# segs_sort = "vg_name,lv_name,seg_start"
# Configuration option report/segs_cols.
# List of columns to report for 'lvs --segments' command.
# See 'lvs --segments -o help' for the list of possible fields.
# segs_cols = "lv_name,vg_name,lv_attr,stripes,segtype,seg_size"
# Configuration option report/segs_cols_verbose.
# List of columns to report for 'lvs --segments' command in verbose mode.
# See 'lvs --segments -o help' for the list of possible fields.
# segs_cols_verbose = "lv_name,vg_name,lv_attr,seg_start,seg_size,stripes,segtype,stripesize,chunksize"
# Configuration option report/pvsegs_sort.
# List of columns to sort by when reporting 'pvs --segments' command.
# See 'pvs --segments -o help' for the list of possible fields.
# pvsegs_sort = "pv_name,pvseg_start"
# Configuration option report/pvsegs_cols.
# List of columns to sort by when reporting 'pvs --segments' command.
# See 'pvs --segments -o help' for the list of possible fields.
# pvsegs_cols = "pv_name,vg_name,pv_fmt,pv_attr,pv_size,pv_free,pvseg_start,pvseg_size"
# Configuration option report/pvsegs_cols_verbose.
# List of columns to sort by when reporting 'pvs --segments' command in verbose mode.
# See 'pvs --segments -o help' for the list of possible fields.
# pvsegs_cols_verbose = "pv_name,vg_name,pv_fmt,pv_attr,pv_size,pv_free,pvseg_start,pvseg_size,lv_name,seg_start_pe,segtype,seg_pe_ranges"
dmeventd {
# Configuration option dmeventd/mirror_library.
# The library dmeventd uses when monitoring a mirror device.
# libdevmapper-event-lvm2mirror.so attempts to recover from
# failures. It removes failed devices from a volume group and
# reconfigures a mirror as necessary. If no mirror library is
# provided, mirrors are not monitored through dmeventd.
mirror_library = "libdevmapper-event-lvm2mirror.so"
# Configuration option dmeventd/raid_library.
# raid_library = "libdevmapper-event-lvm2raid.so"
# Configuration option dmeventd/snapshot_library.
# The library dmeventd uses when monitoring a snapshot device.
# libdevmapper-event-lvm2snapshot.so monitors the filling of
# snapshots and emits a warning through syslog when the usage
# exceeds 80%. The warning is repeated when 85%, 90% and
# 95% of the snapshot is filled.
snapshot_library = "libdevmapper-event-lvm2snapshot.so"
# Configuration option dmeventd/thin_library.
# The library dmeventd uses when monitoring a thin device.
# libdevmapper-event-lvm2thin.so monitors the filling of
# a pool and emits a warning through syslog when the usage
# exceeds 80%. The warning is repeated when 85%, 90% and
# 95% of the pool is filled.
thin_library = "libdevmapper-event-lvm2thin.so"
# Configuration option dmeventd/executable.
# The full path to the dmeventd binary.
# executable = "/sbin/dmeventd"
}
# Configuration option tags/hosttags.
# Create a host tag using the machine name.
# The machine name is nodename returned by uname(2).
# hosttags = 0
# Configuration section tags/<tag>.
# Replace this subsection name with a custom tag name.
# Multiple subsections like this can be created.
# The '@' prefix for tags is optional.
# This subsection can contain host_list, which is a
# list of machine names. If the name of the local
# machine is found in host_list, then the name of
# this subsection is used as a tag and is applied
# to the local machine as a 'host tag'.
# If this subsection is empty (has no host_list), then
# the subsection name is always applied as a 'host tag'.
# Example:
# The host tag foo is given to all hosts, and the host tag
# bar is given to the hosts named machine1 and machine2.
# tags { foo { } bar { host_list = [ "machine1", "machine2" ] } }
# This configuration section has variable name.
# This configuration section does not have a default value defined.
# tag {
# Configuration option tags/<tag>/host_list.
# A list of machine names.
# These machine names are compared to the nodename
# returned by uname(2). If the local machine name
# matches an entry in this list, the name of the
# subsection is applied to the machine as a 'host tag'.
# This configuration option does not have a default value defined.
# host_list = ""
# }
-- no debconf information
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Sun, 19 Jul 2015 19:54:05 GMT) (full text, mbox, link).
Acknowledgement sent
to Bastian Blank <waldi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Sun, 19 Jul 2015 19:54:05 GMT) (full text, mbox, link).
Message #24 received at 791869@bugs.debian.org (full text, mbox, reply):
On Thu, Jul 09, 2015 at 05:16:57AM +0200, Stefan Lippers-Hollmann wrote: > Upgrading src:lvm2 from 2.02.111-2.2 to 2.02.122-1 breaks booting due to > a new systemd unit dependency failures regarding lvmetad when mounting > non-rootfs logical volumes. Jumping to the emergency shell and invoking > "vgchange -ay" and "mount -a" allows booting to finish. Please provide all information from the system regarding the storage. This includes: - /etc/fstab - /etc/lvm/lvm.conf - pvs, vgs, lvs - lsblk - systemctl status in broken state > Kernel: Linux 4.1.0-1.slh.3-aptosid-amd64 (SMP w/2 CPU cores; PREEMPT) Ah, this is no Debian system at all. Bastian -- Kirk to Enterprise -- beam down yeoman Rand and a six-pack.
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Sun, 19 Jul 2015 23:21:08 GMT) (full text, mbox, link).
Acknowledgement sent
to Stefan Lippers-Hollmann <s.l-h@gmx.de>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Sun, 19 Jul 2015 23:21:08 GMT) (full text, mbox, link).
Message #29 received at 791869@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi
On 2015-07-19, Bastian Blank wrote:
> On Thu, Jul 09, 2015 at 05:16:57AM +0200, Stefan Lippers-Hollmann wrote:
> > Upgrading src:lvm2 from 2.02.111-2.2 to 2.02.122-1 breaks booting due to
> > a new systemd unit dependency failures regarding lvmetad when mounting
> > non-rootfs logical volumes. Jumping to the emergency shell and invoking
> > "vgchange -ay" and "mount -a" allows booting to finish.
>
> Please provide all information from the system regarding the storage.
> This includes:
> - /etc/fstab
already provided in the original submission:
# cat /etc/fstab
# /etc/fstab: filesystem table.
#
# filesystem mountpoint type options dump pass
/dev/vg-redstone/debian64 / ext4 defaults,noatime,barrier=0 1 1
LABEL=UEFI /boot/efi vfat auto,user,exec,nodev,nosuid,noatime 1 2
/dev/vg-redstone/swap none swap sw 0 0
/dev/vg-redstone/var /var ext4 auto,user,exec,dev,noatime,barrier=0 1 2
/var/tmp /tmp none bind 0 0
/dev/vg-redstone/home /home ext4 auto,user,exec,nodev,nosuid,noatime,barrier=0 1 2
/dev/vg-redstone/storage /srv/storage ext4 auto,user,noexec,nodev,nosuid,noatime,barrier=0 1 2
LABEL=seagate /srv/seagate ext4 auto,user,noexec,nodev,nosuid,noatime 1 2
> - /etc/lvm/lvm.conf
/etc/lvm/lvm.conf is unchanged from the package default of lvm2
2.02.122-2, but I've attached it (gzipped) nevertheless.
$ md5sum -b /etc/lvm/lvm.conf
de7411c6a935b065dd7dcde6208c364f */etc/lvm/lvm.conf
> - pvs, vgs, lvs
# pvs
PV VG Fmt Attr PSize PFree
/dev/sdb2 vg-redstone lvm2 a-- 800,00g 446,00g
# vgs
VG #PV #LV #SN Attr VSize VFree
vg-redstone 1 5 0 wz--n- 800,00g 446,00g
# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
debian64 vg-redstone -wi-ao---- 10,00g
home vg-redstone -wi-ao---- 30,00g
storage vg-redstone -wi-ao---- 300,00g
swap vg-redstone -wi-ao---- 4,00g
var vg-redstone -wi-ao---- 10,00g
> - lsblk
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 2,7T 0 disk
├─sda1 8:1 0 299M 0 part
└─sda2 8:2 0 2,7T 0 part /srv/seagate
sdb 8:16 0 931,5G 0 disk
├─sdb1 8:17 0 300M 0 part /boot/efi
└─sdb2 8:18 0 800G 0 part
├─vg--redstone-debian64 254:0 0 10G 0 lvm /
├─vg--redstone-var 254:1 0 10G 0 lvm /var
├─vg--redstone-home 254:2 0 30G 0 lvm /home
├─vg--redstone-swap 254:3 0 4G 0 lvm [SWAP]
└─vg--redstone-storage 254:4 0 300G 0 lvm /srv/storage
> - systemctl status in broken state
Taken, and stored in a temporary file, from within the emergency shell.
$ zcat systemctl-status.log.gz
● redstone
State: maintenance
Jobs: 0 queued
Failed: 1 units
Since: Mo 2015-07-20 00:04:38 CEST; 2min 18s ago
CGroup: /
├─1 /sbin/init
└─system.slice
├─lvm2-lvmetad.service
│ └─200 /sbin/lvmetad -f
├─emergency.service
│ ├─573 /bin/sh -c /sbin/sulogin; /bin/systemctl --job-mode=fail --no-block default
│ ├─576 bash
│ └─588 systemctl status
├─systemd-journald.service
│ └─199 /lib/systemd/systemd-journald
├─systemd-networkd.service
│ └─369 /lib/systemd/systemd-networkd
└─systemd-udevd.service
└─203 /lib/systemd/systemd-udevd
> > Kernel: Linux 4.1.0-1.slh.3-aptosid-amd64 (SMP w/2 CPU cores; PREEMPT)
>
> Ah, this is no Debian system at all.
It is a Debian system, I'm just usually running the kernel[1] I'm
developing and working on - but even though I picked the "wrong
one" when submitting the bug, the problem can be reproduced easily
using Debian's linux-image-4.0.0-2-amd64:
All logs above have been gathered using:
$ dpkg -l | grep -e linux-image-amd64 -e linux-image-4.0.0-2-amd64 -e 2.02.122-2 -e 2:1.02.99-2
ii dmeventd 2:1.02.99-2 amd64 Linux Kernel Device Mapper event daemon
ii dmsetup 2:1.02.99-2 amd64 Linux Kernel Device Mapper userspace library
ii libdevmapper-event1.02.1:amd64 2:1.02.99-2 amd64 Linux Kernel Device Mapper event support library
ii libdevmapper1.02.1:amd64 2:1.02.99-2 amd64 Linux Kernel Device Mapper userspace library
ii liblvm2app2.2:amd64 2.02.122-2 amd64 LVM2 application library
ii liblvm2cmd2.02:amd64 2.02.122-2 amd64 LVM2 command library
ii linux-image-4.0.0-2-amd64 4.0.8-1 amd64 Linux 4.0 for 64-bit PCs
ii linux-image-amd64 4.0+65 amd64 Linux for 64-bit PCs (meta-package)
ii lvm2 2.02.122-2 amd64 Linux Logical Volume Manager
$ cat /proc/version
Linux version 4.0.0-2-amd64 (debian-kernel@lists.debian.org) (gcc version 4.9.3 (Debian 4.9.3-1) ) #1 SMP Debian 4.0.8-1 (2015-07-11)
$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.0.0-2-amd64 root=/dev/mapper/vg--redstone-debian64 ro quiet systemd.show_status=1
This particular system is running in UEFI mode, but I can reproduce it
just as well on other (older) systems in BIOS mode.
Starting with lvm2 2.02.122-2, it suddenly boots fine ~40% of the time,
while it fails booting the during the other attempts (with the logs
above). Interesting enough, systems using a SSD for the system
mountpoints usually succeed booting most of the time, while systems
with only spinning HDDs seem to be mouch more likely to be affected.
Using src:lvm2 2.02.122-1 it reliably failed all the time, while that
never happened with src:lvm2 <= 2.02.111-2.2.
I'm affected by this problem on more than 10, fairly different, systems.
After logging into the emergency shell, I can activate the volume group
manually using "vgchange -ay", mount the missing logical volumes with
"mount -a" and exit the emergency shell to continue the boot process.
Regards
Stefan Lippers-Hollmann
[1] Vcs-git: git://github.com/fullstory/linux-aptosid.git
Vcs-Browser: https://github.com/fullstory/linux-aptosid
[lvm.conf.gz (application/gzip, attachment)]
[Message part 3 (application/pgp-signature, inline)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Mon, 20 Jul 2015 00:27:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Ben Caradoc-Davies <ben@transient.nz>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Mon, 20 Jul 2015 00:27:04 GMT) (full text, mbox, link).
Message #34 received at 791869@bugs.debian.org (full text, mbox, reply):
Booting succeeds for me with / and /home on separate LVs in a single
crypto-luks PV (see lsblk below) with lvm2 2.02.122-2 amd64. However,
after updating to the latest lvm2, "pvscan", "pvs", "vgs", and "lvs" all
hang indefinitely until I manually run "pvscan --cache". They worked
fine with 2.02.111-2.2, probably because lvmetad was not enabled.
- lvm.conf is unmodified
- lvm2-monitor.service, avahi-daemon.service, and avahi-daemon.socket
are masked
- Fully dist-upgraded sid/amd64
Nothing helpful in the logs (journalctl or /var/log).
Before "pvscan --cache":
output of "strace pvs" while hung:
[...]
write(3, "request=\"pv_list\"\ntoken =\"filter"..., 36) = 36
write(3, "\n##\n", 4) = 4
read(3, "response = \"token_mismatch\"\nexpe", 32) = 32
read(3, "cted = \"update in progress\"\nrece"..., 1024) = 147
[...]
output of "strace vgs" while hung ("lvs" is similar):
[...]
write(3, "request=\"vg_list\"\ntoken =\"filter"..., 36) = 36
write(3, "\n##\n", 4) = 4
read(3, "response = \"token_mismatch\"\nexpe", 32) = 32
read(3, "cted = \"update in progress\"\nrece"..., 1024) = 147
[...]
Output of "strace -e read=3 pvs while hung:
[...]
write(3, "request=\"pv_list\"\ntoken =\"filter"..., 36) = 36
write(3, "\n##\n", 4) = 4
read(3, "response = \"token_mismatch\"\nexpe", 32) = 32
| 00000 72 65 73 70 6f 6e 73 65 20 3d 20 22 74 6f 6b 65 response =
"toke |
| 00010 6e 5f 6d 69 73 6d 61 74 63 68 22 0a 65 78 70 65
n_mismatch".expe |
read(3, "cted = \"update in progress\"\nrece"..., 1024) = 147
| 00000 63 74 65 64 20 3d 20 22 75 70 64 61 74 65 20 69 cted =
"update i |
| 00010 6e 20 70 72 6f 67 72 65 73 73 22 0a 72 65 63 65 n
progress".rece |
| 00020 69 76 65 64 20 3d 20 22 66 69 6c 74 65 72 3a 30 ived =
"filter:0 |
| 00030 22 0a 72 65 61 73 6f 6e 20 3d 20 22 6c 76 6d 65 ".reason =
"lvme |
| 00040 74 61 64 20 63 61 63 68 65 20 69 73 20 69 6e 76 tad cache
is inv |
| 00050 61 6c 69 64 20 64 75 65 20 74 6f 20 61 20 67 6c alid due to
a gl |
| 00060 6f 62 61 6c 5f 66 69 6c 74 65 72 20 63 68 61 6e obal_filter
chan |
| 00070 67 65 20 6f 72 20 64 75 65 20 74 6f 20 61 20 72 ge or due
to a r |
| 00080 75 6e 6e 69 6e 67 20 72 65 73 63 61 6e 22 0a 0a unning
rescan".. |
| 00090 23 23 0a ##.
|
[...]
For your convenience, the message is:
response = "token_mismatch".expected = "update in progress".received =
"filter:0".reason = "lvmetad cache is invalid due to a global_filter
change or due to a running rescan"..##.
Then "man lvmetad" led me to "pvscan --cache".
After "pvscan --cache":
# pvs
PV VG Fmt Attr PSize PFree
/dev/mapper/sda2_crypt vg lvm2 a-- 55.62g 0
# vgs
VG #PV #LV #SN Attr VSize VFree
vg 1 2 0 wz--n- 55.62g 0
# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log
Cpy%Sync Convert
home vg -wi-ao---- 36.99g
root vg -wi-ao---- 18.62g
Other system information (before "pvscan --cache"):
# systemctl status lvm2-lvmetad
● lvm2-lvmetad.service - LVM2 metadata daemon
Loaded: loaded (/lib/systemd/system/lvm2-lvmetad.service; disabled;
vendor preset: enabled)
Active: active (running) since Mon 2015-07-20 09:27:27 NZST; 38min ago
Docs: man:lvmetad(8)
Main PID: 508 (lvmetad)
CGroup: /system.slice/lvm2-lvmetad.service
└─508 /sbin/lvmetad -f
[...]
fstab excerpt:
/dev/mapper/vg-root / ext4 noatime,errors=remount-ro 0 1
/dev/sda1 /boot ext4 noatime,errors=remount-ro 0 2
/dev/mapper/vg-home /home ext4 noatime,errors=remount-ro 0 2
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 55.9G 0 disk
├─sda1 8:1 0 285M 0 part /boot
└─sda2 8:2 0 55.6G 0 part
└─sda2_crypt 254:0 0 55.6G 0 crypt
├─vg-root 254:1 0 18.6G 0 lvm /
└─vg-home 254:2 0 37G 0 lvm /home
packages:
dmeventd 2:1.02.99-2 amd64
dmsetup 2:1.02.99-2 amd64
libdevmapper-event1.02.1:amd64 2:1.02.99-2 amd64
libdevmapper1.02.1:amd64 2:1.02.99-2 amd64
liblvm2app2.2:amd64 2.02.122-2 amd64
liblvm2cmd2.02:amd64 2.02.122-2 amd64
lvm2 2.02.122-2 amd64
kernel:
Linux ripley 4.0.0-2-amd64 #1 SMP Debian 4.0.8-1 (2015-07-11) x86_64
GNU/Linux
Kind regards,
--
Ben Caradoc-Davies <ben@transient.nz>
Director
Transient Software Limited <http://transient.nz/>
New Zealand
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Mon, 20 Jul 2015 00:45:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Ben Caradoc-Davies <ben@transient.nz>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Mon, 20 Jul 2015 00:45:03 GMT) (full text, mbox, link).
Message #39 received at 791869@bugs.debian.org (full text, mbox, reply):
On Mon, 20 Jul 2015 01:16:12 +0200 Stefan Lippers-Hollmann <s.l-h@gmx.de> wrote: > Interesting enough, systems using a SSD for the system mountpoints usually succeed booting most of the time Thanks for this observation, Stefan. My successful boots are indeed on a system using an SSD. I have not yet had a failed boot with lvm2 2.02.122-2. Kind regards, -- Ben Caradoc-Davies <ben@transient.nz> Director Transient Software Limited <http://transient.nz/> New Zealand
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Mon, 20 Jul 2015 05:30:08 GMT) (full text, mbox, link).
Acknowledgement sent
to Rick Thomas <rbthomas@rcthomas.org>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Mon, 20 Jul 2015 05:30:08 GMT) (full text, mbox, link).
Message #44 received at 791869@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Package: lvm2
Version: 2.02.122-2
Followup-For: Bug #791869
Dear Maintainer,
* What led up to the situation
LVs for home, swap and root all on LVM on top of RAID0.
When running on Debian/Testing, boots fine. When running on Debian/Unstable it can't find LVs with home and swap. Drops to emergency shell.
* What exactly did you do (or not do) that was effective (or ineffective)?
Running 'vgchange -a ay' in emergency shell then exiting emergency shell
* What was the outcome of this action?
gets all OK.
* What outcome did you expect instead?
I didn't expect to get dropped into emergency shell. Debian/Testing doesn't do that!
I'm attaching output of 'journalctl -b' and 'dmesg' of boot with testing (succeeds) and boot with unstable (fails)
Also attaching /etc/fstab and output of 'lvblk'. Note that /etc/lvm/lvm.conf has not been changed since installation.
Output of 'pvs', 'vgs', 'lvs' are logged so that they appear in the unstable-journalctl.txt file.
One difference between the Testing and Unstable booting is that Unstable console shows two occurances of the message:
lvmetad is not active yet Using direct activation during sysinit
This is followed by a 90-second timeout looking for the LV containing home.
I hope this helps!
Rick
-- System Information:
Debian Release: stretch/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.0.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages lvm2 depends on:
ii dmeventd 2:1.02.99-2
ii dmsetup 2:1.02.99-2
ii init-system-helpers 1.23
ii initscripts 2.88dsf-59.2
ii libc6 2.19-19
ii libdevmapper-event1.02.1 2:1.02.99-2
ii libdevmapper1.02.1 2:1.02.99-2
ii liblvm2app2.2 2.02.122-2
ii libreadline5 5.2+dfsg-3
ii libudev1 222-2
ii lsb-base 4.1+Debian13+nmu1
lvm2 recommends no packages.
Versions of packages lvm2 suggests:
pn thin-provisioning-tools <none>
-- no debconf information
[fstab (text/plain, attachment)]
[lvm.conf (text/plain, attachment)]
[lsblk.txt (text/plain, attachment)]
[testing-journal.txt (text/plain, attachment)]
[testing-dmesg.txt (text/plain, attachment)]
[unstable-dmesg.txt (text/plain, attachment)]
[unstable-journal.txt (text/plain, attachment)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Mon, 20 Jul 2015 06:03:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Rick Thomas <rbthomas@pobox.com>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Mon, 20 Jul 2015 06:03:04 GMT) (full text, mbox, link).
Message #49 received at 791869@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
In case it helps, here’s systemctl status as logged during emergency shell. Rick
[systemctl-status.txt (text/plain, attachment)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Mon, 20 Jul 2015 06:33:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Rick Thomas <rbthomas@pobox.com>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Mon, 20 Jul 2015 06:33:04 GMT) (full text, mbox, link).
Message #54 received at 791869@bugs.debian.org (full text, mbox, reply):
On a hunch, I made the following change > # diff /SAVE/etc/lvm/lvm.conf /etc/lvm/lvm.conf > 823c823 > < use_lvmetad = 1 > --- > > use_lvmetad = 0 and ran > # update-initramfs -u Then rebooted. The problem went away… As I understand it, this makes LVM always check the actual physical volumes to see which PVs are present, rather than relying on the cached information kept by lvmetad. Since lvmetad is not present in the initramfs (and wouldn’t be useful, even if it was) this allows the PVs to be scanned in the initramfs phase, at the cost of having to re-scan them after switching to real-root… Maybe getting lvmetad into the initramfs, so it can be used there, then doing a strategically placed ‘pvscan —cache’ when switching to real-root, might do the trick? Hope that helps! Rick
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Tue, 21 Jul 2015 05:03:05 GMT) (full text, mbox, link).
Acknowledgement sent
to Stefan Lippers-Hollmann <s.l-h@gmx.de>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Tue, 21 Jul 2015 05:03:06 GMT) (full text, mbox, link).
Message #59 received at 791869@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi On 2015-07-20, Ben Caradoc-Davies wrote: > On Mon, 20 Jul 2015 01:16:12 +0200 Stefan Lippers-Hollmann > <s.l-h@gmx.de> wrote: > > Interesting enough, systems using a SSD for the system > mountpoints usually succeed booting most of the time > > Thanks for this observation, Stefan. My successful boots are indeed on a > system using an SSD. I have not yet had a failed boot with lvm2 2.02.122-2. Actually I have to partially withdraw that earlier conclusion, today I did encounter one failure on a system with all logical volumes making up the system paths on a SSD. The system in question had been booting fine with lvm2 2.02.122-2 roughly a dozen of times before and I haven't been able to reproduce the failure case again, but it does strengthen the hunch of a timing related issue. Regards Stefan Lippers-Hollmann
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Tue, 21 Jul 2015 18:39:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Bastian Blank <waldi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Tue, 21 Jul 2015 18:39:03 GMT) (full text, mbox, link).
Message #64 received at 791869@bugs.debian.org (full text, mbox, reply):
On Mon, Jul 20, 2015 at 11:11:43AM +1200, Ben Caradoc-Davies wrote: > Booting succeeds for me with / and /home on separate LVs in a single > crypto-luks PV (see lsblk below) with lvm2 2.02.122-2 amd64. However, after > updating to the latest lvm2, "pvscan", "pvs", "vgs", and "lvs" all hang > indefinitely until I manually run "pvscan --cache". They worked fine with > 2.02.111-2.2, probably because lvmetad was not enabled. Thanks for the information, this is finaly a clue what is going on. > output of "strace pvs" while hung: Is there a pvscan or similar task running? This is the only time where the state info is set this way. > Then "man lvmetad" led me to "pvscan --cache". Yeah. pvscan should be run by udev for each new device. For some reason this either don't work, breaks in the middle or no idea what happens. Bastian -- Oblivion together does not frighten me, beloved. -- Thalassa (in Anne Mulhall's body), "Return to Tomorrow", stardate 4770.3.
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Tue, 21 Jul 2015 19:15:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Bastian Blank <waldi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Tue, 21 Jul 2015 19:15:04 GMT) (full text, mbox, link).
Message #69 received at 791869@bugs.debian.org (full text, mbox, reply):
On Tue, Jul 21, 2015 at 08:37:16PM +0200, Bastian Blank wrote: > Yeah. pvscan should be run by udev for each new device. For some > reason this either don't work, breaks in the middle or no idea what > happens. Okay, at least I can prove that removing pvscan breaks everything with similar effects. However I'm still unable to reproduce the problem without a sledgehammer. So the next step could be debugging udev and see what it calls and when. Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, "Day of the Dove", stardate unknown
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Wed, 22 Jul 2015 02:09:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Rick Thomas <rbthomas@pobox.com>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Wed, 22 Jul 2015 02:09:04 GMT) (full text, mbox, link).
Message #74 received at 791869@bugs.debian.org (full text, mbox, reply):
On Jul 21, 2015, at 12:11 PM, Bastian Blank <waldi@debian.org> wrote: > However I'm still unable to reproduce the problem > without a sledgehammer. I reproduced the problem in a tiny test system as follows: I created a virtual machine with VMWare running on my Mac. It has a virtual DVD-drive (loaded with the Jessie 8.1.0 amd64 install image) and three virtual disk drives. One virtual disk is a small (1 GB) drive to hold /boot. The other two (4GB each) to be configured at installation time as a software RAID0 housing a single LVM2 physical volume with three logical volumes for root, home, and swap. When installed with Jessie, everything works fine. Then I did full-upgrade to Testing/Stretch. Everything still works fine. Then I did full-upgrade to Unstable/Sid, and it broke. When i disabled use_lvmetad in /etc/lvm/lvm.conf and did “update-initramfs -u” things went back to working. I don’t expect the choice of VMWare as a platform has anything to do with this problem, so you can probably duplicate this procedure with a different VM platform… The output of lsblk looks like this: > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > fd0 2:0 1 4K 0 disk > sda 8:0 0 1G 0 disk > `-sda1 8:1 0 1022M 0 part /boot > sdb 8:16 0 4G 0 disk > `-sdb1 8:17 0 4G 0 part > `-md0 9:0 0 8G 0 raid0 > |-stretch-root 253:0 0 3.7G 0 lvm / > |-stretch-swap 253:1 0 1.9G 0 lvm [SWAP] > `-stretch-home 253:2 0 2.4G 0 lvm /home > sdc 8:32 0 4G 0 disk > `-sdc1 8:33 0 4G 0 part > `-md0 9:0 0 8G 0 raid0 > |-stretch-root 253:0 0 3.7G 0 lvm / > |-stretch-swap 253:1 0 1.9G 0 lvm [SWAP] > `-stretch-home 253:2 0 2.4G 0 lvm /home > sr0 11:0 1 1024M 0 rom If it matters, the VM has two virtual CPUs and 2 GB of virtual RAM. Hope it helps! Rick
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Thu, 23 Jul 2015 21:27:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Ben Caradoc-Davies <ben@transient.nz>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Thu, 23 Jul 2015 21:27:03 GMT) (full text, mbox, link).
Message #79 received at 791869@bugs.debian.org (full text, mbox, reply):
I have found new GRAVE manifestation of this bug. Rather than create a new bug report, I am adding it to this list. Should this be a new new GRAVE bug. Today I upgraded linux-image-4.0.0-2-amd64 to 4.0.8-2 and encountered an infinite hang in initramfs-tools while it was running vgs: /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating /boot/initrd.img-4.0.0-2-amd64 I was able to proceed only by opening another terminal and running "pvscan --cache". end of ps -ef during the scan (sorry no ww): root 11263 10150 0 09:10 pts/1 00:00:00 /usr/bin/dpkg --status-fd 20 --c root 11265 11263 0 09:10 pts/1 00:00:00 /usr/bin/perl -w /usr/share/debc root 11271 11265 0 09:10 pts/1 00:00:00 /usr/bin/perl /var/lib/dpkg/info root 11280 11271 0 09:10 pts/1 00:00:00 run-parts --report --exit-on-err root 18919 11280 0 09:12 pts/1 00:00:00 /bin/sh /usr/sbin/grub-mkconfig root 18927 18919 0 09:12 pts/1 00:00:00 /usr/sbin/grub-probe --device /d root 18928 18927 0 09:12 pts/1 00:00:00 vgs --options vg_uuid,pv_name -- Kind regards, -- Ben Caradoc-Davies <ben@transient.nz> Director Transient Software Limited <http://transient.nz/> New Zealand
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Thu, 23 Jul 2015 22:15:08 GMT) (full text, mbox, link).
Acknowledgement sent
to Ben Caradoc-Davies <ben@transient.nz>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Thu, 23 Jul 2015 22:15:08 GMT) (full text, mbox, link).
Message #84 received at 791869@bugs.debian.org (full text, mbox, reply):
This bug now makes any kernel upgrade (in this case
linux-image-4.0.0-2-amd64) cause the system to be unbootable. The system
is unable to contact lvmetad and unable to locate the root partition.
There is no luks passphrase prompt.
Please upgrade this bug to CRITICAL. Or should I file a critical bug
against all kernels? Or do users get what is coming to them for
upgrading to a package with an open grave bug?
Stefan, your systemd.unit=emergency.service vgchange instructions do not
work, even with vgchange -ay --config 'global{use_lvmetad=0}' as
suggested here:
https://bugzilla.redhat.com/show_bug.cgi?id=813766
cryptsetup is not available so I do not know how this would work anyway.
Workaround is to:
- Boot another kernel+initramfs (e.g. linux-image-4.0.0-1-amd64)
- Disable lvmetad by editing /etc/lvm/lvm.conf to set "use_lvmetad = 0"
- Run update-initramfs -u
- Reboot into linux-image-4.0.0-2-amd64
Once this is done I can boot. I see:
root@ripley:~# pvs
PV VG Fmt Attr PSize PFree
/dev/mapper/sda2_crypt vg lvm2 a-- 55.62g 0
root@ripley:~# vgs
VG #PV #LV #SN Attr VSize VFree
vg 1 2 0 wz--n- 55.62g 0
root@ripley:~# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log
Cpy%Sync Convert
home vg -wi-ao---- 36.99g
root vg -wi-ao---- 18.62g
Kind regards,
--
Ben Caradoc-Davies <ben@transient.nz>
Director
Transient Software Limited <http://transient.nz/>
New Zealand
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Thu, 23 Jul 2015 22:45:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Ben Caradoc-Davies <ben@transient.nz>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Thu, 23 Jul 2015 22:45:03 GMT) (full text, mbox, link).
Message #89 received at 791869@bugs.debian.org (full text, mbox, reply):
I am unable to reproduce this hang. When I re-enable lvmetad in lvm.conf and run "update-initramfs -u", reboot succeeds (many trials). Perhaps it is just the very intermittent failures on SSDs reported by Stefan? -- Ben Caradoc-Davies <ben@transient.nz> Director Transient Software Limited <http://transient.nz/> New Zealand
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Thu, 23 Jul 2015 23:18:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Ben Caradoc-Davies <ben@transient.nz>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Thu, 23 Jul 2015 23:18:04 GMT) (full text, mbox, link).
Message #94 received at 791869@bugs.debian.org (full text, mbox, reply):
An alternative explanation is that my original hung update-initramfs that required "pvscan --cache" to complete created a broken or incomplete initramfs. -- Ben Caradoc-Davies <ben@transient.nz> Director Transient Software Limited <http://transient.nz/> New Zealand
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Sat, 25 Jul 2015 12:30:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Bastian Blank <waldi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Sat, 25 Jul 2015 12:30:03 GMT) (full text, mbox, link).
Message #99 received at 791869@bugs.debian.org (full text, mbox, reply):
On Tue, Jul 21, 2015 at 09:11:57PM +0200, Bastian Blank wrote: > So the next step could be debugging udev and see what it calls and when. Please provide the complete udev db (udevadm info -e) and udev debugging output (udev.log-priority=8 at the kernel command line) from a failed boot. As this bug only bites a small number of systems (I myself found none, I was only able to produce similar effects by breaking udev rules), I intend to downgrade this bug for now. Bastian -- It is necessary to have purpose. -- Alice #1, "I, Mudd", stardate 4513.3
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Sat, 25 Jul 2015 19:24:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Bastian Blank <waldi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Sat, 25 Jul 2015 19:24:04 GMT) (full text, mbox, link).
Message #104 received at 791869@bugs.debian.org (full text, mbox, reply):
On Tue, Jul 21, 2015 at 07:05:42PM -0700, Rick Thomas wrote:
> I created a virtual machine with VMWare running on my Mac. It has a virtual DVD-drive (loaded with the Jessie 8.1.0 amd64 install image) and three virtual disk drives. One virtual disk is a small (1 GB) drive to hold /boot. The other two (4GB each) to be configured at installation time as a software RAID0 housing a single LVM2 physical volume with three logical volumes for root, home, and swap.
Okay, detection of lvm on md have two problems:
- udev rules in mdadm breaks detection of lvm and
- lvm rules break coldplug.
Bastian
--
There's a way out of any cage.
-- Captain Christopher Pike, "The Menagerie" ("The Cage"),
stardate unknown.
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Sat, 25 Jul 2015 19:39:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Bastian Blank <waldi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Sat, 25 Jul 2015 19:39:03 GMT) (full text, mbox, link).
Message #109 received at 791869@bugs.debian.org (full text, mbox, reply):
Hi Peter Currently I think that all this problems are related to missing or broken pvscan --cache calls. I found one problematic case regarding coldplug; I believe Redhat does not longer use this code path. In none of my tests the "artificial" add event triggers pvscan as it should. The udev rules test for LVM_MD_PV_ACTIVATED, which is never set in this case. My quick fix is to ignore if the event is actually change. Bastian On Sat, Jul 25, 2015 at 09:21:47PM +0200, Bastian Blank wrote: > Okay, detection of lvm on md have two problems: > - udev rules in mdadm breaks detection of lvm and > - lvm rules break coldplug. -- You're dead, Jim. -- McCoy, "Amok Time", stardate 3372.7
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Sat, 25 Jul 2015 19:42:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Stefan Lippers-Hollmann <s.l-h@gmx.de>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Sat, 25 Jul 2015 19:42:03 GMT) (full text, mbox, link).
Message #114 received at 791869@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi On 2015-07-25, Bastian Blank wrote: > On Tue, Jul 21, 2015 at 09:11:57PM +0200, Bastian Blank wrote: > > So the next step could be debugging udev and see what it calls and when. > > Please provide the complete udev db (udevadm info -e) and udev debugging > output (udev.log-priority=8 at the kernel command line) from a failed > boot. Gzipped "udevadm info -e" logs attached from several affected systems, unfortunately I can't provide "udev.log-priority=8" output as using that kernel parameter drops me to the initramfs' busybox shell without any input options (USB keyboard(s), the initramfs complaining about not finding ehci-orion in modules.dep; initramfs-tools 0.120). > As this bug only bites a small number of systems (I myself found none, I > was only able to produce similar effects by breaking udev rules), I > intend to downgrade this bug for now. For me the problem happens on a very diverse set of hardware, starting from ~10 year-old nforce3 systems up to ~1-2 year-old ivy-bridge and baytrail-d systems. The software side of it is relatively similar though, up to date Debian/unstable (KDE desktop/ development system), lvm2 installed and used on all of them - mdadm only on a single one (nforce3). Regards Stefan Lippers-Hollmann
[baytrail-d.log.gz (application/gzip, attachment)]
[ivy-bridge.redstone.log.gz (application/gzip, attachment)]
[ivy-bridge_poseidon.log.gz (application/gzip, attachment)]
[ivy-bridge_trident.log.gz (application/gzip, attachment)]
[nforce3.log.gz (application/gzip, attachment)]
[nforce4.log.gz (application/gzip, attachment)]
[nforce405.log.gz (application/gzip, attachment)]
[Message part 9 (application/pgp-signature, inline)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Sat, 25 Jul 2015 20:18:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Rick Thomas <rbthomas@pobox.com>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Sat, 25 Jul 2015 20:18:03 GMT) (full text, mbox, link).
Message #119 received at 791869@bugs.debian.org (full text, mbox, reply):
On Jul 25, 2015, at 3:21 PM, Bastian Blank wrote: > On Tue, Jul 21, 2015 at 07:05:42PM -0700, Rick Thomas wrote: >> I created a virtual machine with VMWare running on my Mac. It has a virtual DVD-drive (loaded with the Jessie 8.1.0 amd64 install image) and three virtual disk drives. One virtual disk is a small (1 GB) drive to hold /boot. The other two (4GB each) to be configured at installation time as a software RAID0 housing a single LVM2 physical volume with three logical volumes for root, home, and swap. > > Okay, detection of lvm on md have two problems: > - udev rules in mdadm breaks detection of lvm and > - lvm rules break coldplug. > > Bastian OK. We have a tentative diagnosis. That's good. Is there something I can do to verify for sure that this is what's actually happening and give us a clue as to what we need to do to fix it? I'll do the udev stuff you requested in your previous email (I'm traveling right now, but I'll get to it after I return home -- the middle of next week) Is that enough to complete the diagnosis, or are there other tests we can/should do? Enjoy! Rick
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Sat, 25 Jul 2015 22:27:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Sat, 25 Jul 2015 22:27:03 GMT) (full text, mbox, link).
Message #124 received at 791869@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On Sat, 25 Jul 2015 14:27:03 +0200 Bastian Blank <waldi@debian.org> wrote: > On Tue, Jul 21, 2015 at 09:11:57PM +0200, Bastian Blank wrote: > > So the next step could be debugging udev and see what it calls and when. > > Please provide the complete udev db (udevadm info -e) and udev debugging > output (udev.log-priority=8 at the kernel command line) from a failed > boot. > > As this bug only bites a small number of systems (I myself found none, I > was only able to produce similar effects by breaking udev rules), I > intend to downgrade this bug for now. Fwiw, I could easily and reliably reproduce this problem in a VM with LVM (guided setup with separate /, /home, /tmp, /var) on top of mdadm RAID1 with a minimal standard installation. So I fear this might actually bite quite a few people and I would suggest keeping this bug RC for the time being. I see you already got the information you requested from Stefan, I can provide further diagnostics as well, if you want me to. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Mon, 27 Jul 2015 05:57:06 GMT) (full text, mbox, link).
Acknowledgement sent
to Bastian Blank <waldi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Mon, 27 Jul 2015 05:57:06 GMT) (full text, mbox, link).
Message #129 received at 791869@bugs.debian.org (full text, mbox, reply):
On Sun, Jul 26, 2015 at 12:24:43AM +0200, Michael Biebl wrote: > Fwiw, I could easily and reliably reproduce this problem in a VM with > LVM (guided setup with separate /, /home, /tmp, /var) on top of mdadm > RAID1 with a minimal standard installation. There are at least two distinct problems. The cause for the reproducible problem with MD is known. No cause is known for the more random blockage. > I see you already got the information you requested from Stefan, I can > provide further diagnostics as well, if you want me to. If you have a more or less reproducible _non_-MD case, then I could use this information. Bastian -- Peace was the way. -- Kirk, "The City on the Edge of Forever", stardate unknown
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Mon, 27 Jul 2015 06:03:06 GMT) (full text, mbox, link).
Acknowledgement sent
to Bastian Blank <waldi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Mon, 27 Jul 2015 06:03:06 GMT) (full text, mbox, link).
Message #134 received at 791869@bugs.debian.org (full text, mbox, reply):
On Sat, Jul 25, 2015 at 04:15:58PM -0400, Rick Thomas wrote:
> OK. We have a tentative diagnosis. That's good. Is there something I can do to verify for sure that this is what's actually happening and give us a clue as to what we need to do to fix it?
In /lib/udev/rules.d/63-md-raid-arrays.rules, replace the existing blkid
call with:
| IMPORT{builtin}="blkid"
In /lib/udev/rules.d/63-md-raid-arrays.rules, use this diff:
--- a/udev/69-dm-lvm-metad.rules.in
+++ b/udev/69-dm-lvm-metad.rules.in
@@ -55,7 +55,7 @@ LABEL="next"
KERNEL!="md[0-9]*", GOTO="next"
IMPORT{db}="LVM_MD_PV_ACTIVATED"
ACTION=="add", ENV{LVM_MD_PV_ACTIVATED}=="1", GOTO="lvm_scan"
-ACTION=="change", ENV{LVM_MD_PV_ACTIVATED}!="1", TEST=="md/array_state", ENV{LVM_MD_PV_ACTIVATED}="1", GOTO="lvm_scan"
+ENV{LVM_MD_PV_ACTIVATED}!="1", TEST=="md/array_state", ENV{LVM_MD_PV_ACTIVATED}="1", GOTO="lvm_scan"
ACTION=="add", KERNEL=="md[0-9]*p[0-9]*", GOTO="lvm_scan"
ENV{LVM_MD_PV_ACTIVATED}!="1", ENV{SYSTEMD_READY}="0"
GOTO="lvm_end"
I'll add a workaround for the missing blkid call in the next upload, as
I don't want to tie this to the mdadm fix.
Bastian
--
No one wants war.
-- Kirk, "Errand of Mercy", stardate 3201.7
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Mon, 27 Jul 2015 14:00:18 GMT) (full text, mbox, link).
Acknowledgement sent
to Peter Rajnoha <prajnoha@redhat.com>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Mon, 27 Jul 2015 14:00:18 GMT) (full text, mbox, link).
Message #139 received at 791869@bugs.debian.org (full text, mbox, reply):
On 07/25/2015 09:34 PM, Bastian Blank wrote:
> Hi Peter
>
> Currently I think that all this problems are related to missing or
> broken pvscan --cache calls.
>
> I found one problematic case regarding coldplug; I believe Redhat does
> not longer use this code path. In none of my tests the "artificial" add
> event triggers pvscan as it should. The udev rules test for
> LVM_MD_PV_ACTIVATED, which is never set in this case.
The MD here is very similar to DM in a way it is activated -
the MD device is created first (the ADD event) and then initialized
(the CHANGE event).
So we're expecting the CHANGE event with appearing md/array_state sysfs
attribute to declare the MD as initialized (and hence marked with
LVM_MD_PV_ACTIVATED=1).
When this MD activation/initialization happens in initramfs, the udev
database state needs to be transfered over from initramfs to root fs for
the MD device.
We're always doing IMPORT{db} for the LVM_MD_PV_ACTIVATED variable
so the rules can check whether the MD device is ready to use or not.
When switching to root fs and when the coldplug is done, the
ADD event is generated for the MD device - when we have ADD event
and at the same time we have LVM_MD_PV_ACTIVATED=1, we know this is
artificial event (the "coldplug" one) and we do jump to the pvscan
in that case.
That's how it was supposed to work. I can imagine the problematic
part here may be the transfer of the udev database state from initramfs
to root fs - there is a special way that udev uses to mark devices
so that the udev db state is kept from initramfs - I need to recall
that/check that because I don't remember that method right now...
--
Peter
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Mon, 27 Jul 2015 14:15:10 GMT) (full text, mbox, link).
Acknowledgement sent
to Peter Rajnoha <prajnoha@redhat.com>, 791869@bugs.debian.org:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Mon, 27 Jul 2015 14:15:10 GMT) (full text, mbox, link).
Message #144 received at 791869@bugs.debian.org (full text, mbox, reply):
On 07/27/2015 03:57 PM, Peter Rajnoha wrote:
> That's how it was supposed to work. I can imagine the problematic
> part here may be the transfer of the udev database state from initramfs
> to root fs - there is a special way that udev uses to mark devices
> so that the udev db state is kept from initramfs - I need to recall
> that/check that because I don't remember that method right now...
>
It's the OPTIONS+="db_persist" that needs to be used in initramfs
for MD devices. This marks udev db records related to this device with
sticky bit then which is then recognized by udev code and the udev
db state is not cleaned up in that case:
https://github.com/systemd/systemd/blob/master/src/udev/udevadm-info.c#L220
(the udevadm-info --cleanup-db - the records marked with sticky bit persist)
So once this udev db state is properly handed over from initramfs to root fs,
the rules in 69-dm-lvm-metad.rules should work (as it will use the
IMPORT{db}="LVM_MD_PV_ACTIVATED" to retrieve the state from previous runs
and this should fire pvscan then on coldplug properly:
IMPORT{db}="LVM_MD_PV_ACTIVATED"
ACTION=="add", ENV{LVM_MD_PV_ACTIVATED}=="1", GOTO="lvm_scan"
--
Peter
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Mon, 27 Jul 2015 14:30:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Peter Rajnoha <prajnoha@redhat.com>, 791869@bugs.debian.org, 791869@bugs.debian.org:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Mon, 27 Jul 2015 14:30:03 GMT) (full text, mbox, link).
Message #149 received at 791869@bugs.debian.org (full text, mbox, reply):
On 07/27/2015 04:12 PM, Peter Rajnoha wrote: > It's the OPTIONS+="db_persist" that needs to be used in initramfs > for MD devices. This marks udev db records related to this device with > sticky bit then which is then recognized by udev code and the udev > db state is not cleaned up in that case: For example, dracut (the initramfs environment used also in RH systems) has these rules to handle MD devices (it has the OPTIONS+="db_persist"): https://github.com/haraldh/dracut/blob/master/modules.d/90mdraid/59-persistent-storage-md.rules If you already use this in Debian and it doesn't work, it must be a regression in some version of udev as I've already gone through this with Harald Hoyer and Kay Sievers who take care of udev. Simply, this is the correct sequence that should be used: initramfs: - udev running in initramfs .... - mark records with OPTIONS+="db_persist" for devices that require that (currently it's the MD and DM) - udev in initramfs stopped - udev database copied from initramfs to root fs --- switch to root fs --- - udev running in root fs - udevadm info --cleanup-db (but will keep the records marked from initramfs with the db_persist flag) - udevadm trigger --action=add for the coldplug -- Peter
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Mon, 27 Jul 2015 14:51:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Peter Rajnoha <prajnoha@redhat.com>, 791869@bugs.debian.org, 791869@bugs.debian.org, 791869@bugs.debian.org:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Mon, 27 Jul 2015 14:51:03 GMT) (full text, mbox, link).
Message #154 received at 791869@bugs.debian.org (full text, mbox, reply):
Just noticed this option is not yet documented! I've filed a report for udev guys to add mention this in the man page and describe it a bit since it's quite important and yet it's hidden functionality if not documented: https://bugzilla.redhat.com/show_bug.cgi?id=1247210
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Mon, 27 Jul 2015 15:45:07 GMT) (full text, mbox, link).
Acknowledgement sent
to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Mon, 27 Jul 2015 15:45:07 GMT) (full text, mbox, link).
Message #159 received at 791869@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Am 27.07.2015 um 07:56 schrieb Bastian Blank:
> On Sun, Jul 26, 2015 at 12:24:43AM +0200, Michael Biebl wrote:
>> Fwiw, I could easily and reliably reproduce this problem in a VM with
>> LVM (guided setup with separate /, /home, /tmp, /var) on top of mdadm
>> RAID1 with a minimal standard installation.
>
> There are at least two distinct problems. The cause for the
> reproducible problem with MD is known. No cause is known for
> the more random blockage.
It looks like [1] is another duplicate of this bug.
>> I see you already got the information you requested from Stefan, I can
>> provide further diagnostics as well, if you want me to.
>
> If you have a more or less reproducible _non_-MD case, then I could use
> this information.
I tried to make lvmetad work a while ago and ran into [2] and [3].
Looking at /lib/udev/rules.d/69-lvm-metad.rules and rules/Makefile.in of
the current package, it looks like lvm2 was not compiled with
UDEV_SYSTEMD_BACKGROUND_JOBS = yes. The 69-lvm-metad.rules file on amd64 has
RUN+="/sbin/lvm pvscan --background --cache --activate ay --major $major
--minor $minor", ENV{LVM_SCANNED}="1"
udev under systemd doesn't allow long running processes which background
to be started from udev rules, such processes are killed by udevd [4].
Not sure if that is happening here. But fixing [2] and making sure
pvscan is run via /bin/systemd-run look like should be done in any case.
Michael
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774082
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783182
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783120
[4] http://www.freedesktop.org/software/systemd/man/udev.html#RUN{type}
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Mon, 27 Jul 2015 15:45:10 GMT) (full text, mbox, link).
Acknowledgement sent
to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Mon, 27 Jul 2015 15:45:10 GMT) (full text, mbox, link).
Message #164 received at 791869@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Am 27.07.2015 um 17:40 schrieb Michael Biebl: > Am 27.07.2015 um 07:56 schrieb Bastian Blank: >> On Sun, Jul 26, 2015 at 12:24:43AM +0200, Michael Biebl wrote: >>> Fwiw, I could easily and reliably reproduce this problem in a VM with >>> LVM (guided setup with separate /, /home, /tmp, /var) on top of mdadm >>> RAID1 with a minimal standard installation. >> >> There are at least two distinct problems. The cause for the >> reproducible problem with MD is known. No cause is known for >> the more random blockage. > > It looks like [1] is another duplicate of this bug. Bad quoting on my part. I wanted to say, that [1] is another duplicate of the LVM on MD problem. Not the "other" one. > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774082 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Tue, 28 Jul 2015 03:30:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Stefan Lippers-Hollmann <s.l-h@gmx.de>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Tue, 28 Jul 2015 03:30:03 GMT) (full text, mbox, link).
Message #169 received at 791869@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi Just for testing, I've tried using dracut as provider for linux-initramfs-tool instead of initramfs-tools. The results were positive, around 30 successful reboots - going back to initramfs-tools exposed the original problem right away again. I don't use any special initramfs-tools configuration or strange hooks/ scripts: $ dpkg -S /etc/initramfs-tools/ initramfs-tools: /etc/initramfs-tools $ dpkg -S /usr/share/initramfs-tools/ kmod, udev, initramfs-tools, ntfs-3g, dmsetup, lvm2, intel-microcode, fuse, busybox: /usr/share/initramfs-tools $ debsums -as initramfs-tools kmod udev ntfs-3g dmsetup lvm2 intel-microcode fuse busybox $ Regards Stefan Lippers-Hollmann
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Tue, 28 Jul 2015 06:45:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Bastian Blank <waldi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Tue, 28 Jul 2015 06:45:03 GMT) (full text, mbox, link).
Message #174 received at 791869@bugs.debian.org (full text, mbox, reply):
On Mon, Jul 27, 2015 at 05:40:39PM +0200, Michael Biebl wrote: > udev under systemd doesn't allow long running processes which background > to be started from udev rules, such processes are killed by udevd [4]. > Not sure if that is happening here. But fixing [2] and making sure > pvscan is run via /bin/systemd-run look like should be done in any case. The timeout for each event in udevd is 180 seconds and it should write an error to the log. Even a carefully placed sleep 60 does not break booting, however it takes a long time. Bastian -- Totally illogical, there was no chance. -- Spock, "The Galileo Seven", stardate 2822.3
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Tue, 28 Jul 2015 07:12:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Tue, 28 Jul 2015 07:12:03 GMT) (full text, mbox, link).
Message #179 received at 791869@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Am 28.07.2015 um 08:41 schrieb Bastian Blank: > On Mon, Jul 27, 2015 at 05:40:39PM +0200, Michael Biebl wrote: >> udev under systemd doesn't allow long running processes which background >> to be started from udev rules, such processes are killed by udevd [4]. >> Not sure if that is happening here. But fixing [2] and making sure >> pvscan is run via /bin/systemd-run look like should be done in any case. > > The timeout for each event in udevd is 180 seconds and it should write > an error to the log. Even a carefully placed sleep 60 does not break > booting, however it takes a long time. Have you tried running sleep in the background, detached from the controlling terminal, like e.g: #!/bin/sh ( sleep 10 ) >/dev/null 2>/dev/null & -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Wed, 29 Jul 2015 22:39:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Stefan Lippers-Hollmann <s.l-h@gmx.de>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Wed, 29 Jul 2015 22:39:04 GMT) (full text, mbox, link).
Message #184 received at 791869@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi Just confirming that there's no change with src:lvm2 2.02.126-1, the problem is still present. Regards Stefan Lippers-Hollmann
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Fri, 31 Jul 2015 01:30:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Stefan Lippers-Hollmann <s.l-h@gmx.de>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Fri, 31 Jul 2015 01:30:03 GMT) (full text, mbox, link).
Message #189 received at 791869@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi
On 2015-07-25, Bastian Blank wrote:
> On Tue, Jul 21, 2015 at 09:11:57PM +0200, Bastian Blank wrote:
> > So the next step could be debugging udev and see what it calls and when.
>
> Please provide the complete udev db (udevadm info -e) and udev debugging
attached (in the broken state) as nforce4.log.gz (gzipped).
> output (udev.log-priority=8 at the kernel command line) from a failed
> boot.
I've finally found a system where I can grab this information via
serial console (using the serial console makes it less likely to
trigger, but it still happens):
### this is different hardware than the one used for the previous reports ###
Loading Linux 4.0.0-2-amd64 ...
Loading initial ramdisk ...
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Initializing cgroup subsys cpuacct
[ 0.000000] Linux version 4.0.0-2-amd64 (debian-kernel@lists.debian.org) (gcc version 4.9.3 (Debian 4.9.3-2) ) #1 SMP Debian 4.0.8-2 (2015-07-22)
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.0.0-2-amd64 root=/dev/mapper/vg--challenger-debian64 ro console=tty0 console=ttyS0,115200n8 udev.log-priority=8
[ 0.000000] e820: BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009f3ff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009f400-0x000000000009ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000d7feffff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000d7ff0000-0x00000000d7ff2fff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x00000000d7ff3000-0x00000000d7ffffff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000ffffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x0000000127ffffff] usable
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] SMBIOS 2.3 present.
[ 0.000000] AGP: No AGP bridge found
[ 0.000000] e820: last_pfn = 0x128000 max_arch_pfn = 0x400000000
[ 0.000000] PAT configuration [0-7]: WB WC UC- UC WB WC UC- UC
[ 0.000000] e820: last_pfn = 0xd7ff0 max_arch_pfn = 0x400000000
[ 0.000000] found SMP MP-table at [mem 0x000f52f0-0x000f52ff] mapped at [ffff8800000f52f0]
[ 0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[ 0.000000] init_memory_mapping: [mem 0x127e00000-0x127ffffff]
[ 0.000000] init_memory_mapping: [mem 0x120000000-0x127dfffff]
[ 0.000000] init_memory_mapping: [mem 0x100000000-0x11fffffff]
[ 0.000000] init_memory_mapping: [mem 0x00100000-0xd7feffff]
[ 0.000000] RAMDISK: [mem 0x35d60000-0x36ea7fff]
[ 0.000000] ACPI: Early table checksum verification disabled
[ 0.000000] ACPI: RSDP 0x00000000000F91D0 000014 (v00 Nvidia)
[ 0.000000] ACPI: RSDT 0x00000000D7FF3040 000034 (v01 Nvidia AWRDACPI 42302E31 AWRD 00000000)
[ 0.000000] ACPI: FACP 0x00000000D7FF30C0 000074 (v01 Nvidia AWRDACPI 42302E31 AWRD 00000000)
[ 0.000000] ACPI: DSDT 0x00000000D7FF3180 0062AC (v01 NVIDIA AWRDACPI 00001000 MSFT 0100000E)
[ 0.000000] ACPI: FACS 0x00000000D7FF0000 000040
[ 0.000000] ACPI: SSDT 0x00000000D7FF9540 0001CA (v01 PTLTD POWERNOW 00000001 LTP 00000001)
[ 0.000000] ACPI: MCFG 0x00000000D7FF9780 00003C (v01 Nvidia AWRDACPI 42302E31 AWRD 00000000)
[ 0.000000] ACPI: APIC 0x00000000D7FF9480 000072 (v01 Nvidia AWRDACPI 42302E31 AWRD 00000000)
[ 0.000000] Scanning NUMA topology in Northbridge 24
[ 0.000000] No NUMA configuration found
[ 0.000000] Faking a node at [mem 0x0000000000000000-0x0000000127ffffff]
[ 0.000000] NODE_DATA(0) allocated [mem 0x127ff8000-0x127ffbfff]
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000001000-0x0000000000ffffff]
[ 0.000000] DMA32 [mem 0x0000000001000000-0x00000000ffffffff]
[ 0.000000] Normal [mem 0x0000000100000000-0x0000000127ffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000001000-0x000000000009efff]
[ 0.000000] node 0: [mem 0x0000000000100000-0x00000000d7feffff]
[ 0.000000] node 0: [mem 0x0000000100000000-0x0000000127ffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x0000000127ffffff]
[ 0.000000] Nvidia board detected. Ignoring ACPI timer override.
[ 0.000000] If you got timer trouble try acpi_use_timer_override
[ 0.000000] ACPI: PM-Timer IO Port: 0x4008
[ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[ 0.000000] IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
[ 0.000000] Using ACPI (MADT) for SMP configuration information
[ 0.000000] smpboot: Allowing 2 CPUs, 0 hotplug CPUs
[ 0.000000] PM: Registered nosave memory: [mem 0x00000000-0x00000fff]
[ 0.000000] PM: Registered nosave memory: [mem 0x0009f000-0x0009ffff]
[ 0.000000] PM: Registered nosave memory: [mem 0x000a0000-0x000effff]
[ 0.000000] PM: Registered nosave memory: [mem 0x000f0000-0x000fffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xd7ff0000-0xd7ff2fff]
[ 0.000000] PM: Registered nosave memory: [mem 0xd7ff3000-0xd7ffffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xd8000000-0xdfffffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xe0000000-0xefffffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xf0000000-0xfebfffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xfec00000-0xffffffff]
[ 0.000000] e820: [mem 0xf0000000-0xfebfffff] available for PCI devices
[ 0.000000] Booting paravirtualized kernel on bare hardware
[ 0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:2 nr_node_ids:1
[ 0.000000] PERCPU: Embedded 31 pages/cpu @ffff880127c00000 s87256 r8192 d31528 u1048576
[ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 1032057
[ 0.000000] Policy zone: Normal
[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.0.0-2-amd64 root=/dev/mapper/vg--challenger-debian64 ro console=tty0 console=ttyS0,115200n8 udev.log-priority=8
[ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.000000] AGP: Checking aperture...
[ 0.000000] AGP: No AGP bridge found
[ 0.000000] AGP: Node 0: aperture [bus addr 0xcc000000-0xcdffffff] (32MB)
[ 0.000000] Aperture pointing to e820 RAM. Ignoring.
[ 0.000000] AGP: Your BIOS doesn't leave a aperture memory hole
[ 0.000000] AGP: Please enable the IOMMU option in the BIOS setup
[ 0.000000] AGP: This costs you 64MB of RAM
[ 0.000000] AGP: Mapping aperture over RAM [mem 0xcc000000-0xcfffffff] (65536KB)
[ 0.000000] PM: Registered nosave memory: [mem 0xcc000000-0xcfffffff]
[ 0.000000] Memory: 3967052K/4193848K available (5560K kernel code, 1025K rwdata, 1940K rodata, 1252K init, 832K bss, 226796K reserved, 0K cma-reserved)
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] RCU dyntick-idle grace-period acceleration is enabled.
[ 0.000000] RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=2.
[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[ 0.000000] NR_IRQS:33024 nr_irqs:440 16
[ 0.000000] Console: colour VGA+ 80x25
[ 0.000000] console [tty0] enabled
[ 0.000000] console [ttyS0] enabled
[ 0.000000] tsc: Fast TSC calibration using PIT
[ 0.000000] tsc: Detected 2210.129 MHz processor
[ 0.000000] tsc: Marking TSC unstable due to TSCs unsynchronized
[ 0.020000] Calibrating delay loop (skipped), value calculated using timer frequency.. 4420.25 BogoMIPS (lpj=8840516)
[ 0.022819] pid_max: default: 32768 minimum: 301
[ 0.024011] ACPI: Core revision 20150204
[ 0.034613] ACPI: All ACPI Tables successfully acquired
[ 0.040052] Security Framework initialized
[ 0.044016] AppArmor: AppArmor disabled by boot time parameter
[ 0.048002] Yama: disabled by default; enable with sysctl kernel.yama.*
[ 0.052412] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
[ 0.061034] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
[ 0.065570] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes)
[ 0.068010] Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes)
[ 0.076010] Initializing cgroup subsys blkio
[ 0.080006] Initializing cgroup subsys memory
[ 0.084011] Initializing cgroup subsys devices
[ 0.088005] Initializing cgroup subsys freezer
[ 0.092005] Initializing cgroup subsys net_cls
[ 0.096006] Initializing cgroup subsys perf_event
[ 0.100005] Initializing cgroup subsys net_prio
[ 0.104030] CPU: Physical Processor ID: 0
[ 0.108002] CPU: Processor Core ID: 0
[ 0.112003] mce: CPU supports 5 MCE banks
[ 0.116013] Last level iTLB entries: 4KB 512, 2MB 8, 4MB 4
[ 0.120002] Last level dTLB entries: 4KB 512, 2MB 8, 4MB 4, 1GB 0
[ 0.124109] Freeing SMP alternatives memory: 24K (ffffffff81a3b000 - ffffffff81a41000)
[ 0.128932] ftrace: allocating 22402 entries in 88 pages
[ 0.140510] ..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1
[ 0.188000] smpboot: CPU0: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (fam: 0f, model: 2b, stepping: 01)
[ 0.193544] Performance Events: AMD PMU driver.
[ 0.197517] ... version: 0
[ 0.200001] ... bit width: 48
[ 0.204001] ... generic registers: 4
[ 0.208001] ... value mask: 0000ffffffffffff
[ 0.212001] ... max period: 00007fffffffffff
[ 0.216001] ... fixed-purpose events: 0
[ 0.220001] ... event mask: 000000000000000f
[ 0.224674] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
[ 0.228175] x86: Booting SMP configuration:
[ 0.232003] .... node #0, CPUs: #1
[ 0.328045] x86: Booted up 1 node, 2 CPUs
[ 0.332002] smpboot: Total of 2 processors activated (8840.92 BogoMIPS)
[ 0.336521] devtmpfs: initialized
[ 0.347852] PM: Registering ACPI NVS region [mem 0xd7ff0000-0xd7ff2fff] (12288 bytes)
[ 0.352149] pinctrl core: initialized pinctrl subsystem
[ 0.360216] NET: Registered protocol family 16
[ 0.376010] cpuidle: using governor ladder
[ 0.392005] cpuidle: using governor menu
[ 0.395956] TOM: 00000000d8000000 aka 3456M
[ 0.400015] TOM2: 0000000128000000 aka 4736M
[ 0.404064] ACPI: bus type PCI registered
[ 0.408002] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[ 0.412097] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[ 0.424003] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
[ 0.428653] PCI: Using configuration type 1 for base access
[ 0.448086] ACPI: Added _OSI(Module Device)
[ 0.452009] ACPI: Added _OSI(Processor Device)
[ 0.456002] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.460002] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.472379] ACPI: Interpreter enabled
[ 0.476016] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20150204/hwxface-580)
[ 0.484014] ACPI: (supports S0 S1 S3 S4 S5)
[ 0.488002] ACPI: Using IOAPIC for interrupt routing
[ 0.492038] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 0.511874] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-05])
[ 0.516011] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[ 0.524007] acpi PNP0A08:00: _OSC failed (AE_NOT_FOUND); disabling ASPM
[ 0.532847] PCI host bridge to bus 0000:00
[ 0.536004] pci_bus 0000:00: root bus resource [bus 00-05]
[ 0.540003] pci_bus 0000:00: root bus resource [io 0x0000-0x03af window]
[ 0.548002] pci_bus 0000:00: root bus resource [io 0x03e0-0x0cf7 window]
[ 0.556002] pci_bus 0000:00: root bus resource [io 0x9000-0xffff window]
[ 0.560002] pci_bus 0000:00: root bus resource [io 0x03b0-0x03df window]
[ 0.568002] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
[ 0.576002] pci_bus 0000:00: root bus resource [mem 0xd8000000-0xfe02ffff window]
[ 0.584002] pci_bus 0000:00: root bus resource [mem 0xfeb00000-0xfebfffff window]
[ 0.592243] HPET not enabled in BIOS. You might try hpet=force boot option
[ 0.600452] pci 0000:00:02.0: System wakeup disabled by ACPI
[ 0.604202] pci 0000:00:02.1: System wakeup disabled by ACPI
[ 0.612251] pci 0000:00:06.0: legacy IDE quirk: reg 0x10: [io 0x01f0-0x01f7]
[ 0.620003] pci 0000:00:06.0: legacy IDE quirk: reg 0x14: [io 0x03f6]
[ 0.624002] pci 0000:00:06.0: legacy IDE quirk: reg 0x18: [io 0x0170-0x0177]
[ 0.632002] pci 0000:00:06.0: legacy IDE quirk: reg 0x1c: [io 0x0376]
[ 0.640586] pci 0000:00:09.0: System wakeup disabled by ACPI
[ 0.644183] pci 0000:00:0a.0: System wakeup disabled by ACPI
[ 0.652183] pci 0000:00:0b.0: System wakeup disabled by ACPI
[ 0.656182] pci 0000:00:0c.0: System wakeup disabled by ACPI
[ 0.664182] pci 0000:00:0d.0: System wakeup disabled by ACPI
[ 0.668179] pci 0000:00:0e.0: System wakeup disabled by ACPI
[ 0.677041] pci 0000:00:09.0: PCI bridge to [bus 01] (subtractive decode)
[ 0.684071] pci 0000:00:0b.0: PCI bridge to [bus 02]
[ 0.688049] pci 0000:00:0c.0: PCI bridge to [bus 03]
[ 0.692047] pci 0000:00:0d.0: PCI bridge to [bus 04]
[ 0.696287] pci 0000:05:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force'
[ 0.708008] pci 0000:00:0e.0: PCI bridge to [bus 05]
[ 0.712173] ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 *5 7 9 10 11 12 14 15)
[ 0.722577] ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 *7 9 10 11 12 14 15)
[ 0.730066] ACPI: PCI Interrupt Link [LNK3] (IRQs *3 4 5 7 9 10 11 12 14 15)
[ 0.737564] ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 5 *7 9 10 11 12 14 15)
[ 0.744974] ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
[ 0.753684] ACPI: PCI Interrupt Link [LUBA] (IRQs 3 4 5 7 9 10 *11 12 14 15)
[ 0.761269] ACPI: PCI Interrupt Link [LUBB] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
[ 0.769962] ACPI: PCI Interrupt Link [LMAC] (IRQs 3 4 5 7 9 *10 11 12 14 15)
[ 0.777565] ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 5 7 9 10 *11 12 14 15)
[ 0.785278] ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 *5 7 9 10 11 12 14 15)
[ 0.792689] ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 5 7 9 *10 11 12 14 15)
[ 0.800394] ACPI: PCI Interrupt Link [LUB2] (IRQs *3 4 5 7 9 10 11 12 14 15)
[ 0.806994] ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
[ 0.816278] ACPI: PCI Interrupt Link [LSID] (IRQs 3 4 5 7 9 10 *11 12 14 15)
[ 0.824274] ACPI: PCI Interrupt Link [LFID] (IRQs 3 4 5 7 9 *10 11 12 14 15)
[ 0.831001] ACPI: PCI Interrupt Link [LPCA] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
[ 0.840288] ACPI: PCI Interrupt Link [APC1] (IRQs 16) *0, disabled.
[ 0.845987] ACPI: PCI Interrupt Link [APC2] (IRQs 17) *0, disabled.
[ 0.853567] ACPI: PCI Interrupt Link [APC3] (IRQs 18) *0, disabled.
[ 0.860075] ACPI: PCI Interrupt Link [APC4] (IRQs 19) *0, disabled.
[ 0.865959] ACPI: PCI Interrupt Link [APC5] (IRQs *16), disabled.
[ 0.872292] ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22 23) *0, disabled.
[ 0.880297] ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22 23) *0, disabled.
[ 0.886876] ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22 23) *0, disabled.
[ 0.894881] ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22 23) *0, disabled.
[ 0.902576] ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22 23) *0, disabled.
[ 0.909987] ACPI: PCI Interrupt Link [APCS] (IRQs 20 21 22 23) *0, disabled.
[ 0.917571] ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22 23) *0, disabled.
[ 0.924289] ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22 23) *0, disabled.
[ 0.932295] ACPI: PCI Interrupt Link [APSI] (IRQs 20 21 22 23) *0, disabled.
[ 0.938882] ACPI: PCI Interrupt Link [APSJ] (IRQs 20 21 22 23) *0, disabled.
[ 0.946882] ACPI: PCI Interrupt Link [APCP] (IRQs 20 21 22 23) *0, disabled.
[ 0.955294] vgaarb: setting as boot device: PCI:0000:05:00.0
[ 0.956000] vgaarb: device added: PCI:0000:05:00.0,decodes=io+mem,owns=io+mem,locks=none
[ 0.968003] vgaarb: loaded
[ 0.972002] vgaarb: bridge control possible 0000:05:00.0
[ 0.976112] PCI: Using ACPI for IRQ routing
[ 0.986847] pci 0000:00:01.1: can't claim BAR 4 [io 0x4c00-0x4c3f]: no compatible bridge window
[ 0.988004] pci 0000:00:01.1: can't claim BAR 5 [io 0x4c40-0x4c7f]: no compatible bridge window
[ 0.992292] Switched to clocksource refined-jiffies
[ 1.006887] pnp: PnP ACPI init
[ 1.008235] system 00:00: [io 0x4000-0x407f] could not be reserved
[ 1.012005] system 00:00: [io 0x4080-0x40ff] has been reserved
[ 1.016004] system 00:00: [io 0x4400-0x447f] has been reserved
[ 1.020004] system 00:00: [io 0x4480-0x44ff] could not be reserved
[ 1.024005] system 00:00: [io 0x4800-0x487f] has been reserved
[ 1.028005] system 00:00: [io 0x4880-0x48ff] has been reserved
[ 1.032610] pnp 00:01: disabling [io 0x0010-0x001f] because it overlaps 0000:00:01.1 BAR 4 [io 0x0000-0x003f]
[ 1.036006] pnp 00:01: disabling [io 0x0022-0x003f] because it overlaps 0000:00:01.1 BAR 4 [io 0x0000-0x003f]
[ 1.040007] pnp 00:01: disabling [io 0x0010-0x001f disabled] because it overlaps 0000:00:01.1 BAR 5 [io 0x0000-0x003f]
[ 1.044006] pnp 00:01: disabling [io 0x0022-0x003f disabled] because it overlaps 0000:00:01.1 BAR 5 [io 0x0000-0x003f]
[ 1.048060] system 00:01: [io 0x0b78-0x0b7b] has been reserved
[ 1.052007] system 00:01: [io 0x0f78-0x0f7b] has been reserved
[ 1.056007] system 00:01: [io 0x0a78-0x0a7b] has been reserved
[ 1.060007] system 00:01: [io 0x0e78-0x0e7b] has been reserved
[ 1.064007] system 00:01: [io 0x0bbc-0x0bbf] has been reserved
[ 1.068007] system 00:01: [io 0x0fbc-0x0fbf] has been reserved
[ 1.072008] system 00:01: [io 0x04d0-0x04d1] has been reserved
[ 1.076008] system 00:01: [io 0x0290-0x030f] has been reserved
[ 1.080852] system 00:05: [mem 0xe0000000-0xefffffff] has been reserved
[ 1.084196] system 00:06: [mem 0x000d5000-0x000d7fff] has been reserved
[ 1.088009] system 00:06: [mem 0x000f0000-0x000f7fff] could not be reserved
[ 1.092009] system 00:06: [mem 0x000f8000-0x000fbfff] could not be reserved
[ 1.096009] system 00:06: [mem 0x000fc000-0x000fffff] could not be reserved
[ 1.100009] system 00:06: [mem 0xd7ff0000-0xd7ffffff] could not be reserved
[ 1.104017] system 00:06: [mem 0xffff0000-0xffffffff] has been reserved
[ 1.108010] system 00:06: [mem 0x00000000-0x0009ffff] could not be reserved
[ 1.112010] system 00:06: [mem 0x00100000-0xd7feffff] could not be reserved
[ 1.116010] system 00:06: [mem 0xfec00000-0xfec00fff] could not be reserved
[ 1.120010] system 00:06: [mem 0xfee00000-0xfeefffff] has been reserved
[ 1.124011] system 00:06: [mem 0xfefff000-0xfeffffff] has been reserved
[ 1.128011] system 00:06: [mem 0xfff80000-0xfff80fff] has been reserved
[ 1.132011] system 00:06: [mem 0xfff90000-0xfffbffff] has been reserved
[ 1.136011] system 00:06: [mem 0xfffed000-0xfffeffff] has been reserved
[ 1.140026] pnp: PnP ACPI: found 7 devices
[ 1.154733] Switched to clocksource acpi_pm
[ 1.156277] pci 0000:00:01.1: BAR 4: assigned [io 0x0400-0x043f]
[ 1.162406] pci 0000:00:01.1: BAR 5: assigned [io 0x0440-0x047f]
[ 1.168533] pci 0000:01:07.0: BAR 6: assigned [mem 0xfdf00000-0xfdf1ffff pref]
[ 1.175785] pci 0000:00:09.0: PCI bridge to [bus 01]
[ 1.180774] pci 0000:00:09.0: bridge window [io 0xd000-0xdfff]
[ 1.186894] pci 0000:00:09.0: bridge window [mem 0xfde00000-0xfdefffff]
[ 1.193706] pci 0000:00:09.0: bridge window [mem 0xfdf00000-0xfdffffff pref]
[ 1.200955] pci 0000:00:0b.0: PCI bridge to [bus 02]
[ 1.205949] pci 0000:00:0b.0: bridge window [io 0xc000-0xcfff]
[ 1.212070] pci 0000:00:0b.0: bridge window [mem 0xfdd00000-0xfddfffff]
[ 1.218882] pci 0000:00:0b.0: bridge window [mem 0xfdc00000-0xfdcfffff 64bit pref]
[ 1.226651] pci 0000:00:0c.0: PCI bridge to [bus 03]
[ 1.231650] pci 0000:00:0c.0: bridge window [io 0xb000-0xbfff]
[ 1.237767] pci 0000:00:0c.0: bridge window [mem 0xfdb00000-0xfdbfffff]
[ 1.244578] pci 0000:00:0c.0: bridge window [mem 0xfda00000-0xfdafffff 64bit pref]
[ 1.252346] pci 0000:00:0d.0: PCI bridge to [bus 04]
[ 1.257334] pci 0000:00:0d.0: bridge window [io 0xa000-0xafff]
[ 1.263454] pci 0000:00:0d.0: bridge window [mem 0xfd900000-0xfd9fffff]
[ 1.270266] pci 0000:00:0d.0: bridge window [mem 0xfd800000-0xfd8fffff 64bit pref]
[ 1.278037] pci 0000:05:00.0: BAR 6: assigned [mem 0xfd700000-0xfd71ffff pref]
[ 1.285289] pci 0000:00:0e.0: PCI bridge to [bus 05]
[ 1.290277] pci 0000:00:0e.0: bridge window [io 0x9000-0x9fff]
[ 1.296396] pci 0000:00:0e.0: bridge window [mem 0xfd700000-0xfd7fffff]
[ 1.303208] pci 0000:00:0e.0: bridge window [mem 0xd8000000-0xdfffffff 64bit pref]
[ 1.311128] NET: Registered protocol family 2
[ 1.315807] TCP established hash table entries: 32768 (order: 6, 262144 bytes)
[ 1.323271] TCP bind hash table entries: 32768 (order: 7, 524288 bytes)
[ 1.330230] TCP: Hash tables configured (established 32768 bind 32768)
[ 1.336902] TCP: reno registered
[ 1.340173] UDP hash table entries: 2048 (order: 4, 65536 bytes)
[ 1.346262] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes)
[ 1.352891] NET: Registered protocol family 1
[ 1.357610] ACPI: PCI Interrupt Link [APCF] enabled at IRQ 23
[ 1.432337] ACPI: PCI Interrupt Link [APCL] enabled at IRQ 22
[ 1.438271] pci 0000:00:00.0: Found enabled HT MSI Mapping
[ 1.443787] pci 0000:00:0b.0: Found disabled HT MSI Mapping
[ 1.449394] pci 0000:00:00.0: Found enabled HT MSI Mapping
[ 1.454910] pci 0000:00:0b.0: Linking AER extended capability
[ 1.460712] pci 0000:00:00.0: Found enabled HT MSI Mapping
[ 1.466230] pci 0000:00:0c.0: Found disabled HT MSI Mapping
[ 1.471830] pci 0000:00:00.0: Found enabled HT MSI Mapping
[ 1.477338] pci 0000:00:0c.0: Linking AER extended capability
[ 1.483145] pci 0000:00:00.0: Found enabled HT MSI Mapping
[ 1.488661] pci 0000:00:0d.0: Found disabled HT MSI Mapping
[ 1.494260] pci 0000:00:00.0: Found enabled HT MSI Mapping
[ 1.499777] pci 0000:00:0d.0: Linking AER extended capability
[ 1.505585] pci 0000:00:00.0: Found enabled HT MSI Mapping
[ 1.511098] pci 0000:00:0e.0: Found disabled HT MSI Mapping
[ 1.516698] pci 0000:00:00.0: Found enabled HT MSI Mapping
[ 1.522206] pci 0000:00:0e.0: Linking AER extended capability
[ 1.528088] Unpacking initramfs...
[ 1.956396] Freeing initrd memory: 17696K (ffff880035d60000 - ffff880036ea8000)
[ 1.964043] PCI-DMA: Disabling AGP.
[ 1.967669] PCI-DMA: aperture base @ cc000000 size 65536 KB
[ 1.973273] PCI-DMA: using GART IOMMU.
[ 1.977052] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
[ 1.987525] microcode: AMD CPU family 0xf not supported
[ 1.993253] futex hash table entries: 512 (order: 3, 32768 bytes)
[ 1.999427] audit: initializing netlink subsys (disabled)
[ 2.004887] audit: type=2000 audit(1438304487.003:1): initialized
[ 2.012713] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[ 2.019132] zpool: loaded
[ 2.022005] VFS: Disk quotas dquot_6.5.2
[ 2.025986] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 2.033683] alg: No test for stdrng (krng)
[ 2.037863] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[ 2.045363] io scheduler noop registered
[ 2.049327] io scheduler deadline registered
[ 2.053664] io scheduler cfq registered (default)
[ 2.058766] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ 2.064392] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[ 2.071112] GHES: HEST is not enabled!
[ 2.075000] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 2.101587] 00:04: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[ 2.109401] Linux agpgart interface v0.103
[ 2.113580] AMD IOMMUv2 driver by Joerg Roedel <jroedel@suse.de>
[ 2.119614] AMD IOMMUv2 functionality not available on this system
[ 2.125900] i8042: PNP: No PS/2 controller found. Probing ports directly.
[ 2.135245] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 2.140253] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 2.145558] mousedev: PS/2 mouse device common for all mice
[ 2.151231] rtc_cmos 00:02: RTC can wake from S4
[ 2.156038] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
[ 2.162195] rtc_cmos 00:02: alarms up to one year, y3k, 242 bytes nvram
[ 2.168857] ledtrig-cpu: registered to indicate activity on CPUs
[ 2.175371] TCP: cubic registered
[ 2.178761] NET: Registered protocol family 10
[ 2.183574] mip6: Mobile IPv6
[ 2.186587] NET: Registered protocol family 17
[ 2.191064] mpls_gso: MPLS GSO support
[ 2.195333] registered taskstats version 1
[ 2.200054] rtc_cmos 00:02: setting system clock to 2015-07-31 01:01:28 UTC (1438304488)
[ 2.209268] Freeing unused kernel memory: 1252K (ffffffff81902000 - ffffffff81a3b000)
[ 2.217161] Write protecting the kernel read-only data: 8192k
[ 2.223547] Freeing unused kernel memory: 572K (ffff880001571000 - ffff880001600000)
[ 2.231468] Freeing unused kernel memory: 108K (ffff8800017e5000 - ffff880001800000)
Loading, please wait...
invalid udev.log[ 2.343952] random: systemd-udevd urandom read with 4 bits of entropy available
-priority ignored: 8
starting version 223
[ 2.395493] Floppy drive(s): fd0 is 1.44M
[ 2.405976] ACPI: bus type USB registered
[ 2.408426] thermal LNXTHERM:00: registered as thermal_zone0
[ 2.408428] ACPI: Thermal Zone [THRM] (22 C)
[ 2.421883] forcedeth: Reverse Engineered nForce ethernet driver. Version 0.64.
[ 2.430762] FDC 0 is a post-1991 82077
[ 2.437114] SCSI subsystem initialized
[ 2.441271] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
[ 2.448370] e1000: Copyright (c) 1999-2006 Intel Corporation.
[ 2.457827] usbcore: registered new interface driver usbfs
[ 2.463082] ACPI: PCI Interrupt Link [APCH] enabled at IRQ 21
[ 2.469429] ACPI: PCI Interrupt Link [APC4] enabled at IRQ 19
[ 2.475335] usbcore: registered new interface driver hub
[ 2.480723] usbcore: registered new device driver usb
[ 2.486751] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 2.494007] ehci-pci: EHCI PCI platform driver
[ 2.499091] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 2.536054] firewire_ohci 0000:01:0c.0: added OHCI v1.0 device as card 0, 4 IR + 8 IT contexts, quirks 0x11
[ 2.546092] ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17
[ 2.976540] forcedeth 0000:00:0a.0: ifname eth0, PHY OUI 0x5043 @ 1, addr 00:16:17:b6:05:93
[ 2.984924] forcedeth 0000:00:0a.0: highdma csum gbit lnktim desc-v3
[ 2.992444] scsi host0: pata_amd
[ 2.995937] scsi host1: pata_amd
[ 2.999268] ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xfb00 irq 14
[ 3.001425] e1000 0000:01:07.0 eth1: (PCI:33MHz:32-bit) 00:0e:0c:34:1c:fc
[ 3.001428] e1000 0000:01:07.0 eth1: Intel(R) PRO/1000 Network Connection
[ 3.019883] ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xfb08 irq 15
[ 3.027192] ACPI: PCI Interrupt Link [APSI] enabled at IRQ 20
[ 3.033395] scsi host2: sata_nv
[ 3.036681] scsi host3: sata_nv
[ 3.039895] ata3: SATA max UDMA/133 cmd 0x9f0 ctl 0xbf0 bmdma 0xf600 irq 20
[ 3.046882] ata4: SATA max UDMA/133 cmd 0x970 ctl 0xb70 bmdma 0xf608 irq 20
[ 3.048132] firewire_core 0000:01:0c.0: created device fw0: GUID 0010dc000105bafc, S400
[ 3.062072] ehci-pci 0000:00:02.1: EHCI Host Controller
[ 3.067335] ehci-pci 0000:00:02.1: new USB bus registered, assigned bus number 1
[ 3.074764] ehci-pci 0000:00:02.1: debug port 1
[ 3.079362] ehci-pci 0000:00:02.1: irq 22, io mem 0xfeb00000
[ 3.096032] ehci-pci 0000:00:02.1: USB 2.0 started, EHCI 1.00
[ 3.101868] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 3.108684] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 3.115930] usb usb1: Product: EHCI Host Controller
[ 3.120833] usb usb1: Manufacturer: Linux 4.0.0-2-amd64 ehci_hcd
[ 3.126865] usb usb1: SerialNumber: 0000:00:02.1
[ 3.131700] hub 1-0:1.0: USB hub found
[ 3.135491] hub 1-0:1.0: 10 ports detected
[ 3.140356] ohci-pci: OHCI PCI platform driver
[ 3.145348] ACPI: PCI Interrupt Link [APSJ] enabled at IRQ 23
[ 3.151622] scsi host4: sata_nv
[ 3.154922] scsi host5: sata_nv
[ 3.158158] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xf100 irq 23
[ 3.165148] ata6: SATA max UDMA/133 cmd 0x960 ctl 0xb60 bmdma 0xf108 irq 23
[ 3.172281] ohci-pci 0000:00:02.0: OHCI PCI host controller
[ 3.177885] ohci-pci 0000:00:02.0: new USB bus registered, assigned bus number 2
[ 3.185349] ohci-pci 0000:00:02.0: irq 23, io mem 0xfe02f000
[ 3.208303] ata1.00: ATAPI: TOSHIBA ODD-DVD SD-M1802, J031, max UDMA/33
[ 3.244225] ata1.00: configured for UDMA/33
[ 3.246074] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
[ 3.246076] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 3.246077] usb usb2: Product: OHCI PCI host controller
[ 3.246079] usb usb2: Manufacturer: Linux 4.0.0-2-amd64 ohci_hcd
[ 3.246080] usb usb2: SerialNumber: 0000:00:02.0
[ 3.246250] hub 2-0:1.0: USB hub found
[ 3.246259] hub 2-0:1.0: 10 ports detected
[ 3.287336] scsi 0:0:0:0: CD-ROM TOSHIBA ODD-DVD SD-M1802 J031 PQ: 0 ANSI: 5
[ 3.464290] ata2.00: ATAPI: _NEC DVD_RW ND-1300A, 1.0B, max UDMA/33
[ 3.484031] ata5: SATA link down (SStatus 0 SControl 300)
[ 3.484320] ata2.00: configured for UDMA/33
[ 3.487617] scsi 1:0:0:0: CD-ROM _NEC DVD_RW ND-1300A 1.0B PQ: 0 ANSI: 5
[ 3.532033] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 3.560222] ata3.00: ATA-7: SAMSUNG HD103UJ, 1AA01113, max UDMA7
[ 3.566258] ata3.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 0/32)
[ 3.580212] ata3.00: configured for UDMA/133
[ 3.584694] scsi 2:0:0:0: Direct-Access ATA SAMSUNG HD103UJ 1113 PQ: 0 ANSI: 5
[ 3.904021] ata4: SATA link down (SStatus 0 SControl 300)
[ 4.220023] ata6: SATA link down (SStatus 0 SControl 300)
[ 4.229278] sd 2:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
[ 4.237114] sd 2:0:0:0: [sda] Write Protect is off
[ 4.239487] sr 0:0:0:0: [sr0] scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray
[ 4.239491] cdrom: Uniform CD-ROM driver Revision: 3.20
[ 4.251422] sr 1:0:0:0: [sr1] scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
[ 4.262530] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 4.279911] sda: sda1 sda2
[ 4.283028] sd 2:0:0:0: [sda] Attached SCSI disk
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premoun[ 4.464679] device-mapper: uevent: version 1.0.3
t ... done.
Beg[ 4.470727] device-mapper: ioctl: 4.30.0-ioctl (2014-12-22) initialised: dm-devel@redhat.com
in: Mounting root file system ... Begin: Running /scripts/local-top ... lvmetad is not active yet, using direct activation during sysinit
done.
Begin: Running /scripts/local-premount ... done.
Begin: Checking root file system ... fsck from util-linux 2.26.2
debian64: clean, 178882/655360 files, 1273858/2621440 blocks
done.
[ 4.730466] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)
done.
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... done.
[ 5.395461] systemd[1]: Inserted module 'autofs4'
[ 5.412965] systemd[1]: Failed to insert module 'kdbus': Function not implemented
[ 5.485944] systemd[1]: systemd 223 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN)
[ 5.504210] systemd[1]: Detected architecture x86-64.
Welcome to Debian GNU/Linux stretch/sid!
[ 5.545149] systemd[1]: Set hostname to <challenger>.
[ 5.642124] random: nonblocking pool is initialized
[ 6.615490] systemd[1]: Reached target Encrypted Volumes.
[ OK ] Reached target Encrypted Volumes.
[ 6.632180] systemd[1]: Reached target Remote File Systems (Pre).
[ OK ] Reached target Remote File Systems (Pre).
[ 6.648086] systemd[1]: Reached target Swap.
[ OK ] Reached target Swap.
[ 6.660158] systemd[1]: Created slice Root Slice.
[ OK ] Created slice Root Slice.
[ 6.672171] systemd[1]: Listening on Journal Socket (/dev/log).
[ OK ] Listening on Journal Socket (/dev/log).
[ 6.688127] systemd[1]: Listening on fsck to fsckd communication Socket.
[ OK ] Listening on fsck to fsckd communication Socket.
[ 6.708125] systemd[1]: Listening on Journal Socket.
[ OK ] Listening on Journal Socket.
[ 6.720276] systemd[1]: Created slice System Slice.
[ OK ] Created slice System Slice.
[ 6.736966] systemd[1]: Mounting Debug File System...
Mounting Debug File System...
[ 6.752921] systemd[1]: Mounting POSIX Message Queue File System...
Mounting POSIX Message Queue File System...
[ 6.768401] systemd[1]: Created slice system-systemd\x2dfsck.slice.
[ OK ] Created slice system-systemd\x2dfsck.slice.
[ 6.784333] systemd[1]: Created slice system-getty.slice.
[ OK ] Created slice system-getty.slice.
[ 6.800168] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
[ OK ] Listening on /dev/initctl Compatibility Named Pipe.
[ 6.820250] systemd[1]: Listening on Device-mapper event daemon FIFOs.
[ OK ] Listening on Device-mapper event daemon FIFOs.
[ 6.840208] systemd[1]: Listening on udev Control Socket.
[ OK ] Listening on udev Control Socket.
[ 6.856892] systemd[1]: Starting LSB: Set keymap...
Starting LSB: Set keymap...
[ 6.873103] systemd[1]: Starting Increase datagram queue length...
Starting Increase datagram queue length...
[ 6.888267] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[ OK ] Started Forward Password Requests to Wall Directory Watch.
[ 6.908291] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
[ OK ] Started Dispatch Password Requests to Console Directory Watch.
[ 6.928210] systemd[1]: Listening on udev Kernel Socket.
[ OK ] Listening on udev Kernel Socket.
[ 6.944414] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
[ OK ] Set up automount Arbitrary Executab...ats File System Automount Point.
[ 7.006790] systemd[1]: Listening on LVM2 metadata daemon socket.
[ OK ] Listening on LVM2 metadata daemon socket.
[ 7.025279] systemd[1]: Starting Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling...
Starting Monitoring of LVM2 mirrors... dmeventd or progress polling...
[ 7.048248] systemd[1]: Listening on LVM2 poll daemon socket.
[ OK ] Listening on LVM2 poll daemon socket.
[ 7.064365] systemd[1]: Created slice system-serial\x2dgetty.slice.
[ OK ] Created slice system-serial\x2dgetty.slice.
[ 7.080195] systemd[1]: Created slice User and Session Slice.
[ OK ] Created slice User and Session Slice.
[ 7.096089] systemd[1]: Reached target Slices.
[ OK ] Reached target Slices.
[ 7.144971] systemd[1]: Starting Load Kernel Modules...
Starting Load Kernel Modules...
[ 7.160271] systemd[1]: Listening on networkd rtnetlink socket.
[ OK ] Listening on networkd rtnetlink socket.
[ 7.176978] systemd[1]: Mounting Huge Pages File System...
Mounting Huge Pages File System...
[ 7.304826] lp: driver loaded but no devices found
[ 7.313290] systemd[1]: Starting Create list of required static device nodes for the current kernel...
[ 7.313897] ppdev: user-space parallel port driver
Starting Create list of required st... nodes for the current kernel...
[ 7.340308] systemd[1]: Listening on Journal Audit Socket.
[ OK ] Listening on Journal Audit Socket.
[ 7.357035] systemd[1]: Mounted Huge Pages File System.
[ OK ] Mounted Huge Pages File System.
[ 7.372173] systemd[1]: Mounted POSIX Message Queue File System.
[ OK ] Mounted POSIX Message Queue File System.
[ 7.388127] systemd[1]: Mounted Debug File System.
[ OK ] Mounted Debug File System.
[ 7.400690] systemd[1]: Started LSB: Set keymap.
[ OK ] Started LSB: Set keymap.
[ 7.416679] systemd[1]: Started Increase datagram queue length.
[ OK ] Started Increase datagram queue length.
[ 7.432472] systemd[1]: Started Load Kernel Modules.
[ OK ] Started Load Kernel Modules.
[ 7.448623] systemd[1]: Started Create list of required static device nodes for the current kernel.
[ OK ] Started Create list of required sta...ce nodes for the current kernel.
[ 7.488131] systemd[1]: Started LVM2 metadata daemon.
[ OK ] Started LVM2 metadata daemon.
[ 7.505244] systemd[1]: Starting Create Static Device Nodes in /dev...
Starting Create Static Device Nodes in /dev...
[ 7.521231] systemd[1]: Starting Apply Kernel Variables...
Starting Apply Kernel Variables...
[ 7.536238] systemd[1]: Listening on Syslog Socket.
[ OK ] Listening on Syslog Socket.
[ 7.549042] systemd[1]: Starting Journal Service...
Starting Journal Service...
[ 7.626948] systemd[1]: Started Apply Kernel Variables.
[ OK ] Started Apply Kernel Variables.
[ 7.651621] systemd[1]: Started Journal Service.
[ OK ] Started Journal Service.
[ OK ] Started Create Static Device Nodes in /dev.
Starting udev Kernel Device Manager...
[ OK ] Started Monitoring of LVM2 mirrors,...ng dmeventd or progress polling.
[ OK ] Started udev Kernel Device Manager.
Starting LSB: Set preliminary keymap...
Starting Copy rules generated while the root was ro...
Starting LSB: Tune IDE hard disks...
[ OK ] Started Copy rules generated while the root was ro.
[ OK ] Started LSB: Tune IDE hard disks.
[ OK ] Started LSB: Set preliminary keymap.
Starting Remount Root and Kernel File Systems...
[ 9.128398] EXT4-fs (dm-0): re-mounted. Opts: barrier=0
[ OK ] Started Remount Root and Kernel File Systems.
[ OK ] Reached target Local File Systems (Pre).
Starting udev Coldplug all Devices...
[ OK ] Started udev Coldplug all Devices.
[ 9.627291] i2c i2c-0: nForce2 SMBus adapter at 0x400
[ 9.632443] i2c i2c-1: nForce2 SMBus adapter at 0x440
[ 9.688424] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input2
[ 9.696870] ACPI: Power Button [PWRB]
[ 9.701014] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3
[ 9.708547] ACPI: Power Button [PWRF]
[ 9.749209] sr 0:0:0:0: Attached scsi generic sg0 type 5
[ 9.754654] sr 1:0:0:0: Attached scsi generic sg1 type 5
[ 9.760195] sd 2:0:0:0: Attached scsi generic sg2 type 0
[ 9.992502] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[ 10.008780] ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 22
[ 10.025826] cfg80211: Calling CRDA to update world regulatory domain
[ OK ] Found device /dev/ttyS0.
[ 10.262142] powernow_k8: fid 0xe (2200 MHz), vid 0x8
[ 10.267171] powernow_k8: fid 0xc (2000 MHz), vid 0xa
[ 10.272168] powernow_k8: fid 0xa (1800 MHz), vid 0xc
[ 10.277173] powernow_k8: fid 0x2 (1000 MHz), vid 0x12
[ 10.283883] powernow_k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2 cpu cores) (version 2.20.00)
[ 10.333535] [drm] Initialized drm 1.1.0 20060810
[ 10.340138] snd_intel8x0 0000:00:04.0: intel8x0_measure_ac97_clock: measured 53611 usecs (2632 samples)
[ 10.349580] snd_intel8x0 0000:00:04.0: clocking to 46930
[ 10.349587] ath5k: unknown parameter 'override_countrycode' ignored
[ 10.349939] ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16
[ 10.350036] ath5k 0000:01:06.0: registered as 'phy0'
[ 10.378911] EDAC MC: Ver: 3.0.0
[ 10.418363] input: PC Speaker as /devices/platform/pcspkr/input/input5
[ OK ] Reached target Sound Card.
[ 10.531939] [drm] radeon kernel modesetting enabled.
[ 10.537484] MCE: In-kernel MCE decoding enabled.
[ 10.542775] ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
[ 10.549554] [drm] initializing kernel modesetting (RV380 0x1002:0x5B60 0x1043:0x0082).
[ 10.557690] [drm] register mmio base: 0xFD7F0000
[ 10.562363] [drm] register mmio size: 65536
[ 10.568340] [drm] Generation 2 PCI interface, using max accessible memory
[ 10.575206] radeon 0000:05:00.0: VRAM: 128M 0x00000000D8000000 - 0x00000000DFFFFFFF (128M used)
[ 10.583954] radeon 0000:05:00.0: GTT: 512M 0x00000000B8000000 - 0x00000000D7FFFFFF
[ 10.591589] [drm] Detected VRAM RAM=128M, BAR=128M
[ 10.596426] [drm] RAM width 64bits DDR
[ 10.601022] [TTM] Zone kernel: Available graphics memory: 2026328 kiB
[ 10.607633] [TTM] Initializing pool allocator
[ 10.613478] [TTM] Initializing DMA pool allocator
[ 10.619245] [drm] radeon: 128M of VRAM memory ready
[ 10.624287] [drm] radeon: 512M of GTT memory ready.
[ 10.629248] [drm] GART: num cpu pages 131072, num gpu pages 131072
[ 10.637939] [drm] radeon: 1 quad pipes, 1 Z pipes initialized.
[ 10.644856] [drm] PCIE GART of 512M enabled (table at 0x00000000D8040000).
[ 10.651899] radeon 0000:05:00.0: WB enabled
[ 10.656140] radeon 0000:05:00.0: fence driver on ring 0 use gpu addr 0x00000000b8000000 and cpu addr 0xffff8800d0aa4000
[ 10.666997] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 10.673649] [drm] Driver supports precise vblank timestamp query.
[ 10.679869] radeon 0000:05:00.0: radeon: MSI limited to 32-bit
[ 10.686110] radeon 0000:05:00.0: radeon: using MSI.
[ 10.691103] [drm] radeon: irq initialized.
[ 10.695394] [drm] Loading R300 Microcode
[ 10.700608] AMD64 EDAC driver v3.4.0
[ 10.704289] EDAC amd64: DRAM ECC disabled.
[ 10.708439] EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load.
[ 10.708439] Either enable ECC checking or force module loading by setting 'ecc_enable_override'.
[ 10.708439] (Note that use of the override may cause unknown side effects.)
[ 10.772272] radeon 0000:05:00.0: firmware: direct-loading firmware radeon/R300_cp.bin
[ 10.780604] [drm] radeon: ring at 0x00000000B8001000
[ 10.786017] [drm] ring test succeeded in 0 usecs
[ 10.790957] [drm] ib test succeeded in 0 usecs
[ 10.795911] [drm] Radeon Display Connectors
[ 10.800159] [drm] Connector 0:
[ 10.803247] [drm] VGA-1
[ 10.805910] [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
[ 10.811960] [drm] Encoders:
[ 10.814978] [drm] CRT1: INTERNAL_DAC1
[ 10.819033] [drm] Connector 1:
[ 10.822134] [drm] DVI-I-1
[ 10.824979] [drm] HPD1
[ 10.827552] [drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
[ 10.833595] [drm] Encoders:
[ 10.836607] [drm] CRT2: INTERNAL_DAC2
[ 10.840667] [drm] DFP1: INTERNAL_TMDS1
[ 10.844806] [drm] Connector 2:
[ 10.847896] [drm] SVIDEO-1
[ 10.850822] [drm] Encoders:
[ 10.853835] [drm] TV1: INTERNAL_DAC2
[ 10.886112] [drm] fb mappable at 0xD80C0000
[ 10.890354] [drm] vram apper at 0xD8000000
[ 10.894571] [drm] size 3145728
[ 10.897735] [drm] fb depth is 24
[ 10.901008] [drm] pitch is 4096
[ 10.904609] fbcon: radeondrmfb (fb0) is primary device
[ 10.954993] cfg80211: World regulatory domain updated:
[ 10.954997] cfg80211: DFS Master region: unset
[ 10.954997] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 10.955000] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 10.955002] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 10.955003] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
[ 10.955005] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
[ 10.955007] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[ 10.955009] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
[ 10.955010] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
[ 10.955011] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
[ 10.960165] Console: switching to colour frame buffer device 128x48
[ 11.062379] radeon 0000:05:00.0: fb0: radeondrmfb frame buffer device
[ 11.064100] ath5k: phy0: Atheros AR2414 chip found (MAC: 0x79, PHY: 0x45)
[ 11.069441] cfg80211: Calling CRDA for country: CN
[ 11.080548] radeon 0000:05:00.0: registered panic notifier
[ 11.097610] [drm] Initialized radeon 2.41.0 20080528 for 0000:05:00.0 on minor 0
[ 11.116397] cfg80211: Regulatory domain changed to country: CN
[ 11.122303] cfg80211: DFS Master region: FCC
[ 11.126540] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 11.136372] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 11.144440] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2300 mBm), (N/A)
[ 11.153990] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2300 mBm), (0 s)
[ 11.164765] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 3000 mBm), (N/A)
[ 11.174049] cfg80211: (57240000 KHz - 59400000 KHz @ 2160000 KHz), (N/A, 2800 mBm), (N/A)
[ 11.183702] cfg80211: (59400000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4400 mBm), (N/A)
[ 11.193346] cfg80211: (63720000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 2800 mBm), (N/A)
[ 11.206307] cfg80211: Calling CRDA for country: DE
[ 11.280282] cfg80211: Regulatory domain changed to country: DE
[ 11.287446] cfg80211: DFS Master region: ETSI
[ 11.291758] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 11.304214] cfg80211: (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 11.313620] cfg80211: (5150000 KHz - 5250000 KHz @ 80000 KHz, 200000 KHz AUTO), (N/A, 2000 mBm), (N/A)
[ 11.324522] cfg80211: (5250000 KHz - 5350000 KHz @ 80000 KHz, 200000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[ 11.335457] cfg80211: (5470000 KHz - 5725000 KHz @ 160000 KHz), (N/A, 2698 mBm), (0 s)
[ 11.344948] cfg80211: (57000000 KHz - 66000000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)
[ OK ] Created slice system-systemd\x2drfkill.slice.
[ TIME ] Timed out waiting for device dev-vg\x2dchallenger-storage.device.
[DEPEND] Dependency failed for /srv/storage.
[DEPEND] Dependency failed for Local File Systems.
[DEPEND] Dependency failed for File System Check on /dev/vg-challenger/storage.
[ TIME ] Timed out waiting for device dev-vg\x2dchallenger-home.device.
[DEPEND] Dependency failed for /home.
[DEPEND] Dependency failed for File System Check on /dev/vg-challenger/home.
[ TIME ] Timed out waiting for device dev-vg\x2dchallenger-var.device.
[DEPEND] Dependency failed for File System Check on /dev/vg-challenger/var.
[DEPEND] Dependency failed for /var.
[DEPEND] Dependency failed for Update UTMP about System Runlevel Changes.
[DEPEND] Dependency failed for Update UTMP about System Boot/Shutdown.
[DEPEND] Dependency failed for Load/Save RF Kill Switch Status of rfkill0.
[DEPEND] Dependency failed for Flush Journal to Persistent Storage.
[DEPEND] Dependency failed for Network Time Synchronization.
[DEPEND] Dependency failed for Virtual Machine and Container Storage.
[DEPEND] Dependency failed for Load/Save Random Seed.
[DEPEND] Dependency failed for /tmp.
[ OK ] Stopped getty on tty2-tty6 if dbus and logind are not available.
[ OK ] Stopped target Graphical Interface.
[ OK ] Stopped target Multi-User System.
[ OK ] Stopped Network Name Resolution.
[ OK ] Stopped D-Bus System Message Bus.
[ OK ] Stopped LSB: daemon to balance interrupts for SMP systems.
[ OK ] Stopped LSB: set CPUFreq kernel parameters.
[ OK ] Stopped Serial Getty on ttyS0.
[ OK ] Stopped Internet superserver.
[ OK ] Stopped Getty on tty1.
[ OK ] Reached target Login Prompts.
[ OK ] Stopped CUPS Scheduler.
[ OK ] Stopped LSB: Advanced IEEE 802.11 management daemon.
[ OK ] Stopped LSB: start DirMngr daemon.
[ OK ] Stopped Daily Cleanup of Temporary Directories.
[ OK ] Reached target Timers.
[ OK ] Stopped WPA supplicant.
[ OK ] Stopped Login Service.
[ OK ] Stopped Run anacron jobs.
[ OK ] Reached target System Time Synchronized.
[ OK ] Closed Network Name Resolution Service Bus Name.
[ OK ] Closed ACPID Listen Socket.
[ OK ] Stopped System Logging Service.
[ OK ] Closed Syslog Socket.
[ OK ] Closed Network Service Bus Name.
Starting Network Service...
[ OK ] Stopped OpenBSD Secure Shell server.
[ OK ] Stopped Self Monitoring and Reporting Technology (SMART) Daemon.
[ OK ] Closed CUPS Scheduler.
[ OK ] Stopped Simple Desktop Display Manager.
[ OK ] Stopped Permit User Sessions.
[ OK ] Stopped Regular background program processing daemon.
[ 97.254795] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ OK ] Stopped LSB: start and stop UML networking services.
[ OK ] Stopped ACPI Events Check.
[ 97.285241] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[ 97.295750] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ OK ] Stopped LSB: Load kernel modules needed to enable cpufreq scaling.
[ OK ] Reached target Remote File Systems.
[ OK ] Stopped /etc/rc.local Compatibility.
[ OK ] Stopped target Basic System.
[ OK ] Reached target Paths.
[ OK ] Closed D-Bus System Message Bus Socket.
[ OK ] Stopped target System Initialization.
Starting Console System Startup Logging...
[ OK ] Started Emergency Shell.
Starting LSB: Prepare console...
[ OK ] Reached target Emergency Mode.
Starting Create Volatile Files and Directories...
[ OK ] Reached target Sockets.
[ OK ] Started Network Service.
[ OK ] Reached target Network.
[ OK ] Reached target Network is Online.
[FAILED] Failed to start Console System Startup Logging.
See 'systemctl status console-kit-log-system-start.service' for details.
[ OK ] Started Create Volatile Files and Directories.
[ OK ] Started LSB: Prepare console.
Starting LSB: Set console font and keymap...
[ OK ] Started LSB: Set console font and keymap.
Welcome to emergGive root password for maintenance
(or press Control-D to continue):
challenger:~# cat /proc/version
Linux version 4.0.0-2-amd64 (debian-kernel@lists.debian.org) (gcc version 4.9.3 (Debian 4.9.3-2) ) #1 SMP Debian 4.0.8-2 (2015-07-22)
challenger:~# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.0.0-2-amd64 root=/dev/mapper/vg--challenger-debian64 ro console=tty0 console=ttyS0,115200n8 udev.log-priority=8
challenger:~# cat /etc/fstab
# /etc/fstab: filesystem table.
#
# filesystem mountpoint type options dump pass
/dev/vg-challenger/debian64 / ext4 defaults,noatime,barrier=0 1 1
/dev/vg-challenger/var /var ext4 auto,exec,dev,noatime,barrier=0 1 2
/var/tmp /tmp none bind 0 0
/dev/vg-challenger/home /home ext4 auto,exec,nodev,nosuid,noatime,barrier=0 1 2
/dev/vg-challenger/storage /srv/storage ext4 auto,noexec,nodev,nosuid,noatime,barrier=0 1 2
challenger:~# md5sum -b /etc/lvm/lvm.conf
465b8eb81f04535531c5c3a0fec8b788 */etc/lvm/lvm.conf
challenger:~# pvs
PV VG Fmt Attr PSize PFree
/dev/sda2 vg-challenger lvm2 a-- 831,49g 251,49g
challenger:~# vgs
VG #PV #LV #SN Attr VSize VFree
vg-challenger 1 4 0 wz--n- 831,49g 251,49g
challenger:~# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
debian64 vg-challenger -wi-ao---- 10,00g
home vg-challenger -wi------- 310,00g
storage vg-challenger -wi------- 250,00g
var vg-challenger -wi------- 10,00g
challenger:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
fd0 2:0 1 4K 0 disk
sda 8:0 0 931,5G 0 disk
├─sda1 8:1 0 100G 0 part
└─sda2 8:2 0 831,5G 0 part
└─vg--challenger-debian64 254:0 0 10G 0 lvm /
sr0 11:0 1 1024M 0 rom
sr1 11:1 1 1024M 0 rom
challenger:~# systemctl status | cat -
● challenger
State: maintenance
Jobs: 0 queued
Failed: 1 units
Since: Fr 2015-07-31 03:01:31 CEST; 8min ago
CGroup: /
├─1 /sbin/init
└─system.slice
├─lvm2-lvmetad.service
│ └─199 /sbin/lvmetad -f
├─emergency.service
│ ├─479 /bin/sh -c /sbin/sulogin; /bin/systemctl --job-mode=fail --no-block default
│ ├─480 /sbin/sulogin
│ ├─483 bash
│ ├─484 /sbin/sulogin
│ ├─515 systemctl status
│ └─516 cat -
├─systemd-journald.service
│ └─203 /lib/systemd/systemd-journald
├─systemd-networkd.service
│ └─383 /lib/systemd/systemd-networkd
└─systemd-udevd.service
└─206 /lib/systemd/systemd-udevd
challenger:~# vgchange -ay
4 logical volume(s) in volume group "vg-challenger" now active
[ 525.672908] EXT4-fs (dm-3): barriers disabled)
[ 525.731022] EXT4-fs (dm-1): barriers disabled
[ 525.733624] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Opts: barrier=0
[ 525.779844] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: barrier=0
[ 525.783631] EXT4-fs (dm-2): barriers disabled
[ 525.808851] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: barrier=0
challenger:~# mount -a
challenger:~# exit
exit
Error getting authority: Error initializing authority: Could not connect: No such file or directory (g-io-error-quark, 1)
[ 547.192828] systemd-journald[203]: Received request to flush runtime journal from PID 1
Debian GNU/Linux stretch/sid challenger ttyS0
challenger login: root
Passwort:
Letzte Anmeldung: Freitag, den 31. Juli 2015, 03:00:55 CEST auf ttyS0
Linux challenger 4.0.0-2-amd64 #1 SMP Debian 4.0.8-2 (2015-07-22) x86_64
Sie haben Nachrichten.
challenger:~# dpkg -l | grep -e lvm2 -e clvm -e libdevmapper-dev -e libdevmapper1.02.1 -e dmsetup -e libdevmapper-event1.02.1 -e dmeventd -e liblvm2app2.2 -e liblvm2cmd2.02 -e liblvm2-dev -e initramfs-tools -e linux-image-amd64 -e linux-image-4.0.0-2-amd64 -e mdadm
ii dmeventd 2:1.02.103-1 amd64 Linux Kernel Device Mapper event daemon
ii dmsetup 2:1.02.103-1 amd64 Linux Kernel Device Mapper userspace library
ii initramfs-tools 0.120 all generic modular initramfs generator
ii libdevmapper-event1.02.1:amd64 2:1.02.103-1 amd64 Linux Kernel Device Mapper event support library
ii libdevmapper1.02.1:amd64 2:1.02.103-1 amd64 Linux Kernel Device Mapper userspace library
ii liblvm2app2.2:amd64 2.02.126-1 amd64 LVM2 application library
ii liblvm2cmd2.02:amd64 2.02.126-1 amd64 LVM2 command library
ii linux-image-4.0.0-2-amd64 4.0.8-2 amd64 Linux 4.0 for 64-bit PCs
ii linux-image-amd64 4.0+65 amd64 Linux for 64-bit PCs (meta-package)
ii lvm2 2.02.126-1 amd64 Linux Logical Volume Manager
challenger:~# dpkg -S /etc/initramfs-tools/
initramfs-tools: /etc/initramfs-tools
challenger:~# dpkg -S /usr/share/initramfs-tools/
lvm2, fuse, busybox, uswsusp, initramfs-tools, ntfs-3g, udev, kmod, dmsetup: /usr/share/initramfs-tools
challenger:~# debsums -as lvm2 fuse busybox uswsusp initramfs-tools ntfs-3g udev kmod dmsetup
challenger:~# find /etc/udev/rules.d/ /lib/udev/rules.d/ -type f | sort
/etc/udev/rules.d/70-persistent-cd.rules
/etc/udev/rules.d/70-persistent-net.rules
/lib/udev/rules.d/39-usbmuxd.rules
/lib/udev/rules.d/50-firmware.rules
/lib/udev/rules.d/50-udev-default.rules
/lib/udev/rules.d/55-dm.rules
/lib/udev/rules.d/56-lvm.rules
/lib/udev/rules.d/60-block.rules
/lib/udev/rules.d/60-bridge-network-interface.rules
/lib/udev/rules.d/60-cdrom_id.rules
/lib/udev/rules.d/60-crda.rules
/lib/udev/rules.d/60-drm.rules
/lib/udev/rules.d/60-evdev.rules
/lib/udev/rules.d/60-ffado.rules
/lib/udev/rules.d/60-fuse.rules
/lib/udev/rules.d/60-gnupg.rules
/lib/udev/rules.d/60-ir-keytable.rules
/lib/udev/rules.d/60-libgphoto2-6.rules
/lib/udev/rules.d/60-libsane.rules
/lib/udev/rules.d/60-persistent-alsa.rules
/lib/udev/rules.d/60-persistent-input.rules
/lib/udev/rules.d/60-persistent-storage-dm.rules
/lib/udev/rules.d/60-persistent-storage.rules
/lib/udev/rules.d/60-persistent-storage-tape.rules
/lib/udev/rules.d/60-persistent-v4l.rules
/lib/udev/rules.d/60-qemu-system-common.rules
/lib/udev/rules.d/60-serial.rules
/lib/udev/rules.d/60-udev-config-aptosid.rules
/lib/udev/rules.d/64-btrfs.rules
/lib/udev/rules.d/64-xorg-xkb.rules
/lib/udev/rules.d/69-libmtp.rules
/lib/udev/rules.d/69-lvm-metad.rules
/lib/udev/rules.d/69-xorg-vmmouse.rules
/lib/udev/rules.d/70-mouse.rules
/lib/udev/rules.d/70-power-switch.rules
/lib/udev/rules.d/70-spice-vdagentd.rules
/lib/udev/rules.d/70-uaccess.rules
/lib/udev/rules.d/70-udev-acl.rules
/lib/udev/rules.d/71-seat.rules
/lib/udev/rules.d/73-idrac.rules
/lib/udev/rules.d/73-seat-late.rules
/lib/udev/rules.d/75-net-description.rules
/lib/udev/rules.d/75-probe_mtd.rules
/lib/udev/rules.d/78-sound-card.rules
/lib/udev/rules.d/80-debian-compat.rules
/lib/udev/rules.d/80-drivers.rules
/lib/udev/rules.d/80-net-setup-link.rules
/lib/udev/rules.d/80-networking.rules
/lib/udev/rules.d/80-udisks2.rules
/lib/udev/rules.d/85-hdparm.rules
/lib/udev/rules.d/85-hwclock.rules
/lib/udev/rules.d/85-regulatory.rules
/lib/udev/rules.d/90-alsa-restore.rules
/lib/udev/rules.d/95-upower-csr.rules
/lib/udev/rules.d/95-upower-hid.rules
/lib/udev/rules.d/95-upower-wup.rules
/lib/udev/rules.d/99-saned.rules
/lib/udev/rules.d/99-systemd.rules
Regards
Stefan Lippers-Hollmann
[nforce4.log.gz (application/gzip, attachment)]
[Message part 3 (application/pgp-signature, inline)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Fri, 31 Jul 2015 01:45:08 GMT) (full text, mbox, link).
Acknowledgement sent
to Stefan Lippers-Hollmann <s.l-h@gmx.de>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Fri, 31 Jul 2015 01:45:08 GMT) (full text, mbox, link).
Message #194 received at 791869@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi On 2015-07-31, Stefan Lippers-Hollmann wrote: [...] > challenger:~# pvs > PV VG Fmt Attr PSize PFree > /dev/sda2 vg-challenger lvm2 a-- 831,49g 251,49g > challenger:~# vgs > VG #PV #LV #SN Attr VSize VFree > vg-challenger 1 4 0 wz--n- 831,49g 251,49g > challenger:~# lvs > LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert > debian64 vg-challenger -wi-ao---- 10,00g > home vg-challenger -wi------- 310,00g > storage vg-challenger -wi------- 250,00g > var vg-challenger -wi------- 10,00g > challenger:~# lsblk > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > fd0 2:0 1 4K 0 disk > sda 8:0 0 931,5G 0 disk > ├─sda1 8:1 0 100G 0 part > └─sda2 8:2 0 831,5G 0 part > └─vg--challenger-debian64 254:0 0 10G 0 lvm / > sr0 11:0 1 1024M 0 rom > sr1 11:1 1 1024M 0 rom [...] and now the same from the, previously failed, boot that has been 'encouraged' to find the missing logical volumes via: > challenger:~# vgchange -ay > 4 logical volume(s) in volume group "vg-challenger" now active > [ 525.672908] EXT4-fs (dm-3): barriers disabled) > [ 525.731022] EXT4-fs (dm-1): barriers disabled > [ 525.733624] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Opts: barrier=0 > [ 525.779844] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: barrier=0 > [ 525.783631] EXT4-fs (dm-2): barriers disabled > [ 525.808851] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: barrier=0 > > challenger:~# mount -a > challenger:~# exit [...] challenger:~# pvs PV VG Fmt Attr PSize PFree /dev/sda2 vg-challenger lvm2 a-- 831,49g 251,49g challenger:~# vgs VG #PV #LV #SN Attr VSize VFree vg-challenger 1 4 0 wz--n- 831,49g 251,49g challenger:~# lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert debian64 vg-challenger -wi-ao---- 10,00g home vg-challenger -wi-ao---- 310,00g storage vg-challenger -wi-ao---- 250,00g var vg-challenger -wi-ao---- 10,00g challenger:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT fd0 2:0 1 4K 0 disk sda 8:0 0 931,5G 0 disk ├─sda1 8:1 0 100G 0 part └─sda2 8:2 0 831,5G 0 part ├─vg--challenger-debian64 254:0 0 10G 0 lvm / ├─vg--challenger-var 254:1 0 10G 0 lvm /var ├─vg--challenger-home 254:2 0 310G 0 lvm /home └─vg--challenger-storage 254:3 0 250G 0 lvm /srv/storage sr0 11:0 1 1024M 0 rom sr1 11:1 1 1024M 0 rom challenger:~# cat /proc/mounts sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 udev /dev devtmpfs rw,relatime,size=10240k,nr_inodes=495884,mode=755 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /run tmpfs rw,nosuid,relatime,size=810532k,mode=755 0 0 /dev/dm-0 / ext4 rw,noatime,nobarrier,data=ordered 0 0 securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0 tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0 tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0 tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0 cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd 0 0 pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0 cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0 cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0 cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0 cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0 cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0 cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0 cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0 mqueue /dev/mqueue mqueue rw,relatime 0 0 debugfs /sys/kernel/debug debugfs rw,relatime 0 0 systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=33,pgrp=1,timeout=0,minproto=5,maxproto=5,direct 0 0 hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0 /dev/mapper/vg--challenger-storage /srv/storage ext4 rw,nosuid,nodev,noexec,noatime,nobarrier,data=ordered 0 0 /dev/mapper/vg--challenger-var /var ext4 rw,noatime,nobarrier,data=ordered 0 0 /dev/mapper/vg--challenger-home /home ext4 rw,nosuid,nodev,noatime,nobarrier,data=ordered 0 0 /dev/mapper/vg--challenger-var /tmp ext4 rw,noatime,nobarrier,data=ordered 0 0 tmpfs /run/user/103 tmpfs rw,nosuid,nodev,relatime,size=405268k,mode=700,uid=103,gid=110 0 0 tmpfs /run/user/0 tmpfs rw,nosuid,nodev,relatime,size=405268k,mode=700 0 0 tmpfs /run/user/1000 tmpfs rw,nosuid,nodev,relatime,size=405268k,mode=700,uid=1000,gid=1000 0 0 Regards Stefan Lippers-Hollmann
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Fri, 31 Jul 2015 04:03:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Stefan Lippers-Hollmann <s.l-h@gmx.de>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Fri, 31 Jul 2015 04:03:04 GMT) (full text, mbox, link).
Message #199 received at 791869@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi
On 2015-07-31, Stefan Lippers-Hollmann wrote:
> On 2015-07-25, Bastian Blank wrote:
> > output (udev.log-priority=8 at the kernel command line) from a failed
> > boot.
[...]
> Loading, please wait...
> invalid udev.log[ 2.343952] random: systemd-udevd urandom read with 4 bits of entropy available
> -priority ignored: 8
[...]
Well, obviously (or rather not quite that obviously), the maximum log
level is 7.
systemd-223/src/libudev/libudev-util.c:
int util_log_priority(const char *priority)
{
[...]
if (prio >= 0 && prio <= 7)
return prio;
else
return -ERANGE;
[...]
}
However it seems to be even harder to reproduce with udev.log-priority=7
set. While it triggers in roughly 85% of all reboots on this system
without serial console and special logging parameters, it takes quite a
few reboots to reproduce with serial console and udev.log-priority=7.
The attached bootlog (serial console && udev.log-priority=7) has
unfortunately not been recorded with an official Debian kernel, but
I've been able to reproduce it with 4.0.0-2-amd64 as well. Just that I
missed increasing the scrollback buffer in time and wasn't able to
fetch a full bootlog then - and, regardless of the kernel in use,
reproducing takes quite many reboots (too many for now) with full
logging enabled.
Regards
Stefan Lippers-Hollmann
[boot.log.gz (application/gzip, attachment)]
[Message part 3 (application/pgp-signature, inline)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Fri, 31 Jul 2015 06:21:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Stefan Lippers-Hollmann <s.l-h@gmx.de>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Fri, 31 Jul 2015 06:21:03 GMT) (full text, mbox, link).
Message #204 received at 791869@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi On 2015-07-31, Stefan Lippers-Hollmann wrote: > On 2015-07-31, Stefan Lippers-Hollmann wrote: > > On 2015-07-25, Bastian Blank wrote: [...] > The attached bootlog (serial console && udev.log-priority=7) has > unfortunately not been recorded with an official Debian kernel, but > I've been able to reproduce it with 4.0.0-2-amd64 as well. Just that I > missed increasing the scrollback buffer in time and wasn't able to > fetch a full bootlog then - and, regardless of the kernel in use, > reproducing takes quite many reboots (too many for now) with full > logging enabled. It took many reboots (>50), but here is a reproduction with the official Debian kernel - gzipped logs attached. Regards Stefan Lippers-Hollmann
[boot-serialcon.log.gz (application/gzip, attachment)]
[dmesg.log.gz (application/gzip, attachment)]
[journalctl.log.gz (application/gzip, attachment)]
[udevadm-info-post-fix.log.gz (application/gzip, attachment)]
[udevadm-info-pre-fix.log.gz (application/gzip, attachment)]
[Message part 7 (application/pgp-signature, inline)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Fri, 31 Jul 2015 08:57:08 GMT) (full text, mbox, link).
Acknowledgement sent
to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Fri, 31 Jul 2015 08:57:08 GMT) (full text, mbox, link).
Message #209 received at 791869@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On Fri, 31 Jul 2015 08:08:38 +0200 Stefan Lippers-Hollmann
<s.l-h@gmx.de> wrote:
> Hi
>
> On 2015-07-31, Stefan Lippers-Hollmann wrote:
> > On 2015-07-31, Stefan Lippers-Hollmann wrote:
> > > On 2015-07-25, Bastian Blank wrote:
> [...]
> > The attached bootlog (serial console && udev.log-priority=7) has
> > unfortunately not been recorded with an official Debian kernel, but
> > I've been able to reproduce it with 4.0.0-2-amd64 as well. Just that I
> > missed increasing the scrollback buffer in time and wasn't able to
> > fetch a full bootlog then - and, regardless of the kernel in use,
> > reproducing takes quite many reboots (too many for now) with full
> > logging enabled.
>
> It took many reboots (>50), but here is a reproduction with the
> official Debian kernel - gzipped logs attached.
Stefan, you are running amd64, right?
Bastian built the lvm2 on amd64 on a non-systemd system, it seems. This
results in /lib/udev/rules.d/69-lvm-metad.rules lookin like this:
...
ENV{SYSTEMD_READY}="1"
RUN+="/sbin/lvm pvscan --background --cache --activate ay --major $major
--minor $minor", ENV{LVM_SCANNED}="1"
...
If you build lvm2 on a systemd system, those rules look like
...
ENV{SYSTEMD_READY}="1"
ACTION!="remove", ENV{LVM_PV_GONE}=="1", RUN+="/bin/systemd-run
/sbin/lvm pvscan --cache $major:$minor", GOTO="lvm_end"
ENV{SYSTEMD_ALIAS}="/dev/block/$major:$minor"
ENV{ID_MODEL}="LVM PV $env{ID_FS_UUID_ENC} on /dev/$name"
ENV{SYSTEMD_WANTS}="lvm2-pvscan@$major:$minor.service"
If I replace /lib/udev/rules.d/69-lvm-metad.rules with the attached
file, my problems with LVM on top of RAID1 are gone. Can you copy the
attached file to /etc/udev/rules.d/ and test if that fixes your problem?
We likely need a runtime check, not a compile time check, in
69-lvm-metad.rules to decide which rules to run.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
[69-lvm-metad.rules (text/plain, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Fri, 31 Jul 2015 12:21:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Fri, 31 Jul 2015 12:21:03 GMT) (full text, mbox, link).
Message #214 received at 791869@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Am 31.07.2015 um 10:54 schrieb Michael Biebl: > If I replace /lib/udev/rules.d/69-lvm-metad.rules with the attached > file, my problems with LVM on top of RAID1 are gone. Grr, nvm. While testing, I actually had use_lvmetad disabled. Still getting failures, even with the modified 69-lvm-metad.rules. So this was a red herring. That said, it still looks like this specific rule should have a runtime, not a compile time switch. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Sat, 01 Aug 2015 04:36:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Stefan Lippers-Hollmann <s.l-h@gmx.de>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Sat, 01 Aug 2015 04:36:03 GMT) (full text, mbox, link).
Message #219 received at 791869@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi
On 2015-07-31, Michael Biebl wrote:
> On Fri, 31 Jul 2015 08:08:38 +0200 Stefan Lippers-Hollmann
> <s.l-h@gmx.de> wrote:
> > Hi
> >
> > On 2015-07-31, Stefan Lippers-Hollmann wrote:
> > > On 2015-07-31, Stefan Lippers-Hollmann wrote:
> > > > On 2015-07-25, Bastian Blank wrote:
> > [...]
> > > The attached bootlog (serial console && udev.log-priority=7) has
> > > unfortunately not been recorded with an official Debian kernel, but
> > > I've been able to reproduce it with 4.0.0-2-amd64 as well. Just that I
> > > missed increasing the scrollback buffer in time and wasn't able to
> > > fetch a full bootlog then - and, regardless of the kernel in use,
> > > reproducing takes quite many reboots (too many for now) with full
> > > logging enabled.
> >
> > It took many reboots (>50), but here is a reproduction with the
> > official Debian kernel - gzipped logs attached.
>
> Stefan, you are running amd64, right?
Yes, all affected systems are running unstable/ amd64.
While I still use 3 non 64 bit capable i386 systems, I haven't powered
them up often enough to be 100% sure about their status in this regard.
> Bastian built the lvm2 on amd64 on a non-systemd system, it seems. This
> results in /lib/udev/rules.d/69-lvm-metad.rules lookin like this:
> ...
> ENV{SYSTEMD_READY}="1"
> RUN+="/sbin/lvm pvscan --background --cache --activate ay --major $major
> --minor $minor", ENV{LVM_SCANNED}="1"
> ...
>
> If you build lvm2 on a systemd system, those rules look like
> ...
> ENV{SYSTEMD_READY}="1"
> ACTION!="remove", ENV{LVM_PV_GONE}=="1", RUN+="/bin/systemd-run
> /sbin/lvm pvscan --cache $major:$minor", GOTO="lvm_end"
> ENV{SYSTEMD_ALIAS}="/dev/block/$major:$minor"
> ENV{ID_MODEL}="LVM PV $env{ID_FS_UUID_ENC} on /dev/$name"
> ENV{SYSTEMD_WANTS}="lvm2-pvscan@$major:$minor.service"
>
>
> If I replace /lib/udev/rules.d/69-lvm-metad.rules with the attached
> file, my problems with LVM on top of RAID1 are gone. Can you copy the
> attached file to /etc/udev/rules.d/ and test if that fixes your problem?
[...]
I've done a local bin-NMU (on a systemd using chroot, so I ended up
with exactly the same lib/udev/rules.d/69-lvm-metad.rules you got),
as that was easier to deploy and test locally - and it indeed seems
to fix the problem. Both the nforce4 system and the ivy-bridge system
used for reporting this bug have gone through >>20 successful reboots
each and all other affected systems I've tested seem to be fixed as
well (none of them having mdadm installed, I haven't been able to
test the single system using mdadm+lvm2 so far).
Thanks a lot
Stefan Lippers-Hollmann
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Sat, 01 Aug 2015 11:39:08 GMT) (full text, mbox, link).
Acknowledgement sent
to Cristian Ionescu-Idbohrn <cristian.ionescu-idbohrn@axis.com>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Sat, 01 Aug 2015 11:39:08 GMT) (full text, mbox, link).
Message #224 received at 791869@bugs.debian.org (full text, mbox, reply):
On Mon, 27 Jul 2015, Michael Biebl wrote:
>
> Not sure if that is happening here. But fixing [2] and making sure
> pvscan is run via /bin/systemd-run look like should be done in any
^^^^^^^^^^^^^^^^
> case.
>
> Michael
>
>
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783182
Just a minor point here.
I have 2 systems running lvm over raid0.
On one of them (non-systemd init unstable box, but with systemd and
udev 223-2 installed) there's no /bin/systemd-run:
# which systemd-run
/usr/bin/systemd-run
Hardly possible to use _before_ /usr (separate partition) is mounted.
On another system (stretch (104 upgraded, 0 newly installed, 0 to
remove and 141 not upgraded), uptime: 13:09:13 up 840 days, 23:13, 67
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
users), the systemd package is not even installed. udev 222-2 and
lvm2 2.02.111-2.2 are installed.
systemd-run is refered to in /lib/udev/rules.d/69-lvm-metad.rules:
ACTION!="remove", ENV{LVM_PV_GONE}=="1", RUN+="/bin/systemd-run /sbin/lvm pvscan --cache $major:$minor", GOTO="lvm_end"
Cheers,
--
Cristian
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Mon, 03 Aug 2015 04:39:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Stefan Lippers-Hollmann <s.l-h@gmx.de>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Mon, 03 Aug 2015 04:39:03 GMT) (full text, mbox, link).
Message #229 received at 791869@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi
On 2015-08-01, Stefan Lippers-Hollmann wrote:
> On 2015-07-31, Michael Biebl wrote:
[...]
> > Bastian built the lvm2 on amd64 on a non-systemd system, it seems. This
> > results in /lib/udev/rules.d/69-lvm-metad.rules lookin like this:
> > ...
> > ENV{SYSTEMD_READY}="1"
> > RUN+="/sbin/lvm pvscan --background --cache --activate ay --major $major
> > --minor $minor", ENV{LVM_SCANNED}="1"
> > ...
> >
> > If you build lvm2 on a systemd system, those rules look like
> > ...
> > ENV{SYSTEMD_READY}="1"
> > ACTION!="remove", ENV{LVM_PV_GONE}=="1", RUN+="/bin/systemd-run
> > /sbin/lvm pvscan --cache $major:$minor", GOTO="lvm_end"
> > ENV{SYSTEMD_ALIAS}="/dev/block/$major:$minor"
> > ENV{ID_MODEL}="LVM PV $env{ID_FS_UUID_ENC} on /dev/$name"
> > ENV{SYSTEMD_WANTS}="lvm2-pvscan@$major:$minor.service"
> >
> >
> > If I replace /lib/udev/rules.d/69-lvm-metad.rules with the attached
> > file, my problems with LVM on top of RAID1 are gone. Can you copy the
> > attached file to /etc/udev/rules.d/ and test if that fixes your problem?
Just an update for the situation with lvm2 2.02.126-2:
- all affected systems are running the amd64 architecture
- all systems are up to date Debian unstable/main
using initramfs-tools 0.120:
- most systems are broken with lvm2 2.02.126-2, to varying degrees.
the problem is apparently timing sensitive, systems using a SSD
for the system paths (with their dedicated volume group) are less
likely to fail booting, but occassionally they still do break.
- doing a local bin-NMU of lvm2 2.02.126-2, in order to update
/lib/udev/rules.d/69-lvm-metad.rules with the changes pointed out
by Michael Biebl helps me on all non-mdadm == lvm2-only systems.
Not a single failed boot on these systems so far.
- lvm2 (2.02.126-2) on top of mdadm (RAID1) fails reliably for me,
regardless of the bin-NMU for 69-lvm-metad.rules or staying on
the plain lvm2 2.02.126-2; I'm aware of #793631 and just mention
it because the update to lvm2 2.02.126-2 doesn't appear to make
a difference.
using dracut 040+1-1:
- all lvm-only systems are booting fine, no local bin-NMU needed.
- the mdadm(RAID1)+lvm2 system is also booting reliably, no local
bin-NMU needed.
- no issues found with the current lvm2 and dracut (but I obviously
don't need any special initramfs hooks/ scripts)
Regards
Stefan Lippers-Hollmann
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Mon, 10 Aug 2015 14:03:07 GMT) (full text, mbox, link).
Acknowledgement sent
to Bastian Blank <waldi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Mon, 10 Aug 2015 14:03:07 GMT) (full text, mbox, link).
Message #234 received at 791869@bugs.debian.org (full text, mbox, reply):
On Fri, Jul 31, 2015 at 08:08:38AM +0200, Stefan Lippers-Hollmann wrote: > It took many reboots (>50), but here is a reproduction with the > official Debian kernel - gzipped logs attached. Okay, thank you. However it just shows that udev never processes the add event for sda2, so never runs pvscan at all. Bastian -- Another dream that failed. There's nothing sadder. -- Kirk, "This side of Paradise", stardate 3417.3
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Tue, 11 Aug 2015 23:42:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Stefan Lippers-Hollmann <s.l-h@gmx.de>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Tue, 11 Aug 2015 23:42:03 GMT) (full text, mbox, link).
Message #239 received at 791869@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi As indicated in direct conversation, the changes in 2.02.126-3 seem to avoid the problem for me, both on lvm2-only and mdadm+lvm2 systems using initramfs-tools. Regards Stefan Lippers-Hollmann
[Message part 2 (application/pgp-signature, inline)]
Reply sent
to Bastian Blank <waldi@debian.org>:
You have taken responsibility.
(Wed, 12 Aug 2015 13:09:13 GMT) (full text, mbox, link).
Notification sent
to Stefan Lippers-Hollmann <s.l-h@gmx.de>:
Bug acknowledged by developer.
(Wed, 12 Aug 2015 13:09:13 GMT) (full text, mbox, link).
Message #244 received at 791869-done@bugs.debian.org (full text, mbox, reply):
Version: 1.02.126-3 It seems that all non-md problems where caused by a "feature" in udev, which helpfully kills of processes without telling anyone. This was fixed in this version. Bastian -- Beam me up, Scotty! It ate my phaser!
Reply sent
to Bastian Blank <waldi@debian.org>:
You have taken responsibility.
(Wed, 12 Aug 2015 13:09:14 GMT) (full text, mbox, link).
Notification sent
to Josh Triplett <josh@joshtriplett.org>:
Bug acknowledged by developer.
(Wed, 12 Aug 2015 13:09:14 GMT) (full text, mbox, link).
Marked as fixed in versions lvm2/2.02.126-3.
Request was from Bastian Blank <bastian@waldi.eu.org>
to control@bugs.debian.org.
(Wed, 12 Aug 2015 13:30:44 GMT) (full text, mbox, link).
Marked as found in versions lvm2/2.02.126-2.
Request was from Bastian Blank <bastian@waldi.eu.org>
to control@bugs.debian.org.
(Wed, 12 Aug 2015 14:03:06 GMT) (full text, mbox, link).
Merged 774082 791869 792002
Request was from Bastian Blank <bastian@waldi.eu.org>
to control@bugs.debian.org.
(Wed, 12 Aug 2015 14:03:13 GMT) (full text, mbox, link).
Marked as found in versions lvm2/2.02.111-2.2.
Request was from Bastian Blank <bastian@waldi.eu.org>
to control@bugs.debian.org.
(Wed, 12 Aug 2015 14:03:15 GMT) (full text, mbox, link).
Merged 774082 782865 791869 792002
Request was from Bastian Blank <bastian@waldi.eu.org>
to control@bugs.debian.org.
(Wed, 12 Aug 2015 14:03:21 GMT) (full text, mbox, link).
Bug archived.
Request was from Debbugs Internal Request <owner@bugs.debian.org>
to internal_control@bugs.debian.org.
(Mon, 05 Dec 2016 07:30:36 GMT) (full text, mbox, link).
Bug unarchived.
Request was from Don Armstrong <don@debian.org>
to control@bugs.debian.org.
(Wed, 07 Dec 2016 01:39:20 GMT) (full text, mbox, link).
Added tag(s) moreinfo and unreproducible.
Request was from Michael Biebl <biebl@debian.org>
to 782793-submit@bugs.debian.org.
(Mon, 19 Dec 2016 23:45:05 GMT) (full text, mbox, link).
Merged 774082 782793 782865 791869 792002
Request was from Michael Biebl <biebl@debian.org>
to 782793-submit@bugs.debian.org.
(Mon, 19 Dec 2016 23:45:08 GMT) (full text, mbox, link).
Removed tag(s) unreproducible and moreinfo.
Request was from Michael Biebl <biebl@debian.org>
to control@bugs.debian.org.
(Mon, 19 Dec 2016 23:51:06 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Wed, 25 Jan 2017 16:27:04 GMT) (full text, mbox, link).
Acknowledgement sent
to "USPS Ground Support" <roland.tate@digipro-audio.com>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Wed, 25 Jan 2017 16:27:04 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#791869; Package lvm2.
(Tue, 11 Apr 2017 10:15:02 GMT) (full text, mbox, link).
Acknowledgement sent
to nginx@li818-19.members.linode.com:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>.
(Tue, 11 Apr 2017 10:15:02 GMT) (full text, mbox, link).
Bug archived.
Request was from Debbugs Internal Request <owner@bugs.debian.org>
to internal_control@bugs.debian.org.
(Sun, 30 Jul 2017 07:25:00 GMT) (full text, mbox, link).
Send a report that this bug log contains spam.
Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.