Re: [DNG] Chimaera CPU stuck
Hi Luciano, Am Wed, Sep 14, 2022 at 07:24:07AM +0200 schrieb Luciano Mannucci: > hello all! > > I have a virtual machine running under kvm who started hanging giving > this message just before it dies: > > kernel:[ 296.013011] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! > [swapper/0:0] > > This happens only on high i/o load. > The other virtual machines are all running with no problems. > What should I do? The message actually means, that moving memory pages to/from swap space took much longer than the kernel expects. This can happen when another process is using the entire I/O bandwidth to the disk. I had similar issues with my Desktop PC. It turned out this was somehow related to the 32GB RAM of my machine. When a process writes files, the kernel will cache the data first and executes the actual disk writes later depending on cache fill and time. When a process produces data very fast, the cache will grow more and more even while the kernel is already writing data out to disk and at some point an internal threshold in the kernel is hit. (/proc/sys/vm/dirty_ratio) At this time, the kernel will block all processes writing to disks and flush the entire cache content to the disk. If you have a lot of RAM, this flushing can take a lot of time (seconds till minutes). Large RAM machines are affected by this since the threshold is by default set as ratio from f RAM memory. I mitigated this by reconfigure the so called background write threshold cat /etc/sysctl.d/tuning.conf # The following settings are to avoid long application stalls when # writing large files to disk. They lower the amount of write # cached data in RAM until actual writing occurs. This will prevent # the system from writing data in large chunks while everything # else blocks. So this improves the latency of the desktop # The values are by defaulted computed as fraction of the main memory # which results in fairly large cached unwritten data on high memory # systems # Start background writing when more than 128MB data are in write cache # This value is tuned regarding write performance of HDD ~ 100MB vm.dirty_background_bytes=67108864 vm.dirty_bytes=268435456 Maybe this additional information is helpful: https://forum.proxmox.com/threads/io-performance-tuning.15893/ https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/ Hope that helps, cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] fdisk SD card partitioning question
Hi Fred,
Am Sun, Jun 12, 2022 at 12:35:06PM -0700 schrieb Fred:
> I tried fdisk again with the same result.
>
> root@aragog:# /sbin/fdisk /dev/sdb
> Command (m for help): n
> Partition type
>p primary (0 primary, 0 extended, 4 free)
>e extended (container for logical partitions)
> Select (default p): p
> Partition number (1-4, default 1): 1
> First sector (2048-57626623, default 2048):
> Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-57626623, default
> 57626623):
>
> Created a new partition 1 of type 'Linux' and of size 27.5 GiB.
You shouldn't do that. Although its possible to "partition" SD-Cards,
this is not recommended. This is since SD-Cards have some kind of
knowledge about "how FATFS works" to optimize the write cycles. This
won't work if the card is partitioned.
However, the best way to use SD-Cards in Linux only environments is
to format them with f2fs file system. f2fs was developed by Samsung
with internal behavior of embedded MMC memory devices in mind. Which
is pretty the same like an SD-Card. With f2fs you also have
uid/gid as usual and it will help to improve the endurance and
performance of an SD-Card.
cheers,
Andreas
--
gnuPG keyid: 8C2BAF51
fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51
signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] Nasty Linux systemd security bug revealed
On Wed, Jul 28, 2021 at 03:58:02PM +0200, Didier Kryn wrote: > With all respect due to your work, I tend to think that with such > expensive and dangerous machines, more investment should be put into > hardware so as to get controllers with a decent ram. And maybe the > firmware could take safety action when software crashes. Sure, but I'm not the boss :-) > Similarly, more investment should be put in software so as to make a > review of available languages suited for mssion-critical applications > and invest in learning the chosen language. C and C++ are so error-prone > that they are really not suited. Well, you can implement bugs in any kind of language. To be honest, crashes are the most easy ones to find. I know there are other languages outside but here applies the same as above: I'm not the one to decide. I can just give hints and try to push in some direction. But embedded software development is still driven by myths like "C is faster than C++" and its hard overcome these. Maybe a generation thing. My personal way to push through this is to run as much (automated) firmware tests in our hardware-in-the-loop test system as possible. And to have a testcase for every single requirement, situation, sequence or ever seen bug in the software. We end up to have 20-30 testruns a day distributed among different test setups, SoC cpu generations, operating systems. The only missing thing is kind of developer slap robot to punish the developer who made the bad commit automatically :-) > This went far off topic. I have more on the initial topic but am > getting tired (~: Haha, sure :-) cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Nasty Linux systemd security bug revealed
On Sun, Jul 25, 2021 at 07:51:50PM -0400, Steve Litt wrote: > g4sra via Dng said on Sun, 25 Jul 2021 10:26:46 + > > > >And this is why ever sice I entered the profession I have maintained > >that programmers should be vetted and certified in a similar manner to > >other professions such as doctors and lawyers, carrying a similar > >social status. Only those with the appropriate qualification and > >experience should be permitted to work in certain sectors. > > I'm glad you said "certain sectors". I'm glad there are other sectors > (office automation comes to mind) where a guy who gets proficient with > the computer on his kitchen table can get paid work, and learn there. > Otherwise, programming would be restricted to folks rich enough for > their parents to send them to college to learn programming, and then > a triciary education to learn all the security, defense and engineering > stuff, and like doctors and lawyers, they wouldn't start making any > real money until their late 20's. > > Programmers would be selected for family wealth, not for desire and > aptitude. My feeling is, that you can not simply teach someone how to write safe software. It is to a great extend a matter of experience and character if someone is able to do it or not. Experience means, you need to fall into the traps to understand whats going on and whats a bad design. Maybe kind of pair programming can help. But in the end all developers are human and need to start somewhere. Of course there should be continued trainings. And the second thing, nowadays not only managers but also developers are exposed to various kind of pressure. You need to resist to go the easy way or to be pushed in that direction by someone else. And this every single day: "Can't we just... Customer is waiting!", "Distribution already sold it, we need to have it (yesterday)...". No one should think of himself being error-prone - certified or not. We're all just humans and misdo. I believe most risks can be easily mitigated with some experienced members in the design phase and highly veteran testers who qualify the results. I also think, its not a good idea to divide a software development work across to many different persons, there should be developers which an understanding of the whole (embedded-)system. If if would be allowing only highly conscientious people to develop software and check their work multiple times by others it will still contain errors. It has just become too complex. Coming back to the sensor above: 10 years ago it was sufficient to just send the sensor state every 10ms to some central control device. Today the same sensor (often based on the same hardware, product owners think its just a matter of the software) should send the data in 250µs intervals and at the same time, serve complex dynamic webpages with TLS encryption and full certificate chain and send diagnostic or production related data to some IoT edge server in order to enjoy management with colorful plots. And during that it is expected to withstand an DoS attack. But the device is still used in the same place, doing the same work. All these extra function are not used in 99% of the cases, but its in the device just in case someone might need it. And this adds complexity which adds bugs. Most things today a profit driven, and result is, that management tries to avoid any (in their eyes) unnecessary work by reusing existing but maybe much to complex code or designs, have one software for all usecases, implement "workarounds" or simply omits tests. To be honest, price pressure is often applied from the outside - e.g. my employer develops some SoC and although these grow in performance and shrink in size, power and extra parts. With every new device, customers expect them to become cheaper and cheaper and get the software for free. cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Nasty Linux systemd security bug revealed
On Sat, Jul 24, 2021 at 05:35:10PM +0200, Didier Kryn wrote:
> However the manual of alloca() states that "There is no error
> indication if the stack frame cannot be extended." If the same would
> happen with automatic variables, I would expect a crash; otherwise it
> would be a serious flaw in the compiler. According to you there is such
> a flaw?
I have just made a short experiment. On linux, typical stack size is
8MB ( ulimit -s). So using the following test program:
stack_overflow.c:
#include
#include
void
test(int size, int use_it)
{
#if 1
volatile int var[size/sizeof(int)];
#else
volatile int* var = alloca(size);
#endif
if(use_it)
var[0] = 0;
}
int
main(int argc, char* argv[])
{
long size = argc > 1 ? atoi(argv[1]) : 1024;
long use_it = argc > 2 ? atoi(argv[2]) : 0;
printf("Will be allocating %ldkb stackframe %s access\n", size, use_it ?
"with" : "without" );
test(size*1024, use_it);
}
I get the following results:
...:/tmp$ gcc -o stack_overflow stack_overflow.c
...:/tmp$ ./stack_overflow 16000 0
Will be allocating 16000kb stackframe without access
...:/tmp$ ./stack_overflow 16000 1
Will be allocating 16000kb stackframe with access
Speicherzugriffsfehler
...:/tmp$ gcc -o stack_overflow stack_overflow.c -fstack-check
...:/tmp$ ./stack_overflow 16000 0
Will be allocating 16000kb stackframe without access
Speicherzugriffsfehler
...:/tmp$ ./stack_overflow 8000 0
Will be allocating 8000kb stackframe without access
So if -fstack-overflow is not used, the program will crash only if
memory is actually accessed out of bounds of the stack memory. Indeed,
accessing the last instead of the first array element does not crash
at all.
With -fstack-overflow it will already crash on allocation of the array.
(as expected)
When using the alloca() way, I get identical results.
Why I'm so critical about letting it crash: I typically deal with stack
sizes of no more around 2-8kB in automation devices and have to be careful
with that. You can't simply let a newspaper printing machine's motor control
crash, 1000's of newspaper pages would be trashed. Once we had a crash in
simple limit switch device. As a result the high-rack robot pushed a
pallet in 15m height out of the rack. Fortunately, it was just another
robot which was destroyed (stood just below) - not a human being. Still
a very expensive case for the company. So I'm used implement a lot of
checks :-). (Actually we even don't use heap allocation after booting
the firmware)
cheers,
Andreas
--
gnuPG keyid: 8C2BAF51
fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51
signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] desktop-live chimaera isos
On Fri, Jul 23, 2021 at 03:56:24PM -0300, Gastón via Dng wrote: > > 2. Desktop PC, CPU: AMD Athlon 64 3000+, GPU: NVIDIA GeForce4 MX 440, > > RAM: 3GB. > >· > > In this PC the problem did not disappear deactivating AppArmor. > >· > > Possibilities: My personal experience with Geforce MX series is, that these cards run very unstable, regardless if used with Windows or Linux. Especially the ones without FAN suffer from thermal issues. Since compositing uses GL acceleration, the chance is high the card just crashes as soon some GL operations are performed and cards warms. In addition, such old hardware may already have cracks in solder junctions or instable onboard power supply due dried capacitors. You could test what happens when running glxgears (in mesa-utils package) in unsynchronized mode for a while. (It will put some load on the GPU): $ vblank_mode=0 glxgears cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Nasty Linux systemd security bug revealed
Hi, On Thu, Jul 22, 2021 at 07:53:58AM +0200, Didier Kryn wrote: > There's a choice of options in GCC to deal with stack protection. > Eg: -fstack-check > > Plus a bunch of macros. > > They all deal with allocation of automatic variables. For alloca(), > instead, there's explicitely no check. I don't find any reference about automatic variables in the docs regarding this topic. Actually, the description of gcc's alloca() builtin states that it behaves similar to automatic variables. However, all these macros will not prevent you from stack overflow but only help you to detect one when it already happened. Also, the way gcc implements the check (probing SP) works for alloca and for automatic variables in the same way. However, once you have detected a stack overflow, your application is in an inconsistent state. Of course you can implement some kind of rescue. (e.g using libsigsev) But you have to do a clean rewind of your app state back to state before the overflow occurred. This can become quite complex and hard to maintain. And then your're back to state before stack overflow, but what is the application supposed to do then? Log and ignore the request? Terminate? Ask the User? The point is, an application should be designed such that a stack overflow just can not occur. And this implies length checking, regardless if using automatic vars or alloca. > In addition, the compiler is not informed of the invocation of > alloca(); therefore the space allocated to non-static automatic > variables may overlap with the space "allocated" by alloca(). No. This is wrong alloca() is implemented as compiler builtin and does exactly the same as GCC does when allocating automatic vars on the stack. Prove: https://godbolt.org/z/abqK4T43c The generated machine code is identical including the stack overflow checking code. cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Nasty Linux systemd security bug revealed
On Wed, Jul 21, 2021 at 02:36:16PM +0200, Didier Kryn wrote:
> added (by gcc ?) to work around a missing feature of the C language:
> dynamic allocation on the stack. This lack has disapeared many years ago
> ( don't know with which version of the C standard) , with the following
> form of allocation:
>
> ...
>
> n = 2x+1;
>
> {
>
> int array[n];
>
> ...
>
> }
>
> And, therefore, alloca() should be removed.
Well, alloca(n*sizeof(int)) and your suggestion both do the same in that
they allocate memory from stack without any checking. Thus both will
show the same failure mode of possible stack overflow.
In any case, the implementation should put some limit on n before
executing alloca() or int array[n].
To be honest, I really don't seesomething against using alloca() despite
its not Posix. Especially, there is no advantage of array[n]
regarding the stack overflow issue.
Of course, critical software should not rely on dynamic stack allocation
since its unpredictable. (but also not on runtime heap allocation too)
cheers,
Andreas
--
gnuPG keyid: 8C2BAF51
fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51
signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] EFI Installation of Beowulf?
Hi Jonathan, On Mon, Feb 22, 2021 at 11:25:14PM +0100, Jonathan Moebius wrote: > I have switched to a new computer and tried to install Beowulf 3.1.0 in a > pure-EFI setting. > I have tried installing on a SATA SSD as well as a a m.2 PCIe SSD. > Originally, I can confirm, that I'm running similar setups with beowulf and pure EFI boot here. So basically this should be working. > the plan was a dual boot install with Win10 being installed first, however > after several failed attempts, I scraped Win10 and went for a Linux-only > install. What does "failed attempts" mean here? Did Windows fail to install or boot? I believe that if Win 10 does not install, then there is probably a problem in your EFI Bios. Maybe older OS versions don't use some new EFI feature which is broken on your hardware? > Installation seems to run smoothly but after reboot grub presents itself > without the "graphical" selection menu but instead delivers the line > "Minimal BASH-like line editing is supported..." That typically happens when grub does not find its config file. You could check if the bootloader has been installed successfully: root@zeus:/home/andi# efibootmgr -v BootCurrent: 0001 Timeout: 1 seconds BootOrder: 0001,000B,0002,0008,0003,0004,0005 Boot0001* debian HD(1,GPT,c00640c3-e748-405b-8139-eeea224542dd,0x800,0x32000)/File(\EFI\DEBIAN\SHIMX64.EFI) ... root@zeus:/home/andi# lsblk -o name,partuuid,mountpoint NAME PARTUUID MOUNTPOINT nvme0n1 ├─nvme0n1p1 c00640c3-e748-405b-8139-eeea224542dd /boot/efi └─nvme0n1p2 b94969ac-596c-460b-9fca-aa911bad2d8c / Did you check that you're using GPT partition table? EFI boot wont work reliably without that. > EFI Partition may be missing or too small My EFI partition is 100M ( 6M used ) > Grub.cfg may be missing > I compared the grub.cfg from Debian and Devuan. Superficially they look very > similar. Depending on if you use a separate /boot partition, some paths/uuid might be different. How did you chroot into your installation? Did you bind mound /dev, /sys, /proc and related filesystems? Also /boot (if needed) and efi need to be mounted to get grub properly installed. Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] NFS+Kerberos on Beowulf
On Sun, Feb 14, 2021 at 12:23:05AM -0700, Jackman via Dng wrote: > Has anyone successfully gotten NFS and Kerberos working together on > Beowulf? I was able to get a working setup going in a fresh Debian Buster > VM in about 10 minutes. On the other hand, I've been working on trying to > get it working on Beowulf for two days without success. I'm currently using samba4 active directory based kerberos with NFS4 (and windows shares) and prior to that i also used MIT kerberos successfully without any issue. On the NFS4 server: cat /etc/exports /srv/nfs4 *(rw,async,root_squash,crossmnt,fsid=0,sec=krb5i,no_subtree_check) /srv/nfs4/Benutzer*(rw,async,sec=krb5i,no_subtree_check) . cat /etc/default/nfs-common NEED_STATD=no STATDOPTS= NEED_IDMAPD=yes NEED_GSSD=yes Could you double check, that the kerberos keytabs for the services are properly configured. You might also check that dns is working properly. > ➜ ~ mount -t nfs4 storage0:/srv/nfs-test /mnt/test -v You need to specify "-o sec=krb5i" when mounting (at least I do that here). I also use the fqdn of the server. -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Can this drive be saved?
Hi golinux, On Fri, Sep 04, 2020 at 01:50:07AM -0500, goli...@devuan.org wrote: > On 2020-09-01 00:07, goli...@devuan.org wrote: > [...] > I have no idea how reliable the repaired drive is after this radical > surgery. Can it be written to or files deleted? Should I even try? > [...] I wouldn't use a drive anymore which has started reallocating sectors, well which has reallocated sectors all. During manufacturing the drive, it can happen that some sectors are bad, but these sectors are already "reallocated" during the manufacturing end test and will not show up in the SMART information. When a magnetic disc drive starts reallocating sectors, it is an indicator that something within drive starts to be become bad/broken. (Or even has been from the beginning of its live) There is a high chance, that one will observe more and more reallocations. And this is a guarantee for data loss. Just for the record: The magnetic drives in my 24/7 NAS are starting/stopping about 5 to 10 times a day (standby), according to SMART these drives now have roughly 15k start/stops and about 7k power on hours: They don't have a single reallocated sector. If you can afford it, I would suggest you to replace it. cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] kernel instabilities
Hi Ricardo, On Thu, May 28, 2020 at 09:24:59AM +0200, Riccardo Mottola via Dng wrote: > I just tried adding "contrib" to my repositories and I see intel microcode > is available, I hope it helps. > > Do you know how this "update" works? will it be applied also when running > older kernels? Typically the microcode update will be prepend to the normal init-ramdisk image during creation of the init-ramdisk. The kernel will load this microcode in a very early stage. See following link for details https://wiki.debian.org/initramfs I remind that I had several issues with some Intel atom based celeron and certain kernel versions. There is a problem with the power saving in these cpus which was not handled properly in the Kernel. Starting with some kernel which used more aggresive power savings, the machine started crashing randomly. I think the problem is not limited to celerons it seems to persist since a while now, more or less solved for some usecases. It relates to the internal GPU of the processors. See here: https://bugzilla.kernel.org/show_bug.cgi?id=109051 You're very likely required to upgrade to a much newer Kernel version. I suggest you to use the most recent stable kernel version and build it from source ( Not that hard, ask me for help if needed) For me the upgrade fixed the issue. cheers, Andreas signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Update successful but video card issue
Hi Tim, On Sat, Feb 01, 2020 at 04:44:07PM +, Tim Wallace via Dng wrote: > Hi Andreas-- > lspci shows this:01:00.0 VGA compatible controller: Advanced Micro > Devices, Inc. [AMD/ATI] Cape Verde GL [FirePro W4100]which shows the > Cape Verde but not the Southern Island. I think all Cape Verde are > that, though. Yes, Cap Verde is Southern Island generation. So we basically have the same card. > The old radeon kernel module paired with the Xorg radeon driver is the > one that gives random annoying flashes. I can almost live with them, but > under virtualbox win7 which my wife runs once a week it is unbelievably > flashy! Maybe it is something completely different: At work I had similar issues with my monitor attached to the notebook dock. From time to time, the monitor turned black for short time and immediately recovered the image. It seemed to align with some other employees switching on or off some devices in the first place, but in the end turned out to be a loosely fitted display port plug. Could it be the cable? I also heard that in some cases a bad or insufficient display port cable led to unstable monitor operation. It could be also a DP link training issue > The newer amdgpu module fails to work with the Xorg amdgpu driver. > This is with ascii, beowulf, and kernels 4.9, 4.19, and 5.4. I'm able > to get them installed, they just won't start. The Xorg amdgpu version > is 18.1, from late 2018, and a 19.1 is out, from 2019, but claims only > minor tweaks. I'm not thinking it's worth bothering to try to compile > that. Hmm strange. I was using standard beowulf Xorg package with self compiled kernel 5.4.7's amdgpu module here without any issues. cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Update successful but video card issue
On Fri, Jan 31, 2020 at 11:03:24AM +, R. G. Sidler wrote: > > Hi Tim, Ludovic and Andreas. > > I installed only the amdgpu-driver. Since I always start with a naked > base install, I never care about blacklisting any drivers, because I > just don't install them Well, the drm (nvidia/amd/..) kernel modules are all installed with a single kernel package so you can only decide which to install by building your own kernel package. Blacklisting is the only way to force them not to load. But I assume you know that, since you're using Debian/Devuan already :) Maybe another thing: Since the W4100 seems to use the Cap Verde / Souther Island GPU kind (Can you confirm this, using lspci -l e.g.?) you have the option of using two different kernel drivers with a recent linux kernel: - radeon: this is the older/mature one (the default one) - amdgpu: this is the newer one which might have flaws with SI chipset You can choose them by setting some kernel module parameters (I did this, through /etc/default/grub recently to try something) And maybe a clarification: The graphics driver is divided into two parts: the kernel module and the xorg driver. The xorg driver in beowulf should be able to play with both kernel drivers, I think the amd proprietary xorg driver only works with the amdgpu kernel module. > @Andreas I decided to install a dedicated AMD workstation graphics card, > since I only do workstation stuff on my Thinkstation > > I prefer a very stable signal over high performance. Did you observe any difference? I mean, the transmission of data between graphics card and display should be digital nowadays. (I owned a FireGL2 a long while ago but remind only the negative aspects of it) cheers Andreas signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Update successful but video card issue
Hello Tim, On Wed, Jan 29, 2020 at 10:05:54PM +, Tim Wallace via Dng wrote: > I have been happily running ascii but upgraded from my Intel built-in > graphics to an AMD FirePro W4100 because I do a lot of 4K video editing, > but no game-playing, and thought this 50W card would save energy and > work well with 4K. There is a nearly identical Nvidia card, but I > decided to support AMD, for easier Linux support, which has not been my > experience! > [...] > Motherboard ASRock Z97 Extreme6, i7-4790K, 16 GB, latest Bios 2.80 > [...] In the hope this won't disappoint you too much, but in my opinion you should have better invested the money into more memory or a fast SSD. The main purpose of AMD FirePro as well as the NVidia Quadro Cards are multi monitor configuration (They have lots of connectors) Do you have multiple monitors? If you compare their specs with the "gamer" cards you'll see that you get much less gpu performance for the same pricing. Their power consumption is low, because they are typically build from the lowest performance chips of a series, Often even clocked down variants. I suppose the W4100 to be something like an R7 250E card, which is actually the same as an Radeon HD7750 (Like mine, 5 years old). If have a single monitor, you'd better use a recent gamer card. You should remind, that the "Power Consumption" is the maximum value the card will take under full load. Typical GPUs have 8-15 W during Desktop use. My current favorite would be an Radeon RX550X. Its twice as fast as the W4100 but costs only about 90€. Also current cards have better Video decoding and Encoding capabilities than the old ones. I suppose the integrated GPU of the i7 can also drive a 4K Display provided the Mainboard has Display Port Connector. It should work without issues on any current linux distribution. cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd breaking linuxcnc ...
On Mon, Jan 27, 2020 at 04:17:20PM -0800, Rick Moen wrote: > Quoting Dr. Nikolaus Klepp (dr.kl...@gmx.at): > > > Just for your amusement: systemd breaks linuxcnc on RPi4 - who's not > > into machining will most likely not see the fun part of it, but anyway > > :) > > > > https://www.youtube.com/watch?v=RDKaFJmB254 > [...] > un-gentle jerk-forward-or-back of time all at once -- as opposed to the > gradual adjustment any of the real NTP daemons would do -- and that such > rough time discontinuities are problematic for real-time operations. Problems are not limited to real time operation. Stepping time, especially stepping backward will also break time flow of file timestamps. This can cause problem e.g. if you have script, which relies on file timestamps and the time steps back between touching a file and using its timestamp. Also it can happen that the atime becomes earlier than the ctime of a file. The "make" build tool also uses timestamps :-) > (It's distinctive that the entire RPi series lacks by default any RTC > circuitry, so it's particularly vulnerable to such software problems.) This problem has no relation to the existence of a hardware RTC or not. On Linux, the hardware RTC is in almost any case only read when the system boots/resumes and updated on system shutdown/sleep. During operation, Linux always uses a software RTC. (Otherwise system would be very slow, since accessing a hardware RTC is time consuming operation) The point with RPi is, that it has no RTC and thus can not restore current time on boot/resume. Thus in order to get the current time, an RPi must use some kind of NTP protocol. (And needs connection to a time server) cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Tried Debian Stretch with systemd out of constrainsts
On Thu, Jan 09, 2020 at 10:04:28PM +0100, Edward Bartolo via Dng wrote: > [...] > > I still have yet not figured out how to avoid having to use snapd and > install the firmware for the oscilloscope, Hantek 6000B (USB). I have > successfully extracted .hex files from the MS Windows drivers but have > no idea what to do with these hex files which are supposed to contain > the oscilloscope's firmware. The openhantek package has a .rules udev > file to enable detection of the oscilloscope. However, the kernel > still wants to know where to look for the oscilloscope's firmware, and > that particular information is missing. Firmware file for the linux kernel usually reside in /lib/firmware. You could try to copy your hex files there. Make sure to use proper name as expected by kernel. What do you need snapd for? cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Alternatives to synaptic?
On Thu, Jan 09, 2020 at 07:16:38PM +0100, Alessandro Vesely via Dng wrote: > > # apt install libelogind0 libpam-elogind synaptic > > > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following additional packages will be installed: > elogind libept1.5.0 policykit-1 > Suggested packages: > dwww software-properties-gtk > The following packages will be REMOVED: > libpam-ck-connector > The following NEW packages will be installed: > elogind libelogind0 libept1.5.0 libpam-elogind policykit-1 synaptic > 0 upgraded, 6 newly installed, 1 to remove and 3 not upgraded. > Need to get 876 kB/3,047 kB of archives. > After this operation, 11.4 MB of additional disk space will be used. > Do you want to continue? [Y/n] n > Abort. > > > if I just try synaptic, I get additional packages libept1.5.0 and policykit-1, > so adding elogind doesn't seem to help. This is fine and just as expected. Policykit is not related with systemd. policykit is a framework which allows "normal" users to run commands which usually need "root" permissions like removable drive mounting, installing packages, shutting down the system. Its main purpose is to provide a "smooth" feel to GUI desktop users: E.g. Plug in USB-Stick and just click in the file manager on it without the need to enter a password or invoke sudo. For that purpose policykit uses a rule set. E.g. a typical rule to allow mounting a removable drive could be "User must be logged in locally and the session should be still active ( Not switched to another terminal/screen)". In order to determine the state of a user session and if the corresponding program is part of this session policykit can use either: - consolekit (deprectaed and not working well anymore) - systemd (...) - elogind (Just the session management part of systemd extracted) Besides that session management, elogind/systemd provide some additional functions like commands to shutdown/reboot the system as user. You might be able to run without them on a headless machine or with simple desktop environments but virtually all the "big" desktop environments nowadays depend on availability of either "systemd" or "elogind". Even such applications like "apt" or "apt-*" are now linked to libsystemd0. So if you're going to have a package manager, you'll have either libsystemd0 or libelogind0 installed. Back to topic: I personally stick with apt or aptitude but since the the family sticks more or less to GUI, I have also installed "muon". It is Qt/KDE based and is quite similar to aptitude. I didn't like synaptic since it performs too much "background" magic as I'd tolerate. cheers Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind and libelogind0
On Mon, Jan 06, 2020 at 04:10:56PM +0100, Arnt Karlsen wrote: > ..chking elogind history, I found > https://git.devuan.org/amesser/elogind is 404, what happened, > and who is in control of https://github.com/elogind/elogind/ ? elogind packaging for Devuan has been moved a while ago to official Devuan Packages: https://git.devuan.org/devuan-packages/elogind The github URL posted is the upstream project (Without Debian/Devuan packaging). cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We need upgrade reports
On Tue, Dec 31, 2019 at 02:58:10PM -0500, fsmithred via Dng wrote: > Please upgrade your highly customized and configured ascii production system > to beowulf and tell us if it works. Okay, DO THIS ON A COPY, not the real > thing. Well, already did on my production systems, not many test machines for home use :-). I have three machines updated within the last two months, sorry, a little bit lengthy now: [notebook]: Updated from ascii to beowulf roughly a month ago. KDE/Plasma Desktop, Firefox, Visual Code from external Microsoft repo, LVM volumes. No issues during upgrade (*), system seems to be stable (no crashes so far) * I don't remind all details anymore but see below for more recent update. [soho nas/server]: Also about a month ago. This was a new machine with a minimal ascii as trampoline for installing beowulf. No issues during upgrade. Machine is headless, no elogind. Currently working services are: Samba AD DC for Windows clients and providing LDAP/Kerberos to Linux hosts, NFS fileserver, Lighttpd + PHP FPM, MariaDB, Amanda Client. The machine sometimes looks up: once a month or so, either during standby (to ram) or wakeup. I suppose related to Mainboard or Bios. [workstation]: Upgraded just a few days ago from ascii to beowulf. Also a pure desktop machine: KDE/Plasma, KMail, Gnome, Firefox, KiCad, Amanda server (not yet used again), Visual Code, Gimp, LVM for root and other filesystems, mixed NVME/HDD. I run upgrade commands from within a "screen" session in a terminal from KDE. Since I forgot to disable screen-saver before, it locked after a while and prompted me to switch to text console, login and perform a "loginctl" command to unlock. This worked, however I'd recommend to either disable all screen savers during upgrade or use a text console for upgrade. I was required some repeats of the "upgrade" / "dist-upgrade" commands. Also an "--fix-broken install" was needed. I think this was related to autofs package: I host a local package mirror as NFS share which is mounted through autofs, when updating autofs, it will restart / remount all autofs shares so the autofs_*.deb disappeared during install of autofs which dpkg doesn't seem to like :-) After upgrade KDE desktop was not installed anymore. I had to manually install it again (kde-plasma-desktop package). Also elogind* was not upgraded, I think the later was related to libsystemd0 package, which was still installed. I had to manually remove libsystemd0. Afterwards I could upgrade elogind*. Is it correct that libsystemd0 is still present in deb.devuan.org for beowulf? Since libelogind0 replaces it, it shouldn't be there at all, right? After upgrade I noticed, that sound in KDE was not working as expected. KDE/Plasma seem to have more or less fully switched to pulseaudio. The pulseaudio package was installed but not working properly. Today I just figured out, that the libpulse0 package from debian ships with a file /etc/pulse/client.conf.d/00-disable-autospawn.conf which changes behavior to not automatically start pulseaudio server by client if needed. Probably since pulseaudio is now started through systemd on Debian: /usr/lib/systemd/user/pulseaudio.socket /usr/lib/systemd/user/pulseaudio.service This change actually breaks sound/mixers for all pulseaudio using applications, A freshly installed beowulf with KDE desktop might not deliver sound out of the box. As a quick fix I edited /etc/pulse/client.conf.d/00-disable-autospawn.conf and commented out the setting made there. I see two more persistent solutions: - provide own libpulse0 package without that config file - create a devuan package which installs a 01-reenable-autospawn.conf file to revert the setting Another noticeable thing (Wife) is, that the banshee package is not available anymore (removed from Debian as well). With some quirks I was able to generate it locally from the Debian source. We evaluated some alternatives before but most of them suffer GUI usability and focus to much on for our mood unecessary features. KiCad (electronic cad programm) worked fine at once. Old project was converted without issues and was directly useable again. cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] disable elogind messages?
On Sun, Nov 24, 2019 at 07:14:48AM -0600, hal wrote: > > [...] > I've commented out all of these lines. Presumably elogind-user is > absolutely pointless on a Devuan system anyway? Hmm, I wouldn't edit /etc/pam.d/common-* directly. Contents in these files are managed and may/might change during package upgrade/install back. Also on a desktop machine I would choose elogind to be working for normal logins since it is needed for most desktop environments to mount/unmount removable media and to shutdown/reboot the system. If you really want do disable elogind for everything I would recommend to: a) either run "/usr/sbin/pam-auth-update" and unmark elogind entry in the dialog appearing (This will actually change all /etc/pam.d/common* files permanently). And disable elogind service running "/usr/sbin/update-rc.d elogind remove" b) Or just remove libpam-elogind and probably also elogind itself (if its not a dependency of some other package) Otherwise I'd suggest to only edit /etc/pam.d/ files to disable elogind for corresponding service if needed. This should only be required for files including "common-session". cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] disable elogind messages?
On Sat, Nov 23, 2019 at 05:38:54AM -0600, hal wrote: > This still leaves the question however, is there a way to disable the > elogind messages in syslog? It seems like a lot of useless chatter in the > syslogs. Sorry, did not read your E-Mail before. Did you check /etc/pam.d/cron for elogind references? (Including the includes) cron should not produce any elogind output since it uses /etc/pam.d/common-session-noninteractive by default. elogind should be only listed in /etc/pam.d/common-session. cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] audacity 2.2. in Ascii?
Hi Raúl, On Fri, Sep 06, 2019 at 02:53:41PM +0200, Raul Claro wrote: > Dear Dev1ers, > > I am using Ascii very satisfactorily and do not want, for the time being > anyway, to migrate to a newer system. But I would need to use a higher > version of Audacity, not 2.1 any longer but rather 2.2 (or even 2.3) if > possible. Is there anything in Devuan like the backports in Debian, where > some later packages were made available for earlier versions of the OS? > Where can I find a .deb-package Audacity 2.2.? Well, you could be trying to take the audacity 2.2 package from Debian (the Devuan package is actually taken unchanged from Debian) and install it. But most likely this will pull in lots of other library dependencies which can not be satisfied by ascii release. Of course these can be manually installed also. But you should not do that since your ascii install might easily become messed up by that ending in hell when installing/upgrading in future. http://ftp.debian.org/debian/pool/main/a/audacity/ One thing I often do by myself is to take the source package and recompile it on my ascii install. In many cases this recompilation works using the ascii libraries without updating them to newer versions. (Similar thing is done for backports) A workflow would be roughly like follows (shell): $ git clone -b debian/2.3.2-2 https://salsa.debian.org/multimedia-team/audacity.git audacity $ cd audacity $ dpkg-buildpackage -b -uc $ sudo dpkg -i ../audacity*.deb You migt be required to install additional packages: git, dpkg-dev. And the dpkg-buildpackage command might also request extra packages to be installed. Hope this helps to solve your need. cheers, Andreas signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Booting devuan on a rasberry pi
On Sun, Jul 28, 2019 at 07:37:26PM -0500, hal wrote: > On 7/28/19 3:57 PM, hal wrote: > > > > > Some searching says to add "core_freq=250" or "enable_uart=1" but > > so far still nothing. Any suggestions are appreciated. > > I got the serial port working. It's a bit of a task. Apparently the > bluetooth integration messed up the serial port configuration so > when you boot, you're actually connected to the bluetooth chip > on /dev/ttyAMA0. You have to fiddle with /boot/config.txt and > /boot/cmdline.txt to restore the serial functionality. Nice to hear that you got it working! As you mention, I remind that there was something :-) Some time ago, I was going to use the serial port with an LTE shield. I remind I also had to fiddle with it to get it working. Actually, RPi 3 B+ has two UARTs. The usual/default UART is connected with Bluetooth chip by default, thus the Pins on the header are not working - as you already found out. If you want to use Bluetooth and UART: There is another UART in RPi 3 B+ which can be mapped to Bluetooth instead. you could be using core_freq=250 dtoverlay=pi3-miniuart-bt instead of dtoverlay=pi3-disable-bt This additional uart does not support full speed / handshake but fast enough for bluetooth in any case. I think it only works with fixed clock freq. cheers, Andreas signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] usb automount
On Thu, Jul 18, 2019 at 08:16:31PM +0200, al3xu5 / dotcommon wrote: > Please I need your help. > > I have installed a fresh ASCII on a small barebone pc to be used as audio > server. Using MATE and lightdm. > > I have also installed some multimedia stuff and apt updated & upgraded > packages. > > When I plug any usb stick as normal user, it is not automounted and I get a > 'not > authorized to perform operation' error; I can mount the stick manually as root > (sudo). > > Which is the problem? Any idea? Could you please check if you have installed: libpam-elogind elogind libpolkit-backend-elogind-1-0 If not, install these packages, log out and in again. Should work afterwards cheers, Andreas signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Booting devuan on a rasberry pi
On Tue, Jul 16, 2019 at 08:02:43PM -0500, hal wrote: > Hello, > Thank you. Here is the boot output from > devuan_ascii_2.0.0_armel_raspi1.img.xz and setting emmc clock to 50Mhz in > config.txt > > The same sdcard will boot my Raspi A+ fine so maybe it's hardware? > > https://pastebin.com/gtcVxqRd I can confirm the image booting successfully on my RPI 3 Model B+ with 2A USB Powersupply. (USB Keyboard/Mice attached through Hub not working, but I see a login screen) So I think your hardware seems to be broken somehow. cheers, Andreas signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Install failure: cannot boot netinst
Forgot to cc mailing list... - Forwarded message from Andreas Messer - Date: Mon, 27 May 2019 08:07:16 +0200 From: Andreas Messer To: "Blair, Charles E III" Subject: Re: [DNG] Install failure: cannot boot netinst User-Agent: NeoMutt/20170113 (1.7.2) On Mon, May 27, 2019 at 03:05:35AM +, Blair, Charles E III via Dng wrote: >After posting, I learned that I should > disable "Secure Boot" in the bios menu. > However, I have a different problem now. > When booting, the CD-DVD reader makes noises > as though it is reading the netinst CD, but > all I see on the monitor is the cursor in > the upper-left corner, no diagnostic messages. Was there a bootmanager/install options screen before the "Cursor Screen" appeared? It could take some time to load the image from a CDROM since CDROMS are very slow with random seeking/accessing the data. cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 - End forwarded message - signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan on a Purism
On Sun, Nov 04, 2018 at 12:11:44AM +0100, Adam Borowski wrote: > It's a _touchscreen_ phone, not a "real" computer. For that you want Gemini > or GPD Pocket. The input device is not fit for any real hacking. You at > most connect to it from the outside. Well, according to their information it is going to have an USB-C with HDMI output. So Id expect you'ld be able to connect a standard monitor and USB Keyboard/Mice. Looking to their first planning with iMX.6, the devkit even had an SATA connector :-) > > I'd love to try upgrading it's PureOS to Devuan too. It shouldn't be > > too hard, as the Librem5 is designed to allow a number of distributions > > to run on it. Or at least it was, I can no longer find references on > > https://puri.sm/products/librem-5/ of alternative distributions that > > will be installable on the Purism5. > > Crossgrading might be not trivial; vendors of such phones tend to customize > them in a way that makes running an off-the-shelf system require re-doing a > ridiculous amount of non-upstreamed changes. Regarding what they write on their site, many of their development is made on Debian Buster. They just recently announced that their own 'distro' is making some progress. Lots of their changes are pushed back upstream, so I think we can expected that it will run other distrbutions. cheers, Andreas signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan on a Purism
On Thu, Nov 01, 2018 at 08:02:26PM +, Daniel Abrecht wrote: > [...] > I hope they ship the devkit soon, I want to install devuan on it too. > Getting a Desktop Environment and Apps to work so it is usable could then > become a bit tricky though. good to know. I'm also looking forward to receive the devkit and planning to use it with Devuan. Maybe we can get in touch to help each other. cheers, Andreas signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] With ELoginD all users are logged out when one logs out.
Hi Andrey, On Sun, Oct 07, 2018 at 07:36:59PM +0700, Андрей wrote: > [...] > В Mon, 1 Oct 2018 07:20:18 +0200, ты писал(а): > > > Can you please provide more information how to reproduce the issue? > > Especially: Window manager / Desktop environment used and installed > > versions of all package names containing "elogind", "dbus" and > > "policykit"/"polkit". > > On my system it is also not always happens therefore i can not tell > exactly how i do "achieve" this myself. Hm, could also be related to something else. Did you check the system log files (/var/log) after the problem occured?. Maybe they contain some helpful information. > The information you asked for: > > . Window manager / Desktop environment: openbox-3.6.1-4 , all the users > login w/ console then startx. Though startx is not a requirement here. > One user can be loged in in console and then logout when the "kick" of > all other users happens. > [...] > libpolkit-gobject-consolekit-1-0:amd64 If you have elogind (and libpam-elogind) installed you should be using the "elogind" variant of policykit packages, not the consolekit ones. Can you please replace the package above with "libpolkit-gobject-elogind-1-0" and look out if the problem still occurs? cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] With ELoginD all users are logged out when one logs out.
Hi, On Mon, Oct 01, 2018 at 11:27:23AM +0700, Андрей wrote: > Приветствую. > > On Ascii, using ELoginD, when several users are logged in, and latter > one logs out, then all other users are logged out too by the system. > How to fix this (on logout of one user, others remain logged in)? I made a short test and can not reproduce such a problem here. I tried with graphical session "Log in as another user" and with console session. Here, only the single user logging out is logged out, other sessions remain. Can you please provide more information how to reproduce the issue? Especially: Window manager / Desktop environment used and installed versions of all package names containing "elogind", "dbus" and "policykit"/"polkit". cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [ASCII][PATCH] startx to a new tty
Hi Dario, On Sun, Sep 16, 2018 at 09:35:52PM +0200, Dario Niedermann wrote: > Il 16/09/2018 alle 18:43, Andreas Messer ha scritto: ddd> > I see. Anyway I strongly doubt that any DE relies on startx internally: > it's a shell script that's intended to provide a convenient user > interface to console users who want to spawn an X session. Yes a DE does not care how the X-server was started - by startx, by a display manager or something else. But startx can of course start a DE like KDE. And KDE depends on session management - at least some of its functionality. And for that to work properly, the session associated with KDE needs to be "active". > Also note that startx will *always* run X as root, even the stock Devuan > version. My patch doesn't change that. The 'needs_root_rights' variable As far as I understand this only happens when xserver-xorg-legacy package is installed. If this package is not installed, X will never run as root. > I add to 'Xwrapper.config' is only there for Xwrapper (a short lived > program called by startx) to be able to allocate a new tty. After which > it spawns X and quits. Manualpage of Xorg.wrap says something different. My understanding is, that for example using DRI - which actually means using a modern graphics card at all - either requires root permissions of the x server or a working session management. (Session management daemon will adjust permissions such that DRI is available to non-root) > With the stock RedHat-derived version, instead, a new tty is not > allocated: the current tty is taken over by X when you issue startx. > After X quits, the current tty is released, but is now owned by root > (no longer by your user). Which is not the way the XFree86 / Xorg > devs intended startx to work. I dont know much about that. My feeling about this is, that it is something which can not really be solved to fit all needs. From my point, there are two ways: Either have a working session management with running X without root permission or having no session management and running X as root. In the later case, X should have its own tty allocated indeed. So the decision if a new tty shall be allocated actually corellates to if X is running as root or not. Since only Xorg.wrap knows finally if it will run X with root permission or not, its the first place for me were modifications need to be made. Maybe the whole combination of startx/xinit/Xorg.wrap needs adjustments. Both affected packets (xinit, xserver-xorg-legacy) are currently taken unchanged from Debian. So if we were to modify them, forks of these packages have to be created in Devuan package git repos. There we can put the modifications for test and possible future integration. Decision on that is not mine. @Dario: If you want to see this changed, I'd like to encourage you to create an account on Devuan git and just start to work on this topic. cheers, Andreas signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [ASCII][PATCH] startx to a new tty
Hi Dario, On Sun, Sep 16, 2018 at 10:59:52AM +0200, Dario Niedermann wrote: > Il 16/09/2018 alle 10:01, Andreas Messer ha scritto: > > [...] > In short: their addition was a kludge, 100% due to systemd: the only > thing that was causing problems for them, with the X session being seen > as "inactive", was systemd's logind component. Thanks for pointing that out. Unfortunately, many DEs have hopped on the systemd train and therefore depend on its services. In particular, the missing logind was the main barrier to have DEs like Gnome or KDE fully working on Devuan. With fully working I refer to how standard users would expected an desktop environment to behave. Therefor elogind was added to Devuan as a replacement for systemd's logind. But actually elogind is just the logind component from systemd mangled to run standalone. I expect it to show almost the same behavior like the original one. > So, Devuan's stock startx is running code that's only there to > accommodate systemd, and causes incorrect/non-traditional behaviour > on a systemd-less OS. If we were to provide a modified version startx, we have to consider constraints pointed out above. I'm not sure if /usr/bin/startx is part of a packet currently manged/modified by Devuan at all. (Most packets are original Debian ones, without any modification) cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Xorg, choosing setuid vs. libpam-elogind and rant about security (was: Re: Jessie -> Ascii upgrade breaks X)
On Tue, Jun 12, 2018 at 10:49:35AM -1000, Joel Roth wrote: > Hi Andreas, > > And thanks for the explanations! > > Andreas Messer wrote: > > Hi Joel, > > dd> > On Sat, Jun 09, 2018 at 01:52:06PM -1000, Joel Roth wrote: > > > [...] > > > I have and use dbus apps on my system, However, as far as > > > I'm aware, none of these programs has root privileges. > > > > > > As the pam/dbus/elogind/polkit mechanism is capable of > > > handing out root authority, and as all software has bugs, I > > > think we _can_ anticipate that bugs that create security holes > > > will be uncovered in this stack. How much scrutiny did the > > > developers devote? Did anyone ever consider security at > > > through the whole stack? Probably the developers of each > > > component do consider security in their own code. > > > > I'm not sure but i think there is a miss-understanding here. Neither > > dbus, elogind or polkit hand out "root" to other processes. > > > > dbus is just a rather standarized IPC mechanism to allow for > > communication between different processes. > > I may have confused ipc with rpc. > > > Also to make > > system processes (running with root permission) to talk with > > desktop applications. Of course, depending on the particular dbus > > interface the system process provides and how it implements it, > > this might become an attack vector. But in my oppinion this is > > more an issue of the system process implementation and > > dbus api interface definition of that service than of dbus it self. > > > > polkit is some kind of authority which is used by many system > > processes to figure out if a particular user or process is allowed > > to invoke a (in most cases dbus) api of a (maybe system) service. > > Wether access is granted depends on particular rules and maybe > > system state - here comes the session management into > > play. Many of the rules include a "the user must be > > running an active local session" statement. polkit does not perform > > any actions, it just veryfies that something can invoke something > > and reports the result back. > > > > polkit can be backed by two different session management systems, > > either consolekit or logind. But some desktop environments rely > > on a particular one. > > > > elogind itself is one of these session management implementations > > (providing the logind interface) and it tracks the sessions. In > > addition it does some things to the cgroups of the user processes > > and other weird things - its based on systemd-logind. > > > > In order to run without root permissions the xorg xserver > > relies on the session management. I think (not fully sure about this) > > that the session management services can also prepare > > permissions of device files, e.g. granting access to drm files > > for the x-server. > > ISTR that vdev can give process-specific views of /dev, and > appears to offer a different, lightweight option in that direction.[1] > Not clear how much these overlap, pretty clear that vdev > doesn't have anything to say about cgroups. Thanks for the info. The cgroup thing, well I have no idea if that would be really needed to run a desktop system. I was surprised by this when seen the first time. I think system-logind (and in turn elogind) use it to figure out if a process belong to a particular session. system-logind can/will also set various limits while elogind does not as far as i know. While I can understand the session management usecase, I'm not sure if the other crap is really required, especially since there are exisiting solutions for cgroup management. > [...] > So, I'm looking into the security implications of setuid X, > and found this helpful explanation on stackexchange:[2] > >X11 apps run as a non-root user. However, on most platforms >the X11 drivers run as root, so they can access the display >hardware. This introduces the risk that a malicious app >might be able to exploit some security vulnerability in the >X11 code and use it to become root. This is a serious risk, >because X11 is a complex system with a tremendous amount of >code, and all it takes is one security vulnerability >anywhere in that code to make a privilege escalation attack >possible. This is indeed a concern. > >Enabling remote attacks. If I run X11 on my Linux machine, >does that make it easy (or possible) for remote attackers to >"hack" my machine? The answer is no. Remote attackers have >no way to acc
Re: [DNG] Xorg, choosing setuid vs. libpam-elogind and rant about security (was: Re: Jessie -> Ascii upgrade breaks X)
Hi Joel, On Sat, Jun 09, 2018 at 01:52:06PM -1000, Joel Roth wrote: > [...] > I have and use dbus apps on my system, However, as far as > I'm aware, none of these programs has root privileges. > > As the pam/dbus/elogind/polkit mechanism is capable of > handing out root authority, and as all software has bugs, I > think we _can_ anticipate that bugs that create security holes > will be uncovered in this stack. How much scrutiny did the > developers devote? Did anyone ever consider security at > through the whole stack? Probably the developers of each > component do consider security in their own code. I'm not sure but i think there is a miss-understanding here. Neither dbus, elogind or polkit hand out "root" to other processes. dbus is just a rather standarized IPC mechanism to allow for communication between different processes. Also to make system processes (running with root permission) to talk with desktop applications. Of course, depending on the particular dbus interface the system process provides and how it implements it, this might become an attack vector. But in my oppinion this is more an issue of the system process implementation and dbus api interface definition of that service than of dbus it self. polkit is some kind of authority which is used by many system processes to figure out if a particular user or process is allowed to invoke a (in most cases dbus) api of a (maybe system) service. Wether access is granted depends on particular rules and maybe system state - here comes the session management into play. Many of the rules include a "the user must be running an active local session" statement. polkit does not perform any actions, it just veryfies that something can invoke something and reports the result back. polkit can be backed by two different session management systems, either consolekit or logind. But some desktop environments rely on a particular one. elogind itself is one of these session management implementations (providing the logind interface) and it tracks the sessions. In addition it does some things to the cgroups of the user processes and other weird things - its based on systemd-logind. In order to run without root permissions the xorg xserver relies on the session management. I think (not fully sure about this) that the session management services can also prepare permissions of device files, e.g. granting access to drm files for the x-server. That why the non-setuid xserver needs elogind or consolekit to be useable. If these are not to be used, the legacy package with setuid wrapper is needed to run x from console > Will someone who scrutinizes closer have a back door, > is that likely be true for the foreseeable future? > > In a way, running others' code is like driving: putting > oneself in the hands of strangers you've never met and > might not trust for minute in person. Well, you can say this about any software you run which you did not compile by yourself and before that, read and understood its whole source code and all of its dependencies and interactions. cheers Andreas signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] wicd interferes with regular network admin tools
On Sun, May 27, 2018 at 06:42:57PM +0200, Adam Borowski wrote: > On Sun, May 27, 2018 at 05:21:50PM +0100, KatolaZ wrote: > > On Sun, May 27, 2018 at 06:05:09AM -1000, Joel Roth wrote: > > > I was recently suprised to observe network interfaces > > > (wlan0 and eth0) going up without my issuing commands for > > > it. I'd disable an interface, then see it go right back up. > > > > Joel, unfortunately this is the problem with "smart" tools for network > > management: they think they know what is good for you, all the > > time. Both wicd and nm are particularly bad at that, since they try to > > manage network state accordingto what they have been told in their > > config, despite anything. Dunno about conman, but I guess it works > > along the same lines. > > This is actually very puzzling: what we want, is a wrapper for iw which > seeks available wifi networks, and provides a GUI to choose one. The only > reason such a tool would ever look at eth0 is to see if its link is up, and > if so, skip wifi unless explicitly told to connect anyway. > > So why do authors of such tools feel the need to control the state of > non-wifi interfaces? You can make nm to not handle interfaces listed in /etc/network/interfaces. Just ensure that /etc/Networkmanager/NetworkManager.conf contains: [main] plugins=ifupdown [ifupdown] managed=false I think this is default config anyway. Additionally there is a "keyfile" plugin which had a "unmanaged-devices" option. See manpage for details. -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] warning: Devuan jessie i386 doesn't boot on i586
On Wed, Feb 14, 2018 at 10:27:32PM +0100, Alexander Bochmann wrote: > ...on Wed, Feb 14, 2018 at 10:09:17PM +0100, Irrwahn wrote: > > > Alexander Bochmann wrote on 14.02.2018 21:56: > > > System resets before even loading Devuan-built grub. > > Now that is particularly odd, as grub is not among the packages > > that were forked by Devuan but rather is merged from Debian. > > Agh, odd indeed. Just my bad luck again? It is old hardware > after all... As far as i understand, GCC 6 in Devuan and Debian uses by default march=i686. This default setting is used when building all the packages for the i386 arch. So your C3 is probably too old. You could rebuild gcc package using another default value for march in a e.g. VM. and then install this package and rebuild all packages you need on your C3 machine based on that ;-) But thats quite some work to do. Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] RFC: Draft call to action for interested users to test elogind/policykit1 with various desktop environments
Hey Irrwahn, On Sat, Jan 20, 2018 at 10:33:09AM +0100, Irrwahn wrote: > Dear Devuan Devs, > [...] > Please comment about any issues you see with this approach in general, > or the draft document in particular. Furthermore, please let me know > your thoughts on where such a call to action should be posted - I don't > follow any fora or the like, so I wouldn't know!, and also I would > appreciate any directions on where to best put the test image, and any > other procedural hints. > [...] Wow, nicely worked out draft document. I like it. One thing i'm currently thinking off, is that that we need the special build policykit in the image (with logind support) Did you take this into account. I think i have to change some things in logind package to reduce its weird behavior? (Killing processes...?) Cheers, Andreas signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind testing for experimental and ascii-proposed
Hello all, sorry for beeing mute for so long, but i was busy with other things, and still have not much time at the moment On Fri, Jan 19, 2018 at 11:48:43AM +0100, Irrwahn wrote: > Andreas Messer wrote on 19.01.2018 07:16: > > That seems strange. loginctl is a elogind command and when elogind does not > > know about the session loginctl should reject or ask for auth. I'll dig into > > this a little bit more. Probably time to setup a vm. > > So, I did a little more testing: > [...] Thank you very much for the elaborate testing! Taken all the test results into account so far, I conclude we should mark elogind "Conflicts: consolekit". When both are available, one seems not be working properly. Furthermore elogind should get some default configuration which make it to not cause unexpected side effects: - disable killing of porcesses when session ends - ... On Fri, Jan 19, 2018 at 03:56:22PM +0100, Adam Borowski wrote: > [...] > The dbus API is incompatible. Both can coexist, but it's a bad idea to have > consolekit be unaware of sessions handled by logind -- thus, if you want to > keep consolekit alive, it'd better to implement logind API, as that's what > the desktop environments ecosystem moved to. I fully agree with that. > Devuan doesn't (currently?) support non-Linux kernels, but Debian/kfreebsd > and Debian/hurd guys would thank you for this. > > On the other hand, I have doubts whether logind or consolekit are the best > approaches. The more I look at them, the more I boggle about the > pointlessness of the whole concept of "sessions": with systemd, you can't > have more than one GUI session; when a GUI session is on, ssh-ing in lets > you access all resources that are supposed to be restricted to that GUI > session; switching to another VT stops music from playing (because > security). Thus, if you drop things we don't want, it all boils down to > "does this user have a locally logged in session?". Type "who" and here's > your answer. It would be possible to have a thin stub that answers dbus > requests with standard POSIX backends, or similar non-NIH tools like > pm-suspend. > > Such a stub would lose that "fast user switching" feature, but come on -- we > live in a many computers per person world, rather than many persons per > [...] Well, I use :-). On Fri, Jan 19, 2018 at 05:34:23PM +, KatolaZ wrote: > On Fri, Jan 19, 2018 at 06:03:59PM +0100, Didier Kryn wrote: > > But wether that session is local or not is, in my opinion, and as I > > already said, futile; and it seems to be mostly used as a justification to > > develop a tangle of daemons and middleware to bypass the traditional unix > > security framework. > > This is where I get totally lost with sessions: why on Earth should I > be able to mount an external device on a remote host to which I login > via SSH? Or unable to do that, if I am a regular user of that machine? > What is the use case for this madness? Does it really solve a problem, > or is just the usual non-working and useless solution to a problem > that doesn't even exist? For me, the mainreason to have this is. Just imagine the case of a machine having a desktop, but also regulary used by other remote users. We had this scenario at university - all desktops where used to run simulation jobs remotely by all users while the secretary was typing in letters. In that case a remote use should not be able to mount USB stick plugged in by the secretary. There also scenarios, where such desktops are not assigned to a particular user but used by different users. (Students Computer pool) The you really want allow mounting only to the guy logged in and sitting in front of the screen. I you dont want to use it on your system, just dont install it. [...] So for me, there is a need for such a function on a desktop system. I could agree with the problem that logind is doing much more than it should. I really dislike that it: - kills process depending on its decision - manipulates control groups - we have already daemons for this - reboots/shutdowns/supsends the system if it like to do so I'm not fully sure, but as far as I understand consolekit does not do such things, so from my viewpoint consolekit is the one to prefer. It is more unix spirit. But we need a solution to allow for different DEs to be used in devuan and for now, many DEs require logind. So my oppinion is, that, at least for transition or migration purposes we need to provide two paths in devuan, the user needs to choose one of them - consolekit(2) + policykit - elogind + policykit-logind Generally i would like to see get rid of all systemd originating software monoliths. So what i could imagine: - Create a logind replacement which redirects all dbus queries to consolekit and l
Re: [DNG] elogind testing for experimental and ascii-proposed
On Wed, Jan 17, 2018 at 09:26:59PM +0100, Irrwahn wrote: > Hleb Valoshka wrote on 17.01.2018 20:54: > > [...] > > Can you repeat the same but with a local login? > > Outcome is the same when logged in via a VT console, while elogind > is fully enabled (and ck2 and pk installed). With elogind disabled > (ck+pk only), no extra authentication is needed. That seems strange. loginctl is a elogind command and when elogind does not know about the session loginctl should reject or ask for auth. I'll dig into this a little bit more. Probably time to setup a vm. Cheers, Andreas signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind available in experimental and ascii-proposed
On Wed, Jan 17, 2018 at 01:22:13PM +0300, Hleb Valoshka wrote: > On 1/17/18, Andreas Messer <a...@bastelmap.de> wrote: > > > Btw, "ck-list-sessions" crashes for me: > ... > > Have you rebooted your pc after upgrading CK to CK2? > I believe this crash exist only when one is still running old ck > daemon. Unfortunately it looks like there is no way to replace running That might be the problem. I did not reboot. > [...] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind available in experimental and ascii-proposed
On Tue, Jan 16, 2018 at 04:09:58PM +0300, Hleb Valoshka wrote:
> On 1/16/18, Hleb Valoshka <375...@gmail.com> wrote:
>
> > Not yet, devuan ci has issues with repos containing pristine-tar. I'll
> > build it locally and put it somewhere and then write its location
> > here.
>
> https://mega.nz/#!IMFCWRBQ!7xA2eH0PpMqF9v3WF4DhTnAgVFEjRW0pPskA2XaSO78
>
> This tarball contains versions for Ascii and Ceres (experimental),
> built only for amd64.
Sorry, didn't see that the package is already in git.devuan.org. I checked
it out and rebuild it without the elogind Conflict. i can install it in
parallel. I have made a short test:
- lightdm + KDE5: Sessions shows up in logind but not in consolekit
- textlogin: Sessions shows up in both
I think consolekit is handled by lightdm itself, without pam module. Maybe
it has some integrated logic which disables consolekit upond detecting
something else.
Btw, "ck-list-sessions" crashes for me:
#0 0x76fa0646 in strlen () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1 0x76f68d78 in vfprintf () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2 0x76f6f1f9 in printf () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#3 0x585b in list_session (ssid=,
connection=0x5576b0c0) at list-sessions.c:245
lsid = 0x5577d0b0 "6"
x11_display = 0x5576fee0 ""
remote_host_name = 0x5577c470 ""
idle_since_hint = 0x5577c370 ""
vtnum = 4294967295
proxy = 0x55769e30
uid = 1100
session_type = 0x5577c230 ""
session_state = 0x0
is_active = 1
is_local = 1
short_ssid = 0x5577c2bc "Session4"
x11_display_device = 0x5577f360 ""
display_device = 0x5577c450 "/dev/tty1"
creation_time = 0x5577e2b0 "2018-01-16T21:43:10.770409Z"
runtime_dir = 0x1
error = 0x0
sid = 0x55765bd0 "/org/freedesktop/ConsoleKit/Seat1"
session_class = 0x0
short_sid = 0x55765bec "Seat1"
#4 list_sessions (sid=, connection=0x5576b0c0) at
list-sessions.c:343
iter = 0x557781e0
proxy = 0x55769da0
error = 0x0
res = 0x5577dcc0
#5 list_seats (connection=0x5576b0c0) at list-sessions.c:394
iter = 0x55777f70
proxy = 0x55769d10
error = 0x0
res = 0x55779d90
path = 0x5577d770 "/org/freedesktop/ConsoleKit/Seat1"
#6 main (argc=, argv=) at list-sessions.c:451
connection = 0x5576b0c0
context =
retval =
error = 0x0
do_version = 0
entries = {{long_name = 0x5f0d "version", short_name = 86 'V',
flags = 0, arg = G_OPTION_ARG_NONE, arg_data = 0x557571a4 ,
description = 0x5f15 "Version of this application", arg_description =
0x0}, {long_name = 0x0, short_name = 0 '\000', flags = 0, arg =
G_OPTION_ARG_NONE,
arg_data = 0x0, description = 0x0, arg_description = 0x0}}
Maybe something to forward to upstream.
Cheers,
Andreas
signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] elogind testing for experimental and ascii-proposed
Dear folks, since we have to test elogind now with various setups, KatolaZ asked me to write a short guide what needs to be tested. So here we go: Lets start with a short overview about what logind is: It is about session, user and seat management. Its main use is to track who is logged in by which method into a system and which processes belong to such a session. A session can then be assigned to a seat. Seat can be a remote access, x11 display... That information is then used by other software packages to determine e.g. access permissions to hardware. This topic was addressed with another software some time ago, called consolekit. Many desktop environments and tools have been added support for consolekit. e.g. KDE, GNOME, udisks, upower. At some time (e)logind was born in context of systemd. (elogind) implements the same functionality like consolekit and more. Today more and more applications are migrated to (e)logind. Therefor this package is needed in Devuan to support modern Desktop Environments. For now, lots of packages in devuan assci still rely or can use consolekit but this might change in future. This includes udisks (consolekit only), KDE (maybe both). Some packages require (e)logind, e.g. GNOME, for installing the package but at runtime they seem also be able to still use consolekit. In principle consolekit and (e)logind can be used at the same time because the use different D-Bus APIs and consolekit is merely a database. But applications must implement this. Main testing point is to figure out if elogind breaks anything which is formerly working properly. In the currently prepared packages, elogind is although being installed and started, not fully enabled because my internal tests showed that this breaks user mounting, shutdown and reboot via consolekit. This probably requires changes to other packages. We still need to know if anything else breaks by installing the elogind package, or if things become functional after installing it. We need information about as many combinations of display managers and desktop environments as possible, because there is interaction between elogind and all of them and things which work with one display manager and one desktop environment might not work with another display manager. I have tested so far: - text login - lightdm/KDE - lightdm/GNOME (only basic tests) So for testing, you might take with the following steps: - just install packages "elogind" and "libpam-elogind" package and check if they install cleanly. I expect problems when original systemd packages are used. Report any problems with it - invoke "pam-auth-update" as root and ensure that elogind is not selected. This will effectively disable eloginds session management (daemon still runs and dbus api/library is available) - after installing, invoke the command "loginctl". It should not list any session because elogind is not (yet) fully enabled. - After installing, check if login/logout works properly. Especially the graphical logins are interesting. Please report tested display manager / desktop environment here. - Now check if you can mount/unmount removeable media like USB, CDs. Report if it worked before installing elogind and if it still works afterwards - Test if reboot/shutdown via desktop environment is functional. Report if it worked before installing elogind and if it still works afterwards - Now, we should test with fully enabled elogind. Todo so invoke "pam-auth-update" again and enable elogind. Afterwards logout and login again. From now on, if any unexpected behavior occurs, things which work before, please report them. - executing "loginctl" should now list the session. - Now check if you can mount/unmount removeable media like USB, CDs. - Test if reboot/shutdown via desktop environment is functional. As said above, elogind is doing more than only recording the sessions. So with fully enabled elogind the following things should be tested: - Test if reboot/shutdown works via "loginctl poweroff" and "loginctl reboot" - When using the "screen" terminal emulator original logind is killing everything, even the multiplexed application when the session closes. Please test if that happens for your system. I think we have to preconfigure it reasonable here. - When terminating a session with a kill command, I have observed on debian, that the user services survive this and continue running. That means, that if the sessions crashes gpg-agent might be still running and if logging in again it might still have opened the key (not asking for passphrase) I think one can kill the session using the kill command and the login as another user and figure out if there are still processes running under the former user to test this. Thanks for your help. signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org
Re: [DNG] elogind available in experimental and ascii-proposed
On Tue, Jan 16, 2018 at 01:00:30PM +0300, Hleb Valoshka wrote: > On 1/16/18, Andreas Messer <a...@bastelmap.de> wrote: > ... > > When elogind pam module is enabled, the session is correctly registered > > with elogind. This can be done by following steps: > > Afaik pam module is required only for terminal sessions, for DM it > usually isn't required unless your DM doesn't support it directly, but > as elogind is a replacement for logind it should be supported by any > DM which supports logind. Yes we have to figure out if any of the DM works without the pam stuff, but there are people who use terminal sessions :-) And for them, enabling the module will break consolekit. So an example, when elogin pam is not enabled the following works with devuan if consolekit and udisks is installed: 1) login 2) plug in usb stick 3) udisksctl mount But when enabling pam elogind you will get: 1) login 2) plug in usb stick 3) udisksctl mount Which is because when the elogin pam module is enabled, consolekit does not list the session anymore, so activating it effectively breaks consolekit. I don't know why this happens. I need to try with consolekit2, maybe this is fixee already. Original consolekit is pretty old stuff. Btw. did you put the consolekit2 package somewhere already? Tomorrow, I'll provide a lists of steps what to test with elogind so we can check what is working and what not. signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind available in experimental and ascii-proposed
On Mon, Jan 15, 2018 at 10:30:12AM +, KatolaZ wrote: > The package is now available in Devuan in "ascii-proposed" and > "experimental". Please test it extensively and report any issue on > bugs.devuan.org. > > @Andreas: please indicate if there are specific things/combintions to > be tested. In current default configuration, the elogind package will just install all the libraries and start the daemon. But the pam module is not enabled. With that combination I was able to install and use gnome-session with USB mounting and Shutdown/Reboot. But with this configuration, elogind is practically disabled, because it does not know about the session. (I have also installed consolekit, which takes care of these tasks. Fun fact: although gnome-sessions requires logind, it also works without having it really enabled. So why depend on it? :-) When elogind pam module is enabled, the session is correctly registered with elogind. This can be done by following steps: - invoke "sudo pam-auth-update' and enable elogind - log out and log in again - invoke 'loginctl', the session should be listed But now, at least for my system, neither USB mounting nor Shutdown/Reboot buttons work. I think this is because the session is not known by consolekit anymore, so enabling elogind pam breaks consolekit sessions. This is the first thing to investigate. I don't know the reason for this, yet. Maybe the situation improves when using consolekit2, maybe consolekit and elogind can not be used at the same time. (Until now i thought they are 'orthogonal' to each other) So testing should focus on (preferably with both of the configurations elogind fully enabled and only installed): - Mounting devices as user, shutdown/reboot/suspend - Functionallity of Gnome and other X sessions (I'm on KDE mainly) Nevertheless there is more to do: - Rebuild udisks2 with logind support should fix the mounting issue because udisk could ask logind for permissions then. Maybe this breaks consolekit? - figure out how Shutdown/Reboot can be fixed with logind, maybe upower is the solution. > Thanks a lot to Andreas for the great job, and to those who helped him > in the process! I'm passing these flowers back to you ;-) cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] d1h with LANG=de_DE@UTF-8 fails
Hi, just came accross the following: xxx@xxx:~/Devuan/elogind$ d1h prepare unstable Auf Branch suites/experimental Ihr Branch ist auf dem selben Stand wie 'origin/suites/experimental'. nichts zu committen, Arbeitsverzeichnis unverändert There are uncommitted changes or untracked files present. Please commit your changes or ignore untracked files xxx@xxx:~/Devuan/elogind$ LANG=C d1h prepare unstable On branch suites/experimental Your branch is up-to-date with 'origin/suites/experimental'. nothing to commit, working tree clean [suites/unstable d6328942d] creating suite suites/unstable 1 file changed, 1 insertion(+), 2 deletions(-) [= suite "suites/experimental" ready =] Switched to branch 'suites/experimental' Your branch is up-to-date with 'origin/suites/experimental'. -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] initial elogind package ready / RFC
On Sun, Jan 07, 2018 at 07:18:26PM +0300, Hleb Valoshka wrote: > On 1/7/18, Andreas Messer <a...@bastelmap.de> wrote: > [...] > As a temporary solution you can add lintian overrides, at least for > udev warnings. I dont see lintian udev warnings. Do i need special settings? I get the following here: W: libelogind-dev: manpage-has-errors-from-man usr/share/man/man3/sd_bus_message_append.3.gz 111: warning [p 1, 8.8i, div `3tbd1,1', 0.0i]: can't break line W: libelogind-dev: manpage-has-errors-from-man usr/share/man/man3/sd_bus_message_append_basic.3.gz 83: warning [p 1, 3.3i, div `3tbd1,1', 0.0i]: can't break line W: libelogind-dev: manpage-has-errors-from-man usr/share/man/man3/sd_event_add_signal.3.gz 38: warning [p 1, 2.5i]: can't break line W: elogind: binary-without-manpage usr/bin/elogind-inhibit Is there something special to setup for linitian? Or do you mean the udev "uaccess" rule warning from udev? cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] initial elogind package ready / RFC
On Sun, Jan 07, 2018 at 04:47:41PM +0300, Hleb Valoshka wrote: > [...] > I've also made package buildable and fixed some lintian errors. I've > added --with-udevrulesdir=/lib/udev/rules.d \ to CONFFLAGS because > configure.ac invokes pkg-config to get some values from udev.pc which > is installed by udev/eudev, that's not the case for build chroots. Ah, sorry, I forgot about the autogen.sh. Should make clean checkout for build tests in future. > I've also added call to dh_missing --list-missing so you know what > files are not installed to any package. > > It still has some lintian warnings. I see, but these arent these are upstream issues? Should these fixed with quilt patches? > Both elogind and ck2 provide the very similar set of udev rules > imported from sd sources, maybe it would be better to merge them and > provide a shared data package, but this is a more distant task. OK, thanks for the hint. I'm not sure if both packages can be used at the same time. ck(1) and elogind can not interwork. Either the session is listed by ck or by elogind but not by both at the same time. Don't know how this works out with ck2. Anyway, all these changes are your credit? Should I mention your name in commit message? Should also add you to debian/copyright, right? With E-Mail? cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] initial elogind package ready / RFC
On Sat, Jan 06, 2018 at 09:55:44PM +0100, Adam Borowski wrote: > On Sat, Jan 06, 2018 at 04:41:57PM +0300, Hleb Valoshka wrote: > > On 2018-01-05 20:08, Andreas Messer wrote: > > > If anyone like to try it out, checkout branch suites/experimental > > > from https://git.devuan.org/amesser/elogind.git and build with > > > debbuild. This is my first package, comments are welcome. > [...] > > -> d/control & d/libelogind-data.install > > > > libelogind-data contains only l10n files, so there is no need for a > > separate package, merge libelogind-data into libelogind. > > It's a bad idea to mix arch-indep files with arch-specific. Even worse, if > this library is to be ever used by programs other than elogind itself (and > if it were not, it shouldn't be a library), it would make it impossible to > multiarchize it. Agree with that. I have added elogind-data now. > [...] cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] consolekit2
On Sat, Jan 06, 2018 at 08:46:03PM +0300, Hleb Valoshka wrote: > Do we need consolekit2 packaged? I think yes. consolekit (without 2) seems to have issues with ck-lauch-session in combination with displaymanagers like sddm. This was actually the reason for me to package elogind in the hope it will work better with sddm. But in order for elogind tobe useful, other packages need to be adjusted (udisks...) These issues seem to be fixed in consolekit2. cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] initial elogind package ready / RFC
On Sat, Jan 06, 2018 at 04:41:57PM +0300, Hleb Valoshka wrote: > On 2018-01-05 20:08, Andreas Messer wrote: > > If anyone like to try it out, checkout branch suites/experimental > > from https://git.devuan.org/amesser/elogind.git and build with > > debbuild. This is my first package, comments are welcome. First of all thank you for your elaborate review. I agree with most of your comments and adjusted accordingly. > [...] > dh $@ --builddirectory=build --with autoreconf --parallel > ``` > > Remove `--builddirectory=build` as you set it in override_dh_auto_configure > and --parallell, afaik dh is clever enough to enable it automatically. > [...] `--builddirectory` is needed for all dh_* commands. Otherwise they don't know where the build folder is and wont find the files. `--parallel` is on by default for debian/compat>=10 only. Currently I don't see any need to require debhelper>=10 when 9 is sufficient. I also found a workaround to shutdown/reboot and mounting issues with KDE5/Gnome 3: Just don't enable elogind's PAM module. In that case ck-list-session shows the session again and everything works as expected. Of course, the session is not registered with elogind now. I tried reordering pam_elogind.so and pam_ck_connector.so before that but this didn't help. For me this is very obscure - why does Gnome 3 depend on logind if it works without having the session registered with logind? Anyway, I have now changed the libpam-elogind to disabled the pam module by default. Can be manually enabled with `pam-auth-update`. cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] initial elogind package ready / RFC
Hi there, I finally managed to prepare inital devuan packages for elogind. I have split up the stuff in multiple packages, sysv init script for elogind is prepared. Also a libpam-elogind package is build which sets field "Provides: libpam-systemd". Thus I was able to install (and run) Gnome 3 Desktop (gnome-session) with skipping some "Recommends" If anyone like to try it out, checkout branch suites/experimental from https://git.devuan.org/amesser/elogind.git and build with debbuild. This is my first package, comments are welcome. I have already found several issues with using it: When using elogind, consolekit might not working anymore (ck-list-sessions is empty for me). Maybe this is an lightdm issue, for tty logins the session shows up in consolekit and in loginctl. The Shutdown/Reboot buttons and filesystem mounting neither work in KDE5 nor in Gnome 3. The mounting might be related to udisks. I think we have to modify udisks package to support elogind (instead of systemd). In Archlinux AUR there is udisks2-elogind which has some patch included. I have no clue about the power buttons, especially KDE5. Because KDE already sayis in its console out, that it found logind. When using loginctl from commandline I can halt/reboot the system. So its not a general problem of logind. There are some things with package file structure which might be improved. I'm building elogind with the options recommended in autogen.sh. But this implies that commands and libs are installed to /bin and /lib and some very obscure thing, elogind itself is installed to /lib/elogind/elogind. I suggest to install it to /usr/bin, /usr/sbin and /usr/lib as usual and dropping that weird /lib/elogind folder? Oppinions? cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] request: please evaluate/provide elogind-or-other ASAP
On Fri, Jan 05, 2018 at 11:54:09AM +0100, Svante Signell wrote: > On Fri, 2018-01-05 at 07:55 +0100, Andreas Messer wrote: > > Hi Adam, > > > > On Thu, Jan 04, 2018 at 11:44:25PM +0100, Adam Borowski wrote: > > > [...] > > > Thus: could you guys please prioritize work on elogind or some > > > alternative? > > > > Just started yesterday: https://git.devuan.org/amesser/elogind. There was > > already some work by shwsh but that seem to be stalled. (All the devuan > > packet stuff is missing there as well.) > > > > Depends on my time, but I think I will have a basic setup running with > > sysv init script within the next week. I have to sort out how to handle > > openrc > > because this is a compile time setting in elogind. Maybe i have to build > > different packages. > > As I wrote on IRC I'm willing to help you with packagin of elogind. One > confusing thing of elogind is that there exists three repos on github: Sorry, din't see that. > https://github.com/elogind/elogind > https://github.com/wingo/elogind > https://github.com/shwsh/elogind > Which one did you pull from? The shwsh fork's changes have been merged back into elogind. I'm currently using elogind as base, this is the original project and I think we should go with it. I didn't look at other forks. -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] request: please evaluate/provide elogind-or-other ASAP
On Fri, Jan 05, 2018 at 08:32:10AM +0100, Irrwahn wrote: > [...] > Having that out of the way: First off, I appreciate any effort > made in that direction! However, I have one question I deem > important, namely: Will elogind display the same behavior as > systemd-logind regarding killing long running processes upon > user logout? IMNSHO it should not, i.e. it should follow the > principle of least surprise by not killing background user > processes on logout. > > From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394 > I gather that it is possible to configure this in sd-logind, > so I simply assume the same holds for elogind as well. elogind has same behavior and configuration options as systemd's logind. So it has an option where this behavior can be enabled or disabled. BUT: I had a short look into the source. It seems that the killing is implemented by sending a dbus request to systemd to stop a unit. I dont know if systemd-shim implement the StopUnit interface at all? cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] request: please evaluate/provide elogind-or-other ASAP
Hi Adam, On Thu, Jan 04, 2018 at 11:44:25PM +0100, Adam Borowski wrote: > [...] > Thus: could you guys please prioritize work on elogind or some alternative? Just started yesterday: https://git.devuan.org/amesser/elogind. There was already some work by shwsh but that seem to be stalled. (All the devuan packet stuff is missing there as well.) Depends on my time, but I think I will have a basic setup running with sysv init script within the next week. I have to sort out how to handle openrc because this is a compile time setting in elogind. Maybe i have to build different packages. cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Hello & Offer to help
Hello everybody, first of all, I wish you a happy new year! Yesterday I finished to migrate my system from Debian stretch to Devuan ascii. I had a little struggle with KDE5 shutdown/reboot buttons and USB mounting but finally solved this by using lightdm display manager. Anyway, being a long term Debian user, I decided to switch to Devuan because of many unstabilities and black magic happening since Debian stretch. Probably lots of this was related to systemd software bunch incoporating everything which was a separate software package before. But don't get it wrong, I do not dislike systemd as init system itself, just the fact that more and more things are merged into it, making everything else depending on it and making decisions how my system should behave without even telling me. There are some similar alternatives, maybe jobd/launchd is worth a try. Now, after using Linux based systems for quite a long time now I would like to give something back and help Devuan. I think I could help with maintaining some packages. Please give an advice, which packages I could start with or maybe which ones are important. Another idea I have is to spend some work on consolekit. When strugling with the KDE5 shutdown/reboot buttons I figured out that the "ck-launch-session" command from consolekit seems to be buggy. But the original consolekit is not developed anymore because of systemd's logind. I have found that there is a consolekit2 fork of original consolkit which is still alive and maybe it makes sense to have such a package in Devuan? It should fix the problems with ck-launch-session. Or is it better to go on with elogind? There was some discussion in forums about elogind but I'm unsure if this is already going to be added as package to Devuan by someone else. So if you think I can help please give me an advice were to start and maybe which packages are required/needed to be handled. What do you think of consolekit2 package. cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
