- Arch-general - lists.archlinux.org

[arch-general] Resume from sleep doesn't work any more
by Andy Pieters 08 Mar '21

08 Mar '21

Hi all As per the subject, Arch goes nicely to sleep, but waking up goes wrong. I see the entries in the dmesg logs: [32990.466213] nvidia-modeset: ERROR: GPU:0: Failed detecting connected display devices [32990.466250] nvidia-modeset: ERROR: GPU:0: Failed detecting connected display devices [32990.466256] nvidia-modeset: ERROR: GPU:0: Failure reading maximum pixel clock value for display device DVI-I-1. [32990.466785] nvidia-modeset: ERROR: GPU:0: Failed detecting connected display devices [32990.466791] nvidia-modeset: ERROR: GPU:0: Failure reading maximum pixel clock value for display device HDMI-0. [32990.467214] nvidia-modeset: ERROR: GPU:0: Failed detecting connected display devices [32990.467219] nvidia-modeset: ERROR: GPU:0: Failure reading maximum pixel clock value for display device HDMI-1. [32990.467678] nvidia-modeset: ERROR: GPU:0: Failed detecting connected display devices Which are mentioned in the Arch Linux NVIDIA troubleshooting: https://wiki.archlinux.org/index.php/NVIDIA/Troubleshooting#System_does_not… I have applied the fix: sudo strings /sys/firmware/acpi/tables/DSDT | grep -i 'windows ' | sort | tail -1 Windows 2015 cat /boot/loader/entries/arch.conf title Arch Linux linux /vmlinuz-linux initrd /intel-ucode.img initrd /initramfs-linux.img options root=UUID=0d9c3207-a30f-4273-95fa-80e0cf5624ba rw nvidia-drm.modeset=1 resume=PARTUUID=82a0cf4c-5d39-7647-94e3-be1a46741847 acpi_osi=! \"acpi_osi=Windows 2015\" Which is how I boot: cat /proc/cmdline initrd=\intel-ucode.img initrd=\initramfs-linux.img root=UUID=0d9c3207-a30f-4273-95fa-80e0cf5624ba rw nvidia-drm.modeset=1 resume=PARTUUID=82a0cf4c-5d39-7647-94e3-be1a46741847 acpi_osi=! \"acpi_osi=Windows 2015\" I've tried any combination of with and without quotes But resuming from spend still doesn't work. I don't recall exactly when this started happening but things used to work for years... This system has got a built-in Intel GPU and I can switch between setting the intel as IGD in the cmos. but using this setting has no bearing...

1 0

[arch-general] pkgstats and detailed hardware information
by u34＠net9.ga 06 Mar '21

06 Mar '21

Am I right that pkgstats does not collect detailed information about the hardware used? Is it a good idea that it will asks permission for doing that? -- u34

1 0

Re: [arch-general] [arch-dev-public] RFC: Use x86_64-v2 architecture
by mpan 06 Mar '21

06 Mar '21

If a separate arch/repo is going to be set up, perhaps it would be wiser to go straight for v3? May yield even better results and eliminates the need to bump the version after a few years. Since people have a choice, there is no risk of leaving v1 and v2 users behind. If there is going to be a “hard bump” in requirements, giving no option to use older hardware, I would like to point out that there are a few issues. • Somewhere in the thread it was mentioned that we’re talking about CPUs older than 15 years. Mine (E5300) is Q4 2008 and it is v1, with the highest point in sales occurring even later: I bought it around 2010 and it was by no means considered “old” at the time. That means machines not older than 10 years are being eliminated. • I see surprisingly many people claim they do not support v2. It’s hardly reliable data, but it suggests that such a change is closer to kicking out 1/4 of the user base than “unimportant” 1%. • So far no hard data to support the change, in particular one that would outweigh the downsides. It’s undeniable that tuning for newer CPUs increases performance in *some* software. But not only users of such programs, if they care about speed, compile them themselves; but — more importantly — that type of software does not represent the typical user experience. To argue such a change makes sense, one has to either provide data showing improvement, that is both statistically significant and noticeable, or the gain would have to be so huge that no further testing is needed (e.g. 50% increase in speed). For a typical user, not some selected pieces of software or synthetic tests. So far the only arguments I hear are “because it’s newer” and, in this thread, that someone believes the battery life got extended (though by unknown factor and that only applies to laptops). Wasn’t the latest mkinitcpio move to zstd enough of a warning? • The change forces throwing away perfectly good hardware. Sure, abandoning 686 did the same, but then it was a question of maintaining a separate architecture, the arguments were very strong and in the end 686 users would be left behind anyway with or without Arch’s move to x86_64 only. In here we’re talking only about unquantified performance and battery life improvement. I believe that a separate arch/repo would be a better idea.

1 0

[arch-general] Why move LTS to 5.10 when VirtualBox guests Kernel Panic with 5.10?
by David C. Rankin 24 Feb '21

24 Feb '21

Archdevs, You move of both linux and linux-lts to the same kernel is bewildering. That eliminates all fallback capability lts provides. Currently, virtualbox Arch guests are broken on 5.10 (as with most other distros). See: https://www.virtualbox.org/ticket/20055 With linux on 5.10 and lts on 5.4 it was workable to have lts guests. Now you have linux and linux-lts as the same kernel. How does that make sense? -- David C. Rankin, J.D.,P.E.

11 18

[arch-general] PAM 1.3.1 -> 1.5.1 did pam_tally get removed?
by Anton Hvornum 24 Feb '21

24 Feb '21

Hi. This might be suited for the newbie corner, but I'm testing my luck with the mailing list for the first time. I can't remember if I've added the following to /etc/pam.d/system-login or not: auth required pam_tally2.so onerr=succeed file=/var/log/tallylog The reason why I'm asking is because after a system upgrade, that line has now disappeared. And I did not see anything on the archlinux bulletin board about a pam change. The tally logs still appear to update however, just not through the system-login config. Best wishes: Anton Hvornum

7 7

[arch-general] Relicencing Wiki Content under Creative Commons
by alpabrz＠protonmail.com 22 Feb '21

22 Feb '21

Greeting Archers, I would like to reuse and expand a Template from the ArchWiki for another Wiki. For that it would be ideal to relicence the content from GFDL 1.3 to CC BY-SA 4.0 (Creative Commons Attribution-ShareAlike). This page [1] states that GDFL v1.3 was explicitly designed to make interoperation with Creative Commons possible, but only when the content was created before November 1, 2008. And you can not use this permission after August 1, 2009, which would mean my re-licencing would be illegal. Is this correct or am I missing something here? No-one probably cares but I figured I'd ask here nonetheless. Thanks and salutations, alpabrz [1]: https://www.gnu.org/licenses/fdl-1.3-faq.en.html

1 0

Re: [arch-general] [arch-announce] Moving to Zstandard images by default on mkinitcpio
by Piscium 22 Feb '21

22 Feb '21

On Fri, 19 Feb 2021 at 13:37, Arch Linux: Recent news updates: Giancarlo Razzolini via arch-announce <arch-announce(a)lists.archlinux.org> wrote: > > As linux-lts moved to the 5.10 version, all official kernels of Arch Linux now support zstd compressed > initramfs images, so mkinitcpio is switching to zstd compressed images by default with version 30, > which is currently on [testing]. > > If, for any reason, you are using a kernel version prior to 5.9, make sure to change mkinitcpio.conf > COMPRESSION to use one of the compressors supported, like gzip, otherwise you **will not** be able to > boot images generated by mkinitcpio. I am not sure I understand this. If someone has the default mkinitcpio.conf it won't boot? In my case I set it to lz4 over a year ago for speed.

16 24

[arch-general] About package guidelines
by Óscar García Amor 21 Feb '21

21 Feb '21

Hi, When a user submit a package to AUR must follow package guidelines. There is an interesting point that says that in the top of PKGBUILD you must respect the previous contributors [1] and credit them (if any). I'm surprised that this is not respected by the trusted users when they pick an arbitrary package that is maintained in AUR and upload it to the community repository without crediting anyone of past maintainers. I saw this course of acting in several packages and don't like to me. It seems to me a total lack of respect towards the person or people who have been keeping the package so far. If users of the AUR are required to have a minimum of netiquette, more should be required of TUs. Greetings. [1]: https://wiki.archlinux.org/index.php/AUR_submission_guidelines -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me

5 5

[arch-general] fail2ban archlinux
by Maykel Franco 17 Feb '21

17 Feb '21

Hi, I've configured fail2ban with action, filter for my php application. My app output log like this: unknown user foo (192.x.x.x) My jail conf: [php-app-login] enabled = true port = 80 protocol = tcp filter = php-app-login logpath = /var/www/php-app-login/var/logs/dev.log findtime = 3600 bantime = 86400 maxretry = 3 ignoreip = 127.0.0.1/8 My filter definition: [Definition] failregex = unknown user .* $<HOST>$ ignoreregex = It works well, but I like fail2ban add comment in iptables rule when add ban IP. For example: iptables -A INPUT -p tcp --dport 80 -m comment --comment "Ban foo" -j DROP iptables -L -n -v Chain INPUT (policy ACCEPT 94 packets, 23457 bytes) pkts bytes target prot opt in out source destination 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 /* Ban foo */ I've googled and I think something needs to be changed in action but I can't find how to pass the user variable to that action.

2 1

[arch-general] [RFC] Potentially deprecating primus, bumblebee, virtualGL and primus_vk
by Emil Velikov 16 Feb '21

16 Feb '21

Hello all, As some of you may know, I have been an Arch user for over 5 years and a Linux graphics developer working on the whole stack from the kernel DRM all the way up-to Mesa and X. I would like to propose, partially deprecating and potentially removing some of the said packages in light of the development that has been happening over the last few years. tl;dr: these solutions have been partially or completely obsolete, for a while now ## OpenGL/GLX/etc # Background As you know, in the early days we would have both Mesa and vendors provide their own libGL.so.1 and in some cases libglx.so (xorg module). Alongside that drivers lacked dynPM, allowing you to powering off the GPU, when it's not used. To address those primus and bumblebee came about. Note: dynPM is mentioned for completeness, it won't be covered any more. # Since then Nvidia and open source drivers support client - Mesa drivers - since v17.2.0 (at least), packaged 7 Sep 2017 - Nvidia drivers - since v390.25 (at least), packaged 29 Jan 2018 ... and server-side glvnd: - xorg-xserver - since v1.20.6, packaged 23 Nov 2019 - Nvidia drivers - since v435.21, packaged 30 Aug 2019 ## Vulkan # Background On the Vulkan side the drivers are clearly separated from the start - libvulkan_$vendor.so. Yet very few applications would bother selecting the GPU, plus server-side (when using WSI_X11) wasn't complete. GL Vulkan interop was also tricky, with libGL.so.1 being provided by vendors. This resulted in primus_vk. # Since then - Mesa drivers - since 20.1.0, packaged 28 May 2020 Driver selection layer was added, falling back to DRI_PRIME [1] - Nvidia drivers - since v390.25 (at least), packaged 29 Jan 2018 Vulkan implicit layer was added - see [2] ## My proposal: Cleanup the packages, as outlined below and update the wiki. Please check out the Extra notes below. I will be more than happy to tackle this although maintainers will have to push/rebuild the packages for obvious reasons. - primus: replace with a simple compat script primusrun, which a) finds the ID_PATH_TAG for the Nvidia GPU and sets DRI_PRIME=$tag $@ - bumblebee: optirun - replace with script calling primusrun xorg config - should not be needed, double-check and drop bumblebeed - (optionally) remove no longer applicable code, config etc bumblebee - remove no longer applicable group - virtual GL: move to AUR, since it has no more users - primus_vk: replace with a simple compat script pvkrun akin to primusrun, making use of [1] and [2] ## Extra notes: - primus/bumblebee - seemingly been abandoned upstream for 4+ years. Arch maintainers having to carry fixes locally. - primus/virtualgl/primus_vk performance is worse than natively - compat primusrun/optirun/pvkrun are to minimise breakage - some legacy Nvidia drivers may lack support - those drivers live in the AUR, thus a solution for them should also be packaged there. ## Feedback I would love to hear the input from the respective maintainers and the overall Arch developer base as a whole. Is there a particular use-case that I've missed? How would you like this handled - as mentioned above, I'm happy to submit patches be that via Flyspray, email, MR or otherwise. Looking forward to your input -Emil [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1766 [2] http://download.nvidia.com/XFree86/Linux-x86_64/435.17/README/primerenderof…

4 28