Re: [systemd-devel] Scan all USB devices from Linux service

On Thu, Feb 15, 2024 at 12:04:27PM +, Andy Pieters wrote: > On Thu, 15 Feb 2024 at 09:12, Greg KH wrote: > > > > > provenance matters HUGELY when it comes to code, as you need a license > > and other things as well (copyright law is strict.) "AI

Re: [systemd-devel] Scan all USB devices from Linux service

On Thu, Feb 15, 2024 at 08:45:41AM +, Andy Pieters wrote: > On Thu, 15 Feb 2024 at 08:32, Reto wrote: > > > On Wed, Feb 14, 2024 at 05:56:31PM +0100, Vadim Lebedev wrote: > > > This is what ChatGPT proposes: > > > > Can we like not... > > If people want to ask a generative AI they do so on

Re: [systemd-devel] Scan all USB devices from Linux service

On Wed, Feb 14, 2024 at 08:24:25PM +0530, Muni Sekhar wrote: > HI all, > > USB devices can have multiple interfaces (functional units) that serve > different purposes (e.g., data transfer, control, audio, etc.). > > Each interface can have an associated string descriptor (referred to > as

Re: Query on dynamic update of Kernel comandline

On Thu, Dec 21, 2023 at 08:13:15AM +, HARSHAL PATIL (QUIC) wrote: > Hello Everyone, > > Can someone please reply to our query? > > We are really blocked due to this and unable to process in our project. It > will be really great. If you need paid support for a project that you depend on, I

Re: [systemd-devel] Error during SCC_DAEMON installation

On Thu, Aug 24, 2023 at 01:28:57PM +, Maber, Paul wrote: > Classification: Confidential Really? You sent this to a public mailing list :( > CONFIDENTIALITY NOTICE: Proprietary/Confidential Information belonging to CGI > Group Inc. and its affiliates may be contained in this message. If you

Re: [systemd-devel] how to let systemd hibernate start/stop the swap area?

On Thu, Mar 30, 2023 at 09:09:19PM +1100, Michael Chapman wrote: > On Thu, 30 Mar 2023, Luca Boccassi wrote: > > On Thu, 30 Mar 2023 at 10:15, Michael Chapman > > wrote: > > > > > > On Thu, 30 Mar 2023, Lennart Poettering wrote: > > > > On Mi, 29.03.23 13:53, Christoph Anton Mitterer

Re: [systemd-devel] BUG: kworker + systemd-udevd memory leaks found in 6.1.0-rc4

On Tue, Nov 29, 2022 at 04:35:10AM +0100, Mirsad Goran Todorovac wrote: > On 10. 11. 2022. 10:20, Greg KH wrote: > > On Thu, Nov 10, 2022 at 05:57:57AM +0100, Mirsad Goran Todorovac wrote: > > > On 04. 11. 2022. 11:40, Mirsad Goran Todorovac wrote: > > > > > >

Re: [systemd-devel] systemd-repart with multiple block devices

On Wed, Nov 16, 2022 at 05:00:04PM -0500, Mehmet Akbulut wrote: > This email contains information belonging to Motional AD LLC or its > affiliates and may contain confidential, proprietary, copyrighted and/or > privileged information. Any unauthorized review, use, reliance, disclosure, >

Re: [systemd-devel] BUG: kworker + systemd-udevd memory leaks found in 6.1.0-rc4

On Thu, Nov 10, 2022 at 05:57:57AM +0100, Mirsad Goran Todorovac wrote: > On 04. 11. 2022. 11:40, Mirsad Goran Todorovac wrote: > > > Dear Sirs, > > > > When building a RPM 6.1.0-rc3 for AlmaLinux 8.6, I have enabled > > CONFIG_DEBUG_KMEMLEAK=y > > and the result showed an unreferenced object in

Re: [systemd-devel] systemd-udevd -any way to list triggered rules with their files etc ?

On Mon, Oct 03, 2022 at 02:17:04AM +, Branko wrote: > > cat /etc/udev/rules.d/99-zz-network.rules: > ACTION=="add", DRIVERS=="?*", ATTR{address}=="11:22:33:44:55:66", > NAME="wlan17", OWNER="chosen_user", GROUP="chosen_group", MODE="0666" Network devices do not have a group/owner/mode at

Re: [systemd-devel] version bump of minimal kernel version supported by systemd?

On Thu, Mar 24, 2022 at 02:05:09PM +0100, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Mar 24, 2022 at 10:28:39AM +, Luca Boccassi wrote: > > On Thu, 2022-03-24 at 09:38 +0100, Lennart Poettering wrote: > > > On Mi, 23.03.22 11:28, Luca Boccassi (bl...@debian.org) wrote: > > > > > > > At least

Re: [systemd-devel] version bump of minimal kernel version supported by systemd?

On Wed, Mar 23, 2022 at 10:34:00PM +, Dave Howorth wrote: > FWIW, I think Greg was a bit too outspoken calling long maintenance > attempts 'crazy'; that may have intimidated some. I'm thinking of > moving distro to one that provides longer term maintenance than my > present one. Although CIP

Re: [systemd-devel] version bump of minimal kernel version supported by systemd?

On Wed, Mar 23, 2022 at 10:11:36PM +0100, Zbigniew Jędrzejewski-Szmek wrote: > > CIP 4.4 is supposed to be maintained until 2027, which is awfully > long. The question is: is anyone putting new systemd on those > systems? If no, then they're not relevant. Why not email them and ask? thanks,

Re: [systemd-devel] version bump of minimal kernel version supported by systemd?

On Wed, Mar 23, 2022 at 03:58:22PM +, Luca Boccassi wrote: > On Wed, 2022-03-23 at 12:38 +0100, Greg KH wrote: > > On Wed, Mar 23, 2022 at 11:28:29AM +, Luca Boccassi wrote: > > > On Wed, 2022-03-23 at 11:59 +0100, Zbigniew Jędrzejewski-Szmek wrote: > > > >

Re: [systemd-devel] version bump of minimal kernel version supported by systemd?

On Wed, Mar 23, 2022 at 11:28:29AM +, Luca Boccassi wrote: > On Wed, 2022-03-23 at 11:59 +0100, Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Mar 23, 2022 at 09:26:05AM +0100, Greg KH wrote: > > > On Wed, Mar 23, 2022 at 09:17:36AM +0100, Zbigniew Jędrzejewski-

Re: [systemd-devel] version bump of minimal kernel version supported by systemd?

On Wed, Mar 23, 2022 at 09:17:36AM +0100, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Mar 23, 2022 at 08:07:48AM +0100, Greg KH wrote: > > On Tue, Mar 22, 2022 at 05:27:07PM +0100, Zbigniew Jędrzejewski-Szmek wrote: > > > Hi all, > > > > > > we are c

Re: [systemd-devel] version bump of minimal kernel version supported by systemd?

On Tue, Mar 22, 2022 at 05:27:07PM +0100, Zbigniew Jędrzejewski-Szmek wrote: > Hi all, > > we are considering dropping upstream support for kernel versions < 4.4. > Would this be a problem for anyone? (*). Given that upstream (i.e. kernel.org) has dropped support for kernel 4.4, why not just

Re: [systemd-devel] How to grant systemd-nspawn access to USB device?

On Wed, Mar 09, 2022 at 03:04:00PM +0100, Kevin P wrote: > Good evening everyone. > I would like a nspawn container on my Raspberry Pi (Raspbian, systemd 247) > to access a RTL2838 DVB-T USB stick. > Inside the container, dump1090 will run and feed aircraft data (piaware and > adsbexchange

Re: [systemd-devel] Udevd and dev file creation

On Sun, Feb 06, 2022 at 01:43:08PM +0530, Nishant Nayan wrote: > While reading the code I came across :- > struct Manager > struct Worker > Can you please provide an overview on these, I did not get a clear cut > explanation on these structs, the code only has its member variables. Those are the

Re: [systemd-devel] Udevd and dev file creation

On Tue, Feb 01, 2022 at 04:04:01PM +0530, Nishant Nayan wrote: > One thought > Is it advisable to turn off systemd-udevd if I am sure that I won't be > adding /removing any devices to my server. Why would you want to do that? > Or udev also does some work while rebooting? When booting, yes.

Re: [systemd-devel] Udevd and dev file creation

On Tue, Feb 01, 2022 at 10:08:04AM +0530, Nishant Nayan wrote: > Thanks, I will check that out. > Is there any site where I can gain in depth code level knowledge of > systemd-udevd? The code is all there for you to read and understand directly. What specific questions did you have that you did

Re: [systemd-devel] Udevd and dev file creation

On Sun, Jan 30, 2022 at 05:14:49PM +0530, Nishant Nayan wrote: > I have started reading about udevd. > I was trying to find out if there is a way to play with udev without > plugging in/out any devices. > Is there a way to trigger a uevent without plugging in devices? Yes, look at the man page

Re: [systemd-devel] Udevd and dev file creation

On Sun, Jan 30, 2022 at 09:15:14AM +0530, Nishant Nayan wrote: > Hi, > Does creating a dev file in /dev creates a uevent? The kernel creates /dev files directly in devtmpfs. When that happens, yes the kernel sends a uevent. If a user creates a /dev file on their own, no, no ueven happens.

Re: [systemd-devel] Additional Information for Ethernet

On Thu, Dec 09, 2021 at 03:13:42AM +, Spencer Ku (古世瑜) wrote: > Hi All, > We are developing the redfish of openbmc, and want to expose some Ethernet > information through the redfish interface, like packet count, drop count. My > goal is to calculate the bandwidth / drop package rate of the

Re: [systemd-devel] hardware conditional OS boot/load

On Thu, Nov 18, 2021 at 07:16:55PM +, lejeczek wrote: > Hi guys. > > I hope an expert(or two) could shed some light - I ain't a kernel nor > hardware expert so go easy on me please - on whether it is possible to boot > system only under certain conditions, meaning: as early as possible

Re: [systemd-devel] [systemd]: sd-sync lead to kernel panic

On Wed, Jun 30, 2021 at 02:54:24PM +0800, www wrote: > Dear all, > > > systemd version: v234 > kernel version: 5.1.5 That is a very old and obsolete and insecure and known-buggy kernel version. Please work with the vendor who is forcing you to use this kernel version as you are paying them for

Re: [systemd-devel] Ordering of systemd-tmpfiles-setup.service and systemd-modules-load.service

On Wed, Jun 23, 2021 at 12:27:53PM -0500, Ian Pilcher wrote: > I would like to add a udev rule that creates a symlink to a sysfs > directory, and a subdirectory of /run seem like the right place to put > it. Of course this means that the subdirectory needs to exist. sysfs should be

Re: [systemd-devel] Adding USB ID to hwdb/usb.ids

On Wed, Jun 02, 2021 at 03:48:41PM +0200, Reindl Harald wrote: > > > Am 02.06.21 um 07:04 schrieb Greg KH: > > On Tue, Jun 01, 2021 at 09:38:37PM +0200, Michael Biebl wrote: > > > Am Di., 1. Juni 2021 um 20:44 Uhr schrieb Greg KH > > > : > > > >

Re: [systemd-devel] Adding USB ID to hwdb/usb.ids

On Tue, Jun 01, 2021 at 09:38:37PM +0200, Michael Biebl wrote: > Am Di., 1. Juni 2021 um 20:44 Uhr schrieb Greg KH > : > > Works for me! Make sure you are not trying to connect to 'https'. > > No https? Why? Because why would serving up text files about this to

Re: [systemd-devel] Adding USB ID to hwdb/usb.ids

On Tue, Jun 01, 2021 at 08:28:23PM +0200, Daniele Nicolodi wrote: > On 01/06/2021 16:16, Greg KH wrote: > > linux-usb.org does not look broken to me, what needs to be fixed on it? > > I get a "503 Service Unavailable" error trying to access > http://www.linux-usb.or

Re: [systemd-devel] Adding USB ID to hwdb/usb.ids

On Tue, Jun 01, 2021 at 03:04:47PM +0200, Lennart Poettering wrote: > On Do, 13.05.21 11:54, Thomas A (thomas...@gmail.com) wrote: > > > Hi, > > > > I'm trying to add the info for Thrustmaster T150 Racing Wheel to the hwdb. I > > have found that the USB values are stored

Re: [systemd-devel] manually lading kernel modules and have created /dev/* in container?

On Mon, May 17, 2021 at 07:08:55PM +0200, Marc Weber wrote: > > devtmpfs > > thanks. So I can modprobe (-r) the modules from both host/container, > > eg dahdi_transcode makes /dev/dahdi/transcode appear. > > But when mounting from container I can write / read from it (getting errors > > about 

Re: [systemd-devel] manually lading kernel modules and have created /dev/* in container?

On Mon, May 17, 2021 at 10:20:50AM +0200, Marc Weber wrote: > Man says: > > " > > The host system cannot be rebooted and kernel modules may not be >loaded from within the container. > " > > https://lists.freedesktop.org/archives/systemd-devel/2015-February/027805.html > said: > > " >

Re: [systemd-devel] Looking for known memory leaks triggered by stress testing add/remove/up/down interfaces

On Mon, Feb 22, 2021 at 06:22:44AM -0500, Robert P. J. Day wrote: > On Thu, 18 Feb 2021, Lennart Poettering wrote: > > > On Do, 18.02.21 11:48, Robert P. J. Day (rpj...@crashcourse.ca) wrote: > > > > > A colleague has reported the following apparent issue in a fairly > > > old (v230) version of

Re: [systemd-devel] Looking for known memory leaks triggered by stress testing add/remove/up/down interfaces

On Fri, Feb 19, 2021 at 06:09:16PM +0200, Mantas Mikulėnas wrote: > On Fri, Feb 19, 2021 at 4:49 PM Lennart Poettering > wrote: > > > On Fr, 19.02.21 09:28, Robert P. J. Day (rpj...@crashcourse.ca) wrote: > > > > > i guess i expected that the CVE identifier would be in the commit > > > message.

Re: [systemd-devel] udev and btrfs multiple devices

On Thu, Jan 28, 2021 at 01:32:03AM -0700, Chris Murphy wrote: > On Thu, Jan 28, 2021 at 1:03 AM Greg KH wrote: > > > > On Wed, Jan 27, 2021 at 05:19:38PM -0700, Chris Murphy wrote: > > > > > > Next, is it possible to enhance udev so that it can report the

Re: [systemd-devel] udev and btrfs multiple devices

On Wed, Jan 27, 2021 at 05:19:38PM -0700, Chris Murphy wrote: > > Next, is it possible to enhance udev so that it can report the number > of devices expected for a Btrfs file system? This information is > currently in the Btrfs superblock found on each device in the > num_devices field. >

Re: [systemd-devel] Why systemd-nspawn is slower than docker, podman and qemu?! how to Improve nspawn performance?

On Mon, Jan 25, 2021 at 11:56:09AM +0100, Badr Elmers wrote: > Hi, > Why nspawn is slow compared to docker podman and even qemu?! > CPU tasks take twice of the time it takes in docker, podman or qemu > > here I filled a request to improve nspawn performance which contain the > steps and the full

Re: [systemd-devel] Udev rules for interfaces

On Fri, Dec 25, 2020 at 11:01:47AM +0200, Adi Ml wrote: > Hi, > > I am trying to generate rules in udev to block mass storage. It seems like > it only checks the device itself (its class is 00), but not its interface > classes (one of those is 08, a mass storage). It seems like there is only >

Re: [systemd-devel] Udev hardening

On Mon, Dec 14, 2020 at 06:18:24PM +0200, Adi Ml wrote: > I guess that udev can block devices from userspace only, so from there. > > Of course, you are right-whitelist is better. > > As for usbguard, I thought about using seccomp and filterring system calls > in my udev service based on their

Re: [systemd-devel] Udev hardening

On Mon, Dec 14, 2020 at 05:31:17PM +0200, Adi Ml wrote: > I am using udev in order to create a kiosk mode. I want to block devices > which fit a certain vid pid. Block devices from where? The kernel or userspace? udev runs _after_ the kernel has seen the device and bound to it. And usb

Re: [systemd-devel] Udev hardening

On Mon, Dec 14, 2020 at 04:30:58PM +0200, Adi Ml wrote: > Hi, > Is there some way to detect which system calls, I am using in udev (in > order to filter it)? I don't understand, if you don't know what system calls you are needing, why do you need to filter anything? Do you not trust udev to work

Re: [systemd-devel] Udev hardening

On Mon, Dec 14, 2020 at 02:54:31PM +0200, Adi Ml wrote: > Hi, > > I would like to harden my udev service with the > SystemCallFilter option. What systemcalls should be permitted/allowed in > order to secure it and avoid irrelevant system calls? It all depends on what type of scripts/programs you

Re: [systemd-devel] Creating executable device nodes in /dev?

On Fri, Dec 11, 2020 at 12:46:35PM +0200, Jarkko Sakkinen wrote: > On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote: > > On 9.12.2020 2.15, Jarkko Sakkinen wrote: > > > On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote: > > > > > > > As a further argument, I just did

Re: [systemd-devel] Memory in systemctl status

On Mon, Sep 28, 2020 at 02:22:17PM +0200, Reindl Harald wrote: > honestly: do you realize that i know very well how the memory management > of Linux works and that it's pretty fine but not part of the topic at all? *plonk* ___ systemd-devel mailing list

Re: [systemd-devel] Memory in systemctl status

On Mon, Sep 28, 2020 at 11:37:20AM +0200, Reindl Harald wrote: > > > Am 28.09.20 um 11:19 schrieb Benjamin Berg: > >> if i would set "MemoryMax" to 4G "Memory: 8.6G" would kill it when the > >> caches are accounted in that context > > > > No, the kernel kicks in and reclaims memory at that

Re: [systemd-devel] Memory in systemctl status

On Sun, Sep 27, 2020 at 01:41:33PM +0200, Reindl Harald wrote: > Memory: 8.6G > > looks like there is a large part of os-caching included where i wonmder > how that's done because a file can be read by muliple processes / > services and is hopfefully only once cached > > however, that value

Re: [systemd-devel] device enumeration by systemd user instances

On Thu, Jul 25, 2019 at 05:29:33PM +0200, Pawel Szewczyk wrote: > On 7/17/19 23:14, Greg KH wrote: > > > > 100ms seems like a really long time, what exactly is it doing during > > that time? Is the kernel spending too much time regenerating the > > uevents? > &

Re: [systemd-devel] device enumeration by systemd user instances

On Wed, Jul 17, 2019 at 05:46:58PM +0200, Pawel Szewczyk wrote: > Dear all > > I was recently working on reducing booting time and I see one issue that > I think is worth discussing. > > The problem is the device units enumeration seems to take a long time > (>100ms in our case) before any

Re: [systemd-devel] udev_device_get_driver implementation

A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I

Re: [systemd-devel] udev_device_get_driver implementation

On Wed, Apr 24, 2019 at 10:10:08AM -0700, Sayeed hyder wrote: > Forgot to hit "reply all" > > On Wed, Apr 24, 2019 at 9:52 AM Sayeed hyder wrote: > > > Hi Greg, > > > > Sure, this is what I get if I use the syspath from > > udev_device_get_syspath. As you can see, it is showing a symlink to a >

Re: [systemd-devel] udev_device_get_driver implementation

On Wed, Apr 24, 2019 at 08:38:02AM -0700, Sayeed hyder wrote: > Hi, > > I was looking at the udev_device_get_driver implementation. It first gets > the sys path and then appends "driver", and calls readlink to get the > driver information. Does it work for all cases? While working on a project, >

Re: [systemd-devel] Fail to load network modules properly

On Sun, Jan 27, 2019 at 09:14:37PM +0100, Łukasz Słaboń wrote: > Hello everyone, > > Since starting using linux last year (xubuntu 18.04) I am experiencing > occasional problems with wifi interface (broadcom BCM43224 rev 01 > 14e4:4353). From time to time (every 3 - 4 starts) my wifi card is not

Re: [systemd-devel] udev

On Wed, Nov 01, 2017 at 10:04:19AM -0400, David Henderson wrote: > Good morning Lennart, thanks for the follow-up! At this point I am > only interested in building a particular program (udev) from the > systemD collection, not help building a distribution. And I think if > I tried to contact LFS

Re: [systemd-devel] About stable network interface names

On Sat, Jun 10, 2017 at 09:08:17AM +0300, Andrei Borzenkov wrote: > 09.06.2017 23:42, Martin Wilck пишет: > > On Tue, 2017-06-06 at 21:40 +0300, Andrei Borzenkov wrote: > >> > >> Can device and function really change? My understanding is that > >> device > >> part is determined by bus physical

Re: [systemd-devel] Systemd license vs. libcryptsetup license

On Wed, Jun 07, 2017 at 05:26:21PM +0200, Krzysztof Jackiewicz wrote: > Thanks, for explanation. > > > - a collection of rpms, like a linux distro, including systemd.rpm, > > libcryptsetup.rpm, and thousands of other loosely coupled rpms > > → that's a mere aggregation, each of the thousands

Re: [systemd-devel] About stable network interface names

On Mon, May 29, 2017 at 11:34:13AM +0200, Cesare Leonardi wrote: > On 29/05/2017 07:10, Greg KH wrote: > > Anyway, PCI can, and will sometimes, renumber it's devices on booting > > again, that's a known issue. It is rare, but as you have found out, > > will happen. So anyt

Re: [systemd-devel] About stable network interface names

On Mon, May 29, 2017 at 02:35:12AM +0200, Cesare Leonardi wrote: > I ask because I've done several tests, with different motherboards, adding > and removing PCI-express cards and that expectation was not satisfied in > many cases. > > For example, in one of those tests I initially had this setup:

Re: [systemd-devel] WebUSB

On Wed, Jan 25, 2017 at 02:38:06PM +0100, Lars Knudsen wrote: > 1. someone plugs in hardware with an unknown VID/PID but CDC capabilities > 2. modemmanager does it's magic probing and finds "this is not a modem" > 3. the VID/PID(& more if needed) + findings is sent to a cloud db ... Do you want a

Re: [systemd-devel] WebUSB

On Fri, Jan 20, 2017 at 01:18:12PM +0100, Lars Knudsen wrote: > > The full device should be fine if it has a WebUSB interface (even in a > > composite scenario) > > Really?  You want to allow someone "raw" access to a composite device > just because of one specific interface? > >

Re: [systemd-devel] WebUSB

On Fri, Jan 20, 2017 at 12:55:20PM +0100, Lars Knudsen wrote: > On Fri, Jan 20, 2017 at 12:05 PM, Greg KH <gre...@linuxfoundation.org> wrote: > >  - so if we can make a rule that consistently detects USB devices with a > WebUSB > > interface defined, we should g

Re: [systemd-devel] WebUSB

On Fri, Jan 20, 2017 at 11:43:24AM +0100, Lars Knudsen wrote: > > > On Mon, Jan 16, 2017 at 3:23 PM, Simon McVittie > > wrote: > > On Mon, 09 Jan 2017 at 10:20:33 +0100, Lars Knudsen wrote: > > 2. make sure that webusb devices will be somehow

Re: [systemd-devel] WebUSB

On Tue, Jan 10, 2017 at 06:23:13PM +0100, Lars Knudsen wrote: > > > On Jan 10, 2017 18:19, "Greg KH" <g...@kroah.com> wrote: > > On Tue, Jan 10, 2017 at 06:04:46PM +0100, Lars Knudsen wrote: > > I figured that made most sense :) > > >

Re: [systemd-devel] WebUSB

On Tue, Jan 10, 2017 at 08:39:28AM +0100, Lars Knudsen wrote: > > > On Jan 10, 2017 07:51, "Greg KH" <g...@kroah.com> wrote: > > On Mon, Jan 09, 2017 at 01:32:40PM -0800, Reilly Grant wrote: > > On 2017-01-09 9:55 am, Greg KH wrote: > >

Re: [systemd-devel] WebUSB

On Mon, Jan 09, 2017 at 01:32:40PM -0800, Reilly Grant wrote: > On 2017-01-09 9:55 am, Greg KH wrote: > > On Mon, Jan 09, 2017 at 06:13:04PM +0100, Bjørn Mork wrote: > > > Greg KH <g...@kroah.com> writes: > > > > On Mon, Jan 09, 2017 at 09:40:59AM +, Kenne

Re: [systemd-devel] WebUSB

On Mon, Jan 09, 2017 at 06:13:04PM +0100, Bjørn Mork wrote: > Greg KH <g...@kroah.com> writes: > > On Mon, Jan 09, 2017 at 09:40:59AM +, Kenneth Rohde Christiansen wrote: > >> Web USB can only grab devices which has special Web USB headers. It can not > >> grab

Re: [systemd-devel] WebUSB

On Mon, Jan 09, 2017 at 01:12:11PM +0200, Felipe Balbi wrote: > > I don't think we need to change anything in the kernel. What we need is > generic udev rule that fixes up permissions for the WebUSB Interface. > > IIRC, WebUSB is implemented much like CDC ACM, however bInterfaceClass > is set to

Re: [systemd-devel] WebUSB

On Mon, Jan 09, 2017 at 11:29:24AM +0100, Aleksander Morgado wrote: > On Mon, Jan 9, 2017 at 11:07 AM, Greg KH <g...@kroah.com> wrote: > > On Mon, Jan 09, 2017 at 09:40:59AM +, Kenneth Rohde Christiansen wrote: > >> Web USB can only grab devices which has special

Re: [systemd-devel] Stable interface names even when hardware is added or removed, not true

On Wed, Nov 16, 2016 at 03:33:42PM +0200, Pekka Sarnila wrote: > On 'Predictable Network Interface Names' it states as a benefit of the new > policy: > > Stable interface names even when hardware is added or removed, i.e. > no re-enumeration takes place > > Unfortunately this is not true. >

Re: [systemd-devel] TTL for systemd -> EL7

On Wed, Oct 12, 2016 at 09:08:27AM -0400, Chris Bell wrote: > Hey everyone, > > Not sure if this is the right place to ask, but I figured someone here or at > RH would know. What's the TTL for systemd updates on EL7? My Arch box runs > 231, but our EL7 (RHEL7.2) boxes are only at 219, where it

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

On Tue, Aug 16, 2016 at 01:55:34PM +, Jóhann B. Guðmundsson wrote: > On 08/16/2016 12:53 PM, Greg KH wrote: > > On Tue, Aug 16, 2016 at 12:51:12PM +, Jóhann B. Guðmundsson wrote: > > > On 08/16/2016 12:34 PM, Greg KH wrote: > > > >

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

On Tue, Aug 16, 2016 at 12:47:16PM +, Jóhann B. Guðmundsson wrote: > > > On 08/16/2016 12:31 PM, Greg KH wrote: > > On Tue, Aug 16, 2016 at 12:25:47PM +, Jóhann B. Guðmundsson wrote: > > > > > > On 08/16/2016 11:28 AM, Greg KH wrote: > > >

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

On Tue, Aug 16, 2016 at 12:51:12PM +, Jóhann B. Guðmundsson wrote: > On 08/16/2016 12:34 PM, Greg KH wrote: > > > But agreement is usually the best way to work things out, don't you > > think? Isn't it better than the traditional way a company works (a > > projec

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

On Tue, Aug 16, 2016 at 12:35:13PM +, Jóhann B. Guðmundsson wrote: > > > On 08/16/2016 12:13 PM, Greg KH wrote: > > On Tue, Aug 16, 2016 at 11:23:03AM +, Jóhann B. Guðmundsson wrote: > > > Why cant the kernel community figure this out and solve this upstream >

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

On Tue, Aug 16, 2016 at 12:25:47PM +, Jóhann B. Guðmundsson wrote: > > > On 08/16/2016 11:28 AM, Greg KH wrote: > > On Tue, Aug 16, 2016 at 11:15:03AM +, Jóhann B. Guðmundsson wrote: > > > > > > On 08/16/2016 10:44 AM, Greg KH wrote: > > >

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

On Tue, Aug 16, 2016 at 11:23:03AM +, Jóhann B. Guðmundsson wrote: > On 08/16/2016 10:42 AM, Greg KH wrote: > > As long as this new code doesn't break things for users without those > kernel patches, why would you object? Are you having to maintain these > new fe

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

On Tue, Aug 16, 2016 at 11:15:03AM +, Jóhann B. Guðmundsson wrote: > > > On 08/16/2016 10:44 AM, Greg KH wrote: > > On Tue, Aug 16, 2016 at 10:11:27AM +, Jóhann B. Guðmundsson wrote: > > > Recent case in point is the that the wireguard maintainer was/is >

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

On Tue, Aug 16, 2016 at 10:11:27AM +, Jóhann B. Guðmundsson wrote: > Recent case in point is the that the wireguard maintainer was/is interested > seeing it property integrated into systemd. Anywork related to that could not > be started *until* he had his stuff merged in the upstream kernel

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

On Tue, Aug 16, 2016 at 10:11:27AM +, Jóhann B. Guðmundsson wrote: > On 08/16/2016 09:04 AM, Lennart Poettering wrote: > > On Mon, 15.08.16 10:53, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: > > Johann, what you are posting here is really not helpful in any > way. > > >

Re: [systemd-devel] question on special configuration case

On Wed, Jun 08, 2016 at 06:43:04AM +, Hebenstreit, Michael wrote: > > Really? No journal messages are getting created at all? No users logging > > in/out? What does strace show on those processes? > > Yes, messages are created - but I'm not interested in them. Maybe a > user logs in for a

Re: [systemd-devel] question on special configuration case

On Wed, Jun 08, 2016 at 02:04:48AM +, Hebenstreit, Michael wrote: > > What processes are showing up in your count? Perhaps it's just a > > bug that needs to be fixed. > /bin/dbus-daemon > /usr/lib/systemd/systemd-journald > /usr/lib/systemd/systemd-logind > > I understand from the previous

Re: [systemd-devel] question on special configuration case

On Tue, Jun 07, 2016 at 11:50:36PM +, Hebenstreit, Michael wrote: > The base system is actually pretty large (currently 1200 packages) - I > hate that myself. Still performance wise the packages are not the > issue. The SSDs used can easily handle that, and library loads are > only happening

Re: [systemd-devel] systemd network interface names - new twist

On Thu, Jun 02, 2016 at 06:29:50PM +0200, Reindl Harald wrote: > > > Am 02.06.2016 um 18:20 schrieb Greg KH: > > Ok, but please ask on a fedora list as this is a fedora specific issue, > > as it is running a very old version of systemd as well as the kernel, so > >

Re: [systemd-devel] systemd network interface names - new twist

On Thu, Jun 02, 2016 at 10:14:22AM -0600, JB wrote: > Hi Greg, > Thank you very much for responding! > > On 6/2/2016 9:46 AM, Greg KH wrote: > > On Thu, Jun 02, 2016 at 06:24:39AM -0600, JB wrote: > > > I'm running kernel 3.18.22. I'm seeing some odd behavior from sys

Re: [systemd-devel] systemd network interface names - new twist

On Thu, Jun 02, 2016 at 06:24:39AM -0600, JB wrote: > I'm running kernel 3.18.22. I'm seeing some odd behavior from systemd. The > motherboard is an intel board with dual onboard NIC. I installed FC21 > initially with secondary ethernet interface disabled in the BIOS. Then after > install, I

Re: [systemd-devel] when/where was support for assigning "ethX" names removed?

On Fri, May 27, 2016 at 09:14:51AM -0600, Chris Friesen wrote: > On 05/27/2016 08:36 AM, Lennart Poettering wrote: > > On Thu, 26.05.16 12:28, Chris Friesen (cbf...@mail.usask.ca) wrote: > > > > > So I've been playing with this a bit, but I've run into another snag. It > > > seems that on

Re: [systemd-devel] when/where was support for assigning "ethX" names removed?

On Thu, May 26, 2016 at 01:49:07PM -0600, Chris Friesen wrote: > On 05/26/2016 12:41 PM, Martin Pitt wrote: > > Chris Friesen [2016-05-26 12:28 -0600]: > > > So I've been playing with this a bit, but I've run into another snag. It > > > seems that on initial boot even with "net.ifnames=0" the

Re: [systemd-devel] Verify the gpg signature of the given tag

On Wed, May 11, 2016 at 09:57:05AM +0200, poma wrote: > > $ git tag --verify v229 > object 95adafc428b5b4be0ddd4d43a7b96658390388bc > type commit > tag v229 > tagger Lennart Poettering 1455208658 +0100 > > systemd 229 > gpg: Signature made Thu 11 Feb 2016 05:37:38 PM CET

Re: [systemd-devel] service dependency on udev

On Tue, Apr 19, 2016 at 05:25:09PM -0300, Flavio Leitner wrote: > > Hello, > > I have a service that needs to start after all the devices (network > cards at least) have been properly processed by udev. Pretty much > like the old 'network' sysv script. > > Any suggestion? How do you define

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

On Wed, Apr 13, 2016 at 02:42:29AM +0200, Xen wrote: > When you say that probing on the PCI bus never ends, and if we are > talking not about some form of hotplugging, then I really wonder what > you're on about ;-) because I do think the kernel has a limited set of > probes that it can perform,

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

On Wed, Apr 13, 2016 at 01:20:05AM +0200, Xen wrote: > Greg KH schreef op 13-04-16 01:16: > > On Wed, Apr 13, 2016 at 12:39:37AM +0200, Xen wrote: > >> All you need to do is wait a few seconds before you start renaming > > > > Most machines boot to login faster than

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

On Wed, Apr 13, 2016 at 12:39:37AM +0200, Xen wrote: > All you need to do is wait a few seconds before you start renaming Most machines boot to login faster than a "few seconds", so: > or wait on some defined trigger. Exactly what type of "defined trigger" would work for busses that you never

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

On Mon, Apr 11, 2016 at 11:13:25PM +0200, Xen wrote: > >> You can put usb devices at the end of the list. > > > > Why last? How do you know they go last when scanning? How do you know > > when / if they will show up? What about 2 USB devices? 3? > > To me it seems obvious that you initialize

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

On Mon, Apr 11, 2016 at 08:49:48PM +0200, Xen wrote: > It will just not be "predictable" when you remove or add hardware, > because that reorders the resulting lists. > > Ie, if you have: > > ethernet0 > ethernet1 > ethernet2 > > And you add a new device, it might become: > > ethernet0 >

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

On Mon, Apr 11, 2016 at 08:49:48PM +0200, Xen wrote: > It will just not be "predictable" when you remove or add hardware, > because that reorders the resulting lists. > > Ie, if you have: > > ethernet0 > ethernet1 > ethernet2 > > And you add a new device, it might become: > > ethernet0 >

Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames

On Mon, Apr 11, 2016 at 07:59:30PM +0200, Xen wrote: > Greg KH schreef op 11-04-16 15:42: > > On Mon, Apr 11, 2016 at 11:56:00AM +0200, Xen wrote: > >> The predictability issue seems to be due to using a MAC address. > >> > >> AFAIK a reinstall will not change P

Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames

On Mon, Apr 11, 2016 at 11:56:00AM +0200, Xen wrote: > The predictability issue seems to be due to using a MAC address. > > AFAIK a reinstall will not change PCI bus devices etc. No, PCI device numbers change all the time, they are not guaranteed to be stable at all. Yes, lots of machines do

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

On Mon, Apr 11, 2016 at 12:27:24AM +0200, Xen wrote: > Michael Biebl schreef op 11-04-16 00:22: > > So why don't you implement such a scheme? Talk is cheap > > Criticising an idea by saying "do it yourself" is even cheaper. > > MUCH MUCH cheaper. > > Idiot. No he isn't. The developers here

Re: [systemd-devel] Fwd: Random X crash on nvidia card on Gnome 3.20

On Sun, Apr 10, 2016 at 11:12:00PM +0800, Bob Peng wrote: > Today I upgraded to 3.20 and it begins random crash, log is attached. > and dmesg log too. This isn't a systemd issue, it's a nvidia issue, please contact them for support as they are the only ones that can do so because of their closed

Re: [systemd-devel] Utility for persistent alternative driver binding

On Wed, Dec 09, 2015 at 08:43:05AM +0200, Panu Matilainen wrote: > On 12/08/2015 01:47 PM, Greg KH wrote: > >On Tue, Dec 08, 2015 at 11:34:36AM +0200, Panu Matilainen wrote: > >>>As was mentioned recently PCI bus numbers may change between reboots, so > >> > >&

  1   2   3   >