sputnik

Well, it's a weird one. For a month or so I haven't been able to access any funtoo.org ip's, either from browser or ping, whatever. I was busy with other things and worked out pretty quickly that it was localized on my everyday user laptop and discovered it was related to iptables, by stopping them I could access funtoo.org just fine, so I just lived with that for awhile. Today I got serious about it and started removing lines from iptables one by one to find it. Luckily it was line 2 in INPUT, deleted that and funtoo.org is accessible. here is what it says: Chain INPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 2 195M 201G IP4BOGONS all -- !lo * 0.0.0.0/0 0.0.0.0/0 Which goes to: Chain IP4BOGONS (1 references) pkts bytes target prot opt in out source destination 883K 102M RETURN all -- * * 10.0.0.0/8 0.0.0.0/0 18 1008 RETURN all -- * * 172.16.0.0/12 0.0.0.0/0 55910 25M RETURN all -- * * 192.168.0.0/16 0.0.0.0/0 109K 25M DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set fullbogons-ipv4 src I have a cronjob that downloads a list several times a day from http://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt and adds them to an ipset list. It's a list of known "bogons", bogus ip addresses that are being used for...who knows, nothing good for me. As you can see anything that matches that list doesn't get in the door. So my next step was: ipset list fullbogons-ipv4|grep "172.97.103.36" Nope, no match. Then I went to http://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt and looked for 172.97.103.36 there. Nope, ain't there either. But still, for some reason it's apparently matching something somewhere on that list. I can't explain it, but there it is. Zero problems with any other ip's. I've solved this for now by putting in a RETURN above the drop for 172.97.103.36, but I wanted to make the devs aware of it. I've been using this iptables setup for a couple of years, this is the 1st time anything like this has happened. I see on the front page of the wiki that Drobbins has been migrating containers to that address, the timing matches this problem.

There was a similar question in Gentoo a while back, the fellow was going to be on board a ship with no network for 6 months. I can't find it now, but not important, j-g- has good ideas. Especially if you have a similar computer at home <whereever> that is on the network, you can just hand carry the flash drive back & forth with the package files. I have a machine here with all of portage on flash drive, an ancient computer with a tiny HD. Portage doesn't care where it's DIR's are. But if you have to chroot and use qemu then: Door #2, yes it will be a pain because it will take so long to build packages in qemu emulation mode. If that were the case I would update portage to reflect the latest packages and take the DISTFILES to the remote machine, let it find them in $DISTFILES and build them itself. Assuming your _home machine had the same packages installed, else you'd have to manually d/l them. It certainly won't be painless, but you can minimize the pain.

Aren't you missing a quote? Shouldn't Option "Xkbmodel "pc102" be Option "Xkbmodel" "pc102"?

Yes, I agree with you. I get lazy because android is so inherently insecure in so many ways, it seems almost hopeless. I'll have to sniff that out & shut it off too. I always seek out those programs that are the least intrusive, but I find ES File Explorer too handy. I used to use Xposed on my phone, but it was too wimpy (ancient), although I have a newer one now, only 4 years old :P . Maybe I'll go back to that.

Hmm, I do the same with screen as you describe with byobu all the time. Detach, relog in, screen -r, why there it is, still running away! Even multiple sessions. It cares not about the machine you are coming from, same user/same screens. But the more the merrier. I notice great polarization with these types of programs, tmux users aren't fond of screen and vice-versa. Whichever you like, that's the one for you! I also use dtach on my embedded devices for things that run 24/7, a much smaller memory footprint, although limited to one session. +1 on JuiceSSH for android, love it. ES File Explorer for android is also great, much better than any other file manager I've seen, including the one in Cyanogenmod, an FTP client too, so you don't need another client for that. More cool stuff than I know what to do with. SSH Server on android works well for me too. You can set it up to start in the background at boot, I have more ways to log into my androids than Uncle Sam...

The only thing that grabs me is you don't want NetworkManager and dhcpcd both. If you're using NetworkManager delete dhcpcd from rc. Otherwise more or less what I have, don't know about the busybox stuff, did you add that? I don't have it. Here's mine: # rc-update NetworkManager | default acpid | default alsasound | boot autofs | default bluetooth | default bootmisc | boot chronyd | default consolekit | default cups-browsed | default cupsd | default dbus | default devfs | sysinit device-mapper | boot distccd | default dmesg | sysinit fcron | default fsck | boot fuse | default gpm | default hddtemp | default hdparm | default hostname | boot hwclock | boot ip6tables | default ipset | default iptables | default keymaps | boot killprocs | shutdown kmod-static-nodes | sysinit lm_sensors | default local | default localmount | boot lvm | boot metalog | default microcode_ctl | boot modules | boot mount-ro | shutdown mtab | boot netif.lo | sysinit netmount | default nfs | default nfsmount | default openvpn.client | default postfix | default preload | default procfs | boot qemu-binfmt | default root | boot samba | default savecache | shutdown sshd | default swap | boot swapfiles | boot sysctl | boot sysfs | sysinit termencoding | boot tmpfiles.dev | sysinit tmpfiles.setup | boot udev | sysinit udev-mount | sysinit udev-postmount | boot default urandom | boot xdm | default

That's going to be the place, xorg.conf. Are you using fglrx? If so, I believe they (like Nvidia) have quite a comprehensive manual that comes down with the driver. And I don't mean man ati (or whatever), although that could be helpful too. In there will be lots of reading pleasure for you, with many possible additions to xorg.conf to solve this problem or that. I have nvidia, the manual is located in /usr/share/doc/nvidia-drivers-<version>. I have access to an AMD machine, but it's offline currently, but that may be a good place to look (/usr/share/doc). equery f ati-drivers will show it also. If you're using the open source drivers I don't know, but a quick web search should be helpful. Oh, and man xorg.conf may help too.

I run xfs here and hibernate just fine. I don't quite agree with threesixes about the fsck being immature, although I can understand how he gets that impression. It has it's own checking program, xfs_repair, to just check without modifying you run xfs_repair -n <partition>. But it's definitely less descriptive as to errors, or maybe they are just arcane to me. I've been running xfs for about 3 years now and no serious issues, however, it is touchy about things like abrupt power failures. But running the check facility immediately after seems to make them happy, again no issues here in 3 years. My last experience with btrfs was about that time, about 3 years ago, it was a wild adventure! But I don't know where it's at today. I think all of it really boils down to how fast do you need your disks to operate? Are they being accessed alot with the way you use your machine or not? Use huge files alot? If none of that seems to be you then even ext4 will probably suit you just fine. Yes, lvm supports snapshots too and you are already running it. And ZFS is quite popular around here, it has really outstanding snapshot capabilities. I believe the only thing you buy with pure64 setup is saving some disk space, but I've never seriously looked into it, as you say, skype and some others would be unhappy. Same with the Python 3 idea, only more so, there are many, many programs still using Python 2. There may be some headaches but I don't think you have a choice. That's a pretty speedy machine, you won't have any problem with virtualization, although you could certainly use more memory. I'm using a core 2 duo laptop here with 4G and I run virtualbox just fine. qemu is pretty slow though, hmm, I'll have to check that. Webkit & GTK are pretty intensive compiles but without more info we could only guess about that. j-g- has good suggestions, especially since you have no swap. You can of course, easily add swap without reinstalling.

I use iptables and AFAIK that's the way to do it, really on any distro. After all, you can immediately stop and start at will. Manually starting like that will give you immediate feedback if something's wrong, i.e. it will verbally complain and just not start usually. When testing new statements, just INSERT or APPEND them live, with iptables already running. You'll get instant feedback. After everything works you can do iptables-save to save the current rules in memory. Conversely you can do iptables-restore to dump any new changes. Yeah, but I dunno, sometimes it doesn't work all that logically, I like to back up the /var/lib/iptables/rules-save file just in case, I've got a lot of rules. :P Save and restore have messed me up more than once. The rules are written to /var/lib/iptables/rules-save, so if you are concerned about losing lots of previous work you can easily make copies of that file and replace it after changes. Or you can manually test/back-out the changes one by one. After you are happy with all rc-update add iptables default will auto-start the iptables on boot. I do know what you mean about the initial "hey, you gotta save some rules first" thing, frankly I forget how I got past that. I guess you could just create /var/lib/iptables/rules-save with something like this in it: -A INPUT -s 192.168.0.0/24 -j ACCEPT (or whatever your subnet address is) and go from there, just delete that later if you don't want it. Once you have some rules saved you won't see that again.

I don't use xen, so somebody who does might have a better answer. But you can easily edit the world file and add it, if that is the only issue.

I use this: $ cat screensaver_toggle #!/bin/bash #Mike Johnson #toggle the screensaver on/off #place icon in panel to indicate when off DPMS=$(xset -q|grep "DPMS is"|cut -d " " -f5) if [ $DPMS = "Enabled" ]; then lxpanelctl exit && lxpanel -p screensaver_off & xset -dpms xset s off S_STRING=" Screensaver Disabled" DISPLAY_COLOR="red" else lxpanelctl exit && lxpanel -p default & xset dpms xset s on S_STRING=" Screensaver Enabled" DISPLAY_COLOR="orange" fi # Clean up any running aosd_cat processes killall aosd_cat &> /dev/null # Display the desired text echo "$S_STRING" | aosd_cat -n "Georgia Italic 70" -u 1500 -o 300 -R $DISPLAY_COLOR -S black -f 300 -e 4 -p 3 -x 300 Along with a couple of other files, it places an icon in my panel I can click to return to screensaver enabled mode and prints large letters across the screen telling me the status using x11-libs/libaosd. But you don't need all that foo-foo, the xset statements do it all. The s directive turns on/off the screensaver (display of screen), the dpms (energy-star) turns the backlight on & off. I have it tied to a hotkey so I can control it all with a keystroke. The panel icon is a little more intricate, but if you want the large letters on the screen you just need to : USE="pango" emerge -av x11-libs/libaosd and use the above code (comment out the lxpanel lines).

I have a Toshiba TE2000, it's a P4, 15 years old and keeps on ticking, even the CDROM! I don't think you'll find this is much of an issue once you get over the initial install, it's not that horribly slow. I believe LXDE is a good choice, mine is openbox with lxpanel, etc., I think LXDE IS openbox if I remember correctly. The biggest help you can give it is to use ccache and DISTCC - if you have other machines to help. ccache irregardless of other machines. Lots of info about those at the wikis and forums. swamprabbit's suggestion is excellent too. There is also the tinderbox, the developer says it's not maintained anymore, but it seems to have recent activity: http://tinderbox.dev.gentoo.org/. Binary compiles of many packages. I've never used tinderbox, but I do use the binary browsers, they are a very time consuming compile. Also if you can spare a few bucks, mine was 1GB ram, I got 2GB on ebay for something like $12-13, new even. That helped it alot. It's likely you have a tiny HD, if need be it's easy to put /usr/portage on a usb stick. Or if you do have other machines you can just link to /usr/portage through NFS or samba, that's what I do here. Oh, 1 more thing you can do if you increase memory size. You can run /var/tmp/portage as a ramdisk, should be much faster than storing intermediary compiled programs on disk, reading them back, etc. (although I must confess lately I'm not so sure). To do this you make an entry like this in /etc/fstab: tmpfs /var/tmp/portage tmpfs size=2G 0 0 Don't worry about the 2G, it's smart and only uses what's available for the ramdisk. However, a handful of packages cannot fit into such a small size and you will have to make exceptions for them thusly: cat /etc/portage/package.env app-office/libreoffice notmpfs.conf app-text/poppler notmpfs.conf cat /etc/portage/env/notmpfs.conf PORTAGE_TMPDIR="/var/tmp/notmpfs" Then portage will use a "real" temporary directory for those packages. These are examples only, for example, you would almost surely want libreoffice-bin, the compiled version is the king of long compile times. You'll find out what needs to be added to package.env when it says "out of disk space" when it fails ;)

I really don't have a clue, like most package managers, there is bookkeeping stuff in /var/cache, but the easy way out may be to emerge -1 portage, since it's obviously out of kilter. Worth a shot. Oh and you might try revdep-rebuild, same philosophy. I have a Dockstar and a Pogoplug, I feel your pain.

I had to leave off the /boot: menuentry " memtest86+ 5.01" { linux16 /memtest86plus/memtest } I dunno, works Edit: Oh yeah, 'cause "/boot" is really small partition /dev/sda1. So in this case, before mounting, it's just /.

Good call threesixes. I would like to point out such a thing can be automated so you don't have to go thru the drugery with each new kernel. See this post: http://forums.funtoo.org/topic/243-set-grub-theme-via-etcbootconf/?do=findComment&comment=1214

I'm just guessing here, but I think it is due to trying to make a "generic" initramfs. Note that both 3.19 versions are working fine as you reported. I build a new initramfs for each kernel, I think I tried that in the beginning and found out what you are having trouble with. Also, there's this: boot # diff initramfs-funtoo-4.0.0 initramfs-funtoo-4.0.1 Binary files initramfs-funtoo-4.0.0 and initramfs-funtoo-4.0.1 differ boot # ls -l init* -rw------- 1 root root 8367938 Apr 28 18:58 initramfs-funtoo-4.0.0 -rw------- 1 root root 8366709 Apr 30 05:25 initramfs-funtoo-4.0.1 My initramfs' in the boot dir. Yet they were made in exactly the same way, no changes to dracut.conf, only the kernel referred to dracut changed. I believe there is more of a difference than just a "0" changed to a "1". Anyhow, easy to check.

Hmm, well you've got me there then. I specify the kernel line as I suggested and I'm running 4.0.1 just fine. Of course, the best way to not have those "crufty *.olds" not show up is to delete them before running boot-update, solves the problem and keeps things clean, but that's up to you. So it seems something is different about your 4.0.1, I agree, man boot.conf says you should be able to do it that way.

It's this line: kernel vmlinuz-4.0.1 vmlinuz-3.19.0 Instead, do this: kernel vmlinuz[-v] And it'll find all kernels of that type and name them with their versions.

Life is too short for ugly desktops! I'm with you Duncan, and I really love that cityscape you have in the desktops thread. 1st, I don't know of that which you ask. Although I'm sure there is an easy way to find the predominant color in your picture in Gimp or something I don't know that either. But it seems to me you can probably come close with just your eyeballs. I imagine you have looked over Gnome Look and those sorts of collections for themes. I use Emerald rather than GTK and it has the Emerald Theme Manager that allows you to set the colors, for one thing (many other options too). Although it appears to me that Emerald is a (now) forgotten step-child of GTK I'm not aware of any such thing for GTK. So I just find an Emerald theme at Gnome Look that's close enough then modify it. Your question peaked my interest and I did find something that may be interesting though: http://gnomecc.sourceforge.net/ Sounds like it may do what you want, sans the color picker. Much like the Emerald Theme Manager. I hope someone else can chime in with some better ideas. Edit: This will find your predominant color

The startup script thing is easy. In /etc/local.d I believe there is a little doc explaining, but you simply create a file called /etc/local.d/<whatever>.start. It's executed on startup as privileged user (chmod 744 <whatever>.start as root). Just put your echo instruction in there, it'll happen at every boot. Hmm, maybe have to make it a bash script, mine is but not sure that's necessary. Well, you can just paste this in, no need to understand code ;) #!/bin/bash echo 1 > /sys/block/sda/device/queue_depth

https://bugs.funtoo.org/browse/FL-2279

Hmm, kinda late, but I just wanted to point out that I did have the problem in hibernate mode and it's definitely hibernation, powered off. And yeah, the restart in the 77ethernet file does the trick. So I guess that code executes for suspend and hibernation? Hope I'm not misleading people here, it was ages ago I hunted that down.

Sorry guys, been busy, haven't been watching this. @Sandro: Not sure what you are showing, can you give more info? It looks like you are trying to do something with the plugins and fusion icon. They are not applicable at all to compiz anymore, only the old 0.8.8 which isn't even in the tree anymore. In fact, if you do eix compiz, virtually everything listed is utterly useless except for compiz itself. The configs, plugins, fusion, no longer used, all built into the one compiz package now. I hope that helps. Oleg said he fixed the problem you were having, so compiz should emerge fine now. I'll watch here now though, in case you have a problem. @threesixes: Well, same thing, I'm not quite sure what you mean by "icon method", unless you mean the old fusion icon. That was literally a bandaid because compiz 0.8.8 would crash, so they made that icon so that you could easily restart it. Hey, you can't make this stuff up, I ain't kiddin'. Compiz is my desktop manager here, two years, no crashes! So you see, not needed. If you mean you want to use it "occasionally" or something, easy enough. You start compiz at the command line (well, I do it in .xinitrc): compiz --replace And NOTHING else, in spite of old info you may see on the web, no longer true. So easy enough I think to make a little icon if that's what you want, maybe write the code to toggle between it and some other decorator?

Well that seems to be the magic. Just cleaned out my hosts file, commented out all those aliases in /etc/conf.d/hostname, reboot, and perfect. Indeed those warnings in the host were leftover from before, not there on this write. Hopefully we'll get a new bug feature to keep us entertained soon. Once again you've helped me so I didn't have to use my brain. Thank you.

That is interesting gnuisance. Sounds like we go back to the old methods? Perhaps I missed that last time I did dispatch-conf. It's still duping like crazy here, so I'm gonna try that. And yet it still says this in /etc/hosts: # # DO NOT EDIT THIS FILE BY HAND; YOUR CHANGES WILL BE OVERWRITTEN # # Define alias-to-address mappings in /etc/conf.d/hostname Maybe left over from before