Quantcast

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

Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Francesco Pietra-2
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

francesco pietra

 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Francesco Pietra-2
I understand that udev is in focus, however I don't know how to marriage lvmetad and udev

francesco pietra

On Fri, May 19, 2017 at 10:17 AM, Francesco Pietra <[hidden email]> 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

francesco pietra

 



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Darac Marjal-2
In reply to this post by Francesco Pietra-2
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.

signature.asc (923 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Francesco Pietra-2
In reply to this post by Francesco Pietra-2
I forgot to mention that

---changing in /etc/lvm from "use_lvmetad=1" to "use_lvmetad=0"

or commenting out in /etc/defaut/grub

---# GRUB_CMDLINE_LINUX_DEFAULT="quiet"

did not solve the problem


fp

On Fri, May 19, 2017 at 10:21 AM, Francesco Pietra <[hidden email]> wrote:
I understand that udev is in focus, however I don't know how to marriage lvmetad and udev

francesco pietra

On Fri, May 19, 2017 at 10:17 AM, Francesco Pietra <[hidden email]> 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

francesco pietra

 




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Francesco Pietra-2
In reply to this post by Darac Marjal-2
"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 <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Darac Marjal-2
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][hidden email]> 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:[hidden email]
--
For more information, please reread.

signature.asc (923 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Francesco Pietra-2
Your server is booting, but not providing a login

I forgot to say that the request of username/password does indeed appear during booting but transiently, followed by that interminable access to disk. I was unable to stop (with Ctrl-S) at the login request.

Can you log in on
a VT console (press Ctrl+Alt+F2 to see if you get a login prompt)?

No, nothing happens with on Ctrl+Alt+F2 from the GPU server keyboard.

from the VAIO, what does "grep -E 'WW|EE'
/var/log/Xorg.0.log" show (on the server, perhaps as root)?

francesco@.....:~$ grep -E 'WW|EE' /var/log/Xorg.0.log
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    56.025] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[    56.070] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[    56.070] (WW) Disabling Keyboard0
[    56.070] (WW) Disabling Mouse0
francesco@.....:~$ su
Password:
root@.....:/home/francesco# grep -E 'WW|EE' /var/log/Xorg.0.log
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    56.025] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[    56.070] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[    56.070] (WW) Disabling Keyboard0
[    56.070] (WW) Disabling Mouse0
root@.......:/home/francesco#

Those two GPUs had worked without problems on this server with wheezy, and after that on upgrading to jessie.

thanks a lot for your kind help

francesco pietra



On Fri, May 19, 2017 at 11:32 AM, Darac Marjal <[hidden email]> wrote:
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][hidden email]> 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:[hidden email]

--
For more information, please reread.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Francesco Pietra-2
Back to your suspicion about the GTX680, I was really surprised that the Xserver could be raised from the other computer (vaio) on the LAN, only as a superuser.

I had to change "allowed_users=console" (which is default on all my linux boxes) to "allowed_users=anybody" in /etc/X11/Xwrapper.config.

This way the "X" or "startx" commands do their job perfectly, however only from the vaio console. In the "defective" system, rebooting from the console brings again to warnings about failure to connect to lvmetad and EDAC sbridge, followed the login prompt, which disappears immediately, and then "disk scanning" and no way to get the login prompt prompt via Ctrl+AlT+F2 (or F1 or F3). Like for a dead console.

At this point, all that appears to be a silly problem but I could not find a solution. Having to  reinstall amd64 would be a defeat.

fp


On Fri, May 19, 2017 at 4:12 PM, Francesco Pietra <[hidden email]> wrote:
Your server is booting, but not providing a login

I forgot to say that the request of username/password does indeed appear during booting but transiently, followed by that interminable access to disk. I was unable to stop (with Ctrl-S) at the login request.

Can you log in on
a VT console (press Ctrl+Alt+F2 to see if you get a login prompt)?

No, nothing happens with on Ctrl+Alt+F2 from the GPU server keyboard.

from the VAIO, what does "grep -E 'WW|EE'
/var/log/Xorg.0.log" show (on the server, perhaps as root)?

francesco@.....:~$ grep -E 'WW|EE' /var/log/Xorg.0.log
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    56.025] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[    56.070] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[    56.070] (WW) Disabling Keyboard0
[    56.070] (WW) Disabling Mouse0
francesco@.....:~$ su
Password:
root@.....:/home/francesco# grep -E 'WW|EE' /var/log/Xorg.0.log
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    56.025] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[    56.070] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[    56.070] (WW) Disabling Keyboard0
[    56.070] (WW) Disabling Mouse0
root@.......:/home/francesco#

Those two GPUs had worked without problems on this server with wheezy, and after that on upgrading to jessie.

thanks a lot for your kind help

francesco pietra



On Fri, May 19, 2017 at 11:32 AM, Darac Marjal <[hidden email]> wrote:
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][hidden email]> 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:[hidden email]

--
For more information, please reread.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Francesco Pietra-2
I should add that, once the Xserver is launched by the aid of the other computer on LAN, the server works autonomously from its keyboard and terminals. I could run at an impressively high speed a most recent special form of molecular dynamics on the six cores, six threads, and the two GTX680 combined, with a recent cuda driver (375.39, offered by stretch). This is a very strict test. I could use the server this way for my scientific work but it would be unaesthetic at the best.

The need of setting the Xwrapper to anybody confirms that the user has no command of the console, but I was unable to go on this way toward avoiding the external assistance.

fp

On Sun, May 21, 2017 at 11:32 AM, Francesco Pietra <[hidden email]> wrote:
Back to your suspicion about the GTX680, I was really surprised that the Xserver could be raised from the other computer (vaio) on the LAN, only as a superuser.

I had to change "allowed_users=console" (which is default on all my linux boxes) to "allowed_users=anybody" in /etc/X11/Xwrapper.config.

This way the "X" or "startx" commands do their job perfectly, however only from the vaio console. In the "defective" system, rebooting from the console brings again to warnings about failure to connect to lvmetad and EDAC sbridge, followed the login prompt, which disappears immediately, and then "disk scanning" and no way to get the login prompt prompt via Ctrl+AlT+F2 (or F1 or F3). Like for a dead console.

At this point, all that appears to be a silly problem but I could not find a solution. Having to  reinstall amd64 would be a defeat.

fp


On Fri, May 19, 2017 at 4:12 PM, Francesco Pietra <[hidden email]> wrote:
Your server is booting, but not providing a login

I forgot to say that the request of username/password does indeed appear during booting but transiently, followed by that interminable access to disk. I was unable to stop (with Ctrl-S) at the login request.

Can you log in on
a VT console (press Ctrl+Alt+F2 to see if you get a login prompt)?

No, nothing happens with on Ctrl+Alt+F2 from the GPU server keyboard.

from the VAIO, what does "grep -E 'WW|EE'
/var/log/Xorg.0.log" show (on the server, perhaps as root)?

francesco@.....:~$ grep -E 'WW|EE' /var/log/Xorg.0.log
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    56.025] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[    56.070] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[    56.070] (WW) Disabling Keyboard0
[    56.070] (WW) Disabling Mouse0
francesco@.....:~$ su
Password:
root@.....:/home/francesco# grep -E 'WW|EE' /var/log/Xorg.0.log
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    56.025] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[    56.070] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[    56.070] (WW) Disabling Keyboard0
[    56.070] (WW) Disabling Mouse0
root@.......:/home/francesco#

Those two GPUs had worked without problems on this server with wheezy, and after that on upgrading to jessie.

thanks a lot for your kind help

francesco pietra



On Fri, May 19, 2017 at 11:32 AM, Darac Marjal <[hidden email]> wrote:
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][hidden email]> 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:[hidden email]

--
For more information, please reread.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Francesco Pietra-2
NEW:I have finally obtained a red-labeled line on booting, telling "Failed to load console system Reboot Logging"

This implies that it is not merely a problem of console ownership.

A rapid web survey failed to provide indications as to having the console loaded during booting on Debian amd64 stretch.

hope someone knows that

On Sun, May 21, 2017 at 7:22 PM, Francesco Pietra <[hidden email]> wrote:
I should add that, once the Xserver is launched by the aid of the other computer on LAN, the server works autonomously from its keyboard and terminals. I could run at an impressively high speed a most recent special form of molecular dynamics on the six cores, six threads, and the two GTX680 combined, with a recent cuda driver (375.39, offered by stretch). This is a very strict test. I could use the server this way for my scientific work but it would be unaesthetic at the best.

The need of setting the Xwrapper to anybody confirms that the user has no command of the console, but I was unable to go on this way toward avoiding the external assistance.

fp

On Sun, May 21, 2017 at 11:32 AM, Francesco Pietra <[hidden email]> wrote:
Back to your suspicion about the GTX680, I was really surprised that the Xserver could be raised from the other computer (vaio) on the LAN, only as a superuser.

I had to change "allowed_users=console" (which is default on all my linux boxes) to "allowed_users=anybody" in /etc/X11/Xwrapper.config.

This way the "X" or "startx" commands do their job perfectly, however only from the vaio console. In the "defective" system, rebooting from the console brings again to warnings about failure to connect to lvmetad and EDAC sbridge, followed the login prompt, which disappears immediately, and then "disk scanning" and no way to get the login prompt prompt via Ctrl+AlT+F2 (or F1 or F3). Like for a dead console.

At this point, all that appears to be a silly problem but I could not find a solution. Having to  reinstall amd64 would be a defeat.

fp


On Fri, May 19, 2017 at 4:12 PM, Francesco Pietra <[hidden email]> wrote:
Your server is booting, but not providing a login

I forgot to say that the request of username/password does indeed appear during booting but transiently, followed by that interminable access to disk. I was unable to stop (with Ctrl-S) at the login request.

Can you log in on
a VT console (press Ctrl+Alt+F2 to see if you get a login prompt)?

No, nothing happens with on Ctrl+Alt+F2 from the GPU server keyboard.

from the VAIO, what does "grep -E 'WW|EE'
/var/log/Xorg.0.log" show (on the server, perhaps as root)?

francesco@.....:~$ grep -E 'WW|EE' /var/log/Xorg.0.log
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    56.025] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[    56.070] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[    56.070] (WW) Disabling Keyboard0
[    56.070] (WW) Disabling Mouse0
francesco@.....:~$ su
Password:
root@.....:/home/francesco# grep -E 'WW|EE' /var/log/Xorg.0.log
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    56.025] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[    56.070] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[    56.070] (WW) Disabling Keyboard0
[    56.070] (WW) Disabling Mouse0
root@.......:/home/francesco#

Those two GPUs had worked without problems on this server with wheezy, and after that on upgrading to jessie.

thanks a lot for your kind help

francesco pietra



On Fri, May 19, 2017 at 11:32 AM, Darac Marjal <[hidden email]> wrote:
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][hidden email]> 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:[hidden email]

--
For more information, please reread.




Loading...