Re: Innstaling 64bit Debian new comptuer wiith M2. with SDD
Yes. On 09/08/2019 12:25, E Sutton wrote: > Is it possble to innstaling 64bit Debian new computer wiith M2. with > SDD > signature.asc Description: OpenPGP digital signature
Re: debian9 amd64 failure to connect to lvmetad, falling back to device scanning
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. signature.asc Description: PGP signature
Re: debian9 amd64 failure to connect to lvmetad, falling back to device scanning
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 Description: PGP signature
Re: Booting in text mode
On Thu, Nov 24, 2016 at 03:58:51PM +0100, Francesco Pietra wrote: Hallo Having upgraded amd64/gnome to jessie, booting occurs graphically while I want graphics to come only when absolutely needed. Also, nautilus of gnome3 is absolutely hostile to scientific use as a quick replacement of shell commands. Too "intelligent". All that toward mass use, ok, but where is a recipe to boot in text mode? My old, simple .Xsession and killing gdm do not work anymore and I am short of time for such issues . The preferred method for this, under systemd is to run: # systemctl set-default multi-user.target This should set the default boot mode to non-graphical, multi-user mode. When you're ready to start graphical mode, run: # systemctl isolate graphical.target (You could, of course, try simply running the x-display-manager of your choice, but by switching target, any other units that are required for graphical mode are also run). Or give an alternative to replace gnome3 with xfce. The latter on my work station allows booting in text mode and its file manager is not too intelligent, just useful for scientific use. Thanks. francesco pietra -- For more information, please reread.
Re: Repositories
On Mon, May 04, 2015 at 11:40:52PM +0100, Edwin Zarthrusz wrote: Hello Again, With the list of repositories, which bits do I put in URI, distribution, and sections?? This isn't an AMD64-specific question so you might have got a quicker response on debian-user. That said, the format of sources.list is detailed here: https://wiki.debian.org/SourcesList, alternatively read the output of man sources.list on your system. TIA -- Edwin Zarthrusz I don't even pretend to know how the Universe(s) work(s) any longer Be. Love. Ed. -- For more information, please reread. signature.asc Description: Digital signature
Re: complaints about systemd
On Thu, Oct 09, 2014 at 11:41:55AM +0200, Tomasz Kundera wrote: I'd like to say me too as the shortest opinion. Dealing with local networks it is absolutely not important how much time the boot takes. Most machines works all the time. During maintenance reboots I can wait a few seconds more. But the complete lack of simplicity and transparency is horrible. Binary logs are horrible, too. Logs are mostly needed when some troubles arises. In that situation they should be accessible as easy and fast as possible. Often there will be no possibility to start a dedicated binary log analyzer. You need only more and sed to deal with text logs. systemd with no possibility to stay with SystemV is a horrible mistake. If you can start more or sed you should be able to start journalctl. But them again, that probably won't help as, by default, Debian doesn't write the journal to disk (that's the syslogd's job and that writes in the familiar (if inconsistent) text format). On Wed, Oct 8, 2014 at 10:25 PM, Ray Andrews [1]rayandr...@eastlink.ca wrote: On 10/08/2014 12:39 PM, ael wrote: On Wed, Oct 08, 2014 at 03:32:58PM +0200, Michael wrote: The new system reduces some complexity on one side while introducing much more on the other. The whole design so far as I can see lacks the simplicity and transparency that the greatest minds in computer science advocate. That seems to be confirmed in that systemd is more or less permanently broken, ... I don't know enough to weigh in on this, but I spent the morning researching the subject and it does seem like this is no small issue. I myself am deeply troubled by what I read, it seems that cleverness has replaced level-headedness, wiz-bang technology has replaced simplicity and transparency, and featureitis has replaced stability. I hope this gets sorted out. Me, I want my computer to boot reliably, and I wouldn't care even if it did take 2 seconds longer, and I want to be able to understand and even edit how it works. But that's just me. at least on all my machines. It takes *far longer* to boot up and particularly shutdown than ever the old init system did. I have given up even thinking about bug reporting it: what do I say? Where are the logs that throw any light on the system problems? Which bug do I report when it changes from day to day? I suspect that many others are in a similar situation, so that the bug tracking doesn't reflect the real situation. All of that said, some of the underlying design ideas are good, but particulary concurrent systems need that simplicity and transparency, and the technology to do it exists if little used. ael -- To UNSUBSCRIBE, email to [2]debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact [3]listmas...@lists.debian.org Archive: [4]https://lists.debian.org/54359d9d.5070...@eastlink.ca -- Tomasz Kundera References Visible links 1. mailto:rayandr...@eastlink.ca 2. mailto:debian-amd64-requ...@lists.debian.org 3. mailto:listmas...@lists.debian.org 4. https://lists.debian.org/54359d9d.5070...@eastlink.ca signature.asc Description: Digital signature
Re: After a few weeks of almost no issues, Wheezy doesn't boot anymore
On Thu, May 09, 2013 at 09:04:47PM -0400, Harry Prevor wrote: So a few weeks ago, I decided to install Debian Wheezy (then unstable) on a computer I built for my brother. The normal images didn't work for some reason now forgotten, so I had to use the unofficial installation images that included nonfree drivers. I had some problem (also now unforgotten) that made the computer take ~20 minutes to boot up for the first time, but after that Gnome 3 was working fine. Because my younger brother uses this computer and the free software drivers didn't do the graphics card in it (NVidia GTX 660) justice, I had to install the nvidia proprietary drivers as well a few days later if it matters. I pretty much followed the instructions verbatim from http://wiki.debian.org/NvidiaGraphicsDrivers (the Debian way), and the drivers were working fine for a few weeks. I can't remember how many times I rebooted the system during the time when it worked, but it was a few times. I had sometimes gotten similar messages upon boot, but I had always assumed it would be like my first boot in that I would just have to wait thirty minutes for the boot, so rather than waiting I typically did a hard reboot (upon which I did not get the message and the system booted immediately). However, recently I did a hard reboot and I kept getting the same messages, over and over, and they didn't just stop after twenty minutes, making my system essentially bricked. OK. It looks like you're getting general protection faults. It's hard to tell exactly, because we don't see the top of the oops message (pressing shift+pgup should allow you to scroll back). I would suggest, though, that you've possibly got a corrupt disk. Probably during one of those hard reboots. Because it would be rather tedious to type all these messages out manually, I have compiled a video for you all to demonstrate the problem (please mute the audio): http://www.youtube.com/watch?v=ReYNd5p5TvA Sorry for the shaky camera; I could not find a suitable place to rest the camera. Any ideas as to how to debug this? I could probably burn a live Debian USB to debug the issue but I suspect that the live system would not work without the proprietary drivers included in the system. If the only proprietary driver you need is the Nvidia X driver, then a rescue disc will work fine for you. You're likely to be pottering about at the command line anyway. I would start by checking SMART logs on both drives (in case they've failed badly), then try fscking the filesystems. Then try something like debsums -c to search for changed files. With luck, you may just need to re-install the kernel. signature.asc Description: Digital signature
Re: Cannot use Debian
On Tue, Apr 23, 2013 at 11:29:03AM +0300, Vasileios Karaklioumis wrote: I would update the bios and run memtest86.M/B model? Personally, I'd look at more of the error message before even starting that. On Apr 23, 2013 11:27 AM, Goswin von Brederlow [1]goswin-...@web.de wrote: On Mon, Apr 22, 2013 at 06:51:18AM -0500, Chris Swenson wrote: It's possible you have a CPU that has 2 cores, but is still not 64-bit compatible. I have a Dell laptop with Intel Core Duo that would seem to be 64-bit capable, but upon further inspection is not. Check your CPU hardware manufacturer for the specs to see if it can handle 64-bit instructions. ? Chris On Mon, Apr 22, 2013 at 5:37 AM, [2]iujn...@gmail.com wrote: I can install x86 debian on 2006's latptop, and I cannot install x64 debian on 2010 computer (RAM is 4G) I was installed Debian x64 with 1 CD when the booting procedure runs on [4.779430] [81010b42] ? system_call_fastpath+0x16/0x1b and yhe procedure was stalled Clearly the cpu can do 64bit. It might not do it well or it might be broken but the cpu must have the 64bit feature bit and support a hell of a lot of 64bit mode to get past the first few instructions in a 64bit kernel. Certainly by the time userspace runs and syscalls happen, as seen by the system_call_fastpath call, the cpu has clearly proven to handle 64bit mode. Even if it only lasted 4.7 seconds before crashing. MfG Goswin -- To UNSUBSCRIBE, email to [3]debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact [4]listmas...@lists.debian.org Archive: [5]http://lists.debian.org/20130423082658.GB23558@frosties References Visible links 1. mailto:goswin-...@web.de 2. mailto:iujn...@gmail.com 3. mailto:debian-amd64-requ...@lists.debian.org 4. mailto:listmas...@lists.debian.org 5. http://lists.debian.org/20130423082658.GB23558@frosties signature.asc Description: Digital signature
Re: Linking lapack and C standard library
On Thu, Mar 14, 2013 at 12:00:43PM +0100, Francesco Pietra wrote: Hello May I ask how to correctly link lapack and C standard libraries with Debian amd64 wheezy? Packages installed: liblapack3gf liblapack3 libblas3 libc6 libc6-dev ** Try installing the -dev packages for those libraries. libfoo will usually just give you the library for use at runtime, libfoo-dev will bring in the headers, too. The code to compile makes a generic example: LIBS=-llapack -lstdc++ thanks francesco pietra -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caev0nmukjyv54+r5d5534jh+-hjuhpgbs+rggav0m1kd0yz...@mail.gmail.com signature.asc Description: Digital signature
Re: Issues with nvidia 302.17
On Thu, Sep 27, 2012 at 09:58:40AM +0200, Francesco Pietra wrote: Hello: Following upgrading of amd64 wheezy, version 302.17 of nvidia is incompatible with software I was using for molecular dynamics on CPU-GPU. On the other hand, amd64 stable offers a version of nvidia that is too old for the above application. Question: is it possible within amd64 wheezy to have a previous version of nvidia? If yes, a generic guideline on how-to would be much appreciated. It certainly is. Have a read of the instructions at http://snapshot.debian.org/ signature.asc Description: Digital signature
Re: iso boot failure
On Sun, Jul 15, 2012 at 12:56:51PM -0400, C. Bronson H. Crothers wrote: Both the CD and DVD (disk 1) iso (debian linux 6.0.5) images fail to boot, off their respective media. Asus M 3A32 mother board AMD Phenom X4 9850 64 bit 8 GB RAM 250 GB hard drive (previously running lenny). During the upgrade to squeeze the disks failed to boot, and now I have no access to the system at all. I presume you read the release notes? In particular the section about Migration of disk drivers from IDS to PATA subsystem? Other boot media work OK (Win 7, Knoppix) from the CD/DVD drive. This is NOT a BIOS issue. You've A) downloaded the amd64 and NOT the ia64 CD/DVD and B) checked the MD5SUM of the downloaded image? signature.asc Description: Digital signature
Re: is my source.list file out of date.......
On Tue, May 22, 2012 at 02:53:41PM +0100, Michael Fothergill wrote:
Dear Folks,
My source.list file looks like this:
#
# deb cdrom:[Debian GNU/Linux 5.0.7 _Lenny_ - Official amd64 NETINST
Binary-1 20101128-00:59]/ lenny main
#deb cdrom:[Debian GNU/Linux 5.0.7 _Lenny_ - Official amd64 NETINST
Binary-1 20101128-00:59]/ lenny main
deb http://ftp.uk.debian.org/debian/ squeeze main contrib non-free
deb-src http://ftp.uk.debian.org/debian/ squeeze main
deb http://security.debian.org/ squeeze/updates main
#deb-src http://security.debian.org/ lenny/updates main
deb http://volatile.debian.org/debian-volatile squeeze/volatile main
deb-src http://volatile.debian.org/debian-volatile squeeze/volatile main
Is the debian-volatile repository redundant now? If it is would I
just delete it or could I put something else in there.
According to
http://lists.debian.org/debian-volatile-announce/2012/msg0.html,
debian-volatile IS gone now. However, you have squeeze/updates in your
sources.list, so you already have the replacement. You should probably
delete the volatile lines.
I am running Debian Squeeze on an AMD 64 machine.
I recently took the hard drive out of the old AMD64 box and stuck in a
new box with a newer motherboard in it.The OS still runs but I
probably freaked it a bit. Firestarter seems not to work now.
Probably, spotting a new network card, udev has given you a new
interface in persistent-net-rules. Firestarter may be expecting to
firewall, say, eth0 but you're currently using eth1.
Check your network interfaces ('ip addr' and 'ip route' will help). If
you want, you can delete /etc/udev/rules.d/70-persistent-net.rules and
restart udev to re-number your interfaces.
Suggestions on getting it used to what I did welcome.
The new motherboard is a GA-A55M-S2V model and an AMD A 3400 chip.
Regards
Michael Fothergill
--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CANc=Sd2Ba_NwrFhsqkP7u34Wx5pqORu1BqhXquLV4Stm=b7...@mail.gmail.com
signature.asc
Description: Digital signature
Re: debian testing: iceweasel issues
On Wed, May 25, 2011 at 11:17:03AM +0200, dage...@free.fr wrote: Hi, after updates from yesterday morning (2 files - sorry don't really remember which ones it was - so if someone could tell me how to check I'd be please to look and try to remember), iceweasel has big issues: Try /var/log/dpkg.log first, the navigation bar does not work anymore: if I select a web site on the navigation bar list, nothing happens. If I fill the adress and press Enter key or click on the arrow to load the page, nothing happens too. The only way for me to manage is to use a search engine (fortunately the home icon works) and use the results to navigate. Second, all passwords are lost and iceweasel does not want to save passwords again (the password list is empty and remains empty). If you think it's a bug in debian, may I add this bug ? First, Try with a fresh profile (iceweasel -ProfileManager) and see if the problem exists. If so, it probably is a bug, if not, it may be an extension or theme causing you trouble. -- Paul Saunders signature.asc Description: Digital signature
Re: updating question...
On Thu, Apr 14, 2011 at 08:51:34AM -0400, Whit Hansell wrote: Guys, Using Wheezy, debian. In the past I have always done my updates w. #aptitude update #aptitude safe-upgrade #aptitude autoclean #updatedb Everything is working just fine and no problem except the updatedb command. I know it used to actually update the file database and sometimes it actually took some time to do it. And sometimes when I would install a file from outside aptitude I would have to run updatedb to get the system to recognize it. Now when I run updatedb it seem like it is doing nothing. It takes no time at all yet so far am having no recognition problems. Am just wondering if I'm actually doing anything by trying to run it. E.g is it actually updating? A couple of caveats: 1) This isn't strictly amd64 related. 2) updatedb isn't actually related to the package database, but maintains a list of all files on your system. It sounds to me like your locate package has been upgraded to mlocate. As per the package status of mlocate, mlocate differs from plain locate in that when you run locate foo you only see files to which you have access. Also instead of re-reading the whole filesystem, timestamps are taken into account and only changed files are recorded in the database. As a result updatedb is, as you have found, a lot faster. For the record, there's no real need to call updatedb after an update as there should be a cron job that does that for you. However, there's also no harm in it and I can see a reason for doing so. -- Darac signature.asc Description: Digital signature
