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 <chiendar...@gmail.com> 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 <chiendar...@gmail.com> > 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 <chiendar...@gmail.com> >> 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 <mailingl...@darac.org.uk >>> > 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]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. >>>>> >>>>> References >>>>> >>>>> Visible links >>>>> 1. mailto:mailingl...@darac.org.uk >>>>> >>>> >>>> -- >>>> For more information, please reread. >>>> >>> >>> >> >
