[gentoo-user] unity on Gentoo
Good morning All, I have seen there is a unitiy overlay and have read the forum topic about it. On the other hand, I have used unity for a few weeks when installed ubuntu one of my week moments. To be honest, I liked unity. My question is that worth to install it on gentoo? As I can see it requires a few hacks and masking etc. Is there somebody who use it on daily basis, it is stable enough? I appreciate your help! András -- -- Csanyi Andras (Sayusi Ando) -- http://sayusi.hu -- http://facebook.com/andras.csanyi -- Trust in God and keep your gunpowder dry! - Cromwell
Re: [gentoo-user] NFS mount not properly unmounting during shutdown/reboot
Sorry, that wasn't much of a problem description... I have a system that I often manually mount and unmount some NFS mounts... If I try to do a reboot or shutdown of the system while one of these NFS mounts is mounted, it hangs with the last thing showing on the screen as Unmounting /var... I've let it sit there for at least half an hour, maybe more, so I don't think it would ever continue... If I remember to manually unmount the NFS mount before initiating the reboot/shutdown, it doesn't hang. I'm guessing that it hangs at /var because it is the last mountpoint defined in my /etc/fstab? So... any pointers on where to look for a resolution would be appreciated. Resolution being, if I can manually unmount it fine, why can't the system auto-unmount it? Thanks, Charles On 2013-06-09 4:23 PM, Tanstaafl tansta...@libertytrek.org wrote: Hi all, Ok, now would like to investigate this to see why this is causing my shutdowns/reboots to hang with the last thing on the screen being 'unmounting /var...' Anyone got any idea where to look? I sure don't... I see a googling session in my near future, but any pointers that may help expedite this would be appreciated... Thanks!
Re: [gentoo-user] NFS mount not properly unmounting during shutdown/reboot
On 10/06/2013 12:34, Tanstaafl wrote: Sorry, that wasn't much of a problem description... I have a system that I often manually mount and unmount some NFS mounts... If I try to do a reboot or shutdown of the system while one of these NFS mounts is mounted, it hangs with the last thing showing on the screen as Unmounting /var... I've let it sit there for at least half an hour, maybe more, so I don't think it would ever continue... If I remember to manually unmount the NFS mount before initiating the reboot/shutdown, it doesn't hang. I'm guessing that it hangs at /var because it is the last mountpoint defined in my /etc/fstab? So... any pointers on where to look for a resolution would be appreciated. Resolution being, if I can manually unmount it fine, why can't the system auto-unmount it? Let's get some facts to work with can you post your fstab, rc-update show, /etc/exports on the NFS server and the mount options used for the NFS mounts? Thanks, Charles On 2013-06-09 4:23 PM, Tanstaafl tansta...@libertytrek.org wrote: Hi all, Ok, now would like to investigate this to see why this is causing my shutdowns/reboots to hang with the last thing on the screen being 'unmounting /var...' Anyone got any idea where to look? I sure don't... I see a googling session in my near future, but any pointers that may help expedite this would be appreciated... Thanks! -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] NFS mount not properly unmounting during shutdown/reboot
On 2013-06-10 6:38 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On 10/06/2013 12:34, Tanstaafl wrote: If I remember to manually unmount the NFS mount before initiating the reboot/shutdown, it doesn't hang. I'm guessing that it hangs at /var because it is the last mountpoint defined in my /etc/fstab? So... any pointers on where to look for a resolution would be appreciated. Resolution being, if I can manually unmount it fine, why can't the system auto-unmount it? Let's get some facts to work with can you post your fstab, Fyi, I don't have either of these auto-mounting in fstab, but here it is: # fs mountpointtype opts dump/pass # NOTE: If your BOOT partition is ReiserFS, add the notail option to # opts. /dev/sda1 /boot ext2noauto,noatime 1 2 /dev/sda2 noneswapsw 0 0 /dev/sda3 / ext3noatime 0 1 /dev/sda4 /backupsext3noatime 0 2 /dev/vg2/home /home reiserfsnoatime 0 0 /dev/vg2/usr/usrreiserfsnoatime 0 0 /dev/vg2/var/varreiserfsnoatime 0 0 /dev/cdroms/cdrom0 /mnt/cdrom iso9660 noauto,ro 0 0 /dev/fd0/mnt/floppy autonoauto 0 0 # NOTE: The next line is critical for boot! none/proc procdefaults0 0 # glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for # POSIX shared memory (shm_open, shm_unlink). # (tmpfs is a dynamically expandable/shrinkable ramdisk, and will # use almost no memory if not populated with files) shm /dev/shmtmpfs nodev,nosuid,noexec 0 0 rc-update show, # rc-update show apache2 | default bootmisc | boot consolefont | boot devfs |sysinit device-mapper | boot dmesg |sysinit dovecot | default fsck | boot hostname | boot hwclock | boot iptables | default keymaps | boot killprocs |shutdown local | default nonetwork localmount | boot lvm | boot mailman | default modules | boot mount-ro |shutdown mtab | boot mysql | default net.eth0 | default net.lo | boot netmount | default ntp-client | default ntpd | default postfix | default procfs | boot root | boot rpcbind | default savecache |shutdown sshd | default swap | boot swapfiles | boot sysctl | boot sysfs |sysinit syslog-ng | default termencoding | boot tmpfiles.setup | boot udev |sysinit udev-mount |sysinit udev-postmount | default urandom | boot vixie-cron | default xinetd | default /etc/exports on the NFS server Well... there is no 'NFS Server', these are two QNAP boxes that I can enable NFS on... I guess there may be a way to command-line into them to check that, so if it critical to answering the question, I'll see what I can do. All I know for sure is, if I manually unmount it with umount /mnt/qnap-mountpoint, it unmounts immediately. and the mount options used for the NFS mounts? The command I use to mount it is: mount -t nfs -o mountproto=tcp qnap1:/backups /mnt/qnap1 Thanks Alan, hopefully something jumps out at you...
Re: [gentoo-user] NFS mount not properly unmounting during shutdown/reboot
On 10/06/2013 16:36, Tanstaafl wrote: On 2013-06-10 6:38 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On 10/06/2013 12:34, Tanstaafl wrote: If I remember to manually unmount the NFS mount before initiating the reboot/shutdown, it doesn't hang. I'm guessing that it hangs at /var because it is the last mountpoint defined in my /etc/fstab? So... any pointers on where to look for a resolution would be appreciated. Resolution being, if I can manually unmount it fine, why can't the system auto-unmount it? Let's get some facts to work with can you post your fstab, Fyi, I don't have either of these auto-mounting in fstab, but here it is: # fs mountpointtype opts dump/pass # NOTE: If your BOOT partition is ReiserFS, add the notail option to # opts. /dev/sda1 /boot ext2noauto,noatime 1 2 /dev/sda2 noneswapsw 0 0 /dev/sda3 / ext3noatime 0 1 /dev/sda4 /backupsext3noatime 0 2 /dev/vg2/home /home reiserfsnoatime 0 0 /dev/vg2/usr/usrreiserfsnoatime 0 0 /dev/vg2/var/varreiserfsnoatime 0 0 /dev/cdroms/cdrom0 /mnt/cdrom iso9660 noauto,ro 0 0 /dev/fd0/mnt/floppy autonoauto 0 0 # NOTE: The next line is critical for boot! none/proc procdefaults0 0 # glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for # POSIX shared memory (shm_open, shm_unlink). # (tmpfs is a dynamically expandable/shrinkable ramdisk, and will # use almost no memory if not populated with files) shm /dev/shmtmpfs nodev,nosuid,noexec 0 0 rc-update show, # rc-update show apache2 | default bootmisc | boot consolefont | boot devfs |sysinit device-mapper | boot dmesg |sysinit dovecot | default fsck | boot hostname | boot hwclock | boot iptables | default keymaps | boot killprocs |shutdown local | default nonetwork localmount | boot lvm | boot mailman | default modules | boot mount-ro |shutdown mtab | boot mysql | default net.eth0 | default net.lo | boot netmount | default ntp-client | default ntpd | default postfix | default procfs | boot root | boot rpcbind | default savecache |shutdown sshd | default swap | boot swapfiles | boot sysctl | boot sysfs |sysinit syslog-ng | default termencoding | boot tmpfiles.setup | boot udev |sysinit udev-mount |sysinit udev-postmount | default urandom | boot vixie-cron | default xinetd | default /etc/exports on the NFS server Well... there is no 'NFS Server', these are two QNAP boxes that I can enable NFS on... I guess there may be a way to command-line into them to check that, so if it critical to answering the question, I'll see what I can do. All I know for sure is, if I manually unmount it with umount /mnt/qnap-mountpoint, it unmounts immediately. and the mount options used for the NFS mounts? The command I use to mount it is: mount -t nfs -o mountproto=tcp qnap1:/backups /mnt/qnap1 Thanks Alan, hopefully something jumps out at you... I'm not familiar with QNAP but there's nothing for it in fstab, so I presume running the relevant app on your end magically mounts the remote share without consulting fstab? It all looks very much like your init system is simply not umounting the shares at all so when it tries to remount / ro near the end, this fails. 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. I simulated it here and that's the result I got. But this is gentoo, and everything might change
[gentoo-user] [OT] Recent git kernels break rtc (real-time-clock)
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.) So, I have two idle (very non-urgent) questions for you git-kernel nerds out there (I know you're there ;) First, anyone else seeing the same breakage? Second, anyone understand how udev knows if I do, or don't, have a real time clock on my machine? (BTW, I didn't even notice that /dev/rtc is missing for a week or two because the error messages zip by so fast, and nothing seems broken because of it, other than /sbin/hwclock whining quietly.)
