Hi, On Sat, Feb 27, 2021, 2:56 PM Ray Strode <halfline(a)gmail.com&gt; wrote: seems like this is already in updates. you definitely have the gnome-shell 40.beta installed? could be a pam_fprintd is returning a different error code than expected for no enrolled fingerprint

Hi, On Sun, Feb 28, 2021 at 9:46 AM Hans de Goede <hdegoede(a)redhat.com&gt; wrote: So we've been investigating this in the above upstream link. There is a case where pam_fprintd is returning a code we aren't expecting, but, it shouldn't ever happen :-) pam_fprintd checks up front if there are no enrolled fingerprints and then returns the correct error code in that case. You guys are apparently getting past that part and failing later. Almost as if the prints were there and then a split second later disappeared. One theory is there are files present, but they're unreadable. Maybe because of selinux? Can you try in permissive mode, also output ls -lRZ /var/lib/fprint you can put "debug" on the ends of the lines that say pam_fprintd.so in /etc/pam.d/fingerprint-auth that should make the journal more chatty. --Ray

Hi, Ahh, okay. On Tue, Mar 2, 2021 at 9:31 AM Hans de Goede <hdegoede(a)redhat.com&gt; wrote: Ahhh, okay. So authselect is supposed to be writing out dconf files to set org.gnome.login-screen enable-password-authentication false in /etc when it neuters the fingerprint-auth stack. Can you file a bug? There might also be some pam magic we could do to force it to return AUTHINFO_UNAVAIL in that case and then gnome-shell would DoTheRightThing(tm) even without the dconf change. --Ray

Hi, On Tue, Mar 2, 2021, 11:20 AM Pavel Březina <pbrezina(a)redhat.com&gt; wrote: Sorry, let me summarize (but also see Benjamin's email). Right now, if fingerprint auth is disabled in authselect, it's not disabling fingerprint auth at the graphical login screen. To disable fingerprint auth at the login screen, it needs to write out a dconf file to tweak the enabled authentication methods. I'm pretty sure it used to do this, or at least authconfig did. If it doesn't disable it in the dconf config, the login screen will try to use it. It will then fail, and the user will see an error message blink by 3 times as it keeps retrying. Now, on to Benjamin's point, if the fingerprint-auth service returned AUTHINFO_UNAVAIL, then the login screen would treat the failure as a "service unavailable" failure, and know not to retry, which would be better that status quo. It would fix the user experience, but it's still not as good as not trying in the first place. Of course, it wouldn't have to be an either/or. authselect could write out the dconf config, and make sure the fingerprint-auth stub service returns PAM_AUTHINFO_UNAVAIL instead of falling back to PAM_AUTH_ERR from the pam_deny in /etc/pam.d/other make sense? --Ray

On 3/3/21 11:02 AM, Pavel Březina wrote: https://bodhi.fedoraproject.org/updates/FEDORA-2021-d2afa6dc55 I'll also prepare F33 build.

On rawhide I upgraded to authselect-1.2.2-3.fc35 yet I am still encountering the issue of gdm repeatedly complaining about authentication via fingerprint. I've checked and authselect is using the 'ssd' profile.

# authselect current Profile ID: sssd Enabled features: - with-fingerprint - with-silent-lastlog # authselect check Current configuration is valid. I have verified that both sssd and fprintd are running, and are not logging any errors.

Here's what I see from systemctl status fprintd.service: Getting authorization to perform Polkit action net.reactivated.fprint.device.verify Authorization granted to AuthenTec AES2550/AES2810 to call method 'ListEnrolledFingers' for device :1.72! file_storage_discover_prints() for user 'tom' in '/var/lib/fprint/tom/aes2550/0' scan_dev_storedir(): opendir("/var/lib/fprint/tom/aes2550/0") failed: Error opening directory “/var/lib/fprint/tom/aes2550/0”: No such file or directory Requesting device 'AuthenTec AES2550/AES2810' authorization for method ListEnrolledFingers from :1.74 Getting authorization to perform Polkit action net.reactivated.fprint.device.setusername Getting authorization to perform Polkit action net.reactivated.fprint.device.verify Authorization granted to AuthenTec AES2550/AES2810 to call method 'ListEnrolledFingers' for device :1.74! file_storage_discover_prints() for user 'tom' in '/var/lib/fprint/tom/aes2550/0' scan_dev_storedir(): opendir("/var/lib/fprint/tom/aes2550/0") failed: Error opening directory “/var/lib/fprint/tom/aes2550/0”: No such file or directory It looks like "/var/lib/fprint/" is a completely empty directory on my system.

Hi, On 3/2/21 5:20 PM, Pavel Březina wrote: So it seems there are 4 profiles: [hans@x1 ~]$ authselect list - minimal Local users only for minimal installations - nis Enable NIS for system authentication - sssd Enable SSSD for system authentication (also for local users only) - winbind Enable winbind for system authentication What I want is a profile which uses just the good old /etc files to avoid the overhead of running a local daemon (sssd tends to show up as one of the top 10 wakeup sources in powertop on an idle system) and I also don't want a config which tries to go out on the network. So minimal seems to meet my needs; and although I personally do not have much of a need for fingerprint auth, I don't really see why we could not do fingerprint auth with the minimal config. I'm pretty sure I can manually create a pam-config where this works just fine. I guess its in the name minimal, where as "local" might be (1) a better name. Note I'm not suggesting to add another profile just for this but it would be nice if fingerprint auth would at least be a (default off) feature for the minimal config. Shall I file a RFE issue for this at: https://github.com/authselect/authselect/issues/ ? Regards, Hans 1) Might have been a better name in retrospect, but meh

Hi, On 3/4/21 11:50 AM, Pavel Březina wrote: The problem is that IMHO having sssd enabled by default is really the wrong thing to do for like 95% of our users and defaults should be the settings which are best for most / almost all users. This is really just a symptom of a much bigger problem though, which is that we simply have way too much services / daemon's starting up by default. The output of "ps aux" after a default Fedora workstation install is just way way too long. Once upon a time Linux users used to make fun of Windows with all its background processes in the mean time a default Fedora WS install has gotten worse then Windows wrt background processes. Any of these are totally unnecessary for most of our users. We really should be smarter here and the config tools which allows a user to enroll in an authentication domain enable the sssd config when that happens and not have this on by default for everyone. So what I would really like to see is a local profile which uses just /etc files + fprintd if there are fingerprints enrolled. Smartcards are a different story, because those likely also need significant extra setup. Where as fingerprints can easily be enrolled from the local UI tools. Rather then opening a ticket, what I would really like to see is a good discussion about why the sssd profile is the default, because IMHO it is a bad default for most users. Regards, Hans

Hi, On 3/4/21 5:38 PM, Stephen John Smoogen wrote: 20 processes is still a lot when e.g. booting from an eMMC or a sdcard those add a significant amount of time to the startupo time. Also a bunch of what you call hw-related processes are not really necessary. E.g. irqbalance is really only needed on multi-CPU-socket or otherwise exotic systems. Modemmanager really should only run when there actually is a modem (it should be hw-activated, but that is easier said then done), smartd is not really useful, it logs smart issues in syslog/the journal but unless someone is actively monitoring those logs it really does not have much added value, etc. But yes your list of 20 processes, and then specifically abrt (which really should be strictly event driven/activated and should not be running all the time) and atd/crond are the ones which I'm talking about. Those + a bunch of processes which GNOME adds on top. E.g. a whole bunch of evolution processes even though I'm not using the calendar integration, see: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3466 But also gnome-software which is running by default to provide a search-provider, which is a nice feature but the RAM consumption really is too high for that feature on systems with less then 2G of RAM (I know the gnome-software guys have been working on reducing the footprint, but it still is quite large). Etc. just for fun do an ls of /etc/xdg/autostart with a default workstation install. Each one of these processes is there for a reason and many of them are small or exit relatively quickly after having been started but together they really add up. IIRC a default GNOME workstation install consumes about 700-800MB of RAM when logged into the desktop on a 1G RAM system. After I've done a bunch of hacks / tweaks to remove a long list of unnecessary (1) processes I have it down to around 400MB of RAM. Note I'm not trying to blame anyone here; and especially not the authors/maintainers of the mentioned packages, but I do wish that we (the Fedora project) could make some time to go over this list and try to stop a whole bunch of programs / daemons from always starting when that is (IMHO) not really necessary. I would really like to see Fedora to become somewhat more lean / go on a diet here, which is something which I think would benefit everyone. Given that I can halve the base processes RAM set with some hacks I think that it is fair to say that there are still way too much things starting by default. I have actually been considering doing a Fedora workstation light spin for budget x86 machines with 1G / 2G of RAM and an eMMC. Regards, Hans 1) I do realize that what is unnecessary or not is somewhat in the eye of the beholder.

On Thu, 4 Mar 2021 at 13:50, Hans de Goede <hdegoede(a)redhat.com&gt; wrote: snip The problem is that every time this conversation starts... you end up with 200 people all wanting some other program to be stopped/not run/removed but not something they actually think is essential. And instead we end up finding we needed to add one or two things because a lot of users wanted this or that. Workstation like Server like Cloud are going to be general operating systems which are built around fitting the majority of problems people want solved versus a small set of things you or I want in a system. This leads to compromises.. a lot of them. Given that I can halve the base processes RAM set with some hacks I think I agree and think that a spin would be needed. There is going to be an audience for it, but I expect it is a distinct set who are looking for it on small environments and can put up with not having access to 'XYZ app which needs 12 GB of ram out the block' -- Stephen J Smoogen.

On Thu, Mar 04, 2021 at 02:43:26PM -0500, Stephen John Smoogen wrote: I think there's probably three things: 1. A lightweight spin for more extreme use cases 2. Looking at the big things like packagekitd and gnome-software that could perhaps be altered or slimmed down. (For example: perhaps a much more lightweight process for _just_ the search provider, and maybe even something that doesn't need to run all the time to provide that?) 3. Working to move more things to be activated only when needed, or only run when they make sense. Modem Manager, Speech Dispatcher.... I see I'm running bluetoothd on my desktop system which does not have bluetooth. And I don't sync my calendar to my desktop, so all of the infrastructure for doing that is just running for no reason. -- Matthew Miller <mattdm(a)fedoraproject.org&gt; Fedora Project Leader

On Thu, Mar 04, 2021 at 07:50:11PM +0100, Hans de Goede wrote: I agree, we really have too many things starting, to many things running, and too many things generating errors. Instead of 'ps aux', 'systemctl -t service --state running' is easier to interpret: UNIT LOAD ACTIVE SUB DESCRIPTION accounts-daemon.service loaded active running Accounts Service alsa-state.service loaded active running Manage Sound Card State (restore and store) ^ do we really need this avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack bluetooth.service loaded active running Bluetooth service colord.service loaded active running Manage, Install and Generate Color Profiles cups.service loaded active running CUPS Scheduler ^ this should be socket activated, I haven't printed *anything* on this machine ever dbus-:1.2-org.freedesktop.problems@0.service loaded active running dbus-:1.2-org.freedesktop.problems@0.service dbus-broker.service loaded active running D-Bus System Message Bus firewalld.service loaded active running firewalld - dynamic firewall daemon gdm.service loaded active running GNOME Display Manager geoclue.service loaded active running Location Lookup Service gpm.service loaded active running Console Mouse manager iio-sensor-proxy.service loaded active running IIO Sensor Proxy service libvirtd.service loaded active running Virtualization daemon low-memory-monitor.service loaded active running Low Memory Monitor ^ this is interesting. gnome-shell.rpm requires lower-memory-monitor.rpm, and the default preset is on. Do we still want this with systemd-oomd being on by default? mcelog.service loaded active running Machine Check Exception Logging Daemon ModemManager.service loaded active running Modem Manager NetworkManager.service loaded active running Network Manager pcscd.service loaded active running PC/SC Smart Card Daemon pmcd.service loaded active running Performance Metrics Collector Daemon pmie.service loaded active running Performance Metrics Inference Engine pmlogger.service loaded active running Performance Metrics Archive Logger polkit.service loaded active running polkit.service sssd-kcm.service loaded active running SSSD Kerberos Cache Manager sssd.service loaded active running System Security Services Daemon switcheroo-control.service loaded active running Switcheroo Control Proxy service systemd-homed.service loaded active running Home Area Manager ^ hmm, I would think this would be go away on its own. Maybe something to fix upstream. systemd-journald.service loaded active running Journal Service systemd-logind.service loaded active running User Login Management systemd-machined.service loaded active running Virtual Machine and Container Registration Service systemd-networkd.service loaded active running Network Service systemd-resolved.service loaded active running Network Name Resolution systemd-timesyncd.service loaded active running Network Time Synchronization systemd-udevd.service loaded active running Rule-based Manager for Device Events and Files systemd-userdbd.service loaded active running User Database Manager udisks2.service loaded active running Disk Manager upower.service loaded active running Daemon for power management user(a)1000.service loaded active running User Manager for UID 1000 user(a)6.service loaded active running User Manager for UID 6 wpa_supplicant.service loaded active running WPA supplicant Then there's 'systemctl --user -t service --state running' which is even longer :( E.g. at-spi-dbus-bus.service has it's own dbus-broker instance. That's better than in the past, at least it's not a different implementation of dbus than the session bus ;) But we should consider if we can use the session bus again. (In the past, dbus-daemon wasn't efficient enough, so a separate bus was created. But dbus-broker is supposed to be more efficient.) As one of those, I would say that the authors/maintainers of those packages are the people best positioned to fix things. For example, systemd-homed probably shouldn't be running, but this is something to figure out upstream. (BTW, one thing which has improved a lot in this list is the pcp stack. It's still 3 services with ~10 processes altogether, but the total memory usage is <50MB, and CPU usage which was excessive last year is reasonable. The maintainers put in the work here.) Yes. I think there's still plenty of stuff to improve that will apply everywhere. homed, alsactl, geoclue, colord just shouldn't need to be there all the time. Zbyszek

On Fri, Mar 05, 2021 at 03:05:00PM +0100, Hans de Goede wrote: I disagree that those logs are useless -- I often help normal users, and running commands to look back in the logs for problems is a common diagnostic step. This could be better, of course. I am interested in it happening but can't sign up for more stuff. :) It seems like this kind of parallels the Minimization objective (which focuses on package dependencies). That's kind of mothballed right now (I think because Adam is working on RHEL 9 stuff?) and I wouldn't want to overload that more, but maybe there's some kind of useful connection? -- Matthew Miller <mattdm(a)fedoraproject.org&gt; Fedora Project Leader

On Fri, Mar 05, 2021 at 05:12:34PM +0100, Tomasz Torcz wrote: It can, but most people don't have a good setup for even local mail delivery. Out of the box, we don't really do anything useful. It'd be nice for our desktop offerings to have some kind of way of showing these messages in a helpful way. -- Matthew Miller <mattdm(a)fedoraproject.org&gt; Fedora Project Leader

On Fri, Mar 05, 2021 at 05:25:40PM +0000, Zbigniew Jędrzejewski-Szmek wrote: Right??? It might be worthwhile sometime actually making that a release focus. We had someone on Ask Fedora last night posting about basically every warning message he got asking what was wrong and how to fix it, and I don't _really_ feel great about "oh yeah, that's just noise... I mean, it's a real problem, but not a big deal, the message isn't meant for you... just ignore it" as the answer. -- Matthew Miller <mattdm(a)fedoraproject.org&gt; Fedora Project Leader

On Sat, Mar 06, 2021 at 06:04:33PM +0000, Zbigniew Jędrzejewski-Szmek wrote: Well also, we could resolve some of them. Like from here: https://ask.fedoraproject.org/t/systemd-sysv-generator-lacking-native-fil... [ 4.767388] systemd-sysv-generator[1062]: SysV service '/etc/rc.d/init.d/livesys' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. [ 4.767416] systemd-sysv-generator[1062]: SysV service '/etc/rc.d/init.d/livesys-late' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. [ 4.771792] zram_generator::generator[1064]: Creating dev-zram0.swap for /dev/zram0 (4096MB) [ 3.109161] systemd[1]: /usr/lib/systemd/system/plymouth-start.service:15: Unit configured to use KillMode=none. This is unsafe, as it disables systemd's process lifecycle management for the service. Please update your service to use a safer KillMode=, such as 'mixed' or 'control-group'. Support for KillMode=none is deprecated and will eventually be removed. [ 3.128105] systemd[1]: /usr/lib/systemd/system/alsa-restore.service:15: Standard output type syslog is obsolete, automatically updating to journal. Please update your unit file, and consider removing the setting altogether. [ 3.139960] systemd[1]: /usr/lib/systemd/system/mcelog.service:8: Standard output type syslog is obsolete, automatically updating to journal. Please update your unit file, and consider removing the setting altogether. -- Matthew Miller <mattdm(a)fedoraproject.org&gt; Fedora Project Leader

Matthew Miller wrote: I thought it would send email, but then I noticed that it's started with "--capabilities", which breaks email notification according to the manpage, so now I don't know what to believe. It does indeed seem much less useful if it can't send email. Unless Logwatch picks up the warnings from the log? But that again requires local email. It wouldn't take much. Install Postfix, and when Anaconda creates the first user account, have it add a mapping from root to that username in /etc/aliases. Then a variety of MUAs can pick up the emails from /var/spool/mail. But I guess those who want fewer daemons won't be happy to see Postfix added just for a chance to be warned about an imminent breakdown. Björn Persson

Dnia Sun, Mar 07, 2021 at 12:55:21PM -0500, Matthew Miller napisał(a): I have vague recollection of GNOME popup warning me about disk problems discovered by SMART. I see /usr/libexec/gsd-disk-utility-notify running in my session, that was probably the source of the notification. -- Tomasz Torcz “God, root, what's the difference?” tomek(a)pipebreaker.pl “God is more forgiving.”

Do any of the bugs in this thread need to be proposed as blockers or freeze exceptions, for beta or final? This looks like it might have been lost in process because it got closed due to a fix for Fedora 33 instead of staying open until the F34 fix goes stable. https://bugzilla.redhat.com/show_bug.cgi?id=1933520 And a similar sounding bug that's affecting some users: https://bugzilla.redhat.com/show_bug.cgi?id=1935331 -- Chris Murphy

Hi, On 3/5/21 4:17 PM, Matthew Miller wrote: But for MCE exceptions, specifically ECC errors I would expect the kernel to log these through dmesg anyways and then the mcelog service has very little added value IMHO (I have no experience with machines with ECC RAM). Esp. given that ECC RAM is something which most Fedora Workstation users won't have, so having this included / enabled by default feels wrong IMHO. smartd at least has the fact that if it does not run nothing else is asking the disk for its smart reports going for it (and that it may tickle bugs in some disks, which otherwise would not be tickled, going against it). Note I still think smartd is of questionable value too, esp. as long as any messages which it sends out only end up in the journal and are note pushed to the user inside the UI in some way. As for the argument that it sends email if local email delivery is setup, well we don't set that up OOTB and this is about OOTB configuraiton, someone who can setup local email can also do a "dnf install smartd". I know the feeling. This is more about runtime overhead, where as the Minimization objective focuses more on pure disk-space consumption. Sure, there is some overlap but not much. Regards, Hans

On Sun, Mar 7, 2021 at 11:28 am, Björn Persson <Bjorn(a)xn--rombobjrn-67a.se&gt; wrote: No, ABRT used to regularly warn me about thermal events from MCE when I didn't have a good enough CPU fan. That was an Intel machine. I fixed it by replacing the CPU cooler. Thanks, ABRT and MCE. I think I saw some bug fly by several years ago that ABRT's MCE support had broken. Dunno if it still works or not. But it used to work. Michael

On Sun, Mar 07, 2021 at 10:00:56AM +0100, Hans de Goede wrote: It seems mce events can also be generated by the CPU. From the man page: data corruption detected in the CPU caches, in main memory by an integrated memory controller, data transfer errors on the front side bus or CPU interconnect or other internal errors. ... When an uncorrected machine check error happens that the kernel cannot recover from then it will usually panic the system. In this case when there was a warm reset after the panic mcelog should pick up the machine check errors after reboot. It seems like it could be useful even without ECC… I think it's useful to have hardware errors logged, even if nobody immediately looks at them. If a laptop gets broken, and a more knowledgeable persons is asked to look at it and there are hardware errors in the log, be it from mce or smart, that is a very effective way to diagnose the issue and save a few hours wasted on trying to figure out an elusive bug. (This also applies to logs attached in bugzilla: especially when we had the service watchdog enabled, people would regularly report services "hanging". It seems many of those were caused by disk issues, and it's nice to have smartd in there.) In summary: in both cases, I think keeping mcelog and smartd (and other similar things) enabled by default is still useful. We should just make sure they quickly and quietly exit if not applicable on given hardware. Zbyszek > >> So given that I got a couple of "go for it" reactions and that I was > >> already toying with the idea anyways I might actually try to make such > >> a spin happen. > >> > >> The biggest problem for doing such a spin is finding the time for it... > >> > >> Are there any people who would be interested in working on / co-maintaining > >> such a spin with me ? > > > > I am interested in it happening but can't sign up for more stuff. :) > > I know the feeling. > > > It seems like this kind of parallels the Minimization objective (which > > focuses on package dependencies). That's kind of mothballed right now (I > > think because Adam is working on RHEL 9 stuff?) and I wouldn't want to > > overload that more, but maybe there's some kind of useful connection? > > This is more about runtime overhead, where as the Minimization objective > focuses more on pure disk-space consumption. Sure, there is some overlap > but not much. > > Regards, > > Hans > _______________________________________________ > devel mailing list -- devel(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

On Fri, Mar 05, 2021 at 12:56:57PM +0000, Zbigniew Jędrzejewski-Szmek wrote: firewalld, too. For most users it's just putting a static configuration into place once. A little more complicated with virtual machine networking (possibly container stuff too) but even then it's not something that really needs to be always on. -- Matthew Miller <mattdm(a)fedoraproject.org&gt; Fedora Project Leader

Hi, On 3/5/21 11:59 AM, Pavel Březina wrote: Oh, that sounds interesting / sounds like a good development. I'll patiently await the change page for this. Regards, Hans

I'll add that I just hit this today on an old laptop running rawhide. I didn't spend much time debugging the problem, but I did not see any obvious errors being reported in the journal and simply disabling fprintd did not resolve the issue with gdm. Masking fprintd, as Hans noted, is the big hammer workaround.