- Arch-general - lists.archlinux.org

[arch-general] After upgrade
by piequiex 04 Dec '16

04 Dec '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 upgraded linux (4.8.10-1 -> 4.8.11-1) 4.8.11-1-ARCH [ 65.955101] BUG: unable to handle kernel paging request at ffffffff81e00000 [ 65.956510] IP: [<ffffffff8130b914>] __memmove+0x24/0x1a0 [ 65.957874] PGD 1a09067 PUD 1a0a063 PMD 0 [ 65.959198] Oops: 0000 [#17] PREEMPT SMP [ 65.960489] Modules linked in: nf_log_ipv4 nf_log_common xt_LOG ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_pkttype nf_conntrack_ipv4 nf_defrag_ipv4 xt_owner xt_conntrack nf_conntrack iptable_filter bnep sha256_mb mcryptd sha256_ssse3 sha256_generic dm_crypt joydev dm_mod hid_rmi dell_wmi sparse_keymap mxm_wmi btusb mousedev btrtl uvcvideo btbcm btintel bluetooth videobuf2_vmalloc rtsx_usb_ms videobuf2_memops videobuf2_v4l2 videobuf2_core videodev media memstick intel_rapl dell_led iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal coretemp dell_laptop dell_smbios dcdbas snd_soc_rt5640 elan_i2c snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_soc_rl6231 snd_soc_core snd_compress kvm irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul [ 65.972470] glue_helper ablk_helper cryptd r8169 intel_cstate intel_rapl_perf pcspkr input_leds snd_pcm_dmaengine mac_hid i2c_hid snd_hda_intel i2c_i801 i2c_smbus ac97_bus snd_hda_codec i2c_designware_platform i2c_designware_core mei_me snd_soc_sst_acpi mii thermal battery ac spi_pxa2xx_platform snd_soc_sst_match 8250_dw i915 wmi snd_hda_core video drm_kms_helper snd_hwdep intel_gtt syscopyarea sysfillrect dell_rbtn tpm_tis sysimgblt button fb_sys_fops tpm_tis_core i2c_algo_bit tpm mei shpchp lpc_ich fjes sch_fq_codel sg ip_tables x_tables ext4 crc16 jbd2 fscrypto mbcache rtsx_usb_sdmmc rtsx_usb hid_generic usbhid hid sr_mod cdrom sd_mod serio_raw atkbd libps2 dell_smm_hwmon ahci libahci libata scsi_mod xhci_pci ehci_pci ehci_hcd xhci_hcd usbcore usb_common i8042 serio sdhci_acpi sdhci led_class [ 65.988729] mmc_core evdev speedstep_lib snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_timer snd soundcore wl(PO) cfg80211 rfkill nvidia(PO) drm [ 65.993921] CPU: 2 PID: 892 Comm: loadkeys Tainted: P D O 4.8.11-1-ARCH #1 [ 65.999240] task: ffff8801144a0e40 task.stack: ffff880114510000 [ 66.001963] RIP: 0010:[<ffffffff8130b914>] [<ffffffff8130b914>] __memmove+0x24/0x1a0 [ 66.004774] RSP: 0018:ffff880114513cf0 EFLAGS: 00010246 [ 66.007584] RAX: ffffffff81aa2742 RBX: 0000000000000017 RCX: ffff8801a5516e9f [ 66.010453] RDX: ffff8801a587475d RSI: ffffffff81e00000 RDI: ffffffff81e00000 [ 66.013328] RBP: ffff880114513d48 R08: ffff8801198fec00 R09: ffffffff813f8fda [ 66.016231] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 66.019184] R13: ffff880127316e7d R14: ffffffff81aa2742 R15: ffff8801198fec00 [ 66.022165] FS: 00007f900658e480(0000) GS:ffff88012fb00000(0000) knlGS:0000000000000000 [ 66.025209] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 66.028204] CR2: ffffffff81e00000 CR3: 000000011444d000 CR4: 00000000001406e0 [ 66.031219] Stack: [ 66.034191] ffffffff813f92dc ffff88010000009f ffff8801198fec01 0000000000000016 [ 66.037305] 000000001f326800 ffff880127316e9f ffff88011f326800 ffff88011f326800 [ 66.040367] 0000000000004b49 ffff88012b010800 0000000000000000 ffff880114513dc8 [ 66.043353] Call Trace: [ 66.046208] [<ffffffff813f92dc>] ? vt_do_kdgkb_ioctl+0x34c/0x450 [ 66.049051] [<ffffffff813f3fef>] vt_ioctl+0x8df/0x12a0 [ 66.051806] [<ffffffff81226663>] ? touch_atime+0x33/0xd0 [ 66.054481] [<ffffffff8117a6bb>] ? generic_file_read_iter+0x65b/0x840 [ 66.057111] [<ffffffff813e8735>] tty_ioctl+0x365/0xc70 [ 66.059639] [<ffffffff8118ad36>] ? lru_cache_add_active_or_unevictable+0x36/0xb0 [ 66.062150] [<ffffffff812088a1>] ? __vfs_read+0xe1/0x130 [ 66.064583] [<ffffffff8121c483>] do_vfs_ioctl+0xa3/0x5f0 [ 66.066914] [<ffffffff812095a6>] ? vfs_read+0x96/0x130 [ 66.069176] [<ffffffff8121ca49>] SyS_ioctl+0x79/0x90 [ 66.071345] [<ffffffff815f7ff2>] entry_SYSCALL_64_fastpath+0x1a/0xa4 [ 66.073473] Code: 90 90 90 90 90 90 90 48 89 f8 48 83 fa 20 0f 82 03 01 00 00 48 39 fe 7d 0f 49 89 f0 49 01 d0 49 39 f8 0f 8f 9f 00 00 00 48 89 d1 <f3> a4 c3 48 81 fa a8 02 00 00 72 05 40 38 fe 74 3b 48 83 ea 20 [ 66.078059] RIP [<ffffffff8130b914>] __memmove+0x24/0x1a0 [ 66.080161] RSP <ffff880114513cf0> [ 66.082193] CR2: ffffffff81e00000 [ 66.084178] ---[ end trace 7fe3870b4855ddc6 ]--- - -- Have a nice day! ~~~ This PGP signature only certifies the sender and date of the message. It implies no approval from the administrators of nym.mixmin.net. Date: Fri Dec 2 05:47:40 2016 GMT From: piequiex(a)nym.mixmin.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlhBCv0ACgkQViYZwngkfDtAEgCdHlQyjVfhnqG63kc6J8BK1x1e wEQAn1WYCOIAHtkO1GV212PAJIq56Lzo =TcPW -----END PGP SIGNATURE-----

8 23

[arch-general] abs & sourceforge.net
by piequiex 02 Dec '16

02 Dec '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is what I got from sourceforge while trying to build some packet. *.tar.xz: HTML document, UTF-8 Unicode text, with very long lines *.tar.xz.asc: HTML document, UTF-8 Unicode text, with very long lines REFRESH(5 sec): http://downloads.sourceforge.net/project/*.tar.xz? r=*&ts=*&use_mirror=* SourceForge ____________________ Browse Enterprise Blog Deals Help Create Log In or Join - -- Have a nice day! ~~~ This PGP signature only certifies the sender and date of the message. It implies no approval from the administrators of nym.mixmin.net. Date: Wed Nov 23 21:01:11 2016 GMT From: piequiex(a)nym.mixmin.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlg2A5cACgkQViYZwngkfDuwAgCfRBbgl2WhZdjdcHOYwwNgLF7R xn8AmgMin8Im1MuAvzGAyTxm7hCZHIIl =lpcA -----END PGP SIGNATURE-----

4 4

[arch-general] Xorg Thunderbolt3-HDMI RGB problem
by Prutheus 01 Dec '16

01 Dec '16

Hello! I am on i3 with my Dell XPS 13 9360. I have a THunderbolt3-to-HDMI Adapter from pluggable and a monitor and a cube mini projector. My Problem is, that when I connect the cube mini projector to my adapter and enable it via xrandr, I get projected my screen with rgb-errors, like I can see my screen, but everything is destroyed with rgb- errors, I mean the whole screen is broken with these colors, I really can't see much on it. The funny thing is, when I connect the projector to my docking station, it works fine, so this must be a problem with the thunderbolt3-hdmi adapter. Additionally, to fix this issue, I need to unplug the projector from the adapter, plugin my monitor, plug out my monitor and plugin again the projector, now the rgb-errors are away. STRANGE!!! image: http://i.imgur.com/lu6tnrV.jpg I would be very happy if you can tell me where I can find information, e.g. which log files could be useful to you? Also, if you know a solution, please don't be restrained to tell me. Thanks, your Prutheus

1 0

[arch-general] xterm segfaults selecting true-type and unreadable - OK with fixed
by David C. Rankin 30 Nov '16

30 Nov '16

All, I was cleaning up the default xterm look and feel with tweaks to ~/.Xresources. The primary goal was to get a good looking terminal to use in i3, etc.. as I'm having difficulty stomaching what kde has become -- meaning I'll have to do without my go-to konsole. I have xterm to my liking with a very simple Xresources: xterm*termName: xterm-256color Xterm*saveLines: 4096 XTerm*metaSendsEscape: true xterm*VT100.geometry: 111x63 xterm*faceName: DejaVu Mono:size=8:antialias=false xterm*font: 7x13 XTerm*colorBDMode: true xterm*background: #131518 xterm*foreground: #eff0f1 XTerm*scrollBar: true XTerm*rightScrollBar: true The only problem is selecting 'unreadable' from the font menu results in a segfault. If I switch back to the 'fixed' bitmap font (e.g. turn true-type off), 'unreadable' works fine. I've tried setting 'XTerm*font1: fixed' and 'XTerm*font1: DejaVu Mono', etc. which prevents the segfault, but also makes 'unreadable' stay the same size as 'default'. Does anybody know how to make 'unreadable' work with a true-type selection? -- David C. Rankin, J.D.,P.E.

1 0

[arch-general] On containers. WAS: Re: snapcraft.io ...
by Martin Kühne 30 Nov '16

30 Nov '16

This whole sandboxing and containerisation idiocy is such a pain. Oh look, the apps are not secure, the apps sometimes crash. But you know what, let's take a high level approach, because we're such great managers. Let's NOT make better apps and a better stack by actually writing better multimedia libraries. No, let's instead just lock the stuff in which we use anyway, so they can't do more harm than absolutely unavoidable. Let's face it: those wheels are BROKEN, and what we actually need is an effort to reinvent them a few more times so some of them might hold further scrutiny. Slightly off topic, I know, I'll be back at planning my own world domination myself. cheers! mar77i

11 13

Re: [arch-general] [arch-dev-public] Preparing OpenVPN 2.4.x - possible incompatible changes
by Mauro Santos 29 Nov '16

29 Nov '16

On 29-11-2016 17:00, Giancarlo Razzolini wrote: > Em novembro 29, 2016 14:38 Christian Hesse escreveu: >> >> We need root privileges at initialization phase, no? Privileges are >> dropped >> to nobody/nobody when initialization sequence completed. >> >> If we can make things work with non-root system user... Let me know >> how to do >> that. :D >> > > We just need root for creating the tun devices and destroying them. > I managed to make an entire unprivileged deployment. > > Basically all I need is this: > > [Service] > User=openvpn > Group=openvpn > PermissionsStartOnly=true > ExecStartPre=-/usr/bin/openvpn --rmtun --dev tun0 > ExecStartPre=/usr/bin/openvpn --mktun --dev tun0 --dev-type tun --user > openvpn --group openvpn > ExecStart= > ExecStart=/usr/bin/openvpn --cd /etc/openvpn --config %i.conf --daemon > openvpn@%i --writepid /run/openvpn/openvpn(a)%i.pid --status-version 2 > PIDFile=/run/openvpn/openvpn(a)%i.pid > I see a problem with this, the configuration file is not hard coded (good) but the tun device is hardcoded (bad). What happens if one wants more than one server or client instances? What if the user wants to use tap instead of tun devices? It will also not respect the naming configured in the configuration file, or at least it will have to match tun0. Trying to ship more secure unit files/configuration is good but it seems this would probably be best described in the wiki and let the user implement it if desired. > The config file doesn't need any actual user/group configuration, because > it is already started with the right user/group. It needs to use a > different > iproute binary (which in my case is a script) that has sudo permissions > for the openvpn user to run the ip command as root. > >> >> The new systemd units create this automatically. (Well, >> actually /run/openvpn-client and /run/openvpn-server.) > > Nice to hear this. > >> >> Just followed the link from our wiki [2]. Probably you can make this >> work, >> but I am not convinced this can be packaged to work smoothly. >> Dynamic device naming, up/route-up/... scripts, ... There is lot of stuff >> that can and will break. >> >> Still, if you have some clues on how to package this... >> > > I never meant for you (us) to package such setup. I was > just making the case for a dedicated openvpn system user > and it's run directories. At least one of those is already > taken care of. If we can deploy such unprivileged systemd > units, alongside upstream official ones, it's another matter. > > Personally I'm okay with all of this and I'll accommodate my > setup, no matter how openvpn gets packaged. I had to compile > openvpn for at least two release cycles because of a bug on it[0]. > I think you'll probably remember that one. > > Cheers, > Giancarlo Razzolini > > [0] https://bugs.archlinux.org/task/50090 -- Mauro Santos

1 0

Re: [arch-general] [arch-dev-public] Preparing OpenVPN 2.4.x - possible incompatible changes
by Damjan Georgievski 29 Nov '16

29 Nov '16

>> I do not oppose using whatever upstream is deploying, if it's >> rationale. I just think that we could create a system user for >> openvpn, even if most users will deploy it using root. > > We need root privileges at initialization phase, no? Privileges are dropped > to nobody/nobody when initialization sequence completed. > > If we can make things work with non-root system user... Let me know how to do > that. :D You can have systemd-networkd create the tun (or tap) interface and change its ownership to a specific user, that way openvpn doesn't need privileges for that. That's my setup with a bridged tap interface https://gist.github.com/gdamjan/6b988389afe36e4bb769 for tap interfaces, networkd can also do the ip setup, for tun interfaces, openvpn would need to use ... sudo? -- damjan

1 0

[arch-general] Analysis of ABI changes in the Linux kernel
by Ponomarenko Andrey 29 Nov '16

29 Nov '16

Hello, This is a tracker of ABI changes in the new upstream releases of the Linux kernel (defconfig, x86_64): https://abi-laboratory.pro/tracker/timeline/linux/ The tracker performs backward binary compatibility analysis of all public exported symbols and data types (declared in the ".ksymtab" and ".ksymtab_gpl" sections of the vmlinux binary + system calls) and lists all added/removed symbols. The source code of the tool is published on github: https://github.com/lvc/kernel-abi-tracker The tool can be used to compare ABIs of downstream kernels as well. See README of the project. Enjoy!

1 0

Re: [arch-general] unreadable characters login screen after install SOLVED
by niya levi 29 Nov '16

29 Nov '16

> On Mon, Nov 28, 2016 at 8:55 PM, niya levi via arch-general > <arch-general at archlinux.org > <https://lists.archlinux.org/listinfo/arch-general>> wrote: > >/is there another entry i should have comment , uncommented or added in />//etc/default/grub to make it permenant ? />/shadrock / > If you change things in /etc/default/grub, you have to # grub-mkconfig > -o /boot/grub/grub.chf to make the changes available to grub, whose > config is read at a time when no other file systems are visible... > > cheers! > mar77i thanks everyone for all the advice, i ran grub-mkconfig -o /boot/grub/grub.cfg and it boots up fine now. shadrock

1 0

Re: [arch-general] unreadable characters login screen after install
by niya levi 28 Nov '16

28 Nov '16

> Just to check, does "locale -c charmap" return UTF-8? If yes, then it seems > there is an issue with your default console font (I assume you didn't put > anything like this on the kernel command line). So, try changing the console > font either by the kernel cmdline or at runtime in a tty console: > https://wiki.archlinux.org/index.php/Fonts#Console_fonts . > > Also, what is your graphics card, and how do you load the graphics driver > (automatically, early in ramdisk via MODULES= in mkinitcpio.conf, etc.)? Try > booting with nomodeset at the kernel cmdline to disable KMS and see if your > fonts get back to normal... > > Cheers, > -- > Leonid Isaev locale -c charmap" returns lc_ctype UTF-8 my graphics card is a cirrus logic cl-gd5436 pci 1mb vga card it's loaded automatically, have tried adding nomodeset by pressing e at the boot screen with brings me to grub startup file i added nomodeset to the end of the 'linux /boot/vmlinux' line but no change. i got further by pressing e at boot and changing the GRUB_GFXPAYLOAD_LINUX to GRUB_GFXPAYLOAD_LINUX=text and the console screen displayed correctly, to make it permenant i edited /etc/default/grub and also changed the GRUB_GFXPAYLOAD_LINUX line there but upon reboot i was back to the previous block characters. so i can get a correct display if i press e and edit from there on each bootup, is there another entry i should have comment , uncommented or added in /etc/default/grub to make it permenant ? shadrock

3 2