Re: [gentoo-user] Module and kernel woes after two "emerge -DuNe @world"s
TL;DR: It does seem that the kernel was holding things back to the point that things weren't working. :-( On 6/8/19 12:01 PM, Grant Taylor wrote: I'm having problems with newly compiled modules (zfs (et al.) and vbox (et al.)) and kernel after doing two "emerge -DuNe @world"s. I've managed to straighten things out. I'm now running a 4.14.120 kernel, with gcc 8.3.0, binutils 2.31.1-r6, and zfs 0.8.1. I got to a point that I could successfully do the following: emerge -DuNe @world --exclude sys-fs/zfs --exclude sys-fs/zfs-kmod --exclude sys-kernel/spl I had configured gcc and binutils to use 6.4.0 and 2.30-r4 respectively. At that point I upgraded from 4.9.76 to 4.9.177 successfully. Then I upgraded to 4.14.120 successfully. After I got to 4.14.120 successfully, I did another emerge … @world … (above command) just to make sure that everything is copacetic. Then I stepped up to gcc 8.3.0, rebuilt some test modules. After that I stepped binutils (and libs) up to 2.31.1-r6 and rebuilt some test modules. Everything seemed to work. All tests pass. All modules load and unload properly. So I did another emerge … @world … and everything seems to be completely stable. I'm guessing I don't need to do all the emerge … @world … but this system is idle and I can start it in the morning and it finishes recompiling just shy of 900 packages by the end of the day, including emerge --depclean && revdep-rebuild. So, I think that this system is now in a much better state than it was a week ago. The only thing I can think of is that the 4.9.76 kernel was far enough back and before all the Specter / Meltdown / Retpoline fiasco that things were no longer working like they should. This machine had been staying back at 4.9. because OvS didn't want to go above that at the time this system was last updated. Now OvS is happy with 4.14.. (That's why I didn't go to a newer kernel.) Thank you everybody for the suggestions and comments.
Re: [gentoo-user] UEFI kernel installation?
On 6/17/19 3:02 AM, Wols Lists wrote: Did you run VANILLA 2.4? (None of the distro kernels carried those particular changes, for obvious reasons :-) Yes. I would download source form kernel.org and compile it manually. You're making the classic logical mistake of "it's not true for me therefore it can't be true". It wasn't true for me either, but I lived through the news-storm and remember it ... So that's two data points where something wasn't true. Baring additional external data, that proves to my satisfaction that your previous statements weren't /always/ (as in absolute, 100%) the case. -- Grant. . . . unix || die
[gentoo-user] Allow only traffic from Whonix-Gateway
I need to allow only traffic from Whonix-Gateway virtual machine and drop the rest on the host. Only allowed traffic on the host are torified system upgrades. I use qemu-kvm for virtualization. ifconfig -a output: eth0: flags=4099 mtu 1500 ether 00:d8:61:44:3b:36 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 18 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 1000 (Local Loopback) RX packets 500 bytes 42572 (41.5 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 500 bytes 42572 (41.5 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 virbr0: flags=4099 mtu 1500 inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255 ether d6:89:5d:25:a7:35 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 virbr1: flags=4163 mtu 1500 inet 10.0.2.2 netmask 255.255.255.0 broadcast 10.0.2.255 ether ba:50:e8:19:d8:e0 txqueuelen 1000 (Ethernet) RX packets 7380 bytes 1662540 (1.5 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 10658 bytes 16217005 (15.4 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 virbr2: flags=4163 mtu 1500 ether 92:eb:60:36:5b:ec txqueuelen 1000 (Ethernet) RX packets 3 bytes 84 (84.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 120 bytes 5040 (4.9 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 virbr0-nic: flags=4098 mtu 1500 ether 52:54:00:2c:eb:d5 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 virbr1-nic: flags=4098 mtu 1500 ether 52:54:00:8b:c2:e1 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 virbr2-nic: flags=4098 mtu 1500 ether 52:54:00:98:1e:82 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vnet0: flags=4163 mtu 1500 inet6 fe80::fc54:ff:fe25:c4f1 prefixlen 64 scopeid 0x20 ether fe:54:00:25:c4:f1 txqueuelen 1000 (Ethernet) RX packets 7380 bytes 1765860 (1.6 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 12284 bytes 16302650 (15.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vnet1: flags=4163 mtu 1500 inet6 fe80::fc54:ff:fead:3e09 prefixlen 64 scopeid 0x20 ether fe:54:00:ad:3e:09 txqueuelen 1000 (Ethernet) RX packets 6827 bytes 14043836 (13.3 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 8503 bytes 578811 (565.2 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vnet2: flags=4163 mtu 1500 inet6 fe80::fc54:ff:fe85:d7de prefixlen 64 scopeid 0x20 ether fe:54:00:85:d7:de txqueuelen 1000 (Ethernet) RX packets 2086 bytes 195061 (190.4 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 3019 bytes 1392073 (1.3 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vnet3: flags=4163 mtu 1500 inet6 fe80::fc54:ff:fe26:2827 prefixlen 64 scopeid 0x20 ether fe:54:00:26:28:27 txqueuelen 1000 (Ethernet) RX packets 4214 bytes 235337 (229.8 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 4928 bytes 12406927 (11.8 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 wlan0: flags=4163 mtu 1500 inet 192.168.0.221 netmask 255.255.255.0 broadcast 192.168.0.255 inet6 fe80::bb8a:5532:d794:f463 prefixlen 64 scopeid 0x20 ether 48:a4:72:f3:37:c5 txqueuelen 1000 (Ethernet) RX packets 392071 bytes 549678001 (524.2 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 208071 bytes 23596361 (22.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 where virbr0 is default external network interface for virtual machines, virbr1 is whonix external network for gateway, virbr2 is whonix internal network Should I create tap interface to be able to allow only
Re: [gentoo-user] Emerge wants to downgrade icu
Le 16/06/19 à 10:22, Alarig Le Lay a tapoté : > Hi, sorry for the delay. > > On mer. 12 juin 12:31:31 2019, netfab wrote: > > Try --autounmask-backtrack=y emerge option. > > Thanks a lot, it worked. > But why portage bothers about icu so suddenly? > Now that =app-office/libreoffice-bin-6.2.4.2 has been stabilized on amd64, you can remove the --autounmask-backtrack=y emerge option from your command line, libreoffice-bin package will be updated with all its dependencies, including dev-libs/icu, and emerge will not find these conflicts anymore.
Re: [gentoo-user] UEFI kernel installation?
On Monday, 17 June 2019 04:37:13 BST Grant Taylor wrote: > My opinion is that the 2 x RAM no longer applies because systems don't > utilize swap space. As such it's a waste of disk space to dedicate 2 x > RAM to swap. I've also noticed usage of swap has become much more efficient over the years, even when running processes which by their nature chew up all the available RAM, like an emerge with a high -j number. However, if one is using the swap partition to hibernate a system, then it should be at least the amount of RAM, yes? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] UEFI kernel installation?
On 17/06/19 04:37, Grant Taylor wrote: > On 6/16/19 7:02 PM, Wols Lists wrote: >> So you didn't read what I wrote ... Par for the course :-( > > I did. I still hear people say it today. It's not old as in past tense. > >> The basic Unix mechanism needs twice ram. > > I disagree. > >> It's inherent in the design of the thing. Whether linux no longer uses >> the Unix mechanism, or it's had the hell optimised out of it I don't >> know. >> >> Either way, machines today get by on precious little swap - that's fine. >> >> Historic note - the early linux 2.4 vanilla kernels enforced the twice >> ram rule - a lot of people who didn't read the release notes got nasty >> shocks when their machines locked up the moment they touched swap ... > > I disagree because I ran 2.0, 2.2, 2.4, and 2.6 kernels without swap > being twice the ram or greater. Swap did get used. They did not crash > when accessing swap. > Did you run VANILLA 2.4? (None of the distro kernels carried those particular changes, for obvious reasons :-) You want proof? Look at the release notes for - I believe - 2.4.10? Or look at LWN in that time frame. It was quite big news at the time - people were upgrading to Linus' latest kernel and systems were falling over. You're making the classic logical mistake of "it's not true for me therefore it can't be true". It wasn't true for me either, but I lived through the news-storm and remember it ... Cheers, Wol
Re: [gentoo-user] UEFI kernel installation?
On 6/17/19 5:37 AM, Grant Taylor wrote: I doubt it. I've routinely done emerges on machines with < 16 GB of memory and 2 GB of swap.?? Including llvm, clang, gcc, rust, Firefox and Thunderbird. I routinely do an emerge -DuNe @world on a VPS with 1 GB of memory and 1 GB of swap.?? It works just fine.?? If I want to speed things up I enlarge the VPS to 2 GB of memory and 1 GB of swap.?? Granted, it doesn't try to compile things like Firefox and Thunderbird, thus Rust. Yes. I've run systems without swap and <=8GB of RAM for years and haven't had any problems with emerging packages (including rust, firefox, gcc...). If hibernate is not needed, and the system has enough RAM, there is little point in having swap at all. It all depends on the usage, so I don't think any (generic) guidelines make sense.
