[gentoo-user] Re: Latest unstable ntp not generating ntp.drift file.
On Thursday 06 January 2011, Dale wrote: Francesco Talamona wrote: On Wednesday 05 January 2011, Dale wrote: Now on my old system, it would adjust the drift file and the adjustments would get smaller and smaller. On the new rig, as you can see it stays about the same. I would like it to get to a point where it doesn't have to sync so often. I read on the website where they are needing more servers to help with the load and I don't want to be one of the ones putting a load on it. Maybe you copied over /etc/adjtime from the previous machine. I would try to regenerate it... Ciao Francesco I'm sure I didn't copy that. I copied ntp.conf but that is all. I didn't even notice that one being there. I got to see what purpose that has. I may delete it tho and see what happens. It would generate a new one if I restart the service correct? Dale :-) :-) It makes the hardware clock take care of the systematic drift. If a wrong value is stored in it, it can interfere with ntp in the way you described: every time ntp runs it always corrects for the same amount. From man 8 hwclock: The Hardware Clock is usually not very accurate. However, much of its inaccuracy is completely predictable - it gains or loses the same amount of time every day. This is called systematic drift. hwclock's adjust function lets you make systematic corrections to correct the systematic drift. and: It is good to do a hwclock --adjust just before the hwclock --hctosys at system startup time, and maybe periodically while the system is running via cron. This is my recipe: let ntpdate sync your clock, then /sbin/hwclock --systohc and you are done. From that moment on ntp takes care of the non systematic error, while the drift is zeroed by hwclock. Somewhere it is suggested to run /sbin/hwclock --adjust once a year. I experienced what you describe when I built my new machine, I had copied /etc/adjtime (without knowing what it was) from the previous, it took me a good deal of googling... BTW I don't have ntp.drift, I only use ntpdate and the clock is always correct. HTH Francesco -- Linux Version 2.6.36-gentoo-r6, Compiled #2 SMP PREEMPT Mon Jan 3 11:54:58 CET 2011 Two 1GHz AMD Athlon 64 Processors, 4GB RAM, 4021.84 Bogomips Total aemaeth
Re: [gentoo-user] The pound sign SOLVED
On Wed, Jan 05, 2011 at 10:31:17PM +0100, Volker Armin Hemmann wrote: different fonts maybe? Turns out after some more research that it was that the locale was not set. Mike. signature.asc Description: Digital signature
Re: [gentoo-user] Help with eix-test-obsolete
Lately it seems that eix disregards the content of /etc/portage/package.keywords.nowarn From the ChangeLog: *eix-0.22.1 [...] - use /etc/portage/package.nowarn instead of /etc/portage/package.*.nowarn; the latter is now obsolete. If you want continue to use it, set OBSOLETE_NOWARN=true
Re: [gentoo-user] Re: Latest unstable ntp not generating ntp.drift file.
Francesco Talamona wrote: On Thursday 06 January 2011, Dale wrote: Francesco Talamona wrote: On Wednesday 05 January 2011, Dale wrote: Now on my old system, it would adjust the drift file and the adjustments would get smaller and smaller. On the new rig, as you can see it stays about the same. I would like it to get to a point where it doesn't have to sync so often. I read on the website where they are needing more servers to help with the load and I don't want to be one of the ones putting a load on it. Maybe you copied over /etc/adjtime from the previous machine. I would try to regenerate it... Ciao Francesco I'm sure I didn't copy that. I copied ntp.conf but that is all. I didn't even notice that one being there. I got to see what purpose that has. I may delete it tho and see what happens. It would generate a new one if I restart the service correct? Dale :-) :-) It makes the hardware clock take care of the systematic drift. If a wrong value is stored in it, it can interfere with ntp in the way you described: every time ntp runs it always corrects for the same amount. From man 8 hwclock: The Hardware Clock is usually not very accurate. However, much of its inaccuracy is completely predictable - it gains or loses the same amount of time every day. This is called systematic drift. hwclock's adjust function lets you make systematic corrections to correct the systematic drift. and: It is good to do a hwclock --adjust just before the hwclock --hctosys at system startup time, and maybe periodically while the system is running via cron. This is my recipe: let ntpdate sync your clock, then /sbin/hwclock --systohc and you are done. From that moment on ntp takes care of the non systematic error, while the drift is zeroed by hwclock. Somewhere it is suggested to run /sbin/hwclock --adjust once a year. I experienced what you describe when I built my new machine, I had copied /etc/adjtime (without knowing what it was) from the previous, it took me a good deal of googling... BTW I don't have ntp.drift, I only use ntpdate and the clock is always correct. HTH Francesco Well, I tried openntp for a good while last night and it was worse than ntp. It was adjusting the clock by something like 20 seconds at a time. Even ntp wasn't that bad. I went back to plain ntp. This is what ntp has sent to messages overnight while I was napping: Jan 6 00:13:21 localhost ntpd[23712]: ntpd 4.2@1.2290-o Thu Jan 6 05:41:55 UTC 2011 (1) Jan 6 00:13:21 localhost ntpd[23713]: proto: precision = 0.102 usec Jan 6 00:13:21 localhost ntpd[23713]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123 Jan 6 00:13:21 localhost ntpd[23713]: Listen and drop on 1 v6wildcard :: UDP 123 Jan 6 00:13:21 localhost ntpd[23713]: Listen normally on 2 lo 127.0.0.1 UDP 123 Jan 6 00:13:21 localhost ntpd[23713]: Listen normally on 3 eth0 192.168.2.5 UDP 123 Jan 6 00:13:21 localhost ntpd[23713]: Listen normally on 4 eth0 fe80::1e6f:65ff:fe4c:91c7 UDP 123 Jan 6 00:13:21 localhost ntpd[23713]: Listen normally on 5 lo ::1 UDP 123 Jan 6 00:13:21 localhost ntpd[23713]: peers refreshed Jan 6 00:13:21 localhost ntpd[23713]: Listening on routing socket on fd #22 for interface updates Jan 6 09:09:31 localhost ntpd[23713]: Attempting to register mDNS Jan 6 09:09:31 localhost ntpd[23713]: *** WARNING *** The program 'ntpd' uses the Apple Bonjour compatibility layer of Avahi. Jan 6 09:09:31 localhost ntpd[23713]: *** WARNING *** Please fix your application to use the native API of Avahi! Jan 6 09:09:31 localhost ntpd[23713]: *** WARNING *** For more information see http://0pointer.de/avahi-compat?s=libdns_sde=ntpd Jan 6 09:09:31 localhost ntpd[23713]: mDNS service registered. r...@fireball / # It doesn't show that it is doing anything but the clock is somewhat accurate but it is still having to adjust it like before. I use ntpdate to see how far the clock is off. If I run it every few minutes, I can see it drift further away from the correct time then when ntp syncs, it resets it again. It did generate the ntp.drift file but it is still not adjusting the clock like on my other rig. I also read where the caps USE flag should be enabled. I did but it doesn't appear to have helped any. I deleted the /etc/adjtime but it has not been recreated. What creates this file? I deleted it a couple days ago and nothing has brought it back yet. I'm about ready to see what Linux would be like with no freaking clock at all. lol Now to see what I am going to try next. Dale :-) :-)
[gentoo-user] Re: Help with eix-test-obsolete
On Thursday 06 January 2011, Vaeth wrote: Lately it seems that eix disregards the content of /etc/portage/package.keywords.nowarn From the ChangeLog: *eix-0.22.1 [...] - use /etc/portage/package.nowarn instead of /etc/portage/package.*.nowarn; the latter is now obsolete. If you want continue to use it, set OBSOLETE_NOWARN=true That's it. Many thanks! Francesco -- Linux Version 2.6.36-gentoo-r6, Compiled #2 SMP PREEMPT Mon Jan 3 11:54:58 CET 2011 Two 2.6GHz AMD Athlon 64 Processors, 4GB RAM, 10453 Bogomips Total aemaeth
RE: [gentoo-user] Re: New Install Problems with X
On Wed, Jan 5, 2011 at 6:25 PM, walt wrote: On 01/05/2011 06:41 AM, KIM WHALEN wrote: On Wed, Jan 5, 2011 at 8:56 AM, walt wrote: On 01/04/2011 08:10 AM, KIM WHALEN wrote: I'm trying to do a new install on an amd64 box and there are a lot of problems somewhere between X, Gnome, and the Graphics card. I'm using genkernel so there shouldn't be too much of a problem there. The graphics card as identified by the system is: nVidia Corporation NV36 [GeForce FX 5700LE] The base system and xorg-x11 seems to be set up alright. However, when I run startx as a regular user I get errors about drm, dri, and dri2 modules and the screen. Those drm and dri error messages are normal when using the nvidia drivers, but the screen error is not normal. What does it say, exactly? Did you generate your xorg.conf by doing Xorg -configure? Are you using an xorg.conf file at all? The nouveau driver is not nearly ready for prime time yet, so I'd stick with nivida-drivers at least until you have everything else working. I am not using the xorg.conf file That's fine for starters. You may need to add one later if your mouse or keyboard don't work. (BTW, you need to emerge the xf86-input-evdev driver for the mouse and keyboard if you don't have an xorg.conf). (==) Log file: /var/log/Xorg.0.log, Time: Wed Jan 5 09:03:31 2011 List of video drivers: nouveau nvidia FATAL: Error inserting nvidia (/lib/modules/2.6.36-gentoo-r5/video/nvidia.ko): No such device That's definitely a problem. The no such device is a bit ambiguous. I'm thinking maybe the nouveau and nvidia drivers are fighting with each other, so neither one can get full control of the video hardware. IIRC, if you build the nouveau driver into your kernel, it *will* conflict with the nvidia kernel module. I keep two different kernel config files, one with nouveau, and the other without nouveau for use with the nvidia.ko module. Definitely build a kernel without nouveau at least until you get everything else working -- and then *re*emerge nividia-drivers after you boot the new kernel. (Compiling/installing a new kernel will delete all of your existing kernel modules including nvidia.ko!) I already had the xf86-input-evdev driver installed. I could find anything to take out of the kernel, but added nVidia Framebuffer Support. Device Drivers + Graphics Support + Support for Framebuffer Devices + nVidia Framebuffer Support Then I emerge x11-drivers/nvidia-drivers. That, unfortunately, didn't help; it failed to emerge and the output is below. # emerge x11-drivers/nvidia-drivers Calculating dependencies... done! Verifying ebuild manifests Emerging (1 of 1) x11-drivers/nvidia-drivers-260.19.29 Failed to emerge x11-drivers/nvidia-drivers-260.19.29, Log file: '/var/tmp/portage/x11-drivers/nvidia-drivers-260.19.29/temp/build.log' Jobs: 0 of 1 complete, 1 failed Load avg: 0.43, 0.13, 0.04 * Package:x11-drivers/nvidia-drivers-260.19.29 * Repository: gentoo * Maintainer: car...@gentoo.org j...@gentoo.org,sp...@gentoo.org * USE: amd64 elibc_glibc gtk kernel_linux multilib userland_GNU * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found kernel object directory: * /lib/modules/2.6.36-gentoo-r5/build * Found sources for kernel version: * 2.6.36-gentoo-r5 * Checking for MTRR support ... [ ok ] * * WARNING * * * You are currently installing a version of nvidia-drivers that is * known not to work with a video card you have installed on your * system. If this is intentional, please ignore this. If it is not * please perform the following steps: * * Add the following mask entry to /etc/portage/package.mask by * echo =x11-drivers/nvidia-drivers-177.0.0 /etc/portage/package.mask * * Failure to perform the steps above could result in a non-working * X setup. * * For more information please read: * http://www.nvidia.com/object/IO_32667.html Unpacking source... Unpacking NVIDIA-Linux-x86_64-260.19.29.run to /var/tmp/portage/x11-drivers/nvidia-drivers-260.19.29/work Source unpacked in /var/tmp/portage/x11-drivers/nvidia-drivers-260.19.29/work Preparing source in /var/tmp/portage/x11-drivers/nvidia-drivers-260.19.29/work ... * Applying 256.35-unified-arch.patch ... [ ok ] * Converting /kernel/Makefile.kbuild to use M= instead of SUBDIRS= ... [ ok ] Source prepared. Configuring source in /var/tmp/portage/x11-drivers/nvidia-drivers-260.19.29/work ... Source configured. Compiling source in /var/tmp/portage/x11-drivers/nvidia-drivers-260.19.29/work ... * Preparing nvidia module make -j2 HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu- LDFLAGS= IGNORE_CC_MISMATCH=yes V=1 SYSSRC=/usr/src/linux SYSOUT=/lib/modules/2.6.36-gentoo-r5/build HOST_CC=x86_64-pc-linux-gnu-gcc clean module Your kernel was configured to include nvidiafb support! The nvidiafb driver
RE: [gentoo-user] Re: New Install Problems with X
On Thu, Jan 6, 2011 at 1:38 PM, KIM WHALEN wrote: On Wed, Jan 5, 2011 at 6:25 PM, walt wrote: On 01/05/2011 06:41 AM, KIM WHALEN wrote: On Wed, Jan 5, 2011 at 8:56 AM, walt wrote: On 01/04/2011 08:10 AM, KIM WHALEN wrote: I'm trying to do a new install on an amd64 box and there are a lot of problems somewhere between X, Gnome, and the Graphics card. I'm using genkernel so there shouldn't be too much of a problem there. The graphics card as identified by the system is: nVidia Corporation NV36 [GeForce FX 5700LE] The base system and xorg-x11 seems to be set up alright. However, when I run startx as a regular user I get errors about drm, dri, and dri2 modules and the screen. Those drm and dri error messages are normal when using the nvidia drivers, but the screen error is not normal. What does it say, exactly? Did you generate your xorg.conf by doing Xorg -configure? Are you using an xorg.conf file at all? The nouveau driver is not nearly ready for prime time yet, so I'd stick with nivida-drivers at least until you have everything else working. I am not using the xorg.conf file That's fine for starters. You may need to add one later if your mouse or keyboard don't work. (BTW, you need to emerge the xf86-input-evdev driver for the mouse and keyboard if you don't have an xorg.conf). (==) Log file: /var/log/Xorg.0.log, Time: Wed Jan 5 09:03:31 2011 List of video drivers: nouveau nvidia FATAL: Error inserting nvidia (/lib/modules/2.6.36-gentoo-r5/video/nvidia.ko): No such device That's definitely a problem. The no such device is a bit ambiguous. I'm thinking maybe the nouveau and nvidia drivers are fighting with each other, so neither one can get full control of the video hardware. IIRC, if you build the nouveau driver into your kernel, it *will* conflict with the nvidia kernel module. I keep two different kernel config files, one with nouveau, and the other without nouveau for use with the nvidia.ko module. Definitely build a kernel without nouveau at least until you get everything else working -- and then *re*emerge nividia-drivers after you boot the new kernel. (Compiling/installing a new kernel will delete all of your existing kernel modules including nvidia.ko!) I already had the xf86-input-evdev driver installed. I could find anything to take out of the kernel, but added nVidia Framebuffer Support. Device Drivers + Graphics Support + Support for Framebuffer Devices + nVidia Framebuffer Support Then I emerge x11-drivers/nvidia-drivers. That, unfortunately, didn't help; it failed to emerge and the output is below. # emerge x11-drivers/nvidia-drivers Calculating dependencies... done! Verifying ebuild manifests Emerging (1 of 1) x11-drivers/nvidia-drivers-260.19.29 Failed to emerge x11-drivers/nvidia-drivers-260.19.29, Log file: '/var/tmp/portage/x11-drivers/nvidia-drivers-260.19.29/temp/build.log' Jobs: 0 of 1 complete, 1 failed Load avg: 0.43, 0.13, 0.04 * Package:x11-drivers/nvidia-drivers-260.19.29 * Repository: gentoo * Maintainer: car...@gentoo.org j...@gentoo.org,sp...@gentoo.org * USE: amd64 elibc_glibc gtk kernel_linux multilib userland_GNU * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found kernel object directory: * /lib/modules/2.6.36-gentoo-r5/build * Found sources for kernel version: * 2.6.36-gentoo-r5 * Checking for MTRR support ... [ ok ] * * WARNING * * * You are currently installing a version of nvidia-drivers that is * known not to work with a video card you have installed on your * system. If this is intentional, please ignore this. If it is not * please perform the following steps: * * Add the following mask entry to /etc/portage/package.mask by * echo =x11-drivers/nvidia-drivers-177.0.0 /etc/portage/package.mask * * Failure to perform the steps above could result in a non-working * X setup. * * For more information please read: * http://www.nvidia.com/object/IO_32667.html Unpacking source... Unpacking NVIDIA-Linux-x86_64-260.19.29.run to /var/tmp/portage/x11-drivers/nvidia-drivers-260.19.29/work Source unpacked in /var/tmp/portage/x11-drivers/nvidia-drivers-260.19.29/work Preparing source in /var/tmp/portage/x11-drivers/nvidia-drivers-260.19.29/work ... * Applying 256.35-unified-arch.patch ... [ ok ] * Converting /kernel/Makefile.kbuild to use M= instead of SUBDIRS= ... [ ok ] Source prepared. Configuring source in /var/tmp/portage/x11-drivers/nvidia-drivers-260.19.29/work ... Source configured. Compiling source in /var/tmp/portage/x11-drivers/nvidia-drivers-260.19.29/work ... * Preparing nvidia module make -j2 HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu- LDFLAGS= IGNORE_CC_MISMATCH=yes V=1 SYSSRC=/usr/src/linux SYSOUT=/lib/modules/2.6.36-gentoo-r5/build HOST_CC=x86_64-pc-linux-gnu-gcc clean module Your kernel was configured
[gentoo-user] Re: Latest unstable ntp not generating ntp.drift file.
On Thursday 06 January 2011, Dale wrote: I deleted the /etc/adjtime but it has not been recreated. What creates this file? I deleted it a couple days ago and nothing has brought it back yet. /sbin/hwclock --systohc does. What happens in the long run if you don't run any synchronization service at all? Does the time go stray or it just exhibits a systematic error? Ciao Francesco -- Linux Version 2.6.36-gentoo-r6, Compiled #2 SMP PREEMPT Mon Jan 3 11:54:58 CET 2011 Two 2.9GHz AMD Athlon 64 Processors, 4GB RAM, 11659 Bogomips Total aemaeth
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
On 1/5/2011 12:04 AM, Thanasis wrote: I think you should prefer openntpd over ntpd, because I think openntpd is developed by openbsd, which means more secure ... I tried openntp a couple years ago. It was a giant pain in the ass. IIRC it was combination of crap defaults, poor docs, and plain not working. I think this was over five years ago and doubtfully thing have improved, but I definitely wasn't impressed at the time. kashani
Re: [gentoo-user] Re: Latest unstable ntp not generating ntp.drift file.
On Thu, 06 Jan 2011 11:31:30 -0600, Dale wrote: Well, I tried openntp for a good while last night and it was worse than ntp. It was adjusting the clock by something like 20 seconds at a time. Even ntp wasn't that bad. ntpd won't shift the clock by too much at a time. If your clock is further out, you should use ntp-client to correct it. Add ntp-client to the default runlevel to make sure the clock is correct when you boot. -- Neil Bothwick This is as bad as it can get; but don't bet on it. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Latest unstable ntp not generating ntp.drift file.
The only thing I have changed with openntp is in /etc/ntpd.conf, I added `listen on *`, maybe a few servers and in /etc/conf.d/ntpd or whatever it's called, I added `-s` to OPTIONS. I've been using that on a server for a year and my laptops for over two. I've had no problems with syncing.
Re: [gentoo-user] Re: Latest unstable ntp not generating ntp.drift file.
on 01/06/2011 07:31 PM Dale wrote the following: Well, I tried openntp for a good while last night and it was worse than ntp. It was adjusting the clock by something like 20 seconds at a time. That's probably because you didn't put -s in the start up options in /etc/conf.d/ntpd: # See ntpd(8) man page ... some popular options: # -s Set the time immediately at startup NTPD_OPTS=-s
Re: [gentoo-user] Slotted PHP behavior
But watch out -- after the eselect, you'll need to move your php.ini from e.g. /etc/php/apache2 to /etc/php/apache2-php5.3. Here I get confused. I believe a development version of php.ini was installed to /etc/php/apache2-php5.3/php.ini. It included a development value for error_reporting which I needed to change to the production value in order to prevent squirrelmail from triggering many error messages. At this point I have my old php.ini (which I don't think I ever edited) and the new development version of php.ini for 5.3.4. I did a diff between them and there are about 15 chunks of difference. The problem is I'm not sure which changes are due to the 5.3.3-5.3.4 switch and which are due to the fact that it's a development version of the config file. What I'd like to do is run a default 5.3.4 production php.ini but I don't know how to come up with that. New/deleted parameters are probably from the upgrade. Values that have been changes are probably your changes. You can re-emerge PHP with the production php.ini according to this (I haven't tried it): http://olemarkus.org/2010/10/choosing-between-development-and-production-version-of-php-ini/ Ah, perfect! Adding the following to /etc/make.conf and re-emerging php I was able to use etc-update to merge the latest production version of php.ini: PHP_INI_VERSION=production I guess we're in a transitional phase with PHP on Gentoo. I hope it works out. - Grant What is gained by this new extra layer for PHP on Gentoo? I was happy when it behaved like every other ebuild and I could use etc-update along with -5 and I didn't have to bother with eselect. A ton of crap broke with the PHP 5.2 - 5.3 upgrade. In theory, this will help with future upgrades; but I'm not sure how, since I can't *run* both versions at the same time. Does anyone know how having 5.3 installed will help me when I'm stuck running 5.2 for some of my sites?
Re: [gentoo-user] Re: Latest unstable ntp not generating ntp.drift file.
Francesco Talamona wrote: On Thursday 06 January 2011, Dale wrote: I deleted the /etc/adjtime but it has not been recreated. What creates this file? I deleted it a couple days ago and nothing has brought it back yet. /sbin/hwclock --systohc does. What happens in the long run if you don't run any synchronization service at all? Does the time go stray or it just exhibits a systematic error? Ciao Francesco I been using hwclock and it did generate adjtime file. So far so good. I been googling a bit. I ran a command with and sleep cycles for a while to let the adjtime file get a good figure. It changed each time. I'm going to let it run for a while more. I ran that while ntp was stopped too. I didn't want ntp to get in the way. I haven't tried long term without ntp running. I did stop the service a while and it was off a lot in just a little bit. I think I was unmasking the unstable version and compiling it. Since this is a 4 core rig, it doesn't take that long. Downloading source, compiling and installing couldn't take longer than a few minutes plus me editing config files. I figure it was about 20 minutes or so and it was off a little less than a minute if I recall correctly. I guess my clock would be off hugely if left alone for a day or so. Since I don't reboot very often, I would have my days and nights messed up before long. lol I'm hoping having a good adjtime file will help some at least. Time will tell I guess. Pardon that usage of time. ;-) Dale :-) :-)
[gentoo-user] Re: New Install Problems with X
On 01/06/2011 10:43 AM, KIM WHALEN wrote: Sorry, I did # echo =x11-drivers/nvidia-drivers-177.0.0 /etc/portage/package.mask first Good, you're now trying to install the correct version. then tried it again and got the following error. Your kernel was configured to include nvidiafb support! The nvidiafb driver conflicts with the NVIDIA driver, please reconfigure your kernel and *disable* nvidiafb support, then try installing the NVIDIA kernel module again. Looks like you haven't done that yet, right?
RE: [gentoo-user] Re: New Install Problems with X
On Thu, Jan 6, 2011 at 3:02 PM, walt wrote: On 01/06/2011 10:43 AM, KIM WHALEN wrote: Sorry, I did # echo =x11-drivers/nvidia-drivers-177.0.0 /etc/portage/package.mask first Good, you're now trying to install the correct version. then tried it again and got the following error. Your kernel was configured to include nvidiafb support! The nvidiafb driver conflicts with the NVIDIA driver, please reconfigure your kernel and *disable* nvidiafb support, then try installing the NVIDIA kernel module again. Looks like you haven't done that yet, right? Haven't got it installed yet. Should I just buy a new nVidia card? I really wouldn't mind, I just don't want to get a new one if I'm going to have the same problems. Thanks.
Re: [gentoo-user] Re: Latest unstable ntp not generating ntp.drift file.
Jacob Todd wrote: The only thing I have changed with openntp is in /etc/ntpd.conf, I added `listen on *`, maybe a few servers and in /etc/conf.d/ntpd or whatever it's called, I added `-s` to OPTIONS. I've been using that on a server for a year and my laptops for over two. I've had no problems with syncing. I have used ntp on another machine for years with no problems. I think this is deeper than ntp. That's why I am looking for something else. I don't think it is ntp itself that is the problem. I'm working on adjtime now. I plan to update the BIOS if that doesn't help. Maybe they changed something in there. I think there has been 3 or 4 updates since the version I have. Dale :-) :-)
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
kashani wrote: On 1/5/2011 12:04 AM, Thanasis wrote: I think you should prefer openntpd over ntpd, because I think openntpd is developed by openbsd, which means more secure ... I tried openntp a couple years ago. It was a giant pain in the ass. IIRC it was combination of crap defaults, poor docs, and plain not working. I think this was over five years ago and doubtfully thing have improved, but I definitely wasn't impressed at the time. kashani It is a basic program for sure. Commands that I used before with ntp were missing. The plain ntp has a lot more options and more commands for seeing what is going on while openntp does not have much. I think either would work here if I didn't have some underlying issue somewhere. Dale :-) :-)
Re: [gentoo-user] Re: New Install Problems with X
On Thursday 06 January 2011 20:10:15 KIM WHALEN wrote: On Thu, Jan 6, 2011 at 3:02 PM, walt wrote: On 01/06/2011 10:43 AM, KIM WHALEN wrote: Sorry, I did # echo =x11-drivers/nvidia-drivers-177.0.0 /etc/portage/package.mask first Good, you're now trying to install the correct version. then tried it again and got the following error. Your kernel was configured to include nvidiafb support! The nvidiafb driver conflicts with the NVIDIA driver, please reconfigure your kernel and *disable* nvidiafb support, then try installing the NVIDIA kernel module again. Looks like you haven't done that yet, right? Haven't got it installed yet. Should I just buy a new nVidia card? I really wouldn't mind, I just don't want to get a new one if I'm going to have the same problems. Thanks. could you please use an email client that does not butcher threading? And a new card does not help you if you don't set up your kernel correctly.
Re: [gentoo-user] Re: New Install Problems with X
On Thu, Jan 6, 2011 at 4:20 PM, Volker Armin Hemmann wrote: On Thursday 06 January 2011 20:10:15 KIM WHALEN wrote: On Thu, Jan 6, 2011 at 3:02 PM, walt wrote: On 01/06/2011 10:43 AM, KIM WHALEN wrote: Sorry, I did # echo =x11-drivers/nvidia-drivers-177.0.0 /etc/portage/package.mask first Good, you're now trying to install the correct version. then tried it again and got the following error. Your kernel was configured to include nvidiafb support! The nvidiafb driver conflicts with the NVIDIA driver, please reconfigure your kernel and *disable* nvidiafb support, then try installing the NVIDIA kernel module again. Looks like you haven't done that yet, right? Haven't got it installed yet. Should I just buy a new nVidia card? I really wouldn't mind, I just don't want to get a new one if I'm going to have the same problems. Thanks. could you please use an email client that does not butcher threading? And a new card does not help you if you don't set up your kernel correctly. I made the kernel with the nvidia driver as a module and the emerge x11-drivers/nvidia-drivers worked. However, running Xorg -configure still fails. . . . and I would love to use and email client that doesn't butcher threading, but I can't until I get this problem fixed. I have to do a remote login from a machine at work and use optonline's webbased client. Sorry.
Re: [gentoo-user] Re: New Install Problems with X
On 01/07/11 09:51, KIM WHALEN wrote: On Thu, Jan 6, 2011 at 4:20 PM, Volker Armin Hemmann wrote: On Thursday 06 January 2011 20:10:15 KIM WHALEN wrote: On Thu, Jan 6, 2011 at 3:02 PM, walt wrote: On 01/06/2011 10:43 AM, KIM WHALEN wrote: Sorry, I did # echo =x11-drivers/nvidia-drivers-177.0.0 /etc/portage/package.mask first Good, you're now trying to install the correct version. then tried it again and got the following error. Your kernel was configured to include nvidiafb support! The nvidiafb driver conflicts with the NVIDIA driver, please reconfigure your kernel and *disable* nvidiafb support, then try installing the NVIDIA kernel module again. Looks like you haven't done that yet, right? Haven't got it installed yet. Should I just buy a new nVidia card? I really wouldn't mind, I just don't want to get a new one if I'm going to have the same problems. Thanks. could you please use an email client that does not butcher threading? And a new card does not help you if you don't set up your kernel correctly. I made the kernel with the nvidia driver as a module and the emerge x11-drivers/nvidia-drivers worked. However, running Xorg -configure still fails. . . . and I would love to use and email client that doesn't butcher threading, but I can't until I get this problem fixed. I have to do a remote login from a machine at work and use optonline's webbased client. Sorry. But the warning message specifically says to *disable* that support, not just make it a module. From what I remember, you can't have *any* support for framebuffer in your kernel config. Also, if you're getting to a new step, can you include the output from Xorg -configure? Jake Moe
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
On Thu, 2011-01-06 at 14:46 -0600, Dale wrote: kashani wrote: On 1/5/2011 12:04 AM, Thanasis wrote: I think you should prefer openntpd over ntpd, because I think openntpd is developed by openbsd, which means more secure ... I tried openntp a couple years ago. It was a giant pain in the ass. IIRC it was combination of crap defaults, poor docs, and plain not working. I think this was over five years ago and doubtfully thing have improved, but I definitely wasn't impressed at the time. kashani It is a basic program for sure. Commands that I used before with ntp were missing. The plain ntp has a lot more options and more commands for seeing what is going on while openntp does not have much. I think either would work here if I didn't have some underlying issue somewhere. Dale :-) :-) Dale, can you post (a sanitised) version of what 'ntpq -p' gives after ntpd has been running for some time, and the sanitised result of 'ntptrace. Also include your full (sanitised) ntp.conf and /etc/conf.d/ntpd. This might help us see more detail of what is happening. BillK * sanitised - obfuscate public IP's only. -- William Kenworthy bi...@iinet.net.au Home in Perth!
[gentoo-user] Re: pdf -gt; txt
meino.cramer at gmx.de writes: I want to convert a couple of pdf-documents, which are of test and ASCIIbased tables, to pure text (ASCII, vim-editable ;) ). app-text/pdftk http://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/ Is very cool for all things PDF on linux. hth, James
[gentoo-user] More locale oddness
Hi there, Can anyone else reproduce this, please, or tell me what behaviour is expected? $ locale LANG=en_GB.UTF-8 LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=en_GB.UTF-8 LC_TIME=en_GB.UTF-8 LC_COLLATE=en_GB.UTF-8 LC_MONETARY=en_GB.UTF-8 LC_MESSAGES=en_GB.UTF-8 LC_PAPER=en_GB.UTF-8 LC_NAME=en_GB.UTF-8 LC_ADDRESS=en_GB.UTF-8 LC_TELEPHONE=en_GB.UTF-8 LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=en_GB.UTF-8 LC_ALL= $ date +%l:%M%P 1:39 $ LC_TIME=POSIX $ date +%l:%M%P 1:39am $ I had a single line of only LANG=en_GB.UTF-8 in /etc/env.d/02locale; adding LC_TIME=POSIX allows various scripts and stuff (I've written) to show the date properly, but I think I read somewhere that this is bad. Thanks for any advice, Stroller.
Re: [gentoo-user] More locale oddness
Stroller wrote: Hi there, Can anyone else reproduce this, please, or tell me what behaviour is expected? $ locale LANG=en_GB.UTF-8 LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=en_GB.UTF-8 LC_TIME=en_GB.UTF-8 LC_COLLATE=en_GB.UTF-8 LC_MONETARY=en_GB.UTF-8 LC_MESSAGES=en_GB.UTF-8 LC_PAPER=en_GB.UTF-8 LC_NAME=en_GB.UTF-8 LC_ADDRESS=en_GB.UTF-8 LC_TELEPHONE=en_GB.UTF-8 LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=en_GB.UTF-8 LC_ALL= $ date +%l:%M%P 1:39 $ LC_TIME=POSIX $ date +%l:%M%P 1:39am $ I had a single line of only LANG=en_GB.UTF-8 in /etc/env.d/02locale; adding LC_TIME=POSIX allows various scripts and stuff (I've written) to show the date properly, but I think I read somewhere that this is bad. Thanks for any advice, Stroller. This is mine: r...@fireball / # locale LANG= LC_CTYPE=POSIX LC_NUMERIC=POSIX LC_TIME=POSIX LC_COLLATE=POSIX LC_MONETARY=POSIX LC_MESSAGES=POSIX LC_PAPER=POSIX LC_NAME=POSIX LC_ADDRESS=POSIX LC_TELEPHONE=POSIX LC_MEASUREMENT=POSIX LC_IDENTIFICATION=POSIX LC_ALL= r...@fireball / # No idea about anything bad tho. Just for comparison. Dale :-) :-)
Re: [gentoo-user] Re: New Install Problems with X
On Thursday 06 January 2011 23:51:38 KIM WHALEN wrote: I made the kernel with the nvidia driver as a module and the emerge x11-drivers/nvidia-drivers worked. However, running Xorg -configure still fails. you don't even need that. cat /etc/X11/xorg.conf Section ServerLayout Identifier aticonfig Layout Screen 0 aticonfig-Screen[0]-0 0 0 InputDeviceKeyboard0 CoreKeyboard InputDeviceMouse0 CorePointer EndSection Section Module EndSection Section InputDevice Identifier Mouse0 Driver evdev Option CorePointer Option Name Logitech, Inc. MX610 Laser Cordless Mouse EndSection Section InputDevice Identifier Keyboard0 Driver evdev Option AutoRepeat 500 30 Option XkbRules xorg Option XkbModel evdev Option XkbLayout de Option XkbOptions terminate:ctrl_alt_bksp EndSection Section Monitor Identifier aticonfig-Monitor[0]-0 Option VendorName ATI Proprietary Driver Option ModelName Generic Autodetecting Monitor Option DPMS true EndSection Section Device Identifier aticonfig-Device[0]-0 Driver fglrx BusID PCI:1:0:0 EndSection Section Screen Identifier aticonfig-Screen[0]-0 Device aticonfig-Device[0]-0 Monitoraticonfig-Monitor[0]-0 DefaultDepth 24 SubSection Display Viewport 0 0 Depth 24 EndSubSection EndSection this is for fglrx - just change fglrx to nvidia - and you have a working nvidia xorg.conf. Just stop doing stupid things with your kernel config. No framebuffer. Not even as modules!
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
William Kenworthy wrote: Dale, can you post (a sanitised) version of what 'ntpq -p' gives after ntpd has been running for some time, and the sanitised result of 'ntptrace. Also include your full (sanitised) ntp.conf and /etc/conf.d/ntpd. This might help us see more detail of what is happening. BillK * sanitised - obfuscate public IP's only. I should have posted this a while back. Here we go: r...@fireball / # ntpq -p remote refid st t when poll reach delay offset jitter == +triangle.kansas 128.252.19.1 2 u4 64 127 56.270 673.749 238.194 +B1-66ER.matrix. 192.43.244.182 u 14 64 377 75.505 672.846 165.087 +kallisti.us 208.90.144.523 u 22 64 377 62.917 663.831 168.738 *kazilik.haqr.ne 209.51.161.238 2 u 42 64 377 66.483 653.962 166.119 r...@fireball / # ntptrace localhost: stratum 16, offset 0.00, synch distance 0.000240 r...@fireball / # This is ntp.conf but I omitted the parts that are commented out. server 64.6.144.6 server 67.159.5.90 server 67.59.168.233 server 204.62.14.98 driftfile/var/lib/ntp/ntp.drift restrict default nomodify nopeer restrict 127.0.0.1 This makes sense if you read the command: r...@fireball / # cat /var/log/messages | grep ntp | tail -n 30 Jan 6 19:58:14 localhost ntpd[3017]: Attemping to register mDNS Jan 6 19:58:14 localhost ntpd[3017]: *** WARNING *** The program 'ntpd' uses the Apple Bonjour compatibility layer of Avahi. Jan 6 19:58:14 localhost ntpd[3017]: *** WARNING *** Please fix your application to use the native API of Avahi! Jan 6 19:58:14 localhost ntpd[3017]: *** WARNING *** For more information see http://0pointer.de/avahi-compat?s=libdns_sde=ntpd Jan 6 19:58:14 localhost ntpd[3019]: precision = 1.000 usec Jan 6 19:58:14 localhost ntpd[3019]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled Jan 6 19:58:14 localhost ntpd[3019]: Listening on interface #1 wildcard, ::#123 Disabled Jan 6 19:58:14 localhost ntpd[3019]: Listening on interface #2 eth0, fe80::1e6f:65ff:fe4c:91c7#123 Enabled Jan 6 19:58:14 localhost ntpd[3019]: Listening on interface #3 lo, ::1#123 Enabled Jan 6 19:58:14 localhost ntpd[3019]: Listening on interface #4 lo, 127.0.0.1#123 Enabled Jan 6 19:58:14 localhost ntpd[3019]: Listening on interface #5 eth0, 192.168.2.5#123 Enabled Jan 6 19:58:14 localhost ntpd[3019]: kernel time sync status 2040 Jan 6 19:58:14 localhost ntpd[3019]: frequency initialized 500.000 PPM from /var/lib/ntp/ntp.drift Jan 6 20:02:33 localhost ntpd[3019]: synchronized to 67.59.168.233, stratum 3 Jan 6 20:02:33 localhost ntpd[3019]: time reset +0.237917 s Jan 6 20:02:33 localhost ntpd[3019]: kernel time sync status change 2001 Jan 6 20:07:31 localhost ntpd[3019]: synchronized to 67.159.5.90, stratum 2 Jan 6 20:13:57 localhost ntpd[3019]: synchronized to 204.62.14.98, stratum 2 Jan 6 20:17:34 localhost ntpd[3019]: time reset +0.567387 s Jan 6 20:24:05 localhost ntpd[3019]: synchronized to 67.159.5.90, stratum 2 Jan 6 20:27:05 localhost ntpd[3019]: synchronized to 204.62.14.98, stratum 2 Jan 6 20:31:40 localhost ntpd[3019]: synchronized to 67.159.5.90, stratum 2 Jan 6 20:35:33 localhost ntpd[3019]: time reset +0.604521 s Jan 6 20:44:29 localhost ntpd[3019]: synchronized to 67.159.5.90, stratum 2 Jan 6 20:47:44 localhost ntpd[3019]: synchronized to 204.62.14.98, stratum 2 Jan 6 20:55:22 localhost ntpd[3019]: time reset +0.663361 s Jan 6 21:01:22 localhost ntpd[3019]: synchronized to 204.62.14.98, stratum 2 Jan 6 21:04:05 localhost ntpd[3019]: synchronized to 67.159.5.90, stratum 2 Jan 6 21:08:40 localhost ntpd[3019]: synchronized to 204.62.14.98, stratum 2 Jan 6 21:17:01 localhost ntpd[3019]: time reset +0.676538 s r...@fireball / # Notice it is off about .6 seconds every 15 to 20 minutes or so? It never gets any closer than this either. I let it run for a good day the other day and it was still the same. On my old rig, it would get to a point where the corrections were smaller and the syncs were father apart. I have seen it go for hours between syncs and be only .01 or .02 seconds off. My old rig wouldn't sync so often either. The drift file would also change and be some rather odd numbers. The file on this rig never changes and looks like some sort of a default value. Speaking of: r...@fireball / # cat /var/lib/ntp/ntp.drift 500.000 r...@fireball / # This is the adjtime file from a good ways back: r...@fireball / # cat /etc/adjtime 0.00 1294340368 0.00 1294340368 UTC r...@fireball / # And the current one after some updates: r...@fireball / # cat /etc/adjtime 0.00 1294365381 0.00 1294365381 UTC r...@fireball / # Does any of this put the light on something I may be missing? I started with a copy of ntp.conf from my old rig. I did change the servers but I change them sometimes anyway. I use
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
On Fri, 7 Jan 2011 14:31:52 Dale wrote: William Kenworthy wrote: Dale, can you post (a sanitised) version of what 'ntpq -p' gives after ntpd has been running for some time, and the sanitised result of 'ntptrace. Also include your full (sanitised) ntp.conf and /etc/conf.d/ntpd. This might help us see more detail of what is happening. BillK * sanitised - obfuscate public IP's only. I should have posted this a while back. Here we go: r...@fireball / # ntpq -p remote refid st t when poll reach delay offset jitter === === +triangle.kansas 128.252.19.1 2 u4 64 127 56.270 673.749 238.194 +B1-66ER.matrix. 192.43.244.182 u 14 64 377 75.505 672.846 165.087 +kallisti.us 208.90.144.523 u 22 64 377 62.917 663.831 168.738 *kazilik.haqr.ne 209.51.161.238 2 u 42 64 377 66.483 653.962 166.119 r...@fireball / # ntptrace localhost: stratum 16, offset 0.00, synch distance 0.000240 r...@fireball / # This is ntp.conf but I omitted the parts that are commented out. server 64.6.144.6 server 67.159.5.90 server 67.59.168.233 server 204.62.14.98 Have you tried switching servers? I'm using server 0.au.pool.ntp.org server 1.au.pool.ntp.org Try the equivalent for your location, or there are 0.gentoo.pool.ntp.org and so on. -- Reverend Paul Colquhoun, ULC.http://andor.dropbear.id.au/~paulcol Before you criticize someone, you should walk a mile in their shoes. Then, when you do, you'll be a mile away, and you'll have their shoes.
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
Paul Colquhoun wrote: On Fri, 7 Jan 2011 14:31:52 Dale wrote: This is ntp.conf but I omitted the parts that are commented out. server 64.6.144.6 server 67.159.5.90 server 67.59.168.233 server 204.62.14.98 Have you tried switching servers? I'm using server 0.au.pool.ntp.org server 1.au.pool.ntp.org Try the equivalent for your location, or there are 0.gentoo.pool.ntp.org and so on. I have. I started out with the same servers on my old rig and changed them to see if it would matter a week or so ago. I use this command to get the best servers: netselect -s 3 pool.ntp.org That generally works pretty well. I try to update them every once in a while. I'm thinking about removing the router and hooking directly to my DSL modem. That's the only thing that has changed from the old rig to the new rig. This is how close the old rig is and it is hooked to the router too: r...@smoker / # ntpdate -b -u -q pool.ntp.org server 72.26.125.125, stratum 2, offset -0.87, delay 0.09828 server 64.34.218.21, stratum 2, offset -0.002207, delay 0.09799 server 149.20.68.17, stratum 2, offset 0.009124, delay 0.13466 6 Jan 23:23:31 ntpdate[15816]: step time server 64.34.218.21 offset -0.002207 sec r...@smoker / # According to the log, it synced a hour or so ago and the previous sync was about 7 hours before that. Now why can't my new rig do that? Dale :-) :-)
Re: [gentoo-user] More locale oddness
Apparently, though unproven, at 03:49 on Friday 07 January 2011, Stroller did opine thusly: Hi there, Can anyone else reproduce this, please, or tell me what behaviour is expected? $ locale LANG=en_GB.UTF-8 LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=en_GB.UTF-8 LC_TIME=en_GB.UTF-8 LC_COLLATE=en_GB.UTF-8 LC_MONETARY=en_GB.UTF-8 LC_MESSAGES=en_GB.UTF-8 LC_PAPER=en_GB.UTF-8 LC_NAME=en_GB.UTF-8 LC_ADDRESS=en_GB.UTF-8 LC_TELEPHONE=en_GB.UTF-8 LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=en_GB.UTF-8 LC_ALL= $ date +%l:%M%P 1:39 $ LC_TIME=POSIX $ date +%l:%M%P 1:39am $ I had a single line of only LANG=en_GB.UTF-8 in /etc/env.d/02locale; adding LC_TIME=POSIX allows various scripts and stuff (I've written) to show the date properly, but I think I read somewhere that this is bad. Your output looks fine, except for the last two commands. LC_TIME is an envvar, you have set it without exporting it, then ran data again and got a change. I don't understand how you managed that as LC_TIME would no longer be POSIX at that stage: $ cat /etc/env.d/02locale LANG=en_GB.utf8 $ locale LANG=en_GB.utf8 LC_CTYPE=en_GB.utf8 LC_NUMERIC=en_GB.utf8 LC_TIME=en_GB.utf8 LC_COLLATE=en_GB.utf8 LC_MONETARY=en_GB.utf8 LC_MESSAGES=en_GB.utf8 LC_PAPER=en_GB.utf8 LC_NAME=en_GB.utf8 LC_ADDRESS=en_GB.utf8 LC_TELEPHONE=en_GB.utf8 LC_MEASUREMENT=en_GB.utf8 LC_IDENTIFICATION=en_GB.utf8 LC_ALL= $ date +%l:%M%P 8:16 $ LC_TIME=POSIX $ date +%l:%M%P 8:17 $ LC_TIME=POSIX date +%l:%M%P 8:18am As for the correct way and what is bad, I've also read stuff. I've read lots and lots and lots of opinions, but not much fact. So here's my own mere opinion: It doesn't really matter where you set it as long as it gets the job done. Put it in conf.d to have it global. Put it in /etc/profile* to have it global for a shell Put it in ~/.profile* to set it for a single user. Or maybe you meant that you've read some people opine that setting just LC_TIME is bad? -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: New Install Problems with X
Apparently, though unproven, at 22:10 on Thursday 06 January 2011, KIM WHALEN did opine thusly: On Thu, Jan 6, 2011 at 3:02 PM, walt wrote: On 01/06/2011 10:43 AM, KIM WHALEN wrote: Sorry, I did # echo =x11-drivers/nvidia-drivers-177.0.0 /etc/portage/package.mask first Good, you're now trying to install the correct version. then tried it again and got the following error. Your kernel was configured to include nvidiafb support! The nvidiafb driver conflicts with the NVIDIA driver, please reconfigure your kernel and *disable* nvidiafb support, then try installing the NVIDIA kernel module again. Looks like you haven't done that yet, right? Haven't got it installed yet. Should I just buy a new nVidia card? I really wouldn't mind, I just don't want to get a new one if I'm going to have the same problems. Thanks. For completeness, you do not actually need to remove all FB support to use nVidia proprietary drivers, just the nVidia-specific ones. You can use CONFIG_FB_VESA=y just fine like I do. It gives me more than 80x25 on the console which is how I like it. -- alan dot mckinnon at gmail dot com
