SOLVED - Re: [gentoo-user] NFS mount not properly unmounting during shutdown/reboot
On 2013-06-10 4:29 PM, Alan McKinnon alan.mckin...@gmail.com wrote: The simplest way around this is to add nfsmount to the default runlevel. This will work today as it reads /etc/fstab at startup to mount stuff and your fstab has no nfs shares in it. It reads /etc/mtab at shutdown to umount stuff and your QNAP share will be in that file. Cool, I'll do that. I'll still try to remember to umount it manually because I don't like testing something that might cause my system to not safely/fully shutdown, but this way hopefully if I ever do forget, it will handle it for me. I simulated it here and that's the result I got. But this is gentoo, and everything might change tomorrow so YMMV :-) Lol, yeah, there are never any guarantees... You could also write a scriptlet to do the umount and put it in /etc/conf.d/local - see /etc/init.d/local for details I may look into that, but some reading tells me you are right and that adding nfsmount to the default runlevel should work. Thanks a lot for your time Alan. Charles
Re: [gentoo-user] NFS mount not properly unmounting during shutdown/reboot
on 06/10/2013 11:29 PM Alan McKinnon wrote the following: snip You could also write a scriptlet to do the umount and put it in /etc/conf.d/local - see /etc/init.d/local for details Actually /etc/conf.d/local has been replaced by files you put in directory /etc/local.d/ ie: /etc/local.d/*.start and /etc/local.d/*.stop
Re: [gentoo-user] NFS mount not properly unmounting during shutdown/reboot
On 11/06/2013 14:38, Thanasis wrote: on 06/10/2013 11:29 PM Alan McKinnon wrote the following: snip You could also write a scriptlet to do the umount and put it in /etc/conf.d/local - see /etc/init.d/local for details Actually /etc/conf.d/local has been replaced by files you put in directory /etc/local.d/ ie: /etc/local.d/*.start and /etc/local.d/*.stop Your right - I mistakenly copy-pasted the wrong path from /etc/init.d/local my bad -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Linux Fiber SAN
Hello Everyone, Was wondering what people are running these days, and how do they compare to the 10,000 dollar SAN boxes. We are looking to build a fiber san using IET and glusterFS, and was wondering what kind of luck people where having using this approach, or any for that matter. Kind Regards, Nick.
[gentoo-user] app-admin/system-config-printer-gnome-1.3.12 not building
Hy,
I've got a problem related to system-config-printer-gnome-1.3.12 not being
able to be built. The build process stops with the log bellow. Its bottom
line says it was impossible to download :
http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd; , which I've
succeeded to download using wget with no extra parameters.
Any hints?
Thanks
Francisco
Emerging (1 of 4) app-admin/system-config-printer-gnome-1.3.12
* system-config-printer-1.3.12.tar.xz SHA256 SHA512 WHIRLPOOL size ;-)
...
[ ok ]
Unpacking source...
Unpacking system-config-printer-1.3.12.tar.xz to
/var/tmp/portage/app-admin/system-config-printer-gnome-1.3.12/work
Source unpacked in
/var/tmp/portage/app-admin/system-config-printer-gnome-1.3.12/work
Preparing source in
/var/tmp/portage/app-admin/system-config-printer-gnome-1.3.12/work/system-config-printer-1.3.12
...
* Applying system-config-printer-gnome-1.3.12-split.patch
...
[ ok ]
* Running eautoreconf in
'/var/tmp/portage/app-admin/system-config-printer-gnome-1.3.12/work/system-config-printer-1.3.12'
...
* Running intltoolize --automake --copy --force
...
[ ok ]
* Running aclocal
...
[ ok ]
* Running autoconf
...
[ ok ]
* Running automake --add-missing --copy
...
[ ok ]
Source prepared.
Configuring source in
/var/tmp/portage/app-admin/system-config-printer-gnome-1.3.12/work/system-config-printer-1.3.12
...
* econf: updating system-config-printer-1.3.12/config.sub with
/usr/share/gnuconfig/config.sub
* econf: updating system-config-printer-1.3.12/config.guess with
/usr/share/gnuconfig/config.guess
./configure --prefix=/usr --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --libdir=/usr/lib64 --with-desktop-vendor=Gentoo
--without-udev-rules --enable-nls
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether NLS is requested... yes
checking for style of include used by make... GNU
checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes
checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none needed
checking dependency style of x86_64-pc-linux-gnu-gcc... gcc3
checking for intltool-update... /usr/bin/intltool-update
checking for intltool-merge... /usr/bin/intltool-merge
checking for intltool-extract... /usr/bin/intltool-extract
checking for xgettext... /usr/bin/xgettext
checking for msgmerge... /usr/bin/msgmerge
checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/gmsgfmt
checking for perl... /usr/bin/perl
checking for perl = 5.8.1... 5.12.4
checking for XML::Parser... ok
checking for msgfmt... (cached) /usr/bin/msgfmt
checking for gmsgfmt... (cached) /usr/bin/gmsgfmt
checking for xgettext... (cached) /usr/bin/xgettext
checking for msgmerge... (cached) /usr/bin/msgmerge
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for ld used by x86_64-pc-linux-gnu-gcc...
/usr/x86_64-pc-linux-gnu/bin/ld
checking if the linker (/usr/x86_64-pc-linux-gnu/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking how to run the C preprocessor... x86_64-pc-linux-gnu-gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for CFPreferencesCopyAppValue... no
checking for CFLocaleCopyCurrent... no
checking for GNU gettext in libc... yes
checking whether to use NLS... yes
checking where the gettext function comes from... libc
checking for python... /usr/bin/python
checking for python version... 2.7
checking for python platform... linux2
checking for python script directory...
${prefix}/lib64/python2.7/site-packages
checking for python extension module directory...
${exec_prefix}/lib64/python2.7/site-packages
checking for x86_64-pc-linux-gnu-pkg-config...
/usr/bin/x86_64-pc-linux-gnu-pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for GLIB... yes
checking for x86_64-pc-linux-gnu-pkg-config... (cached)
/usr/bin/x86_64-pc-linux-gnu-pkg-config
checking pkg-config is at least version 0.9.0... yes
Package systemd was not found in the pkg-config search path.
Perhaps you should add the directory containing `systemd.pc'
to the PKG_CONFIG_PATH environment variable
No package 'systemd' found
configure: creating ./config.status
config.status: creating Makefile
config.status: creating po/Makefile.in
config.status: creating system-config-printer
Re: [gentoo-user] [OT] Recent git kernels break rtc (real-time-clock)
On Mon, Jun 10, 2013 at 7:31 PM, walt w41...@gmail.com wrote: After the recent 3.9 -- 3.10 kernel merge window, udev no longer creates /dev/rtc (or /dev/rtc0) during bootup on my ~amd64 machines. (The only machines I have now.) Not a git-kernel nerd, but just an ordinary kernel nerd. :) The kernel RTC driver creates /dev/rtc0 and then I assume udev creates /dev/rtc from there, so if you are missing rtc0 that's a possible source of the problem. Which would coincide with your kernel upgrade. I know 3.9 introduced a couple new RTC-related option so maybe it changed around some more to 3.10 series. I would run menuconfig and see what it thinks you have enabled in that section, just in case something got lost in transition from one kernel to the next. In dmesg on my non-git 3.9.4 kernel it looks like: [1.237994] rtc_cmos 00:04: RTC can wake from S4 [1.238158] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 [1.238177] rtc_cmos 00:04: alarms up to one month, y3k, 114 bytes nvram, hpet irqs [1.241101] rtc_cmos 00:04: setting system clock to 2013-06-04 04:28:34 UTC (1370320114) I'm using the PC-Style CMOS RTC driver, and I have all of the RTC-related options enabled except for the debugging options.
Re: [gentoo-user] [OT] Recent git kernels break rtc (real-time-clock)
2013/6/11 Paul Hartman paul.hartman+gen...@gmail.com On Mon, Jun 10, 2013 at 7:31 PM, walt w41...@gmail.com wrote: After the recent 3.9 -- 3.10 kernel merge window, udev no longer creates /dev/rtc (or /dev/rtc0) during bootup on my ~amd64 machines. (The only machines I have now.) Not a git-kernel nerd, but just an ordinary kernel nerd. :) The kernel RTC driver creates /dev/rtc0 and then I assume udev creates /dev/rtc from there, so if you are missing rtc0 that's a possible source of the problem. Which would coincide with your kernel upgrade. I know 3.9 introduced a couple new RTC-related option so maybe it changed around some more to 3.10 series. I would run menuconfig and see what it thinks you have enabled in that section, just in case something got lost in transition from one kernel to the next. In dmesg on my non-git 3.9.4 kernel it looks like: [1.237994] rtc_cmos 00:04: RTC can wake from S4 [1.238158] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 [1.238177] rtc_cmos 00:04: alarms up to one month, y3k, 114 bytes nvram, hpet irqs [1.241101] rtc_cmos 00:04: setting system clock to 2013-06-04 04:28:34 UTC (1370320114) I'm using the PC-Style CMOS RTC driver, and I have all of the RTC-related options enabled except for the debugging options. I'm using gentoo-sources-3.8.13 - out of your scope, though, but I have recently faced the same issue. I rebuilt the kernel using --menuconfig, to make sure that all RTC options were enabled. It works, now. Good luck Francisco
Re: [gentoo-user] [OT] Recent git kernels break rtc (real-time-clock)
On Tue, Jun 11, 2013 at 02:50:46PM -0300, Francisco Ares wrote I'm using gentoo-sources-3.8.13 - out of your scope, though, but I have recently faced the same issue. I rebuilt the kernel using --menuconfig, to make sure that all RTC options were enabled. It works, now. Me too. It seems that there were some changes recently in the .config file. I recently built a 3.7.10-gentoo-r1 kernel on a new machine and was on the verge of sending an email to the list asking what the bleep I was doing wrong. After some experimentation, I found that I need either CONFIG_RTC=y or CONFIG_HPET_EMULATE_RTC=y. make menuconfig Device Drivers --- Character devices --- * Enhanced Real Time Clock Support (legacy PC RTC driver) [*] HPET - High Precision Event Timer You might be able to get away without the the legacy RTC support if you enable HPET. I don't know. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
[gentoo-user] Re: [OT] Recent git kernels break rtc (real-time-clock)
On 06/11/2013 04:00 PM, Walter Dnes wrote: It seems that there were some changes recently in the .config file. I recently built a 3.7.10-gentoo-r1 kernel on a new machine and was on the verge of sending an email to the list asking what the bleep I was doing wrong. After some experimentation, I found that I need either CONFIG_RTC=y ... That fixed the problem for me, thanks. OTOH, I've never had CONFIG_RTC enabled before, including 3.9.5, yet I've always had /dev/rtc until 3.10. Now I have /dev/rtc /dev/rtc0, FWIW. I have no idea why you guys are having the same problem with older kernels, except maybe some useflag has changed recently. Are all of you running ~amd64, maybe? BTW, I pull directly from kernel.org, I don't use sys-kernel/git-sources, so my git kernels are not affected by any useflags, FWIW. Thanks guys.
Re: [gentoo-user] Linux Fiber SAN
Am 11.06.2013 16:19, schrieb Nick Khamis: Hello Everyone, Was wondering what people are running these days, and how do they compare to the 10,000 dollar SAN boxes. We are looking to build a fiber san using IET and glusterFS, and was wondering what kind of luck people where having using this approach, or any for that matter. Kind Regards, Nick. Hello Nick, the question is, what are you doing with it and why do you think you need a fibre channel SAN. Our goal indeed is to get rid of the SAN infrastructure as it is delicately to all kinds of failure with nearly zero fault tolerance. An example, you have an hicup or a power failure in your network. SAN is dead from nowon and must be reinitialized on the server. Simple NFS comes back up without any fuzz. Another, you boot your storage systems due to an os update or something like that. Your SAN will be dead. NFS will just go on as if nothing happened. We use netapp storage systems which are NAS and SAN capable. Another point is, that if you have a SAN lun, there is either no way to increase or decrease size on the fly, on cifs or nfs you can resize your share on the go. So if you do not have a _really_ good reason to use a fribre channel SAN, don't! Regards, Norman
