Re: debian9 amd64 failure to connect to lvmetad, falling back to device scanning

Darac Marjal <[email protected]>
Newsgroups gmane.linux.debian.ports.amd64
Message-ID <[email protected]>
On Fri, May 19, 2017 at 11:12:25AM +0200, Francesco Pietra wrote:
>     "It is not required for normal usage"
>
>   The fact is that the X79-based computer does not offer a login
>   possibility, it goes to disk scanning (kernel et al) for hours (at
>   least 4hr).
>
>   Access to file was only possible from a LAN-connected other computer
>   (laptop VAIO) or booting from Super Grub2 disk.
>
>   Whether all issues arise from inability to connect to lvmetad, I
>   cannot say. I am no system analyzer. I merely need the X79-GPU-based
>   machine for applications (molecular dynamics with recent CUDA).
>   fp

Personally, I doubt that your GPU (Graphics Processing Unit) is related
to how the disks are access, but perhaps you've got a very special
system.

Also, I'm not sure what issue you're... Oh, I see what's happening!

Your server is booting, but not providing a login. You ARE able to log
into the server using another computer on the network. This means that
the server HAS booted from the disk(s). LVM is *not* your problem (if it
was, the system would probably not be able to load
/etc/network/interfaces in order to bring up the network, nor the SSH
daemon, nor the user's home directory ...)

The issue you're having is more likely with that GPU. Can you log in on
a VT console (press Ctrl+Alt+F2 to see if you get a login prompt)? When
you log in from the VAIO, what does "grep -E 'WW|EE'
/var/log/Xorg.0.log" show (on the server, perhaps as root)?

>   On Fri, May 19, 2017 at 10:24 AM, Darac Marjal
>   <[1][email protected]> wrote:
>
>     On Fri, May 19, 2017 at 10:17:44AM +0200, Francesco Pietra wrote:
>
>         Hello:
>         On a vintage VAIO I have no problems with amd64 stretch. With a
>         raid1-based on the X79 chip, upgrading from jessie to stretch
>       (I need
>         a higher CUDA version than available on jessie for latest
>         experimental NAMD molecular dynamics) went on regularly.
>       However, the
>         command
>
>         # systemctl set-default multi-user.target
>
>         (which worked fine on said VAIO to boot at the $ linux prompt)
>       led to
>         failure to connect to lvmetad, falling back to device scanning,
>         whereby an endless disk scanning begun.
>
>         I tried:
>
>         1) Super grub2 disk: OK it led to clean boot but I found no way
>       to
>         fix the problem.
>
>         2) Accessing the X79 computer from said VAIO (both are on a
>       LAN)
>         equally allowed to manage everything but I was unable to fix
>       the
>         problem.
>
>         3) From said VAIO:
>          # systemctl enable lvm2-lvmetad.service
>
>         OK, but it was lost on needed reboot.
>
>         I never had to reinstall a debian amd64 but this time I am
>       lost.
>
>         Thanks for any kind suggestion
>
>     Have you enabled the daemon in lvm.conf? Look for "use_lvmetad".
>
>     However, I think this should not be a problem. lvmetad is the LVM
>     Metadata Daemon, which is primarily a caching daemon. If you have a
>     lot
>     of disks, or change your logical volumes frequently, the lvmetad
>     can
>     speed up the varioud LVM commands. It is not required for normal
>     usage
>     and ~99% of people can ignore the "failure to connect" message.
>
>         francesco pietra
>          
>
>     --
>     For more information, please reread.
>
>References
>
>   Visible links
>   1. mailto:[email protected]

-- 
For more information, please reread.
signature.asc (application/pgp-signature, 906 B)
-----BEGIN PGP SIGNATURE-----

iQJqBAABCgBUFiEE1A0c5XWknk+U2MemZUdBNabqRbUFAlkeu4o2FIAAAAAAFQAY
cGthLWFkZHJlc3NAZ251cGcub3JnbWFpbGluZ2xpc3RAZGFyYWMub3JnLnVrAAoJ
EGVHQTWm6kW1GzoP/AzHzktg8g3osQHm6JXkU8zcYUlumP8/6r8JxP8qjTlu9dRM
yGJjsHTCcGqno2gokXHheqFXOtkwKgF6Iao2cgqQ1t/y1wlR/Zx90ECldm0S61j5
dRhnnNDtBFrVtKriLj4hekGtGnkV+vmd8zil3CIYDK54L0eqqXIWYYJPhVVMKoO8
3x109oF3aUshgqOavb2ajW3KcP7ikPa8FytBq8uqPbct4e0AmPLVuHF4uRDK6B+2
9G+tDOLvK9OmfgNcxbSCUNcKaoL4qCs3WUUXd7i20HNze/EhxL84gmjub8Hb6i3H
xa5ZSMR/AQNpCLCm2v2AfoeaY6NW5iQ0YHM24J3FHq4YQQ50zBHqgfDxQdXOmLnQ
egidfaPZ5gwa/jNGXnI+ZDNWLVqtmdy60Z4VnjaDsn2VMd1O4PxERPAvxJUrCuhc
8l9nHmDEBz5Z9xFJAXrrWXsXhWfrGIW/JQcXPOq9k+Xrmkn7bHOAKSZzUqccxh7A
ugd3AAk/a4CNbDdvTgbjzIArZbmXWKgnxQf7A1fZqVPZkIypU1SYFYULvIPeee+9
MGxLCXJ5tbXEHLl8cxjS31WjQUz/zsdCHlXyuvt/aDWiaO+w7trRnoMVfoLsbXBP
tJ3mHdV8e0PEGgEKq5U+bX+ZHDlyHVgZ1ia7/Qxfm0tWZdRjs55v+HvM9WtF
=nWi+
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.