August 2018 - Arch-general - lists.archlinux.org

[arch-general] i3stats depends on wireless_tools, causing "firmware load for regulatory.db failed" w/o wireless-regdb
by David C. Rankin 16 Aug '18

16 Aug '18

Archdevs, There seems to be a funny depends (or missing depends) issue for *some* systems without wireless that have i3status installed. This appears to be because i3stats depends on wireless_tools, which during boot triggers an attempt to load /var/lib/regulatory.db -- which fails because the file doesn't exist with the following: [ 11.924427] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 11.928144] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 11.928215] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 11.928219] cfg80211: failed to load regulatory.db This issue was touched on from a different angle in: https://bbs.archlinux.org/viewtopic.php?id=234568 The /var/lib/regulatory.db file is provided by wireless-regdb (a dependency of crda), but neither are a dependency wireless_tools. I don't know exactly what hardware triggers the attempt to load on systems without wireless. I have 2 SuperMicro boards that do throw the error, but similar setups on MSI and Gigabyte that don't. The error appears harmless, so I don't know if it is something that should even be addressed, but I thought I'd pass it along and let you devs make the call. -- David C. Rankin, J.D.,P.E.

5 6

Re: [arch-general] Thoughts
by John Ramsden 16 Aug '18

16 Aug '18

I wouldn't mind taking a look as well. -- John Ramsden On Wed, Aug 15, 2018, at 2:44 PM, Robin Broda via arch-general wrote: > On 8/15/18 5:18 PM, Yury Grebenkin via arch-general wrote: > > please let me know and I will send you a copy as a plain text file > > Instead of turning this into a single-way "me too" thread, > just share whatever you have upfront. > > kthx > > -- > Rob (coderobe) > > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

1 0

[arch-general] Booting EFISTUB Kernel: Tianocore Wants *.efi.
by Ralph Corderoy 12 Aug '18

12 Aug '18

Hi, I've an Asus C200M Chromebook with coreboot and TianoCore UEFI newly flashed. Today was spent working through the wiki to have it EFISTUB boot a kernel in ESP. The disk has a ESP partition, and a root partition that's LUKS dmcrypt'd. (All this is new to me.) I used efibootmgr(8) to add a boot menu item, and I changed the order so it was second after USB. https://wiki.archlinux.org/index.php/EFISTUB#Using_UEFI_directly On finishing the installation and rebooting, I ended up EFI shell without any visible errors. Poking about, I could see ESP had `\vmlinuz-linux', in EFI terms, and the two initrds. Explicitly running the kernel, e.g. `fs0:\vmlinuz-linux' either did nothing, or said it wasn't the right kind of thing. I forget. On a hunch I used EFI's `cp' to copy it to `\vmlinuz-linux.efi'. `ls' then shows it in a different colour to its source and it booted with `\vmlinuz-linux.efi'. Where along the line do I arrange for the kernel to end with `.efi'? -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy

1 0

[arch-general] valgrind error -- the 'impossible' happened?? (fully updated Arch system)
by David C. Rankin 12 Aug '18

12 Aug '18

After update to current (as of now linux 4.17.14, and I just tested with 4.17.13 and the error is there too), valgrind fails with an 'impossible' error: ===== error start $ valgrind ./bin/opendir_readdir_dyn_char_basic ==1196== Memcheck, a memory error detector ==1196== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==1196== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==1196== Command: ./bin/opendir_readdir_dyn_char_basic ==1196== valgrind: the 'impossible' happened: Unsupported arch_prctl option host stacktrace: ==1196== at 0x580441BA: show_sched_status_wrk (m_libcassert.c:355) ==1196== by 0x580442D4: report_and_quit (m_libcassert.c:426) ==1196== by 0x58044517: panic (m_libcassert.c:502) ==1196== by 0x58044517: vgPlain_core_panic_at (m_libcassert.c:507) ==1196== by 0x5804454A: vgPlain_core_panic (m_libcassert.c:512) ==1196== by 0x580DAE22: vgSysWrap_amd64_linux_sys_arch_prctl_before (syswrap-amd64-linux.c:286) ==1196== by 0x580A0C23: vgPlain_client_syscall (syswrap-main.c:1857) ==1196== by 0x5809D48A: handle_syscall (scheduler.c:1126) ==1196== by 0x5809EBB6: vgPlain_scheduler (scheduler.c:1443) ==1196== by 0x580AED50: thread_wrapper (syswrap-linux.c:103) ==1196== by 0x580AED50: run_a_thread_NORETURN (syswrap-linux.c:156) sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 1196) ==1196== at 0x401A1C5: ??? (in /usr/lib/ld-2.28.so) ==1196== by 0x178BFBFE: ??? Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. ===== error end My question is does this look like an arch issue or is it just a kde upstream issue? I was answering a question on SO with a simple opendir/readdir of names into a dynamically allocated pointer-to-pointer-to-char and was showing how to test with valgrind. To my surprise valgrind croaked on Arch, but ran fine on SuSE and an old Arch box, so there is something wrong in the current valgrind on Arch. test source file at https://stackoverflow.com/questions/51804567/c-writing-readdir-to-char-arra… (it just reads the contents of the directory given as the first argument ('.' default) and qsorts and outputs the stored names before freeing the names and pointers. -- David C. Rankin, J.D.,P.E.

2 2

[arch-general] Reliability test for hard drives and SSD
by Andrey Ponomarenko 10 Aug '18

10 Aug '18

Hi there! Good news for all interested in hardware compatibility and reliability. I've started a new project to estimate reliability of hard drives and SSD in real-life conditions based on the SMART data reports collected by Linux users in the Linux-Hardware.org database since 2014. The initial data (SMART reports), analysis methods and results are publicly shared in a new github repository: https://github.com/linuxhw/SMART. Everyone can contribute to the report by uploading probes of their computers by the hw-probe tool! The primary aim of the project is to find drives with longest "power on hours" and minimal number of errors. The following formula is used to measure reliability: Power_On_Hours / (1 + Number_Of_Errors), i.e. time to the first error/between errors. Please be careful when reading the results table. Pay attention not only to the rating, but also to the number of checked model samples. If rating is low, then look at the number of power-on days and number of errors occurred. New drive models will appear at the end of the rating table and will move to the top in the case of long error-free operation. Thanks to ROSA, Arch, Fedora, Ubuntu, Debian, Mint, openSUSE, Gentoo users and others who had made this work possible by contribution to the database!

3 8

[arch-general] Can I build Arch Linux from Scratch?
by Turritopsis Dohrnii Teo En Ming 09 Aug '18

09 Aug '18

Good morning from Singapore, Can I build Arch Linux from Scratch like Linux from Scratch? Please advise. Thank you. ===BEGIN SIGNATURE=== Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 30 Oct 2017 [1] https://tdtemcerts.wordpress.com/ <https://tdtemcerts.wordpress.com/>[2] http://tdtemcerts.blogspot.sg/ <http://tdtemcerts.blogspot.sg/>[3] https://www.scribd.com/user/270125049/Teo-En-Ming <https://www.scribd.com/user/270125049/Teo-En-Ming>===END SIGNATURE===

4 3

Re: [arch-general] Kernel source URL change
by Geo Kozey 08 Aug '18

08 Aug '18

On August 8, 2018 4:54 AM, Giancarlo Razzolini via arch-general <arch-general(a)archlinux.org> wrote: > Em agosto 7, 2018 23:31 W B via arch-general escreveu: > > > It isn't an order. > > > > > Can you tell us why this change was required, please? > > Have you read the original post to the list? Specially this [0]? > The author of original post was only speculating about possible reasons for the recent changes. He also asked few questions which weren't answered. > Those tar files you just linked are not signed by Linus anymore, they are signed > instead by Greg Kroah-Hartman. You would have known this if you bothered to actually > download them and check the signature. > Greg Kroah-Hartman PGP key was already included as validpkgkey inside PKGBUILD so there is no real argument here. > Another reason for this move is to apply our patches as commits. You can use any other > kernel if you want. > There is no tradition in Arch to self-host package sources as Debian does unless upstream has completely broken release process. This can impose security risks on Arch as we now have to trust their github infra rather than kernel.org (we all know what happened to gentoo recently). I'm aware that Barthalion made an effort to hardenize Arch github infra but still this is a new risk which didn't exist before. Is it general Arch move to self-host sources and applying patches as commits or will linux kernel package stay as outlier? > [0] https://www.kernel.org/minor-changes-to-tarball-release-format.html > > Cheers, > Giancarlo Razzolini Yours sincerely G. K.

5 5

[arch-general] Kernel source URL change
by Andrey Vihrov 08 Aug '18

08 Aug '18

Hi, Recently the way kernel sources are retrieved was changed in the linux package [1]. Now the sources are fetched from https://github.com/archlinux/linux. I see a few problems with this: - Previously the list of applied patches was very transparent. You could immediately see that the kernel and kernel patch tarballs come from kernel.org, and view individual extra patches. Now the code comes from a non-kernel source, and cannot be verified as easily. - Previously, if a new kernel version is released and is not yet in the repos, you could more or less take the official linux PKGBUILD, change one number and build it yourself. With the new layout it is not clear how to achieve this. - An often cited Arch policy is to use software as released by upstream with minimal patching. What becomes of this policy if one of the core packages builds from a technical fork instead of upstream? If the patches from kernel.org will no longer be signed, as announced in [2], then an alternative would be git tags from [3] and [4]. It's understandable if it may make development harder, nonetheless it would allow for better transparency and follow upstream closer — just one user's opinion. [1] https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/lin… [2] https://www.kernel.org/minor-changes-to-tarball-release-format.html [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ [4] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git -- Regards, Andrey

9 10

Re: [arch-general] Kernel source URL change
by Giancarlo Razzolini 08 Aug '18

08 Aug '18

Em agosto 7, 2018 23:31 W B via arch-general escreveu: > It isn't an order. > > Can you tell us why this change was required, please? > Have you read the original post to the list? Specially this [0]? Those tar files you just linked are not signed by Linus anymore, they are signed instead by Greg Kroah-Hartman. You would have known this if you bothered to actually download them and check the signature. Another reason for this move is to apply our patches as commits. You can use any other kernel if you want. [0] https://www.kernel.org/minor-changes-to-tarball-release-format.html Cheers, Giancarlo Razzolini

1 0

[arch-general] Grub-efi install issue
by Matthew Dyer 07 Aug '18

07 Aug '18

Hi all, I am trying to install arch to a efi system and got as far as the configure the packages but grub install is whare I am stuck. First off, in the wiki it says to mount the efi partition, but it doesn't say whare to mount it to. Secondly, I run the following to install grub-install --target=x86_64-efi --efi-directory=/dev/sda1 --bootloader-id=GRUB and get the following error. something about unable to get the udev. What am I missing? Would something rong? The wiki artical s a bit confusing. Thanks.

2 2