Re: [gentoo-user] Boot and EFI partitions

[Victor Ivanov]

On Wed, 6 Dec 2023 at 17:35, Marco Rebhan  wrote:
> No, you do not need an XBOOTLDR partition with systemd-boot and in fact I have
> never used one, and I'm not sure why the guide advertises it so prominently.
>
Good to know! Then I'm not sure why the guide is advocating for one if
they're both FAT32. And, as I mentioned earlier, the Boot Loader
Specification doc does suggest that it's optional, so I would have
been surprised if any implementation would require the partition.

> There seems to be a lot of cargo cult around boot partitions (probably left
> over from the BIOS days), you really only need the ESP. The set up I have used
> for years is ESP at /boot, containing systemd-boot, kernel, initramfs and so
> on, and that's it (excluding of course / and other actual system partitions).
>
I disagree that it's _just_ BIOS days thing. While you can,
irrespective of boot loader, have all of your kernel and initrd images
dumped into ESP without any functional issues and do away with a
separate partition, there are benefits to the contrary. One such
benefit is journaling. Unless your EFI firmware allows for a non-FAT32
ESP, then storing the kernel and initrd images will need to be on a
separate partition.

While data corruption during write operations on this partition, given
its usage patterns, is perhaps highly improbable it's certainly not
impossible. So while the benefits of a journaling system for /boot may
be small, they can be a legitimate consideration.

In this line of reasoning, perhaps the boot loader guide(s),
particularly the one in the Handbook, are aimed at covering a
partition layout that:
a) is compatible between EFI and BIOS set ups (with difference being ESP);
b) is consistent across boot loader choices and compatible enough if
one should wish to switch from one to the other at a later point;
c) allows for cases where rootfs may not be readable by a boot loader
(e.g. encryption as previously mentioned); and
d) offers a degree of protection from corruption on writes;

while leaving the coverage various possible layout choices to those
that are more familiar with what they're doing. So some of it may be
baggage from BIOS days, I admin, I also would not be surprised if it
was a conscious decision to reduce the complexity of a first-time set
up by someone new to Gentoo. A 50+ page document, while exhaustive,
certainly wouldn't classify as a "handbook" or something to use as a
reference.

Regards,
Victor

Re: [gentoo-user] Boot and EFI partitions

[Victor Ivanov]

On Wed, 6 Dec 2023 at 15:32, Peter Humphreey  wrote:
>
> I want to use bootctl from systemd-boot, as usual, to give me a
> boot menu without that grub monster.
>
As a disclaimer, I do not and have not used systemd-boot specifically.
That said...

> In particular, the Gentoo wiki says I must have an EFI partition of type esp
> [1] - not a directory in, say, /boot, as my other machines have. All right so
> far, but the Gentoo systemd-boot page says I need a /boot partition as well,
> of type XBOOTLDR [2]. So now I seem to need /efi on /dev/nvme0n1p1 and /boot 
> on
> /dev/nvme0n1p2, both with FAT32 file systems.
>
This is indeed my understanding as well.

Irrespective of systemd-boot ESP is required for EFI bootloader
executables to be stored into. This is part of the GPT and UEFI
standard, so this should be of type ESP and formatted as FAT32, and is
usually the first partition on the boot drive when using GPT. Not
required for BIOS/Legacy boot, as the guide already mentions.

Moving on to "/boot", it has long been recommended (but not always
required) to have "/boot" as a separate partition. In practice, it
would often be the case (especially with GRUB) that "/boot" could
simply be a directory on your root partition. But sometimes, e.g. with
LVM and/or encrypted root, "/boot" has to be separated out so that the
kernel image could be read and booted by the boot loader before rootfs
could be unlocked. This could be any filesystem recognised by the boot
loader of choice.

So, a typical GPT set up, especially when having encrypted rootfs,
would look something like:

/dev/nvme0n1p1: ESP, GPT type 0xEF00, FAT32, usually mounted under
/efi (preferred) or /boot/efi (legacy)
/dev/nvme0n1p2: boot, GPT type 0x8300, ext3/ext4/etc, usually mounted
under /boot
/dev/nvme0n1p3: rootfs - GPT type 0x8308 if using LUKS, 0x8300 for
standard rootfs

So, without knowing much about systemd-boot from the guide linked it
seems to me that its implementation doesn't differ too much from this
reasonably well established model, except for a few additional
constraints which, based on my understanding, are:
1. You _must_ have an XBOOTLDR partition (functionally equivalent to
"boot" above) _in addition to_ the ESP and cannot simply use "/boot"
under your rootfs partition
2. XBOOTLDR partition _must_ be of GPT type 0xEA00
3. XBOOTLDR partition _must_ have GUID set to
"bc13c2ff-59e6-4262-a352-b275fd6f7172"
4. XBOOTLDR partition _must_ be formatted with a filesystem supported
by your EFI BIOS with FAT32 being universally supported, though your
particular EFI BIOS _might_ support others

I say "must" as it appears to be from the guide like this is the
requirement for systemd-boot, the actual Boot Loader Specification
page appears to suggest that an XBOOTLDR partition is optional. So
there may be a viable configuration without it.

Mount point recommendations seem consistent with previously
established conventions re EFI ESP and /boot.

Hope this helps. I'm happy to be corrected in case I misunderstood
anything specific to systemd-boot.

Best Regards,
Victor

Re: [gentoo-user] Re: How to move ext4 partition

[Victor Ivanov]

On Wed, 20 Sept 2023 at 23:58, Grant Edwards  wrote:
> Yep, that's pretty much what I decided on based on the tar command
> shown at
>
>https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Stage
>
> Interestingly, the Arch Linux Wiki recommends using bsdtar because
> "GNU tar with --xattrs will not preserve extended attributes".
I remember coming across this too as I've previously had issues
preserving some extended attributes, notably on files under my home
directory. However, I found that using "--xattrs-include='*.*'" in
addition to "--xattrs" works pretty well and does record attributes
that would otherwise be excluded with just "--xattrs".

I cannot comment, however, if it truly includes "everything" in every
possible scenario.

>
> Both the drive being "fixed" and the backup drive are in a USB3
> attached dual slot drive dock, so I'm thinking compression might be
> worthwhile.
>
Then LZO or zstd might indeed be a better approach as suggested by Frank.

> > Just make sure you update /etc/fstab and bootloader config file with
> > the new filesystem UUID or partition indices.
>
> I always forget one or the other until after I try to boot the first
> time.  That's why I keep systemrescuecd and Gentoo minimal install
> USB drives on hand.

Me too, even just recently when I migrated my OS to another build I
decided to do a few partition touch ups and fell once more into this
trap. I updated fstab but not the bootloader. Luckily, Gentoo minimal
install image is so tiny a bootable medium can literally be created in
minutes.

Good luck!

Regards,
V

Re: [gentoo-user] Re: How to move ext4 partition

[Victor Ivanov]

On Thu, 21 Sept 2023 at 02:01, Frank Steinmetzger  wrote:
> > $ tar -cpf /path/to/backup.tar --xattrs --xattrs-include='*.*' -C / .
>
> Does that stop at file system boundaries (because you tar up '/')? I think
> it must be, otherwise you wouldn’t use it that way.
No, it doesn't. It will archive everything recursively including
mounted directories, so fair point for raising this. It's something
that I do not normally consider, as I tend not to do full root backup
on the running system itself. But how cool is using bind mount for
this situation as you suggest? Simple and effective, I like it.

Actually, the presence of -C in the above example is purely out of
habit. I use it when pointing to a full path, e.g. "/path/to/dir" so
it doesn't end up creating the "path/to/dir" path prefix inside the
archive and only archives the contents of the path.

It's effectively changing to that directory and archiving everything
there, but saves you from doing the "cd".

Naturally, for "/" this is superfluous and "-C / ." can be replaced
with just "/".

> > Provided backup space isn't an issue, I wouldn't bother with
> > compression. It could be a lot quicker too depending on the size of
> > your root partition.
>
> Or not, depending on the speed of the backup device. ;-)
> LZO compression (or zstd with a low setting) has negligible CPU cost, but
> can lower the file size quite nicely, specially with large binaries or debug
> files.
>
That's true :) I had somehow forgotten of tar's support for LZO and
zstd as my default finger memory approach is to use -J for xz. Good
memory nudge here!

Regards,
V

Re: [gentoo-user] Re: How to move ext4 partition

[Victor Ivanov]

On Wed, 20 Sept 2023 at 22:29, Grant Edwards  wrote:
>
> That depends on how long it takes me to decide on tar vs. rsync and
> what the appropriate options are.

I've done this a number of times for various reasons over the last 1-2
years, most recently a few months ago due to hard drive swap, and I
find tar works just fine:

$ tar -cpf /path/to/backup.tar --xattrs --xattrs-include='*.*' -C / .

Likewise to extract, but make sure "--xattrs" is present

Provided backup space isn't an issue, I wouldn't bother with
compression. It could be a lot quicker too depending on the size of
your root partition.

> That said, I think I will go with the backup, repartition, restore
> method.
Sounds like a sound course of action to me, reinstalling is just too
much faff and can often be avoided. I have a long standing distrust of
partition management utilities that claim to move filesystem data too.
I'm sure they work just fine :)

Just make sure you update /etc/fstab and bootloader config file with
the new filesystem UUID or partition indices.

Regards,
V

Re: [gentoo-user] Migrate install from Intel 6th gen to AMD Zen 4

[Victor Ivanov]

Thank you both for the suggestions.

Generally speaking the process went very smooth. I decided not to
recompile all of @world a-priori and go for gold.

Initially it 'appeared' to have hung after 'Loading ramdisk' but this
ultimately turned out to be a frame buffer issue as the machine was,
in fact, booting.

I had installed 'sys-kernel/gentoo-kernel-bin' as a fallback option,
as Nikos suggested, and tried booting into it to investigate the
issue. Sadly, it wouldn't even go past 'Waiting for systemd-udevd',
although not freezing so not quite/yet a frame buffer issue with this
kernel. I gave up on it immediately and relied on my gut feeling that
my kernel should have, in fact, booted as expected (SSH to the
rescue).

There are still issues with 'amdgpu' and early frame buffer where it
continues to hang after loading the ramdisk, especially over
DisplayPort and having a separate nVidia dGPU, but I might post
separately re this if I can't figure it out. I suspect DRM issues and
module conflicts (I've explored the nvidia and amdgpu Getntoo Wiki
articles).

All in all this was a success and a _huge_ improvement over my
previous setup, pretty chuffed with the platform. My 'favourite'
package, QtWebEngine, now only takes 28 min to compile (with
+jumbo-build). I'm still to take it out for a spin with actual work,
but expect huge gains.


On 29/08/2023 11:58, Rich Freeman wrote:
> Well, you won't get segfaults so much as SIGILL, but I'd probably
> simplify a bit.

My bad, but at least the general point was conveyed :)

> As you can see I'm not even setting march. Maybe I could set it a
> little more aggressively and not risk any problems, but I'm concerned
> about the situation where I might have an unplanned CPU upgrade. My
> motherboard could die, and if it does I'd rather be able to just
> replace the motherboard+CPU and not have to fuss around with
> rebuilding my entire system from a rescue disk.

This seems sensible. I don't think there's going to be that big of an
improvement with exact -march, as you point out, except in HPC loads.
I could probably have set it "znver3" or "znver2" to cover a wider
range of CPUs. Then again, since I opted for AM5 and, more crucially,
DDR5 it's unlikely that I would be going to an earlier generation
unless all key components happen to fail at the same time. So fingers
crossed nothing fails any time soon.

> I do have CPU_FLAGS_X86 set, but it seems like most of these are used
> by less critical packages, and I'm not sure how much trouble getting
> these wrong would be.

CPU_FLAGS_X86 aren't that critical tbh as not all packages would
leverage these flags. And, realistically, I was expecting the new ones
to be a superset of the old ones which ultimately ended up being the
case. Unlikely that this would be an issue. Perhaps only for some
packages and if doing a backwards migration to an earlier generation
hardware.

> You say you're "thinking about upgrading" so it sounds like you aren't
> in a hurry and odds are you don't have the new hardware looking at you
> and begging you to boot it up.

Not at the time of writing, but parcels did start arriving quite speedily :)

Cheers,
- V

[gentoo-user] Migrate install from Intel 6th gen to AMD Zen 4

[Victor Ivanov]

Hello,

I will soon be upgrading from a mobile Skylake platform to a desktop
Ryzen 7000 series and a full re-install is not an option unless all
else fails. I'm thinking of simply moving the drive and recompile as
necessary. I don't see why this wouldn't work, but wanted to double
check with the community just in case.

My existing make.conf has:

COMMON_FLAGS="-march=skylake -O2 -pipe"
CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt sse
sse2 sse3 sse4_1 sse4_2 ssse3"

My current strategy is:
00) Recompile kernel to support AMD CPU (already done)
01) Upgrade @world to avoid later dependency problems (already done)
1) Replace "-march=skylake" with "x86_64[-v1|v2|v3|v4]" or just "generic"
2) Run "emerge -1aqv @system"
3) Move drive to new system and boot
4) Update to "-march=znver4"
5) Update CPU_FLAGS_X86 with output of "$ cpuid2cpuflags"
6) Run "emerge -1aqv @system"
7) Reboot (optional, just in case)
8) Run "emerge -1aqv --emptytree --keep-going @world"
9) Fingers crossed it all goes well

Am I missing anything critical that could break step (8) or any
packages I should include in step (2) in addition to @system to avoid
likelihood of segfaults?

Best Regards,
- V

Re: [gentoo-user] KWallet refuses to auto open at login

[Victor Ivanov]

On Mon, 12 Jun 2023 at 09:33, Michael  wrote:
>
> You could try making gnome keyring wait until a login session is up an running
> and only run if an application asks for it.  Take a look in /etc/pam.d/sddm
> (or perhaps /etc/pam.d/sddm-autologin?) then add an 'only_if' conditional
> statement at the end, e.g.:
>
> -session optional pam_gnome_keyring.so only_if=gdm,sddm,xdm, here>
>
> This means whenever an application requires gnome keyring it will ask you for
> your passwd, instead of auto-unlocking it at the start of the desktop login
> session.  However, this may or may not fix your problem, because as you point
> out the other host is working normally without this tweak.
>
Interesting suggestion, thanks! I tried this, as well as adding force_run to
"-session  optional  pam_kwallet5.so auto_start"
neither option worked.

> out the other host is working normally without this tweak. I wonder ... is
> the other host running on (much) slower hardware?
>
Yes and no. They're both Skylake machines with mobile CPUs, only
difference is the one it's not working on is a quad-core i7 HQ series
and the other (where it's working) is a dual-core i7 U-series low
voltage.

On the other hand, I decided to F it, and move back to Xorg. It all
works fine on Xorg after the usual wipe of KDE-related stuff in
~/.config, ~/.local, and ~/.cache. Trying a Wayland session _after_
the fact, is still broken. Yet, I can't see anything in the logs to
suggest why this might be the case.

This, on top of Night Colour also not work well (gets stuck in
whatever state it was in if the display goes to sleep) tells me
Wayland is _still_ not ready for day to day use. Which is a shame,
because it's _this_ close, but annoyances like the above are just not
worth the hassle (yet).

Ironically, the timing of my post is near perfect with that of the
other thread re Wayland issues.

Best Regards,
Victor

Re: [gentoo-user] KWallet refuses to auto open at login

[Victor Ivanov]

On Mon, 12 Jun 2023 at 06:53, Bryan Gardiner  wrote:
> Are you testing with LightDM and SDDM logins where you type your
> password manually, rather than relying on autologin, or fingerprint
> readers, etc.?  If memory serves me, something needs to pass down the
> password to kwallet, so with autologin, it can't unlock the wallet.
> (At least, not without extra help, I see the Arch wiki mentions
> pam_autologin for this but I haven't used it: [1])
>
Yes, I never use auto login. It's password based SDDM set up.

Configs are in line with suggestions in Gentoo Wiki. I too consulted
the Arch Wiki but most of it overlaps (as one might expect). To be
honest, these days the kde-plasma/kwallet-pam package comes with the
correct config by default and I've not had to touch it manually.

Re: [gentoo-user] KWallet refuses to auto open at login

[Victor Ivanov]

On Sun, 11 Jun 2023 at 14:22, Neil Bothwick  wrote:
>
> Anything in the logs? Maybe someting to indicate whether PAM is trying to
> open the wallet and failing, or whether it is not trying at all.
>
Thanks, Neil, good point. Not that I can tell. /var/log/auth.log looks
identical on both systems after cold boot login. Here's an example
(same on both hosts):

---
Jun 11 23:13:04 somehost sddm-helper: pam_unix(sddm-greeter:session):
session opened for user sddm(uid=) by (uid=0)
Jun 11 23:13:06 somehost start-stop-daemon:
pam_unix(start-stop-daemon:session): session opened for user
pcscd(uid=(uid=) by (uid=0)
Jun 11 23:13:15 somehost sddm-helper: gkr-pam: unable to locate daemon
control file
Jun 11 23:13:15 somehost sddm-helper: gkr-pam: stashed password to try
later in open session
Jun 11 23:13:15 somehost sddm-helper: pam_kwallet5(sddm:auth):
pam_kwallet5: pam_sm_authenticate
Jun 11 23:13:15 somehost sddm-helper: pam_kwallet5(sddm:setcred):
pam_kwallet5: pam_sm_setcred
Jun 11 23:13:15 somehost sddm-helper: pam_unix(sddm:session): session
opened for user *(uid=*) by (uid=0)
Jun 11 23:13:15 somehost sddm-helper: gkr-pam: gnome-keyring-daemon
started properly and unlocked keyring
Jun 11 23:13:15 somehost sddm-helper: pam_kwallet5(sddm:session):
pam_kwallet5: pam_sm_open_session
Jun 11 23:13:15 somehost sddm-helper: pam_kwallet5(sddm:setcred):
pam_kwallet5: pam_sm_setcred
Jun 11 23:13:17 somehost gnome-keyring-daemon[5636]: discover_other_daemon: 1
Jun 11 23:13:17 somehost polkitd[3881]: Registered Authentication
Agent for unix-session:2 (system bus name :1.48
[/usr/lib64/libexec/polkit-kde-authentication-agent-1], object path
/org/kde/PolicyKit1/AuthenticationAgent, locale en_GB.utf8)
---

So it would appear "pam_kwalletd5" is loaded and initialised. There
are no errors It makes me wonder if gnome keyring is to blame and if
there's some sort of a race condition. On the other hand, there is the
message "discover_other_daemon: 1". Besides, if it were a race I would
expect KWallet to work at least some of the time on either system,
while the issue is always reproducible on one host and never on the
other.

Other logs such as "/var/log/sddm.log" and
"$HOME/.local/share/sddm/wayland-session.log" also look similar on
both hosts without anything related to KWallet.

I've also one-shot "eix -I# sddm" (SDDM owns sddm-helper) with
--noconfmem. Still no luck. Use flags are more or less identical on
both hosts as well.

Something is tricksing me badly and I'm one step from emerging @world
with --noconfmem and --empytree to see if that helps.

Re: [gentoo-user] KWallet refuses to auto open at login

[Victor Ivanov]

On Sat, 10 Jun 2023 at 12:58, Andrew Udvare  wrote:
>
> Does a new user account work the way it is supposed to?
>
Unfortunately, no. New accounts also get the same broken behaviour.

[gentoo-user] KWallet refuses to auto open at login

[Victor Ivanov]

Hello fellow penguins,

I have to admit I'm at my wits' end with KWallet. This thing has been
driving me insane for the last couple of weeks, roughly since the
upgrade to Plasma 5.27 or shortly after.

Every time I log in, it refuses to automatically open and prompts for
a password whenever an application wants to read secrets. Admittedly,
this is under Wayland which, following from recent news re this being
the Gentoo preference, I decided to give a try. But this also happens
under X11, so I doubt it's got anything to do with Wayland.

I've tried everything I can think of:
- I've double checked the auto unlock guide in the Gentoo Wiki, made
sure PAM rules are in place and kwallet-pam is installed. Which should
be all good regardless, as it used to work just fine;
- I've also oneshot all of: kde-plasma/ , kde-frameworks/ , kde-apps/
, and anything returned by "eix -I# pam", "eix -I# xdg", and "eix -I#
dbus"
- when the above failed to yield any meaningful resolution, I repeated
the one-shot step this time with "--noconfmem" and re-reviewed any
changes from the default configs;
- finally, I nuked all of my $HOME settings under ~/.config, ~/.cache,
and ~/.local and started from scratch;
- and yes, the KWallet was set up and re-setup (plenty of times) with
Blowfish with the same password as my login;

The irony is, I have an equivalent Gentoo setup on a separate machine,
also moved to Wayland at the same time as I keep them both up to date
at the same intervals, and it works flawlessly. I've recursively
diff'd all config files under /etc between the two hosts and, other
than some minor, unrelated host-specific differences, everything is
identical, including configs under /etc/pam.d.

I can get it to kind of work with a blank password, but that's not the
point and is not a viable "solution". Even then, it still doesn't auto
open, but at least it doesn't produce annoying prompts to open.

I've always despised KWallet for its flaky behaviour but for the last
few years it hadn't given me any issues up until now.

I'm truly bewildered. Is there anything I am missing?

Best Regards,
Victor

Re: [gentoo-user] Question about runlevels.

[Victor Ivanov]

On 18/03/2021 18:36, Grant Taylor wrote:
Do services started in the "boot" runlevel continue to run in the 
"default" runlevel?



Yes

Or do they get stopped as part of transitioning from the "boot" runlevel 
to the "default" runlevel?  (Or any other runlevel that doesn't include 
the service.


Generally yes, when changing from one runlevel to another OpenRC will 
stop all services from the previous (current) runlevel and start the 
services for the next (new) runlevel.


However, my understanding is that the `boot' and `sysinit' runlevels are 
"special" and services started there are also included in all 
"non-special" runlevels.


In your case, `myService-boot' should remain active in `default' along 
with `myService-default'. You can double check that by running


 $ rc-status


I'm wondering about having two things that are very similar (as in use 
the same ports), but distinctly different (different configurations) 
with the following:



...
My expectation is that OpenRC will (try to) start myService-default when 
the system enters the default runlevel.  But it will fail if 
myService-boot is still running.


It's difficult to say without understanding what they do and their end 
goal. It also depends on how the services are coded. If they try to bind 
to the same port then yes, chances are that `myService-default' will 
fail at this point as the former would still be running.


If that's the case, one option is to separate their responsibilities 
and/or make `myService-default' depend on `myService-boot' and have it 
leverage whatever it is that `myService-boot' already provides.


- V

Re: [gentoo-user] Re: Odd Chrome behavior when dragging tab to create new window

[Victor Ivanov]

On 12/03/2021 16:48, Grant Edwards wrote:

On 2021-03-12, Spackman, Chris  wrote:

On 2021/03/12 at 02:57pm, Grant Edwards wrote:


When I drag a tab out of it's parent window to create a new window
[...] instead of staying where it's put the new window will follow
the mouse cursor around the desktop anytime Chrom(e|ium) has focus.

[...]
any keypress will cause the weird behavior to stop.


I have the same problem. Started recently. Right clicking on the tab
and choosing "Move tab to new window" (if there is only one window)
or "Move tab to another window" => "New window" (if there is already
more than one window) works without problem.


Yep, same here.


I've no idea what is causing the problem. Fluxbox is my window
manager.


I'm using openbox.

KDE here. I don't use Chrome so I only just fired it up (completely 
clean "install") and have the same behaviour.


As to what's causing it I can only guess but I did notice that when I 
try to move a tab - even on a single tab window - my mouse pointer jumps 
to the title bar area above it which presumably causes the window 
manager to pick up the "click & hold" gesture and leads to the whole 
window moving about.


However, this only seems to be happening when using the "System titlebar 
and borders". If you right click on the tab area (not on the tab itself) 
and untick said option the issue will disappear. At least it does on my 
machine and I can move tabs about as normal.


- Victor




OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-user] Re: python3 question

[Victor Ivanov]

On 13/01/2021 20:06, n952162 wrote:

What encoding is your editor using?


vi?  How would I determine that?  My locale is C



You could use:

  :set fenc

to display the current encoding used for the file, or

  :set fenc=utf8

to force UTF-8 or any other encoding of your chosing. You can also add a 
magic line with fenc to the file to always ensure that the specified 
encoding is used, assuming you also have magic lines enabled in vimrc.


- Victor



OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-user] Recommended location of the Gentoo ebuild repository

[Victor Ivanov]

On 16/12/2020 14:55, Rich Freeman wrote:

Now, where exactly in /var it goes is more a matter of debate.
/var/db is not specified in FHS, but it is used by FreeBSD which I
think was one of the selling points.  Personally I stick it in
/var/cache as (IMO) it just contains a local copy of a repository that
is entirely stored elsewhere.  Some would certainly disagree with
that.  I think /var/lib would be an alternative place that keeps more
to FHS.


This is very interesting, thanks for sharing! I was wondering what the 
rationale was behind /var/db but it comes as no surprise that it may 
have something to do with FreeBSD and Gentoo's overall ties/inspiration 
from FreeBSD. Personally, I too agree that /var/cache might be a better 
approach and is commonly used by other distros to store their repos' 
cache (e.g. Debian and derivatives).


Whether it's ultimately the "right" place, I don't know but to me it 
seems one of Linux' larger issues is the general lack of consistency 
between distros. This is a whole other debate of course. And while often 
inconsistencies may stem from otherwise perfectly sound decisions, I 
think such aspects - in their cumulative form - contribute to the 
hindering of wider adoption of Linux outside the tech community.



However, moving it out of /usr was a move with near-universal support.
And you can really put it anywhere you want by editing one line in
your portage config.  I don't think the directory even exists in the
base install - it gets created the first time you sync so it is
entirely user-configurable.


I completely agree with this, I was extremely happy when I read the news 
a while back as it makes far more sense. In fact, prior to the move I 
had been wondering with friends why the repo cache was under /usr.




OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-user] [SOLVED] fsck.fat 4.1 - File system couldn't be fixed [SOLVED]

[Victor Ivanov]

On 13/12/2020 14:17, Michael wrote:

Pre-UEFI /boot on a single partition/filesystem used to be formatted as ext2,
primarily because /boot is a small fs in size, is written to only occasionally
and unless it happened to crash while writing to it not much benefit would be
had by adding the journal of ext3/ext4, while adding a fs overhead for the
journal and making write operations last longer.
...
So, for Linux on conventional installations (Legacy BIOS + separate /boot fs +
spinning disk setups) ext2 is a valid fs choice.  When /boot is part of the /
block device, then the fs type for /boot would necessarily be whatever is
chosen for the / partition, as long as the boot manager has the corresponding
driver to be able to load it.


Well, I don't dispute the validity of ext2 as a choice. Or any other 
filesystem that the bootloader can read really - that's a perfectly 
valid statement.


I was merely 'going further' as a suggestion purely in the sense that in 
this day and age there's hardly any reason to not be using a journaled 
filesystem even for /boot.


As you say, /boot is written to rarely so the overhead of a journal is 
negligible and for all intents and purposes can be ignored completely. 
Disk space itself these days is really not a concern at all (unless on a 
really really archaic machine) - let alone for a small boot partition - 
so that too can be ignored as a contributing factor. Data integrity, on 
the other hand, is far more critical. I have had ext2 fail on me during 
a system crash when updating a kernel back in the days a number of 
times, so I personally did away with ext2 as a /boot filesystem about 
15y ago. Not surprisingly most distros will default to ext3/4 for /boot 
as well. But ultimately, we are free to decide ourselves.



Unfortunately, sometimes guides put the EFI partition mount point to be
a directory within the /boot directory (e.g. /boot/efi) which itself can
be the mount point for the boot partition. This can lead to people
formatting both as vfat or indeed using the EFI partition itself in lieu
of a separate /boot partition. I am not suggesting this is what happened
in your case, but I have seen it happen.


If /boot/efi is a directory (it should be according to the UEFI spec) then as
far as I know directories cannot be formatted with a fs.


Well.. naturally, this isn't what I meant :)

But you can have your boot fs (e.g. vfat/ext[2/3/4]) mounted under 
"/boot" and your EFS partition (vfat) mounted under "/boot/efi". The 
actual EFI directory that you speak of would then be under 
"/boot/efi/EFI". I used this as an example but, naturally, one can use 
any mount point that suits and it doesn't have to be under /boot.


For the sake of the example, perhaps a better choice of naming would 
have been "/boot/efs".


> NOTE:  The UEFI firmware can boot natively linux kernel images without
> chainloading some 3rd party Boot Manager's .EFI executable like GRUB, 
rEFInd,
> syslinux, etc., as long as the EFI stub support has been enabled in 
the linux
> kernel and 'root=PARTUUID=...' has been added in the built-in kernel 
command

> line entry.

Absolutely! I actually love this aspect about UEFI. It's a brilliant 
idea, but for some reason I always found it somewhat fiddly. Perhaps the 
lack of being able to alter the kernel command line prior to booting has 
put me off. Though I have to admit, I too am susceptible to "old habits 
die hard" and have always stuck to chainloading GRUB and never really 
thought much about it :)


> Gentoo is thankfully flexible enough to allow you to make your own 
choices on
> configuring your system.  Whatever works for you best is a valid 
choice to

> make.:-)

This! When people ask why I go through all the pain of using Gentoo and 
literally seeing myself getting older in the mirror while waiting for 
packages to compile (or portage to finish resolving dependencies) I 
always give this as my first argument - you can do whatever you want 
with this distro, it's that flexible... And we all love Gentoo for it




OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-user] [SOLVED] fsck.fat 4.1 - File system couldn't be fixed [SOLVED]

[Victor Ivanov]

On 13/12/2020 07:42, the...@sys-concept.com wrote:

I was following the Gentoo handbook, maybe I didn't read it correctly
and/or miss the information on alternative setting.  I didn't see any
explanation that I need to have support for "fsck.fat".
I better stay away from any "vfat" format on boot partition, and I don't
see a reason to have initramfs (another complexity).

No worries at all, despite my using Gentoo for the better part of a 
decade I too sometimes do something silly without realising. And you're 
right that this part of the guidebook could be improved to make some 
clarifications.


In any case, I've looked at the fstab on one of my machines and I do 
have dump/pass set to "0 2" for the EFI partition (which is of course 
vfat). I changed that to "1 2" to match your previous setup, though I 
was sceptical if that would make any difference. I created a /forcefsck 
file and managed to reboot just fine which suggests that either:


1) my ramdisk has fsck.fat bundled; or
2) was able to use the binary from the root partition after it was 
mounted read-only


[I could check explicitly, but I'm feeling a bit lazy]

Out of curiosity, do you have the "sys-fs/dosfstools" package installed?

This is the package that provides the fsck.fat binary. It's not a 
dependency of commonly installed system packages so unless you install 
it manually it's probably missing which might explain why fsck is 
exiting with an error code.


- Victor



OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-user] [SOLVED] fsck.fat 4.1 - File system couldn't be fixed [SOLVED]

[Victor Ivanov]

On 13/12/2020 03:07, the...@sys-concept.com wrote:

if you have UEFI system most likely your "boot" partition is some form
of "vfat"


I strongly disagree with this statement. Most Linux distributions, 
including Gentoo, advise (or outright default to) having your /boot 
partition either separate, or having /boot as part of your root 
filesystem. And this is very sensible indeed.


Personally, I would even go further by saying that /boot should be 
journaled (e.g. ext4). Most distros do that by default.


A UEFI set-up only requires the EFI system partition to be vfat. It does 
not require the kernel or the ramdisk to be on it. GRUB2 can be 
configured to install only its own EFI-related files on the EFI system 
partition, then reading the kernel and the grub config file from your 
/boot partition:


  # grub-install --efi-directory=/path/to/efi 
--boot-directory=/boot/efi /dev/[nvme...|sd...]


You do not need CSM enabled for this.

Unfortunately, sometimes guides put the EFI partition mount point to be 
a directory within the /boot directory (e.g. /boot/efi) which itself can 
be the mount point for the boot partition. This can lead to people 
formatting both as vfat or indeed using the EFI partition itself in lieu 
of a separate /boot partition. I am not suggesting this is what happened 
in your case, but I have seen it happen.


Now if you use a different boot loader (e.g. rEFInd) it is up to that 
bootloader to have relevant support for the filesystem that your /boot 
partition is using.


> fsck.fat 4.1 (2017-01-24) open: no such file or directory
>
> There is a similar related bug filed about it (but I don't know why is
> it marked resolved)
> https://bugs.gentoo.org/306119

I don't think this issue is related wrt the root cause. But 
force-checking for filesystem errors certainly revealed the issue for 
your case: you don't have the fsck.fat binary in your initramfs. As a 
result, the filesystem checking process fails, the boot process is 
interrupted prematurely, and you're dropped into a shell to investigate. 
This is normal behaviour when an error occurs before the boot process 
switches to the real root.


One option is to disable filesystem checking for vfat - like you did, 
another is to make sure that the mkfs.fat binary is included in the 
ramdisk image. I am not sure how the latter would be best achieved with 
genkernel, perhaps others can advise on this.


- Victor

Re: [gentoo-user] Determine what's keeping Python 3.7 around?

[Victor Ivanov]

On 07/12/2020 00:30, Neil Bothwick wrote:

On Sun, 6 Dec 2020 22:04:53 +, Victor Ivanov wrote:


My understanding was that "equery d" gives you a list from portage,
not caring about what is currently installed, where "emerge -pvc"
will tell you what is preventing the removal of the package.


Not so based on my understanding (i.e. the man page). As far as I can
tell 'equery d' ought to only look at the installed packages unless the
'--all-packages' flag is passed. Not unlike other operations (e.g.
'equery list') which also look by default only at installed packages.


But does it take into account the USE flags with which those packages
were installed? That used to not be the case, but I haven't used equery
for a long time, for just that reason.

Fair point, `equery u ` shows both the default USE flags as well 
as those with which the package is installed. The latter can be stale if 
USE flags have been tampered with and the package has not yet been 
rebuilt with the new set of USE flags but otherwise it should match the 
state. So I always assumed that this is the case for all operations as 
it would make sense.


In any case, virtually all of equery functionality re installed packages 
would be rather useless if it didn't take into account the configured 
USE flags of said packages. The man page could also do with some more 
love as it's not particularly clear.




OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-user] Determine what's keeping Python 3.7 around?

[Victor Ivanov]

On 06/12/2020 21:55, Jack wrote:
My understanding was that "equery d" gives you a list from portage, not 
caring about what is currently installed, where "emerge -pvc" will tell 
you what is preventing the removal of the package.


Not so based on my understanding (i.e. the man page). As far as I can 
tell 'equery d' ought to only look at the installed packages unless the 
'--all-packages' flag is passed. Not unlike other operations (e.g. 
'equery list') which also look by default only at installed packages.




OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-user] Determine what's keeping Python 3.7 around?

[Victor Ivanov]

I'm on the same boat as Grant and, despite being fully up to date, have 
found it incredibly infuriating to not be able to figure out why I have 
so many python interpreters installed. I don't mind the consumed space, 
but I get the itch from not knowing *why*.


On 06/12/2020 20:16, Neil Bothwick wrote:

emerge -cpv python:3.7 will show you what is keeping 3.7.


Thank you Neil for this amazing hack! This has truly been great at 
solving the mystery.


Using this I finally found out that on my system the only thing keeping 
Python 3.7 was:


app-office/libreoffice-bin-6.4.6.2-r2 requires dev-lang/python:3.7[xml]

On that note, I feel like I should share my sentiment on what I had 
tried before to solve this conundrum:


$ eix --installed-with-use python_targets_python3_7
$ eix --installed-with-use python_single_target_python7_7

but obviously the above only work for ebuilds that explicitly have the 
respective PYTHON_TARGETS and PYTHON_SINGLE_TARGET variables and will 
not include hard dependencies - this is to be expected.


More shockingly however, I was surprised that equery did not reveal 
_anything_ useful at all e.g.


$ equery depends python:3.7
$ equery depends '=dev-lang/python:3.7'
$ eix --installed-depend python:3.7

eix above was also useless as it provided a very different output to 
that of `emerge -cpv'.  I thought the whole purpose of 'equery depends 
' was to do exactly that - list any packages that depend on the 
given atom. Or am I completely misunderstanding how the above 3 work?!


- Victor



OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-user] update fails, but I don't see why

[Victor Ivanov]

On 05/12/2020 10:13, Dale wrote:

that as, I learned the hard way.  Once you get Gentoo installed and all
the packages you want installed completed, it is wise to add the
--oneshot option to the defaults in make.conf.  That helps keep the
world file clean since you won't have packages in the world file that
shouldn't be there.  If later you want to add a package to the world
file, you have to specify that you want it added.  If it is already
installed, you can do a emerge -n --select y  and it adds
it to the world file.  It will then be maintained automatically.


Excellent pro-tip for keeping your world file clean! While I personally 
use the reverse of this (i.e. I manually add -1 to things I do not want 
to end up in my world file) this is a lot more of a sane approach for 
the every day person or those new to Gentoo.


On a side note, '--select y' is not necessary as it is implied by '-n'.

One thing I would add as well is that regular 'world' cleaning is good 
practice to have regardless of the above. Every couple of months (on 
average, I don't really keep track) I tend to look at my world file and 
take note of entries that may have found their way there either 
automatically (lack of -1) or something I used to use and no longer 
need. These can be cleaned up with --deselect, followed by --depclean e.g.:


# emerge --deselect ATOM [ATOM...]
# emerge -a --depclean

Last time round I only deselected 2-3 packages but that removed about 30 
or so unnecessary dependencies, so pretty chuffed. Disk space is cheap 
these days and there's little reason to be so pedantic, but I tend to 
get quite a satisfying feeling when my system becomes 'leaner' so I do 
it anyway. Having fewer packages installed also helps speed up portage's 
dependency resolution stage during updates which is already an 
incredibly slow process (depending on CPU's single thread performance ofc).


- Victor



OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-user] update fails, but I don't see why

[Victor Ivanov]

On 03/12/2020 21:06, tastytea wrote:

Python 3.8 is the new default target and not all packages support it
yet. You can put
   */* PYTHON_TARGETS: python3_7
into /etc/portage/package.use as a workaround. Don't forget to remove
it in a month or so.


I'm on the same boat. It's indeed because of Python 3.8 being the new 
default.


I seriously doubt it's because of packages being fundamentally 
incompatible, I reckon it's just another slightly premature rollout of 
the newer interpreter without all relevant ebuilds having been updated 
correctly. Not unlike what we experienced with the previous large scale 
rollout after the deprecation of Python 2 when for a few days, without 
manual intervention, many packages were complaining.


The above should work, but also I suspect simply waiting for a few days 
should resolve the issue as maintainers take notice and update the ebuilds.


- Victor



OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-user] Configure sshd to listen on specific interfaces?

[Victor Ivanov]

On 27/08/2020 14:40, Grant Edwards wrote:
> I do _not_ want it to listen on 0.0.0.0.
>
> I want it to listen on 127.0.0.1 and on whatever IP addresses are
> assigned to two specified interfaces.

As far as I'm aware, I don't think OpenSSH allows for listening on a
specific interface.

You can, however, work around this in a rather unusual way via
ip/nftables and DNAT.

You will need to enable IP[v6] forwarding via sysctl (or sysctl.conf):

net.ipv4.ip_forward=1
net.ipv4.conf..route_localnet=1

The latter option is critical as, by default, the kernel will not allow
you to route to 127.0.0.0/8 as a security precaution.


iptables


(1) iptables -t nat -A PREROUTING -i  -p tcp --dport 22 -j DNAT
--to-destination 127.0.0.1:22
[2] ip6tables -t nat -A PREROUTING -i  -p tcp --dport 22 -j DNAT
--to-destination [::1]:22


nftables (json-like)


table inet nat {
  chain prerouting {
type nat hook prerouting priority dstnat; policy accept;
iif "" tcp dport 22 dnat ip to 127.0.0.1:22
iif "" tcp dport 22 dnat ip6 to [::1]:22
  }
}


nftables (cmdline)
==

[1] nft add table inet nat
[2] nft add chain inet nat prerouting { type nat hook prerouting
priority dsnat\; }
(3) nft add rule inet nat prerouting iif  tcp dport 22 dnat ip to
127.0.0.1:22
[4] nft add rule inet nat prerouting iif  tcp dport 22 dnat ip6
to [::1]:22

As always, 1-2 are not required if you already have a relevant table/chain.

Adjust as needed for multiple IFACEs.

- V



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?

[Victor Ivanov]

On 27/08/2020 02:31, Grant Taylor wrote:
>     - SRS (mail-filter/libsrs2) []
>    - emerge -a mail-filter/libsrs2
> 
I have been quietly following this discussion and I've seen SRS being
mentioned a number of times.

Now, I know what SRS _does_ (perhaps not fully?) to prevent unintended
rejection by a receiving MTA due to SPF policy and I know it's highly
recommended if not mandatory for any sensible MTA set-up (allegedly).

However, I'm less aware of the actual use cases where it is absolutely
necessary to prevent above issues with SPF. Is SRS only relevant for
MTAs that do any sort of forwarding/open relay?

Oddly enough, I find some of the explanations I came across (including
Wikipedia) fairly atrocious compared to SPF, DKIM, and DMARC which are
perfectly explained and their use-cases are very clear. Though frankly,
these three are fairly self explanatory themselves for anyone with
technical background.

I have been running my own MTA for just under a decade without SRS (but
with the rest of the above) and never had issues with delivery - be that
local or remote. However, I have explicitly disabled open relay and do
not make use of any forwarding maps.

It makes me wonder - am I missing something and have I just been lucky?

- V



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Thunderbird 78

[Victor Ivanov]

On 21/08/2020 15:36, Jack wrote:
> On 8/21/20 8:28 AM, Victor Ivanov wrote:
> I seem to be slow on the pickup with parts of this thread, but I'm not
> sure exactly what you are looking for here.  I assume you did find how
> Balsa handles encryption for sending and receiving mail. If you are
> talking about encrypting the local storage of all or selected messages,
> I agree it is not a current option.

Apologies, I kind of didn't want to fully hijack the thread.

You're almost correct except that I'd like to encrypt the remote
storage, not the local. Since IMAP works in both directions and allows
for a full message, including headers, to be pushed to a given folder
(handy for provider migration) one can use this feature to:

(1) download a message in full
(2) PGP encrypt the message according to RFC and a key of choice
(3) push the encrypted message to the server
(4) delete/expunge the previous, unencrypted message

Both TB/Enigmail and KMail can use this technique to permanently decrypt
a PGP encrypted message. The reverse, however, is a bit more clunky.

KMail, has a working PGP encrypt filter but its message pushing is not
always RFC compliant when it issues the IMAP "APPEND" command to push
the message. It uses the current date/time instead of the one in the
message's "Date" header which should take precedence according to RFC.
This only appears to happen with multi-part messages, is easily
reproducible even without PGP, and I have filed a bug report which has
never been looked into. Plain-text messages are APPENDed correctly.

The net result here is that as some providers, such as GMail, use the
timestamp provided in the APPEND command to overwrite the message's Date
header this leads to incorrect date/time indexing in folders/labels. So
an old message now becomes recent when uploaded. KMail also fails to
expunge the old message properly leaving the unencrypted message in
addition to the newly pushed encrypted.

TB/Enigmail too offers an "Encrypt to key" filter which ought to do the
job but is completely broken and does not work at all. On the other hand
pushing a message via IMAP works correctly for both plain-text and
multi-part messages.

The other mail clients that I have mentioned all have a correct APPEND
implementation but do not seem to have an option (or filter choices) to
perform the PGP procedure above. I'm hopeful that TB 78.2 will have this
feature in one form or another.

- V



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Thunderbird 78

[Victor Ivanov]

On 21/08/2020 01:28, Jack wrote:
> Per my suggtion elsewhere in the thread, have you tried Balsa?

I hadn't heard of Balsa up until this thread. It's minimalistic. I like
it. But it too fails to satisfy the PGP requirement for filtering and
encrypting existing mail. Unless I somehow failed to find the relevant
filtering options (v2.6.1).


> Can you elaborate on how threading and conversations are different? ...
> In terms of combining sent and received messages, unless you are going
> to have some way of showing conversations across folders (which don't
> exist in gmail) the only way I can think of is to copy your sent
> messages into the folder the replies are in, and I do sometimes do
> this.  I try to set all my mailing lists to send me copies of my own
> messages, but doing a bcc to yourself would have the same effect.

Well... that's exactly what "conversation" view is. I don't think I have
much more to add. Sure, GMail uses labels instead of folders and
emulates the latter in IMAP but that's totally irrelevant, so long as
said "categories" are available to the mail client.

Most email clients can be configured to sync either just mail headers or
entire emails for the last X number of days (or all mail). So, at the
very least, being able to have an "extended" threaded view (e.g. by
means of a virtual folder - just like a unified inbox) so to speak that
combines emails from both Inbox and Sent seems rather trivial and could
be done whenever (re)indexing subscribed folders.

BCC'ing myself or having both sent and incoming mail in one mailbox is a
workaround - not a solution. It's neither elegant nor should it be
necessary to achieve the above behaviour.

KMail so far comes as close as it gets (from what I've seen) to
customising threading and appearance of email listing though it too
can't combine multiple folders.

Anyway, as I said, the PGP and standalone (or exportable) config to me
are more important in a mail client. "Conversation" view is more of a
desirable feature rather than something I can't live without.

- V



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Thunderbird 78

[Victor Ivanov]

On 20/08/2020 18:16, Jack wrote:
>> From what I read, there is much enthusiasm  for Claws/Evolution.
>>
>> Sadly, this direct comparison, seems out of date and does not include
>> TB-78, but it is the most comprehensive comparison I have found. A
>> direct comparison, that is up to date, would be very cool, imho:
>>
>> https://appmus.com/vs/mozilla-thunderbird-vs-evolution
>>
>> and
>>
>> https://www.techradar.com/best/best-email-clients#best-free-email-clients
> This list is pretty unimpressive.  Most of their "free" offers aren't. 
> Their description of Gmail doesn't even mention free use, that I can
> see.  Then they include Slack - and the main negative is "no email."  In
> addition, especially for gmail, it's not really an email "client,"  it's
> an email service with web interface.  I certainly don't call that an
> email client.  Am I just too old?

I completely agree. Unfortunately, I think it's a sad state of affairs
wrt mail clients these days.

I tried many of the open-source ones such as TB, Evolution, Claws Mail,
Geary, and KMail. While there is a lot of personal preferences when it
comes to choice, it seems neither of these can get a few simple things
I'm personally looking for into a single package:

- stand-alone configuration:
  being able to rsync "~/.client" or "~/.config/client" across multiple
  machines or through a decent export/import functionality is rather
  critical when working from different machines. Not a fan of KDE's
  Akonadi, though I appreciate what it tries to do as a whole.

- decent PGP support:
  In particular, being able to (re) encrypt existing and unencrypted
  emails either on-demand, en-masse via filter, or automatically upon
  receipt of a new one. All the above clients fail this point for
  different reasons.

- No Gnome 3-like BS interface [luckily most satisfy this]:
  Gnome 3's "simplicity" is not only ugly but also utterly
  dysfunctional. When I see an application utilising Gnome 3 conventions
  for UI design it leaves my drive faster than the speed of light (it
  seems things can indeed travel faster in such cases)

- Conversation view [none have that]
  It may seem silly and it's certainly a personal preference, but
  GMail's conversation view is incredibly useful to me. None of the
  above are capable of combining sent and received mail in correct order
  with the option to either scroll through to the end or collapse
  individual emails. Yes, threaded mail is similar and is better than
  nothing but it's not the same. Though TB's threading often breaks and
  requires a folder rebuild to get it right.

So I keep reverting to TB whose main drawback for me so far has been the
PGP support. I hope TB 78 resolves this, but I'm not fond at all of the
approach they have taken to ditch external tools (i.e. GnuPG) in favour
of a built-in separate key management tool.

If anyone has been able to successfully achieve the PGP point,
preferably with TB/Enigmail or KMail, I would be very grateful for some
input.

- V



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: How to hide a network interface from an application

[Victor Ivanov]

On 14/08/2020 01:03, Alexey Mishustin wrote:
> groupadd noinet
> usermod -a -G noinet 
> iptables -A OUTPUT -i  -m owner --gid-owner noinet -j DROP
>and calling not
> Plex
>but
> sg noinet Plex
>(or whatever name the binary has)

This is a very elegant generic solution, thank you for sharing. I had
completely forgotten the fact that filtering can be done based on UID/GID.

For the sake of completeness, here's the equivalent nftables solution
for those, such as myself, who may have migrated (exclusively) to nft:

  table inet filter {
chain output {
  type filter hook output priority filter; policy accept;
  meta skgid "noinet" oifname "" drop
}
  }

and in command line form:

  (1) nft add table inet filter
  (2) nft add chain inet filter output { type filter hook output
priority 0\; }
  (3) nft add rule inet filter output meta skgid noinet oifname
 drop

The first two are, of course, only relevant if there is no existing
table and chain that one can already use. If such exist, simply use (3)
and substitute names as appropriate.

Regards,
- V



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Disabling ssh password login on all accounts?

[Victor Ivanov]

On 11/08/2020 11:21, Walter Dnes wrote:
>   The one sevice I have listening for external connections on my laptop
> is sshd (192.168.1.0/24).  Before taking it anywhere, I want to prohibit
> password-based login for *ALL* accounts, not just root.  This would
> require users to be listed in ~/.ssh/authorized_keys  Looking through
> /etc/ssh/sshd_config I *THINK* that I need to set "no" at...
> 
> # To disable tunneled clear text passwords, change to no here!
> #PasswordAuthentication yes
> 
>   Is that correct?  If not, what is the correct setting to change?
> 
Hi Walter,

Yes that's one of the options you need to disable. The other one is
"ChallengeResponseAuthentication" which will also disable PAM-based
authentication (which may include passwords). So you should have the
following global settings in /etc/ssh/ssd_config:

PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no

PubkeyAuthentication should default to "yes" but it doesn't hurt to
explicitly set it in case the defaults ever change.

If you so wish, you can also have configurations based on IP address
and/or network. It can be useful as a "fallback" mechanism from trusted
clients, e.g.:

Match Address 192.168.1.0/24
PasswordAuthentication yes


- Victor



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] keepassxc 2.6.0 strange rendering

[Victor Ivanov]

On 10/07/2020 10:40, Tamer Higazi wrote:
> I wanted to try keepassxc 2.6.0, but the output looks really nonsense
> and the output looks entirely "broken".
> I uploaded the screenshot at "imgur" imagehost. url:
> https://imgur.com/WfrrP0T
> 
> 
> I tried the same with the AppImage from the maintainer, the result is
> the same.
> 
> 
> Any ideas what is going on ?
> 

This is most curious. Under KDE Plasma version 2.6.0 works flawlessly.
What DE are you using?

Have you tried to force one of the other themes under "View > Theme"? By
default it will try to use your desktop environment's current theme.

Regards,
Victor



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Victor Ivanov]

From what I gather, taking into account your other email as well, there
are two separate things going on which may or may not be related:

1) The (now open) filesystem isn't being mounted where it should as per
fstab

2) Even then, there appears to be a bogus 'private' parent directory:
/run/media/private// as opposed to /run/media//

On 11/06/2020 23:17, Dale wrote:
> This is my fstab entry:
>
> UUID="7f0cf585-57c8-4a50-808b-987fc13ceee0"
> /home/dale/Desktop/Videos/Private  ext4 defaults,users 0 0
> ...
> You notice anything off about that?  I make a error somewhere?  Miss a
> option maybe?

fstab doesn't like quotes. The correct syntax would be:
UUID=7f0cf585-57c8-4a50-808b-987fc13ceee0

Re (1) above, given that /etc/conf.d/dmcrypt is only used by the dmcrypt
service through OpenRC its contents are irrelevant when using KDE. So,
from the perspective of DN updating fstab with the correct syntax should
be a two birds, one stone solution to both (1) and (2).

Unless your encrypted volume is always connected to the system and you
would like it to be automatically unlocked (via means of being asked to
enter your password), there is no need to enter anything into
/etc/conf.d/dmcrypt and you can leave the file blank/commented out.

Re (2), frankly, I have no idea but I'm curious as to where that
"private" parent directory might come from. The only possible source for
this that I can guess is from your entry in /etc/conf.d/dmcrypt in the
value for "target":

> ## 3TB private drive external
> target='private'
> source=UUID='107be33c-b31c-44b8-b4e7-400ee19fb440'

While this should only affect the name of the block device created under
"/dev/mapper" it seems too much of a coincidence that the bogus parent
directory bears the same name. I've tried to reproduce your set-up but I
still don't get such a parent under /run/media. Perhaps you can try
changing the value to something else and see if it creates a directory
with the new name? If so, this would confirm the theory, but it still
shouldn't be doing that. At least it would be a starting point for
diagnosis, if it's worth going into that at all.

Also, note that, as I mentioned, when mounting a crypto container
through KDE DN or Dolphin your dmcrypt config is irrelevant and
disregarded. You should hence expect upon opening the container to have
the filesystem's block device appear as "/dev/mapper/luks_abcd1234".

- Victor



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Victor Ivanov]

On 10/06/2020 21:52, Dale wrote:
> I've got that in dmcrypt and fstab as the wiki says.  That part works. 
> It's the KDE part that isn't working correctly.  However, I did do one
> thing different, I put users instead of user.  Plural not singular. 
> Should users work the same as user?

This makes little sense. The main difference between user and users is
that the former only allows the user who mounted the filesystem (or
root) to unmount the filesystem, whereas the latter (plural) relaxes
this rule and allows any user to unmount the filesystem.

On 10/06/2020 21:52, Dale wrote:
> I wonder, other distros have crypttab file instead of dmcrypt.  I wonder
> if I created a crypttab file if that would help KDE even if Gentoo
> ignores it or doesn't know it exists.

Doubtful. As far as I'm aware "/etc/crypttab" is for systems that use
that atrocity called systemd. So unless you have your system set up to
use systemd, "/etc/conf.d/dmcrypt" is the correct one to use.

On 10/06/2020 21:52, Dale wrote: 
> It sounds like the Device Notifier is just not set up or designed to do
> what I want to do.
Unfortunately, it's quite basic indeed. I still, however, think you can
achieve what you intend to with fstab. I personally tested what I wrote
in my previous email and, apart from the usual false error message, it
mounts it exactly where I've described in /etc/fstab. I can also eject
it via Device Notifier. Could it be that there's something else going on
in your case?

- Victor



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Victor Ivanov]

On 10/06/2020 07:59, Dale wrote:
> It tells me I don't have permission to access but it also mounts it

This KDE bug re Device Notifier has been present for a long time and
it's seriously infuriating. Mounting from Dolphin, on the other hand,
seems to work just fine, though it too doesn't miss the opportunity to
complain about privileges.

It's not a Gentoo specific issue, as I've experienced this on other
distros too. I believe there was an upstream bug report that kept
getting resolved and reopened.

On 10/06/2020 07:59, Dale wrote:
> I type in the password but it mounts it to the wrong place.
This is normal. By default, volumes mounted from userspace will be
mounted under "/run/media//". This makes sense and is
entirely due to user privileges. Mounting under other directories would
require escalation of privileges. But most basic UI features are
designed for the most common scenario.

On 10/06/2020 07:59, Dale wrote:
> How do I tell the Device Notifier that I want it mounted somewhere
> else?
From KDE you can't and there's no KDE-specific tool to allow you to do
that. But you can add the UUID of the filesystem to /etc/fstab and KDE
will then mount it under that location. However, make sure that the UUID
is that of the open volume, not the encrypted container.

For example, if you manually open the encrypted volume via the command
line, e.g.:

  # cryptsetup open /dev/sdz1 crypto_volume_name

This will ask you for the encryption password and, if correct, will
create a new block device "/dev/mapper/crypto_volume_name".

You can then get the UUID of "/dev/mapper/crypto_volume_name" with:

  # blkid /dev/crypto_volume_name

At this point you can close your LUKS container via:

  # cryptsetup close crypto_volume_name

You can bypass steps 1 and 3 above by mounting via the KDE as usual,
which will automatically create the block device
"/dev/mapper/luks_abcdef1234". You can then get its UUID via step 2 and
replace step 3 by ejecting the mounted volume.

Finally, add this UUID to /etc/fstab in the usual way:

UUID= /dst/mount/dir  [mount_options],user 0 0

Note "user" under mount options. This is critical to making it work
seamlessly from KDE, otherwise it will require escalation of privileges
to mount the volume.

Once you do the above, the volume should automatically be mounted under
"/dst/mount/dir" the next time you mount it via Dolphin or Device Notifier.

It still won't get rid of the annoying "You don't have permissions"
error message, but it does work.

Hope this helps.

- Victor



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Victor Ivanov]

On 07/06/2020 12:52, Victor Ivanov wrote:
> Indeed. I second Rich and too would recommend sticking with AES for this
> reason. LUKS will support an AES key of up to 512 bits. It's fast and
> hardware acceleration is widely available.
>  ...
> For example, Intel's native AES  extensions work in 4x4 data blocks of
> 128 bits but will support variable key lengths. Their white paper [3]
> suggests supported key lengths are 128, 192, and 256 bits but I've been
> using a 512 bit key on my drives for years with negligible performance
> impact (Skylake systems).

Perhaps this requires extra clarification re key length, which I should
have included, as it may give misleading information.

As an algorithm AES fundamentally only goes up to 256 bits for key
length. However, in XTS mode (aes-xts) two _separate_ keys are used for
the initialisation vector and the block encryption. As such, for AES-256
in XTS mode, one needs to supply 2x256b keys.

Effectively, 512b are used, but this too may be misleading. It's better
than 1x256b but certainly not as good as 1x512: (2^256 + 2^256) vs
2^512. It also maps well to hardware extensions already supporting key
sizes of 256b.

This is not possible in CBC or GCM mode which only allows for a single
key of up to 256b.

My apologies, it was a case of my fingers getting ahead of my thoughts
and not having formulating the latter appropriately.

Regards,
Victor



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Victor Ivanov]

On 07/06/2020 09:08, Dale wrote:
> You can have a password, a key file, both or likely other options as
> well.  On one video, the guy generated a key file with urandom that was
> 1024 characters.  As he put it, try typing that in.

Indeed! All of these techniques have various pros/cons which is partly
why my last reply  / novel ended up being long yet still shallow.

A key file would, generally, be more secure provided you can keep the
medium on which it is stored secure as well. A long and strong password
doesn't have to be difficult to type though. A lot of 2FA dongles, such
as the YubiKey will allow for one (or more) of its key slots to be
programmed in plain text. If you have one, this would allow you to
effectively "paste" a very long password in less than a second. Then
again, you will have to keep your dongle secure as well, as plain text
means anyone can "paste" the password into a text file. Again, pros/cons
of the strategy.

On 07/06/2020 09:08, Dale wrote:
> Then I found out about crypttab.  I don't have that on my system, yet.

Crypttab is the standard on most distributions. Gentoo, however, uses
"/etc/conf.d/dmcrypt". Personally, I find its syntax less of an eyesore
and more favourable, but it does effectively the same thing. And the
comments inside it are even better than a man page haha

On 07/06/2020 09:08, Dale wrote:
> I still don't think I'm ready to try and do this on a hard drive.

Don't let any of that discourage you :) It's a lot simpler than it may
seem, and most desktop environments (I believe you we using KDE?) have
excellent support for mounting and unmounting/ejecting encrypted volumes
both internal, as well as removable, once the LUKS container has been
set up.

The guide [1] (also linked to earlier) is comprehensive, but
fundamentally the most relevant part for getting started are steps
2.3-2.5. If you use genkernel, with LUKS="yes" in the config it will
have taken care of the kernel for you and even created a initramfs
suitable for an encrypted root.

As Rich suggested try it out with a flash drive or a loopback file.

On a side note re drives, if using LUKS with an SSD you may or may not
wish to keep trimming disabled, as it may lead to leaked data regarding
the blocks being trimmed [2]. For this reason, trim pass-through is left
OFF by default. The leaked information, however, is minimal and I doubt
it poses any significant risk for the average use case.

On 07/06/2020 09:08, Dale wrote:
> I notice that one can use different encryption tools.  I have Blowfish,
> Twofish, AES and sha***

Bear in mind not all of the items listed are encryption algorithms per
se. The SHA and Argon families are hashing algorithms/functions used to
hash your password and store it an obfuscated form. They are also used
as HMAC functions in the context of encrypted data exchange. The key
thing is that hash functions are one-way. That is, it's computationally
straightforward to create the hash of a given input, but computationally
infeasible to reverse the process. They do not use a a separate
encryption key, and the result is always deterministic and reproducible.

I would stick with SHA as its widely supported. Except for sha1 which
was cracked a few years back. If you choose sha256 or better yet sha512
you can't go wrong.

Argon2 is a great choice, but if I'm not mistaken it's only supported by
LUKS2 which Gentoo only recently made the default. I believe most
current distros have LUKS2 by default, but older ones, including some
LTS versions and distros with release cycles of once per century or so
may not support that, so for removable drives I would stick to LUKS1.

On 07/06/2020 11:33, Rich Freeman wrote:
> AES is probably the most mainstream crypto system out there and is
> considered very secure.  It is also widely supported by hardware and
> all recent Intel/AMD CPUs.

Indeed. I second Rich and too would recommend sticking with AES for this
reason. LUKS will support an AES key of up to 512 bits. It's fast and
hardware acceleration is widely available.

For example, Intel's native AES  extensions work in 4x4 data blocks of
128 bits but will support variable key lengths. Their white paper [3]
suggests supported key lengths are 128, 192, and 256 bits but I've been
using a 512 bit key on my drives for years with negligible performance
impact (Skylake systems). But since data block size is fixed, this
hardly surprising. Acceleration of key length > 128b then only becomes
relevant at key generation time which is a one-time step, so the cost of
this step becomes largely irrelevant.

[1] https://wiki.gentoo.org/wiki/Dm-crypt
[2] http://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html
[3]
https://www.intel.com/content/dam/doc/white-paper/enterprise-security-aes-ni-white-paper.pdf



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Victor Ivanov]

On 06/06/2020 21:12, Rich Freeman wrote:
> My point remains:
>
> The header is as secure as the disk.  If the disk is secure against
> brute-force, then so is the header.

I never said otherwise. This was, in fact, explicitly stated in my
concluding remarks of my original post where I say "If using a password,
a strong password is a must." It was also emphasised once more in my
response to your previous email, towards the end.

But it also doesn't mean that one might not want to take additional
preemptive steps following an attack, depending on the circumstances
surrounding the attack.

On 06/06/2020 21:12, Rich Freeman wrote:
> Maybe we're miscommunicating, but it seems like you're moving the
> goalposts here.
> ...
> Your original point was, "The problem here is that a leaked header
> immediately means a compromised volume."

I believe we're on the same page and it's indeed due to miscommunication
and I suspect this is where the main point of miscommunication lies.
You're taking my statement out of context. No doubt, I most certainly
could have phrased this part better and made it clearer. It may not have
been obvious but that sentence was aimed specifically in the context
where a weak password is used or, especially, when a password has been
compromised and how being able to change said password might have little
effect. In which case the point still stands - when a password is
compromised, there is a possibility that changing said password may not
necessarily be the end of the matter as the (old) header may or may not
have been leaked too either as part of the same or a previous attack -
not necessarily involving physical access.

On 06/06/2020 21:12, Rich Freeman wrote:
> The whole reason you're using encryption is to
> protect the data if your disk is stolen/etc.  If they steal the disk
> they get the header too.  So, if a leaked header means that your
> volume is compromised, then a stolen disk does so as well, which means
> your encryption is worthless.

This is probably another point of confusion. You make a strong case
about a stolen drive, but this was never a case I specifically argued
about. If the whole drive itself is stolen then there's little to
discuss as there's nothing that can be done post facto to mitigate the
circumstances, so any points raised re a leaked header or a change of
password can be thrown out of the window and the only hope in such a
scenario is that the password used is strong enough to safe guard
against guessing attacks. So this case is largely irrelevant re some of
the points I made.

Perhaps it seems that the goalpost moves because I never set one - my
original email was a _general discussion_ on the different
considerations that one might want to have if using a password and how
the ability to change a password may lead to a false sense of security.
Clearly, at the end of the day how exactly all these points fit together
is dependent on the threat model and what scenarios are more and less
likely to happen, which I also pointed out but perhaps not as clearly as
I should have. And so is the analysis, assessment of implications, and
steps to take following an attack.

The only time I referred to non-password methods (such as detached
header) was in response to your previous email re header security.
Retrospectively, I admit I too may have taken your point into a
different, more general direction that takes the discussion beyond the
scope of just passwords. For which I'm certainly liable.

I hope this clarifies the matter.

Best Regards,
Victor



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Victor Ivanov]

On 06/06/2020 19:51, Rich Freeman wrote:
> If you're talking about the drive header that is actually written to
> disk, it is as secure as the entire drive is, since the drive contains
> the header.

I never said it was any less secure. It would be daft to even assume
something like that as it's de facto the door to the encrypted data.

The point I was making is simply that it increases the risk of data
breach when a password is used, especially if (one of) the password(s)
has been or is subsequently compromised. After all, it's difficult to
remember passwords that are long enough and have high entropy. There are
also the practicals inconveniences of having to type a long password.

On 06/06/2020 19:51, Rich Freeman wrote:
> If the password can be brute-forced then the encryption is worthless.
> ...
> If you're using LUKS the security of the system is only as secure as
> your password(s).  LUKS uses a random key to encrypt the drive, and it
> applies many rounds of encryption to your password to protect the
> session key.  That will greatly slow down a brute force attack.
> However, if your encryption key is "12345" then a brute force attack
> is likely to succeed.

Hence my previous point on ensuring a strong password.

On 06/06/2020 19:51, Rich Freeman wrote:
> Sure, if the attacker has a copy of the header they can spend as much
> time as they wish brute-forcing it.  However, the same is true if they
> have the entire disk, and that is precisely the scenario we're trying
> to guard against.

Not true. A key file stored outside the header is arguably way more
secure than a password - there's no longer a single point of failure.
Then there is also the option of having a detached LUKS header that is
never written to the block device in the first place which effectively
leaves the adversary with a stolen brick.

Are any of the "more secure" setups inconvenient to use? Sure. And I
doubt the average person would be that paranoid to use a detached
header, which by itself introduces a whole lot of issues like how do you
store the header itself securely. I was merely emphasising the fact that
when using a password, having the facility to change the password can
give a false sense of security in a select number of cases, especially
if the password being used prioritises memorability over sophistication,
often leading to low entropy, and that this is particularly problematic
for leaked passwords as brute-forcing high entropy passwords is not
feasible anyway as per your own words.

Regards,
Victor



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Victor Ivanov]

On 06/06/2020 05:37, Dale wrote:
> One other question, can one change the password every once in a while? 
> Or once set, you stuck with it from then on? 

A point I forgot to mention in my previous email is regarding passwords.
While most encryption methods will allow for a password change (CryFS
doesn't) be mindful that with methods used to encrypt large amounts of
data the actual encryption key is generated once at volume creation time
and is never changed. A password is only used to decrypt/derive the key
itself.

This is purely due to practical considerations. If you change the actual
encryption key, then all encrypted data will have to be decrypted with
the old key and re-encrypted with the new key. This may be a perfectly
reasonable thing to do for file-based encryption or small amounts of
data where a password change also means a key change, but is completely
infeasible for larger scale volume encryption that may contain hundreds
of GB of data.

Thus, if a password has been compromised, it is not unreasonable to
assume that anyone who knows the password and has had access to the
encrypted volume might be able to get [or has already got] hold of the
encryption key itself once the volume was opened. Hence, changing a
leaked password doesn't make a compromised volume secure again.

Of course, if it can be safely determined that a leaked password has not
yet been used to access the volume, a swift preemptive change of the
password will retain security.

There is one exception to this where an adversary has a copy of the
header (or similar) of the encryption volume. Here's a quick example
with LUKS. A LUKS volume has a ~2MB header which stores all (hashed)
passwords and the password-encrypted decryption key. The header can be
read and stored separately. In fact, it's good practice for one to back
up the header in case it ever gets corrupted (a corrupt header often
means saying goodbye to your data w/o a backup).

The problem here is that a leaked header immediately means a compromised
volume. An adversary who gets hold of the header can now spend as much
time as they would like to brute force a password (depending on password
strength) and derive the encryption key. Or if they have an (older) copy
of the header with a leaked password before it was changed they can get
hold of the encryption key with virtually no effort at all by using said
password. The only solution to a compromised header is full
re-encryption. Even having a rolling password won't change that.

Bottom line wrt passwords, one should not rely on or assume that having
the facility to change a password will keep their data safe. If using a
password, a strong password is a must.

Again, it boils down to the usual trade-offs, likelihood of physical
access, etc, etc. But I thought it an important point to note, as a
surprisingly large number of people I have spoken to before seem to be
unaware of this caveat (I'm not suggesting you are one of them).

Regards,
Victor



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Victor Ivanov]

On 06/06/2020 12:05, Rich Freeman wrote:
> Usually you want the encryption as close to the disk as possible
> because if somebody gets your disk it gives them less to work with.
> They don't know that you have a logical volume called "home" on it,
> and so on.

I concur with Rich on this.

One of the key considerations for encryption is how much is it that want
encrypted and what metadata are you willing to have publicly visible. As
an extreme example, you can think of the simplest form of encryption -
on a per file basis. Contents are encrypted, but things like file name
and size, creation and modification timestamps, filesystem directory
tree are all available to an imaginary adversary. One can further deduce
information about the file by its extension, and use all of that to come
up with a good attack strategy for decryption. In other cases, contents
may be irrelevant to an adversary, as they can already infer a lot about
a person - if that's what they are interested in - from directory
listings etc, depending on what they are looking for. Filesystem-based
support for encryption will inevitably leak some metadata.

On the other extreme you have block-level encryption which hides all
contents, including filesystem information, for a given block device.
With multiple physical partitions, however, this too can leak a degree
of information. For example, it would be reasonable to assume that the
largest partition is a person's "storage" partition. So attempts can be
targeted at that block device, ignoring all other ones. It's also
cumbersome to manage as unlocking multiple block devices would require
multiple password entries unless a common key file is used.

Michael mentioned CryFS which is kind of in the middle. It's an
"overlay" filesystem, anything within a CyFS volume is encrypted into
fixed-size (e.g. 64KB) block files. This includes file names and all
file meta data, directory structure, etc., and all encrypted content can
be interleaved across different blocks. However, depending on the size
of the average files you have, it can have a significant overhead where
contents of the encrypted CryFS volume can be considerably larger than
the actual contents of your encrypted data. This can addressed, to a
degree, by playing with the block size. Smaller block size will reduce
overhead but will increase the number of block-sized encrypted files on
the actual filesystem, which can eat up a lot of INodes.  The downside
is, the block size cannot be changed once a CryFS volume is created, and
neither can the password. These require creating a new CryFS volume and
migrating your files. As such, my personal view on the matter is that
CryFS is usually good for small volumes and is indeed very good for
securing content on cloud services like Dropbox that do not normally
encrypt your data.

Personally, I have been using LUKS and LVM for many years. On OS-bearing
drives I would have a non-encrypted /boot partition for the kernel and
initrd whilst the remainder of the drive would be a LUKS encrypted block
device - two partitions in total (3 for a GPT system). Within the
latter, I would create LVM partitions as I desire (including OS root).
LUKS has 8 slots that can hold up to 8 passwords or key files (or any
combination of both) at a time. This set up is pretty much zero-leak.
For an external drive I would use LUKS across the whole drive. Note in
the former case the /boot partition is still vulnerable and a
compromised kernel image could lead to a leaked LUKS password once the
LUKS block device is opened. Signing the kernel and its modules is one
possible solution. At the end of the day, which method you choose is
based on a balancing trade-offs and likelihoods of an attack.

That said, virtually all modern processors in the last 10y or so have
native hardware extensions for accelerating common encryption algorithms
such as AES. As such, having full-disk encryption has very little
performance overhead on read/write speeds. You can use "cryptsetup
benchmark" to see upper bound estimates of read/write speeds. The values
shown are in-memory estimates and are thus CPU/memory bottlenecked. For
example, on one of my systems with a mobile i7 CPU AES with 512b key
(maximum supported by LUKS with AES) shows about 2,000MB/s for both
read/write. This is more than enough to saturate a SATA3 drive's 6Gb/s
best-case data rate as well as a lot of current generation consumer
grade NVMe drives.

In summary (and final remarks):
* Performance overhead these days is largely irrelevant for common use cases
* Use case (e.g. cloud storage or local drives) and what is left behind
unencrypted is a key consideration when choosing a method.
* Generally, block-level encryption is preferable to filesystem encryption
* LUKS is Linux-specific. If cross-platform compatibility is required
this won't be a good choice. Then again, so is LVM.
* TrueCrypt is obsolete - do not use this if you can avoid it
* VeraCrypt (its successor) is cross platform. 

Re: [gentoo-user] [SOLVED] eselect-opengl Blockage (with a capital "B") problem

[Victor Ivanov]

When the lbglvnd flag was introduced I remember I solved this issue by:

# emerge --unmerge eselect-opengl
# emerge -1qv mesa

After that, a simple update of @world rebuilt everything else on its own.

Personally, I had been waiting for libglvnd support for _a long time_.
This - and I mean GLVND in general - is something that should have come
to Linux many years ago, along with NVIDIAs PRIME render offloading.

10y ago I used to have an Optimus laptop with an Nvidia GPU and it was
an absolute hell to get it running, I remember writing tonnes of scripts
using VirtualGL and a dummy X server running on the Nvidia GPU. This was
before bumblebee.

Today, I still need this with an external GPU.

But now it takes 1 environment variable to offload to the other GPU!
GLVND literally made my Linux work experience a million times better.
I'm extatic.

- V

On 20/05/2020 07:07, Dale wrote:
> J. Roeleveld wrote:
>> On 20 May 2020 05:44:58 CEST, Walter Dnes  wrote:
>>> On Tue, May 19, 2020 at 03:14:03PM +0200, J. Roeleveld wrote
>> On Mon, May 18, 2020 at 01:53:19PM -0400, Walter Dnes wrote:
>  Thank you very much.  I've got the update (156 packages) running
>>> now.
> I had set "-libglvnd" in make.conf on my main machine, but only
>>> against
> xorg-server on my secondary machine.  Setting "-libglvnd" in
>>> make.conf
> solves the problem.
 Only for now.
 "Libglvnd" is scheduled to be removed as a USE flag.  I would
 definitely suggest to switch to having that one on before it becomes
 mandatory.

 It has a lot of benefits over the eselect hack to be able to have
 multiple opengl implementations running.
>>>  The reason I had originally turned it off was because when it first
>>> showed up as a flag, I checked Google to find out what it was.  Almost
>>> every hit on webforums was like...
>>>
>>> Person 1 - Help; my "update world" dies
>>> Person 2 - Turn off "libglvnd" in make.conf
>>> Person 1 - Thank you; my update works fine now
>>>
>>>  Add me to the list.  If this is to be a new default config setup, I'd
>>> appreciate a news item about it, like the python 3.6 to 3.7 switchover.
>> I actually had to enable this on my new laptop before it became stable to 
>> get the Nvidia chip and my external displays working.
>> I am actually happy with this as I don't have to keep changing the opengl 
>> setting anymore when I need 3D performance.
>>
>> --
>> Joost
> 
> 
> Reading this thread, I checked and I to have this USE flag turned
> off/disabled/whatever.  I removed it from make.conf and commented out
> everything else I found in /etc/portage and am checking to see what all
> had to be rebuilt.  I figure I may as well change now while I have a
> otherwise stable system, except for the sddm-helper chewing memory
> problem, and get ahead of the curve.  ;-)  Using that grep -r trick
> comes in handy.  Learned that from this list too. 
> 
> It's odd how following a thread that may not even affect you ends up
> doing so.  :/
> 
> Just in case, this is what emerge spit out on my screen. 
> 
> 
> Calculating dependencies... done!
> [ebuild   R    ] sys-libs/libblockdev-2.23-r1::gentoo  USE="cryptsetup
> lvm tools -bcache -device-mapper -dmraid -escrow -gtk-doc -introspection
> -kbd -test -vdo" PYTHON_SINGLE_TARGET="python3_7 -python3_6
> (-python3_8)" 0 KiB
> [ebuild   R    ] media-libs/libdvdnav-6.0.0::gentoo  USE="-static-libs"
> ABI_X86="(64) -32 (-x32)" 0 KiB
> [ebuild  N ] media-libs/libglvnd-1.3.1::gentoo  USE="X -test"
> ABI_X86="32 (64) (-x32)" 698 KiB
> [ebuild   R   ~] media-libs/mesa-20.0.4-r1::gentoo  USE="X classic dri3
> egl gallium gbm gles2 libglvnd* llvm wayland zstd -d3d9 -debug -gles1
> -lm-sensors -opencl -osmesa (-selinux) -test -unwind -vaapi -valgrind
> -vdpau -vulkan -vulkan-overlay -xa -xvmc" ABI_X86="32 (64) (-x32)"
> VIDEO_CARDS="(-freedreno) -i915 -i965 -intel -iris (-lima) -nouveau
> (-panfrost) -r100 -r200 -r300 -r600 -radeon -radeonsi (-vc4) -virgl
> (-vivante) -vmware" 0 KiB
> [blocks b  ] media-libs/mesa[-libglvnd(-)]
> ("media-libs/mesa[-libglvnd(-)]" is blocking media-libs/libglvnd-1.3.1)
> [ebuild   R    ] sys-libs/libcap-2.26-r2::gentoo  USE="pam (split-usr)
> -static-libs" ABI_X86="32 (64) (-x32)" 0 KiB
> [ebuild   R    ] x11-drivers/nvidia-drivers-440.82:0/440::gentoo  USE="X
> acpi driver gtk3 kms libglvnd* multilib tools -compat -static-libs -uvm
> -wayland" ABI_X86="32 (64) (-x32)" 0 KiB
> [ebuild   R    ] x11-base/xorg-server-1.20.7:0/1.20.7::gentoo 
> USE="elogind ipv6 libglvnd* suid udev xorg -debug -dmx -doc -kdrive
> -libressl -minimal (-selinux) -static-libs -systemd -unwind -wayland
> -xcsecurity -xephyr -xnest -xvfb" 0 KiB
> [uninstall ] app-eselect/eselect-opengl-1.3.1-r4::gentoo
> [blocks b  ] app-eselect/eselect-opengl
> ("app-eselect/eselect-opengl" is blocking
> x11-drivers/nvidia-drivers-440.82, x11-base/xorg-server-1.20.7,
> media-libs/mesa-20.0.4-r1)
> 
> 
> 
> Now let us pray to the portage gods for 

Re: [gentoo-user] Kernel config for Docker

[Victor Ivanov]

Andrew makes a good point that, of course, not all options will be
relevant to a particular image or use case. The script is aimed to check
for "full" compatibility. Having some reported as missing is by no means
a deal breaker.

Re nftables it's a very valid point as well. I too use nftables instead
of iptables and, in general, anything that dares touch my rules I will
either disable the option for it to do so or, if that's not possible,
swiftly eradicate it off my system with vengeance. I'm not a big fan of
how Docker manages netfilter rules so I too tend to disable that from
the config and, as Andrew said, it has been slow at adopting nftables.
It seems Docker is being developed with primary consideration for stable
(read archaic) distributions that have long release cycles.

If you use nftables at all - even via other software such as firewalld,
etc - Docker may or may not like that. Previously, though admitedly
quite a while ago, Docker just loved adding iptables rules in addition
to my nftables rules. Needless to say, that quickly became a mess.

nftables is _a lot_ easier to manage, even writing rules manually feels
a lot more intuitive. So I think the learning curve (at least in terms
of syntax) tends to be less steep IMO if you decide to go down that road
at some point.

Anyway, this probably wasn't a post of high contribution value haha

Keep us updated in case you encounter any issues!

Cheers,
Victor

On 17/05/2020 09:31, Peter Humphrey wrote:
> On Sunday, 17 May 2020 00:58:54 BST Andrew Udvare wrote:
>> On 16/05/2020 13:12, Peter Humphrey wrote:
>>> I can't find any of those. Any clues for the uninitiated?
>>
>> I am running Docker fine on 5.6.12 and I am missing a lot:
> 
> --->8
> 
>> In regards to NF options, I use nftables and I manage the firewall
>> manually for Docker (I set {"iptables": false} in
>> /etc/docker/daemon.json). Docker has been extremely slow at adopting
>> nftables.
> 
> I'm still pretty much in the dark about setting up nftables and iptables in 
> the kernel config. Not to worry, though; I dare say it'll become clearer in 
> time.
> 
>> You definitely do not need zfs installed to use Docker. This machine
>> doesn't have it.
>>
>> As Victor stated, CFQ is deprecated and gone and BFQ will work fine. And
>> the script is basically for Red Hat (or corporate) users who still use
>> iptables, CFQ, ext3 apparently, and a much older kernel.
>>
>> On my slightly stabler server (running 5.4.38), this is the output and
>> Docker still works fine. Again on that server I use nftables and manage
>> the firewall manually. The system has ext4 for its root and the rest of
>> it is ZFS.
> 
> --->8
> 
> Thanks gents. I'll just try it and see what happens.
> 



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Realtek r8169 realtek.ko not loaded.

[Victor Ivanov]

Hi Alexander,

A while back I had the exact same issue with a remote machine that I am
managing. It has an Asus B45-M mobo with an r8169 chipset. Ever since
the 5.2.x kernel family - where it last used to work - it has been a pain.

Initially I added a manual "soft" dependency in "/etc/conf.d/modules" as
William has suggested to you with "realtek" appearing first in the list.
But this stopped working following an update to 5.4.x and is still the
case today with the 5.6.x family (I keep testing it once in a while).

I then decided to build both realtek and r8169 modules into the kernel:

REALTEK_PHY=y
CONFIG_R8169=y

It did require a bit of faff as the whole chain of dependencies from
REALTEK_PHY had to be built in as well, but I think that was about 5-6
kernel options in total.

Adding it to the ramdisk as William suggests might work too. In my case
I didn't bother trying this due to the fact that every failed attempted
required manual intervention by someone to get the machine booted with
working kernel.

I have a gut feeling that tells me adding it to the initrd probably
won't work. But if you're planning on trying it, please keep us posted.
I would be very interested in hearing your solution.

Regards,
V

On 17/05/2020 09:07, Alexander Puchmayr wrote:
> Hi there
> 
> I just upgraded an older notebook with r8169 network chip to new kernel 5.4 
> (sys-kernel/gentoo-sources-5.4.28) with genkernel. 
> After booting the new kernel the network adapter was not initialized, no 
> network interface eth0.
> Dmesg says
> [6.390973] r8169 :08:00.0: realtek.ko not loaded, maybe it needs to 
> be 
> added to initramfs?
> [6.392864] r8169: probe of :08:00.0 failed with error -2
> 
> After searching with google I found a thread in the kernel mailing list
> https://bugzilla.kernel.org/show_bug.cgi?id=204343
> The cause is a soft depencency to module realtek.ko, which needs to be loaded 
> first.
> 
> Doing this manually, i.e. rmmod r8169 && modprobe realtek && modprobe r8169 
> works fine; network interface eth0 gets configured and is operating.
> 
> Since the kernel loads the network module before systemd is running, it has 
> to 
> be configured in initrd somehow.
> So, the final question is, how to get that into initrd with genkernel?
> I need to add something like this
> 
> cat /etc/modprobe.d/realtek 
> Softdep r8169 pre: realtek
> 
> How do I get this into initrd with genkernel-next?
> 
> Thanks in advance
>   Alex
> 
> PS 
> Profile:
> default/linux/amd64/17.0/desktop/plasma/systemd
> 
> Relevant packages:
> sys-apps/gentoo-systemd-integration-7
> sys-apps/kmod-26-r5
> sys-apps/systemd-244.3
> sys-kernel/genkernel-next-69
> sys-kernel/gentoo-sources-5.4.28
> 
> Lspci
> 08:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
> RTL8111/8168/8411 
> PCI Express Gigabit Ethernet Controller (rev 03)
> 
> 
> 
> 



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Kernel config for Docker

[Victor Ivanov]

Some of these are obsolete and have been removed in newer kernels.

NF_NAT ones have been superseded by / renamed to:

CONFIG_NF_NAT
CONFIG_IP_NF_NAT
CONFIG_IP6_NF_NAT

I'm not sure about CONFIG_INET_XFRM_MODE_TRANSPORT but I believe it's
now incorporated into other XFRM config variables in newer kernels. I
will need to look at the kernel changelogs. But you should be fine
without it.

AUFS is not part of the main kernel tree, so the following option does
not apply:

CONFIG_AUFS_FS

That said, Docker does _not_ require AUFS, but it does still support it
as an option. Docker docs, recommend using OverlayFS instead which is
also part of the main kernel tree.

As far as I recall there are patches and overlays that will allow you to
enable AUFS if needed. Debian, for example, does not include AUFS and
instead uses DKMS for AUFS support.

The CFQ I/O scheduler is obsolete and has been removed, so the following
do not exist and have no alternatives except for running an older kernel:

CONFIG_IOSCHED_CFQ
CONFIG_CFQ_GROUP_IOSCHED

Docker will run just fine with the BFQ scheduler.

Generally speaking the docker kernel validation script is fundamentally
flawed by design - it doesn't check the kernel options based on the
kernel version. Instead it uses as single global list of CONFIG options
and matches against that.

- Victor

On 16/05/2020 18:12, Peter Humphrey wrote:
> Afternoon all,
> 
> I'm trying to follow the wiki[1] to set up gentoo-sources-5.4.38, but the 
> wiki 
> seems to have been written for a different kernel version. Nothing daunted, I 
> set as many parameters as I could, rebooted and ran /usr/share/docker/contrib/
> check-config.sh. I got 9 things missing, thus:
> 
> $ /usr/share/docker/contrib/check-config.sh > /tmp/config-check
> $ grep missing /tmp/config-check
> - CONFIG_NF_NAT_IPV4: missing
> - CONFIG_NF_NAT_NEEDED: missing
> - CONFIG_IOSCHED_CFQ: missing
> - CONFIG_CFQ_GROUP_IOSCHED: missing
>   - CONFIG_INET_XFRM_MODE_TRANSPORT: missing
> - CONFIG_AUFS_FS: missing
> - /dev/zfs: missing
> - zfs command: missing
> - zpool command: missing
> 
> I can't find any of those. Any clues for the uninitiated?
> 
> 1.  https://wiki.gentoo.org/wiki/Docker
> 



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] How can I force emerge to use python 3.6?

[Victor Ivanov]

Why do you think emerge might be the issue? It's quite rare for portage
itself to be causing problems with packages.

That said, if you have good reason to believe so you can adjust the
PYTHON_TARGETS for sys-apps/portage in /etc/portage/package.use like so:

sys-apps/portage PYTHON_TARGETS: +python3_6 -python3_7

Or you can keep both. You will of course need to rebuild portage
following this change.

Likewise, you use the syntax of the above entry to adjust the python
targets for any package.

Your default interpreter choice (as reported by eselect) is likely not
respected by portage because the current profile defaults only build
portage against python 3.7.

- Victor

On 16/05/2020 02:32, William Kenworthy wrote:
> How can I force emerge to use python 3.6 when 3.7 is installed? -
> eselect list shows 3.6 is #1 and 3.7 as fallback so that doesn't work.
> 
> I am trying to narrow down a failure which appears to be a combination
> of building packages that are stored on a moosefs network share and
> python 3.7
> 
> BillK
> 
> 



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Update Gentoo recently is becoming difficult

[Victor Ivanov]

Python has indeed been a bit of a mess recently for me as well, but I
haven't had any major issues.  Presumably, this could be attributed to
the fact that since python migrations started I have been using the
--changed-deps flag to emerge, which I noticed did help to clean a few
things up during world upgrades.

I suspect the whole situation is due to maintainers trying to quickly
get up to speed Python 3.7 and dropping of Python 2.7 where possible as
Rich mentioned earlier.  So I didn't really pay much attention to it
except for the one or two packages that broke.

On my (stable) systems I find myself having 4 versions of python
present: 2.7, 3.6, 3.7, and 3.8.  However, since the latest bulk move to
3.7 there appears to only be a single package unnecessarily pulling in
both 3.6 and 3.8, and that's "dev-lang/python-exec".  It does seem
rather unnecessary.

I do, however, have a rather large number of packages that are built
with both +python_targets_python3_7 _and_ +python_targets_python2_7.  I
suspect the latter dependency will be cleared out soon.

I haven't had issues with boost though, with 1.72.0-r1 being the only
one installed.  Perhaps "--changed-deps" might be worth trying if you
haven't?

- V

On 12/05/2020 14:36, Alessandro Barbieri wrote:
> Yes, I have trouble too in upgrading. Python is messy now: I don't want
> Python3_8 targets but some package require them (for what reason?). Also
> a boost slot conflict.
> 
> Il Mar 12 Mag 2020, 04:03 Raphael MD  > ha scritto:
> 
> Hello,
> 
> I’ve been realizing to update Gentoo is becoming worse every time.
> My 2018 install, that I’ve recently update because python, was still
> those days running like a square wheel.
> 
> I was trying to update my KDE profile 17, but was a pain, I’ve
> suffered a lot, many blocks, flag problems, circular dependency and
> in the end perl messed me and the system entirely broke.
> 
> Now I’m installing a new fresh system, and even in the beginning to
> emerge the world update, like manual says, circular dependency
> problem with Bluetooth and Systemd. 
> 
> I’m long openRC user, I’ve started again using Systemd stage3, and
> now suffering with python 3.6/3.8 dependency mess.
> 
> I don’t know if I’m out of luck or Gentoo is becoming a pain to
> maintain and update.
> 
> I know, there are some periods is better to avoid update and appear
> this time is now! Lol 
> 
> Thanks.
> 
> 
> -- 
> M.S. Raphael Mejias Dias
> ​Nuclear Engineer | Reactors
> 
> Secure e-mail: raphael.mejias.d...@protonmail.com
> 
> PGP Key for raph...@gmail.com :
> https://pgp.mit.edu/pks/lookup?op=get=0x87BC5A746072F951
> 



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] sci-libs/scipy-1.1.0 fails to compile (SOLVED)

[Victor Ivanov]

In case anyone encounters the same issue, the problem was solved by
single threaded build using MAKEOPTS="-j1". No other config changes.

Why this works but not otherwise remains a mystery. I also had the same
problem earlier today with dev-python/matplotlib-2.2.2-r1 except the
linker was complaining about an incompatible version of libc. Again
solved by -j1 and no other config modifications.

I have sometimes experienced this with some packages but exceptionally
rarely which is why it's not on usually on my "to try" list. If anyone
has any insights as to why this might be happening (in general), I would
be grateful and happy to expand my knowledge :)

Cheers,
Victor

On 07/05/2020 15:53, Victor Ivanov wrote:
> Ah, thanks for pointing this out! It appears I'm blind ...
> 
> It's rather surprising though, as sci-libs/lapack was neither upgraded
> nor rebuilt. Since sci-libs/scipy wasn't upgraded either it ought to
> link just fine as it had previously been built against the same version
> of sci-libs/lapack. I'm quite baffled.
> 
> Rebuilding sci-libs/lapack didn't help and neither did ~amd64 keywording
> it. The error remains the same, which would make sense as there's not
> really a new version of sci-libs/lapack.
> 
> Cheers,
> Victor
> 
> On 07/05/2020 15:04, Peter Humphrey wrote:
>> On Thursday, 7 May 2020 14:31:41 BST Victor Ivanov wrote:
>>> Hi all,
>>>
>>> For some reason SciPy fails to compile after today's Python 3.6 ->
>>> Python 3.7 global update. It was the only package that failed out of all.
>>>
>>> Normally build.log (attached) is helpful enough to get me to resolve the
>>> issue. However, it fails with a surprisingly unhelpful message during a
>>> call to gfortran. Or maybe I'm unable to spot the proper error message.
>>
>> Isn't this the cause?
>>
>> x86_64-pc-linux-gnu-gcc: 
>> /var/tmp/portage/sci-libs/scipy-1.1.0/temp/tmpeyMzsQ/
>> source.c
>> /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
>>  
>> /var/tmp/portage/sci-libs/scipy-1.1.0/temp/ccGtNhqg.o: in function `main':
>> source.c:(.text.startup+0x8c): undefined reference to `cblas_ddot'
>> collect2: error: ld returned 1 exit status
>>
> 



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] sci-libs/scipy-1.1.0 fails to compile

[Victor Ivanov]

Ah, thanks for pointing this out! It appears I'm blind ...

It's rather surprising though, as sci-libs/lapack was neither upgraded
nor rebuilt. Since sci-libs/scipy wasn't upgraded either it ought to
link just fine as it had previously been built against the same version
of sci-libs/lapack. I'm quite baffled.

Rebuilding sci-libs/lapack didn't help and neither did ~amd64 keywording
it. The error remains the same, which would make sense as there's not
really a new version of sci-libs/lapack.

Cheers,
Victor

On 07/05/2020 15:04, Peter Humphrey wrote:
> On Thursday, 7 May 2020 14:31:41 BST Victor Ivanov wrote:
>> Hi all,
>>
>> For some reason SciPy fails to compile after today's Python 3.6 ->
>> Python 3.7 global update. It was the only package that failed out of all.
>>
>> Normally build.log (attached) is helpful enough to get me to resolve the
>> issue. However, it fails with a surprisingly unhelpful message during a
>> call to gfortran. Or maybe I'm unable to spot the proper error message.
> 
> Isn't this the cause?
> 
> x86_64-pc-linux-gnu-gcc: /var/tmp/portage/sci-libs/scipy-1.1.0/temp/tmpeyMzsQ/
> source.c
> /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
>  
> /var/tmp/portage/sci-libs/scipy-1.1.0/temp/ccGtNhqg.o: in function `main':
> source.c:(.text.startup+0x8c): undefined reference to `cblas_ddot'
> collect2: error: ld returned 1 exit status
> 



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Trackpad nightmare: Elantech ETPS/2

[Victor Ivanov]

On 05/05/2020 18:44, Michael wrote:
> 
> I'm on an old Lenovo which must have different hardware/firmware.  It does 
> not 
> suffer from such trackpad problems.  Just an idea: have you migrated your 
> system to libinput driver and removed all old synaptics syntax in /etc/X11/
> xorg.conf.d/ to avoid potential clashes?
> 
Yes, as I mentioned in my original email I use libinput and have done so
ever since it became a reasonable replacement. Certainly so for at least
the last three to four years.

I don't believe it's a library issue as the error messages in dmesg -
which are far more disturbing than those in Xorg.log - come directly
from the psmouse module.

It would appear ELAN trackpad drivers are generally in a very sorry
state across the board. In my very rare and limited use of Windows I
remember having a similarly abominable experience, albeit due to other
symptoms. With Synaptics trackpads, although not perfect, I have yet to
experience anything as hellish as this.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Trackpad nightmare: Elantech ETPS/2

[Victor Ivanov]

On 05/05/2020 15:28, inasprecali wrote:
> 
> I experience very similar symptoms on my ThinkPad 13. It doesn't
> happen often, but it does sometimes happen.
> 
It's good to hear that there are others sharing the pain - at least to a
degree - today, as most topics I've come across stop around 2018, which
made me believe the issue had been resolved in the kernel.

> 
> Unfortunately I'm not aware of any real solution, but as a
> workaround, you can unmount and re-mount the psmouse module when
> the problem occurs (if psmouse is not built compiled as a module,
> I suggest you do it).  At least this is what works for me, YMMV:
> 
> # modprobe -r psmouse
> # modprobe psmouse
> 
This is basically what I've been doing. However, it's not as easy when
it causes the keyboard to freeze as well, where the only solution is
usually a hard reset without access to an external keyboard. It's also
incredibly time consuming to do a few times an hour, even without having
to reboot.

I might bump up the bug report on kernel.org and see if gets any attention.



signature.asc
Description: OpenPGP digital signature

[gentoo-user] Trackpad nightmare: Elantech ETPS/2

[Victor Ivanov]

Dear fellow Gentoo users,

Despite being a largely silent gentoo-user subscribers, I am always
fascinated by the helpful and in-depth discussions that pop up every so
often on this mailing list.

I hope somebody can help me resolve this frustrating situation or at
least help be debug it in a meaningful way that can help a bug report.

My laptop's trackpad is an ETPS/2 Elantech on a ThinkPad Yoga 260 (ca.
2016). Every so often it freezes and refuses to respond to any and all
input. The freeze usually lasts for a second or so, but can sometimes be
longer in the range of 10-15 seconds or even freeze indefinitely until
the "psmouse" kernel module is reloaded. It also experiences "jumping"
behaviour, most commonly encountered when press-holding one of the
companion buttons along with a dragging gesture, but that's not an
exclusive scenario.

When a freeze occurs, my dmesg is usually plagued messages as seen in
the attachment provided (excerpt) while Xorg.0.log often shows error
messages as in the attachment (excerpt). Apart from these messages, both
dmesg and Xorg logs look otherwise healthy.

A quick Google search can reveal complaints about this issues across
distributions (Ubuntu, Fedora, Debian) that can be traced back to at
least 2012 in various laptop models. There also appears to be a related
upstream kernel bug [1] that has been left in limbo.

Ever since I got this laptop I have been having this issue every so
often but usually only with the odd hiccup and rarely impeding in any
way. Lately, however this has been a nightmare. Given that this is my
daily driver for work and research and this issue is getting out of
hand. The worst part is that the internal keyboard is on the same serial
bus and a freeze in the touchpad driver often causes a freeze of the
keyboard where keyboard events get queued up and eventually interpreted
rapidly all at once, should the touchpad recover. If not, the system
appears to have frozen (even though it's not and can be controlled with
USB peripherals).

I run a Plasma desktop on a 17.1 profile with libinput. I have _not_
been able to identify any recent package updates that may have led to
the increase in frequency. The issue is present on both kernel 5.4.28
(stable) as well as 5.6.10 (~amd64).

For close to 15y on Gentoo, I have not once encountered an issue that I
have been unable to debug and solve :( Though admittedly, this may well
not be a Gentoo-specific issue.

To keep this email short(ish), I haven't provided too much detail, but
am happy to dig further. Any input, especially if someone has
encountered this themselves, would be greatly appreciated!

[1] https://bugzilla.kernel.org/show_bug.cgi?id=48161

Cheers,
Victor
[Tue May  5 10:03:52 2020] psmouse serio1: Touchpad at isa0060/serio1/input0 
lost sync at byte 6
[Tue May  5 10:03:52 2020] psmouse serio1: Touchpad at isa0060/serio1/input0 
lost sync at byte 6
[Tue May  5 10:03:52 2020] psmouse serio1: Touchpad at isa0060/serio1/input0 
lost sync at byte 6
[Tue May  5 10:03:52 2020] psmouse serio1: Touchpad at isa0060/serio1/input0 - 
driver resynced.
[Tue May  5 10:03:52 2020] psmouse serio1: Touchpad at isa0060/serio1/input0 
lost sync at byte 6
[Tue May  5 10:03:52 2020] psmouse serio1: Touchpad at isa0060/serio1/input0 
lost sync at byte 6
[Tue May  5 10:03:52 2020] psmouse serio1: Touchpad at isa0060/serio1/input0 
lost sync at byte 6
[Tue May  5 10:03:52 2020] psmouse serio1: Touchpad at isa0060/serio1/input0 
lost sync at byte 6
[Tue May  5 10:03:52 2020] psmouse serio1: Touchpad at isa0060/serio1/input0 
lost sync at byte 6
[Tue May  5 10:03:52 2020] psmouse serio1: issuing reconnect request
[Tue May  5 10:05:28 2020] psmouse serio1: Touchpad at isa0060/serio1/input0 
lost sync at byte 6
[Tue May  5 10:05:28 2020] psmouse serio1: Touchpad at isa0060/serio1/input0 - 
driver resynced.
[Tue May  5 10:05:28 2020] psmouse serio1: Touchpad at isa0060/serio1/input0 
lost sync at byte 6
[Tue May  5 10:05:28 2020] psmouse serio1: Touchpad at isa0060/serio1/input0 - 
driver resynced.
[Tue May  5 10:05:29 2020] psmouse serio1: Touchpad at isa0060/serio1/input0 
lost sync at byte 6
[Tue May  5 10:05:29 2020] psmouse serio1: Touchpad at isa0060/serio1/input0 
lost sync at byte 6
[Tue May  5 10:05:29 2020] psmouse serio1: Touchpad at isa0060/serio1/input0 
lost sync at byte 6
[Tue May  5 10:05:30 2020] psmouse serio1: Touchpad at isa0060/serio1/input0 
lost synchronization, throwing 5 bytes away.
[Tue May  5 10:05:31 2020] psmouse serio1: resync failed, issuing reconnect 
request
[Tue May  5 10:28:17 2020] psmouse serio1: Touchpad at isa0060/serio1/input0 
lost sync at byte 6
[Tue May  5 10:28:17 2020] psmouse serio1: Touchpad at isa0060/serio1/input0 
lost sync at byte 6
[Tue May  5 10:28:17 2020] psmouse serio1: Touchpad at isa0060/serio1/input0 
lost sync at byte 6
[Tue May  5 10:28:17 2020] psmouse serio1: Touchpad at isa0060/serio1/input0 
lost sync at byte 6
[Tue May  5 10:28:17 2020] psmouse serio1: Touchpad at