Bug#859156: multipath-tools: boot ends in rescue mode - boot partition marked as systemd_ready=0

[Ritesh Raj Sarraf]

Control: tag -1 +moreinfo


Hello Alban,


Thanks for the bug report.

On Fri, 2017-03-31 at 05:55 +0200, Alban Browaeys wrote:
> Package: multipath-tools
> Version: 0.6.4-5
> Severity: normal
> 
> systemd at bootup mounts / and /home both lvm2 logical volumes above
> bcache0 physical volume. But then it timeout waiting for /boot and
> /boot/efi device UUIDs... and fallbacks to the rescue shell.
> 

I haven't worked of bcache so far, so please bear with my questions.

> 
> I flushed all entries from /etc/multipath/wwids (after backing it up)
> and now all is fine.
> Leaving the above entries there and commenting out 60-multipath.rules the code
> which sets SYSTEMD_READ=0 also let me boot properly.
> 
> From tests, where sda7 is /boot a "bare metal" partition:
> sudo sh -c "env - SEQNUM="1" ACTION="add" $(udevadm info  -x /dev/sda7|sed -n
> '/^E:/ {   s at E: \(.*\)=\(.*\)@\1="\2"@p  }' | tr '\n' ' ' )  /sbin/multipath
> -u /dev/sda7; ";echo $?
> with wwids cleanup up I get:
> /dev/sda7 is not a valid multipath device path
> 1
> but with wwids restored:
> sda7 is a valid multipath device path
> 0
> thus SYSTEMD_READY="0" and DM_MULTIPATH_DEVICE_PATH="1" are both set.
> Thus systemd waits and timeout bringing the /boot device unit (then the mount
> unit fails
>  because of dependency to this device unit).
> 
> 
> 
> Configuration is a bit uncommon:
> /boot and /boot/efi on sda<n> partitions
> bcache (backing and caching devices are sda<n> partition and sdb disk)
> is an lvm2 physical volume, above that are mostly root / and /home
> logical volumes.
> 
> 


From your report so far, here's what I understand.

bcache is stacked directly on top of physical SCSI block device.
A Device Mapper Physical Volume is created on top of the bcache based enumerated
 device.
LVM linear targets are created on top of the DM Physical device.


In which layer is multipath involved ?
Or is your bug report about multipath misbehaving in this setup ? But I still
don't see where exactly are multipath targets involved in this setup.


> This is pretty serious an issue (fail to boot) though I have been unable to
> sort out
> if the wwids file entries  I cleanup were a local issue, another package issue
> or added by multipathd itself.
> They were not restored after reboot.
> 
> Best regards
> Alban
> 
> 
> PS: mind my current is a local binnmu per I fixed a locking bug in
> uev_update_path when called
> by udev. This should not relate to this issue. Pending another bug report.
> 
> 
> -- Package-specific info:
> /etc/multipath.conf does not exist.
> 
> 
> -- System Information:
> Debian Release: 9.0
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'),
> (1, 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.10.0-trunk-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages multipath-tools depends on:
> ii  init-system-helpers  1.47
> ii  kpartx               0.6.4-5.1
> ii  libaio1              0.3.110-3
> ii  libc6                2.24-9
> ii  libdevmapper1.02.1   2:1.02.137-2
> ii  librados2            10.2.5-6
> ii  libreadline7         7.0-2
> ii  libsystemd0          232-22
> ii  libudev1             232-22
> ii  liburcu4             0.9.3-3
> ii  lsb-base             9.20161125
> ii  sg3-utils-udev       1.42-2
> ii  udev                 232-22
> 
> multipath-tools recommends no packages.
> 
> Versions of packages multipath-tools suggests:
> ii  multipath-tools-boot  0.6.4-5.1
> 
> -- no debconf information
> 
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-lvm-maintainers/attachments/20170331/9fea37cb/attachment-0001.sig>