> > "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 On Fri, May 19, 2017 at 10:24 AM, Darac Marjal <mailingl...@darac.org.uk> 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. >
