[systemd-devel] udev database cross-version compatibility

[Valentin David]

Hello,

Back in 2014 and again in 2020, there were discussions on the mailing-list 
related to udev database version safety. This was important to know if libudev 
from a container could access to /run/udev/data files safely. Given then 
libudev and systemd-udevd would be potentially different version.

The conclusion was that there was no guarantee. And based on that flatpak has 
not provided /run/udev/data to applications.

Later, the format changed in #16853 (udev: make uevents "sticky"). But this 
caused issue #17605 (Units with BindsTo= are being killed on upgrade 
from v246 to v247).

This was fixed by #17622 (sd-device: make sd_device_has_current_tag() 
compatible with udev database generated by older udevd).

It seems to me, because udev needs to handle upgrade and downgrade, that it 
will continue to handle some compatibility across versions.

Is it safe now for flatpak to provide /run/udev/data to containers?

(Also, snapd does it, oops)

--
Valentin David
m...@valentindavid.com

Re: [systemd-devel] udev remove event no longer contains ID_VENDOR_ID/ID_MODEL_ID

[Matt Turner]

On Thu, Aug 17, 2023 at 11:09 AM Matt Turner  wrote:
>
> Hello,
>
> I'm working on updating ChromeOS's ancient udev-225 + 24 patches to 
> udev-249.9.
>
> In the course of testing, we discovered that udev remove events no
> longer contain ID_VENDOR_ID or ID_MODEL_ID. Apparently this change
> happened sometime between v225 and v239 (it was noticed during an
> earlier attempt to update udev to 239). Someone questioned whether
> this was an intentional change or a bug, and I suspect it's
> intentional and requires some changes to ChromeOS.
>
> I searched but didn't find anything in git log v225..v239, but I
> easily could have missed something "obvious" in ~15k commits.
>
> Before I bisect to find where the change happened, does anyone happen
> to remember offhand?
>
> Thanks,
> Matt

FWIW, we discovered that the vendor/model/revision IDs are also
available in the PRODUCT= variable (in both v225 and v249) so we've
switched to using that.

[systemd-devel] udev remove event no longer contains ID_VENDOR_ID/ID_MODEL_ID

[Matt Turner]

Hello,

I'm working on updating ChromeOS's ancient udev-225 + 24 patches to udev-249.9.

In the course of testing, we discovered that udev remove events no
longer contain ID_VENDOR_ID or ID_MODEL_ID. Apparently this change
happened sometime between v225 and v239 (it was noticed during an
earlier attempt to update udev to 239). Someone questioned whether
this was an intentional change or a bug, and I suspect it's
intentional and requires some changes to ChromeOS.

I searched but didn't find anything in git log v225..v239, but I
easily could have missed something "obvious" in ~15k commits.

Before I bisect to find where the change happened, does anyone happen
to remember offhand?

Thanks,
Matt

[systemd-devel] udev ata_id environment keys not imported for sata hdd

[Mauricio Garavaglia]

Hello,

While debugging why `pm-utils` hdparam udev rules were not picked up by my
SATA HDD, I found that it depends on the presence of the 
`ID_ATA_FEATURE_SET_APM`

env key to set the drive advanced power management. This key is returned by
`ata_id` correctly but, among other values, they are never imported as
environment keys by udev.

They seem to be imported in `/lib/udev/rules.d/60-persistent-storage.rules`

# ATA
KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*", SUBSYSTEMS=="scsi", \
 ATTRS{vendor}=="ATA", IMPORT{program}="ata_id --export $devnode"

But this rule is not applied since `sg3_utils` already set an 
`ID_SERIAL` in [1].


I workaround this by introducing a new rule that imports the `ata_id` 
output on that
device, without the ID_SERIAL condition, which makes hdparm to detect 
APM correctly.


So, regardless of how hdparm is detecting APM capabilities, I'm not sure 
the current

behavior is expected or not. I would assume the `ata_id` env properties are
always imported if the device has `ID_ATA=1`. Does it make sense?

I found this on an fresh Ubuntu 22.04.2 LTS with systemd 249 
(249.11-0ubuntu3.9)


Thanks!


[1] 
https://github.com/hreinecke/sg3_utils/blob/master/scripts/55-scsi-sg3_id.rules#L100C61-L100C61



--
Mauricio Garavaglia

Re: [systemd-devel] udev rule, continue to next rule only if preb failed

[daggs]

Greetings,

> Sent: Friday, May 26, 2023 at 12:02 PM
> From: "daggs" 
> To: "Lennart Poettering" 
> Cc: systemd-devel@lists.freedesktop.org
> Subject: Re: [systemd-devel] udev rule, continue to next rule only if preb 
> failed
>
> Greetings Lennart,
>
> > Sent: Friday, May 26, 2023 at 11:23 AM
> > From: "Lennart Poettering" 
> > To: "daggs" 
> > Cc: systemd-devel@lists.freedesktop.org
> > Subject: Re: [systemd-devel] udev rule, continue to next rule only if preb 
> > failed
> >
> > On Do, 25.05.23 20:25, daggs (da...@gmx.com) wrote:
> >
> > > Greetings,
> > >
> > > I'm trying to implement the following behavior:
> > > if a usb is added ot removed, run a script before all other existing 
> > > rules but continue to existing iff the script failed
> > > I've added the following rule to /etc/udev/rules.d/5-usb_vm.rules:
> > > ACTION=="add", SUBSYSTEM=="usb", RUN="/usr/local/bin/handle_udev_action"
> > > ACTION=="remove", SUBSYSTEM=="usb", 
> > > RUN="/usr/local/bin/handle_udev_action"
> > >
> > > /usr/local/bin/handle_udev_action runs exit 1 iff the device is a 
> > > specific one (for testing)
> > > but the code continues to the next rule.
> > > is there any way to stop it if the script returned 9?
> >
> > Please see documentation. RUN= is invoked *after* the rules have
> > finished execution.
> >
> > There's IMPORT{program}=, which is run as part of rule processing, but it 
> > can only be used for very quickly
> > running programs, and you have to communicate results of your script
> > via properties you write to stdout rather than exit status.
> >
> > Lennart
> >
> > --
> > Lennart Poettering, Berlin
> >
>
> thank you for the information, I'll into it
>
> Dagg
>

I was able to implement the first part (the detection and action) using import 
without any issues.
but I'm wondering if I can prevent execution of the rest of the rules without 
changing the default usb rule files.
I think it might be done with the goto directive, however I'm nor sure I 
understand how a goto in file one at /etc/udev/rules.d affects another rule 
which gets executed later at /lib/udev/rules.d/
maybe udev knows it by noticing the rules are using shared subsystem and action?

Thanks,

Dagg

Re: [systemd-devel] udev rule, continue to next rule only if preb failed

[daggs]

Greetings Lennart,

> Sent: Friday, May 26, 2023 at 11:23 AM
> From: "Lennart Poettering" 
> To: "daggs" 
> Cc: systemd-devel@lists.freedesktop.org
> Subject: Re: [systemd-devel] udev rule, continue to next rule only if preb 
> failed
>
> On Do, 25.05.23 20:25, daggs (da...@gmx.com) wrote:
>
> > Greetings,
> >
> > I'm trying to implement the following behavior:
> > if a usb is added ot removed, run a script before all other existing rules 
> > but continue to existing iff the script failed
> > I've added the following rule to /etc/udev/rules.d/5-usb_vm.rules:
> > ACTION=="add", SUBSYSTEM=="usb", RUN="/usr/local/bin/handle_udev_action"
> > ACTION=="remove", SUBSYSTEM=="usb", RUN="/usr/local/bin/handle_udev_action"
> >
> > /usr/local/bin/handle_udev_action runs exit 1 iff the device is a specific 
> > one (for testing)
> > but the code continues to the next rule.
> > is there any way to stop it if the script returned 9?
>
> Please see documentation. RUN= is invoked *after* the rules have
> finished execution.
>
> There's IMPORT{program}=, which is run as part of rule processing, but it can 
> only be used for very quickly
> running programs, and you have to communicate results of your script
> via properties you write to stdout rather than exit status.
>
> Lennart
>
> --
> Lennart Poettering, Berlin
>

thank you for the information, I'll into it

Dagg

Re: [systemd-devel] udev rule, continue to next rule only if preb failed

[Lennart Poettering]

On Do, 25.05.23 20:25, daggs (da...@gmx.com) wrote:

> Greetings,
>
> I'm trying to implement the following behavior:
> if a usb is added ot removed, run a script before all other existing rules 
> but continue to existing iff the script failed
> I've added the following rule to /etc/udev/rules.d/5-usb_vm.rules:
> ACTION=="add", SUBSYSTEM=="usb", RUN="/usr/local/bin/handle_udev_action"
> ACTION=="remove", SUBSYSTEM=="usb", RUN="/usr/local/bin/handle_udev_action"
>
> /usr/local/bin/handle_udev_action runs exit 1 iff the device is a specific 
> one (for testing)
> but the code continues to the next rule.
> is there any way to stop it if the script returned 9?

Please see documentation. RUN= is invoked *after* the rules have
finished execution.

There's IMPORT{program}=, which is run as part of rule processing, but it can 
only be used for very quickly
running programs, and you have to communicate results of your script
via properties you write to stdout rather than exit status.

Lennart

--
Lennart Poettering, Berlin

[systemd-devel] udev rule, continue to next rule only if preb failed

[daggs]

Greetings,

I'm trying to implement the following behavior:
if a usb is added ot removed, run a script before all other existing rules but 
continue to existing iff the script failed
I've added the following rule to /etc/udev/rules.d/5-usb_vm.rules:
ACTION=="add", SUBSYSTEM=="usb", RUN="/usr/local/bin/handle_udev_action"
ACTION=="remove", SUBSYSTEM=="usb", RUN="/usr/local/bin/handle_udev_action"

/usr/local/bin/handle_udev_action runs exit 1 iff the device is a specific one 
(for testing)
but the code continues to the next rule.
is there any way to stop it if the script returned 9?

Thanks

Dagg

[systemd-devel] udev: parent device DEVPATH in rule

[Ian Pilcher]

What is the best way to use the parent device DEVPATH (or the DEVPATH
where a parent attribute matched) as a substitution in a udev rule?

I am doing this to create stable paths to the sysfs directories
containing the hardware monitoring attributes of my NAS, but the
location of the sysfs attributes provided by the it87 driver has changed
over the years ...

 ACTION!="add", GOTO="n5550_hwmon_end"
 SUBSYSTEM!="hwmon", GOTO="n5550_hwmon_end"

 # coretemp attributes are always in DEVPATH directory
 ATTR{name}=="coretemp", RUN{program}+="/bin/sh -c 'mkdir -p /run/n5550 
&& ln -s /sys$devpath /run/n5550/coretemp'", GOTO="n5550_hwmon_end"


 # it87 attributes are in DEVPATH directory on newer kernels
 ATTR{name}=="it8728", RUN{program}+="/bin/sh -c 'mkdir -p /run/n5550 
&& ln -s /sys$devpath /run/n5550/it87'", GOTO="n5550_hwmon_end"


 # On older kernels, it87 attributes are in parent's DEVPATH
 ATTRS{name}=="it8728", RUN{program}+="/bin/sh -c 'mkdir -p /run/n5550 
&& ln -s /sys$parent_devpath /run/n5550/it87'"


 ^^^
 LABEL="n5550_hwmon_end"

Of course "$parent_devpath" doesn't exist, so I'm trying to figure out
what I should be using instead.

(For added fun, the "older" kernel is this case is from CentOS 7, which
has systemd 219.)

Ideas appreciated.  Thanks!

--

Google  Where SkyNet meets Idiocracy

[systemd-devel] udev regression makes NAS unbootable

[Ian Pilcher]

Does anyone have any ideas on how I can move this issue forward?

  https://github.com/systemd/systemd/issues/20212

As the subject says, it makes my NAS (and other systems with "lots" of
block devices) basically unbootable.  Red Hat reverted the commits that
introduced the issue in their RHEL 8 branch:

  https://github.com/redhat-plumbers/systemd-rhel8/pull/175

Thanks!

--

 In Soviet Russia, Google searches you!


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Chris Murphy]

On Thu, Feb 4, 2021 at 6:28 AM Lennart Poettering
 wrote:
>
> On Mi, 03.02.21 22:32, Chris Murphy (li...@colorremedies.com) wrote:
> > It doesn't. It waits indefinitely.
> >
> > [* ] A start job is running for
> > /dev/disk/by-uuid/cf9c9518-45d4-43d6-8a0a-294994c383fa (12min 36s / no
> > limit)
>
> Is this on encrypted media?

No. Plain partitions.


-- 
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

On Mi, 03.02.21 22:32, Chris Murphy (li...@colorremedies.com) wrote:

> On Thu, Jan 28, 2021 at 7:18 AM Lennart Poettering
>  wrote:
> >
> > On Mi, 27.01.21 17:19, Chris Murphy (li...@colorremedies.com) wrote:
> >
> > > Is it possible for a udev rule to have a timeout? For example:
> > > /usr/lib/udev/rules.d/64-btrfs.rules
> > >
> > > This udev rule will wait indefinitely for a missing device to
> > > appear.
> >
> > Hmm, no, that's a mis understaning. "rules" can't "wait". The
> > activation of the btrfs file system won't happen, but that should then
> > be caught by systemd mount timeouts and put you into recovery mode.
>
> It doesn't. It waits indefinitely.
>
> [* ] A start job is running for
> /dev/disk/by-uuid/cf9c9518-45d4-43d6-8a0a-294994c383fa (12min 36s / no
> limit)

Is this on encrypted media?

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Chris Murphy]

On Wed, Feb 3, 2021 at 10:32 PM Chris Murphy  wrote:
>
> On Thu, Jan 28, 2021 at 7:18 AM Lennart Poettering
>  wrote:
> >
> > On Mi, 27.01.21 17:19, Chris Murphy (li...@colorremedies.com) wrote:
> >
> > > Is it possible for a udev rule to have a timeout? For example:
> > > /usr/lib/udev/rules.d/64-btrfs.rules
> > >
> > > This udev rule will wait indefinitely for a missing device to
> > > appear.
> >
> > Hmm, no, that's a mis understaning. "rules" can't "wait". The
> > activation of the btrfs file system won't happen, but that should then
> > be caught by systemd mount timeouts and put you into recovery mode.
>
> It doesn't. It waits indefinitely.
>
> [* ] A start job is running for
> /dev/disk/by-uuid/cf9c9518-45d4-43d6-8a0a-294994c383fa (12min 36s / no
> limit)

https://github.com/systemd/systemd/issues/18466


-- 
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Chris Murphy]

On Thu, Jan 28, 2021 at 7:18 AM Lennart Poettering
 wrote:
>
> On Mi, 27.01.21 17:19, Chris Murphy (li...@colorremedies.com) wrote:
>
> > Is it possible for a udev rule to have a timeout? For example:
> > /usr/lib/udev/rules.d/64-btrfs.rules
> >
> > This udev rule will wait indefinitely for a missing device to
> > appear.
>
> Hmm, no, that's a mis understaning. "rules" can't "wait". The
> activation of the btrfs file system won't happen, but that should then
> be caught by systemd mount timeouts and put you into recovery mode.

It doesn't. It waits indefinitely.

[* ] A start job is running for
/dev/disk/by-uuid/cf9c9518-45d4-43d6-8a0a-294994c383fa (12min 36s / no
limit)


-- 
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev blkid check on mmcblk0boot0 and boot1

[Alan Perry]

On 2/2/21 2:13 PM, Jeremy Linton wrote:

Hi,

On 2/2/21 1:46 PM, Alan Perry wrote:


On 2/2/21 1:55 AM, Lennart Poettering wrote:

On Mo, 01.02.21 16:36, Alan Perry (al...@snowmoose.com) wrote:
Hi, Per the udev rules, the blkid builtin is run on mmcblk*boot* 
devices to look for partition and filesystem. Those devices contain 
hardware-specific boot information and are unlikely to have 
anything on them that blkid would identify. Why isn't there a rule 
to exclude them from blkid? Is there some case that I am missing? 
Probably noone who cares about MMC enough prepped a patch for this 
so far. Also it probably doesn't matter too much... I mean, if blkid 
doesn't find anything it doesn't find anything, so not much bad 
happened? If this matters to you, and it's really clear that there 
is unlikely anything blkid-recognizable on it, then by all means, 
please send a PR! 


I have been looking into a problem that we occasionally see with 
hangs at boot time during the probe of
mmcblk0boot0. Doing some searching, I have seen reports of similar 
hangs over the years, so I see a

potential benefit of not doing the probe.

Is the blkid/libblkid code robust enough that it could sanely handle 
whatever hardware-specific collection of

bits representing the boot configuration that happens to be there?


Well I guess someone could put something like an efi system partition 
on a mmc boot. In which case you would want to probe it.


Yes, but that would seem to be the exception to how it is used. Looking 
through u-boot code, it has been used for bootloader executable images 
and/or boot info data and parameters.It seems to me that the prudent 
thing to do would be to not probe it by default.




OTOH, this really sounds like a determination of why the system is 
hanging when its touching those partitions is in order.


(hang as in, does the kernel have a bug, or is it trying to update a 
fat/etc dirty bit on a read only partition, etc?)


What I have observed is that a udevd worker thread initiates built-in 
blkid and displays nothing else after that. I am still investigating 
that part and don't know if it is in the kernel or libblkid or 
elsewhere. From systemd's perspective, boot does not complete, because 
it is waiting on boot0. However I can run blkid from the shell and it 
completes.


But, even if it wasn't hanging, in the typical case it is a waste of 
boot time to do blkid probes of these devices.


alan







I had been planning on sending a PR. As I said, the idea seemed so 
obvious to me that I wanted to confirm that
it hadn't been considered and rejected at some point in the past 
before I did.


As far as the change itself, would it be something as simple as adding:

KERNEL!="mmcblk[0-9]boot[0-9]"

before the last clause of this rule:

# probe filesystem metadata of disks
KERNEL!="sr*", IMPORT{builtin}="blkid"


alan


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev blkid check on mmcblk0boot0 and boot1

[Jeremy Linton]

Hi,

On 2/2/21 1:46 PM, Alan Perry wrote:


On 2/2/21 1:55 AM, Lennart Poettering wrote:

On Mo, 01.02.21 16:36, Alan Perry (al...@snowmoose.com) wrote:
Hi, Per the udev rules, the blkid builtin is run on mmcblk*boot* 
devices to look for partition and filesystem. Those devices contain 
hardware-specific boot information and are unlikely to have anything 
on them that blkid would identify. Why isn't there a rule to exclude 
them from blkid? Is there some case that I am missing? 
Probably noone who cares about MMC enough prepped a patch for this so 
far. Also it probably doesn't matter too much... I mean, if blkid 
doesn't find anything it doesn't find anything, so not much bad 
happened? If this matters to you, and it's really clear that there is 
unlikely anything blkid-recognizable on it, then by all means, please 
send a PR! 


I have been looking into a problem that we occasionally see with hangs 
at boot time during the probe of
mmcblk0boot0. Doing some searching, I have seen reports of similar hangs 
over the years, so I see a

potential benefit of not doing the probe.

Is the blkid/libblkid code robust enough that it could sanely handle 
whatever hardware-specific collection of

bits representing the boot configuration that happens to be there?


Well I guess someone could put something like an efi system partition on 
a mmc boot. In which case you would want to probe it.


OTOH, this really sounds like a determination of why the system is 
hanging when its touching those partitions is in order.


(hang as in, does the kernel have a bug, or is it trying to update a 
fat/etc dirty bit on a read only partition, etc?)





I had been planning on sending a PR. As I said, the idea seemed so 
obvious to me that I wanted to confirm that
it hadn't been considered and rejected at some point in the past before 
I did.


As far as the change itself, would it be something as simple as adding:

KERNEL!="mmcblk[0-9]boot[0-9]"

before the last clause of this rule:

# probe filesystem metadata of disks
KERNEL!="sr*", IMPORT{builtin}="blkid"


alan


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev blkid check on mmcblk0boot0 and boot1

[Lennart Poettering]

On Di, 02.02.21 11:46, Alan Perry (al...@snowmoose.com) wrote:

>
> On 2/2/21 1:55 AM, Lennart Poettering wrote:
> > On Mo, 01.02.21 16:36, Alan Perry (al...@snowmoose.com) wrote:
> > > Hi, Per the udev rules, the blkid builtin is run on mmcblk*boot*
> > > devices to look for partition and filesystem. Those devices contain
> > > hardware-specific boot information and are unlikely to have anything
> > > on them that blkid would identify. Why isn't there a rule to exclude
> > > them from blkid? Is there some case that I am missing?
> > Probably noone who cares about MMC enough prepped a patch for this so
> > far. Also it probably doesn't matter too much... I mean, if blkid
> > doesn't find anything it doesn't find anything, so not much bad
> > happened? If this matters to you, and it's really clear that there is
> > unlikely anything blkid-recognizable on it, then by all means, please
> > send a PR!
>
> I have been looking into a problem that we occasionally see with hangs at
> boot time during the probe of
> mmcblk0boot0. Doing some searching, I have seen reports of similar hangs
> over the years, so I see a
> potential benefit of not doing the probe.
>
> Is the blkid/libblkid code robust enough that it could sanely handle
> whatever hardware-specific collection of bits representing the boot
> configuration that happens to be there?

Well, the idea is that blkid tries to recognize what it can recognize
and is careful enough to not be fooled too easily. So far we didn't
really have any reports that media was rubbish on it was misdetected somehow.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev blkid check on mmcblk0boot0 and boot1

[Alan Perry]

On 2/2/21 1:55 AM, Lennart Poettering wrote:

On Mo, 01.02.21 16:36, Alan Perry (al...@snowmoose.com) wrote:
Hi, Per the udev rules, the blkid builtin is run on mmcblk*boot* 
devices to look for partition and filesystem. Those devices contain 
hardware-specific boot information and are unlikely to have anything 
on them that blkid would identify. Why isn't there a rule to exclude 
them from blkid? Is there some case that I am missing? 
Probably noone who cares about MMC enough prepped a patch for this so 
far. Also it probably doesn't matter too much... I mean, if blkid 
doesn't find anything it doesn't find anything, so not much bad 
happened? If this matters to you, and it's really clear that there is 
unlikely anything blkid-recognizable on it, then by all means, please 
send a PR! 


I have been looking into a problem that we occasionally see with hangs 
at boot time during the probe of
mmcblk0boot0. Doing some searching, I have seen reports of similar hangs 
over the years, so I see a

potential benefit of not doing the probe.

Is the blkid/libblkid code robust enough that it could sanely handle 
whatever hardware-specific collection of

bits representing the boot configuration that happens to be there?

I had been planning on sending a PR. As I said, the idea seemed so 
obvious to me that I wanted to confirm that
it hadn't been considered and rejected at some point in the past before 
I did.


As far as the change itself, would it be something as simple as adding:

KERNEL!="mmcblk[0-9]boot[0-9]"

before the last clause of this rule:

# probe filesystem metadata of disks
KERNEL!="sr*", IMPORT{builtin}="blkid"


alan


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev blkid check on mmcblk0boot0 and boot1

[Lennart Poettering]

On Mo, 01.02.21 16:36, Alan Perry (al...@snowmoose.com) wrote:

>
> Hi,
>
> Per the udev rules, the blkid builtin is run on mmcblk*boot* devices to look
> for partition and filesystem. Those devices contain hardware-specific boot
> information and are unlikely to have anything on them that blkid would
> identify. Why isn't there a rule to exclude them from blkid? Is there some
> case that I am missing?

Probably noone who cares about MMC enough prepped a patch for this so
far. Also it probably doesn't matter too much... I mean, if blkid
doesn't find anything it doesn't find anything, so not much bad
happened?

If this matters to you, and it's really clear that there is unlikely
anything blkid-recognizable on it, then by all means, please send a
PR!

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] udev blkid check on mmcblk0boot0 and boot1

[Alan Perry]

Hi,

Per the udev rules, the blkid builtin is run on mmcblk*boot* devices to 
look for partition and filesystem. Those devices contain 
hardware-specific boot information and are unlikely to have anything on 
them that blkid would identify. Why isn't there a rule to exclude them 
from blkid? Is there some case that I am missing?


alan


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

On Mi, 27.01.21 17:19, Chris Murphy (li...@colorremedies.com) wrote:

> Is it possible for a udev rule to have a timeout? For example:
> /usr/lib/udev/rules.d/64-btrfs.rules
>
> This udev rule will wait indefinitely for a missing device to
> appear.

Hmm, no, that's a mis understaning. "rules" can't "wait". The
activation of the btrfs file system won't happen, but that should then
be caught by systemd mount timeouts and put you into recovery mode.

udev only does the most basic form of btrfs raid activation. If you
want more complex policies (i.e. "boot cleanly if 5 of the 7 hdd's
have shown up plus 30s passed") then put that into some storage
daemon. udev is not supposed to implement complex policies like that.

> It'd be better if it gives up at some point and drops to a dracut
> shell. Is that possible? The only alternative right now is the user
> has to force power off, and boot with something like
> rd.break=pre-mount, although I'm not 100% certain that'll break soon
> enough to avoid the hang.

That should be the default.

But note that once you throw cryptsetup into mix the mount activation
timeout is typically automatically turned off, because we cannot
distinguish the cases where devices didn't show up because hdd borked
from "user didn't type in their pw in time". To give the user any time
they want for typing it in the logic thus turns off root fs activation
timeouts.

> 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.
> https://github.com/storaged-project/udisks/pull/838#issuecomment-768372627

systemd/udev has no clue about btrfs superblocks. It only talks to
libblkid, and to the kernel. It doesn't parase anything on its own. If
you want this property to be attached to the udev device, please
request this from the libblkid maintainer, since we basically import
all props it gives us 1:1 into udev rules.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Greg KH]

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 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.
> > > https://github.com/storaged-project/udisks/pull/838#issuecomment-768372627
> >
> > It's not up to udev to report that, but rather have either the kernel
> > export that, or have the tool that udev calls determine that.
> 
> I mean expose in udevadm info, e.g.
> 
> E: ID_BTRFS_NUM_DEVICES=4

Again, that is up to either the kernel, or a tool that udev calls to do
that, udev itself doesn't know device-specific things, that's not what
it is designed to do.

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Chris Murphy]

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 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.
> > https://github.com/storaged-project/udisks/pull/838#issuecomment-768372627
>
> It's not up to udev to report that, but rather have either the kernel
> export that, or have the tool that udev calls determine that.

I mean expose in udevadm info, e.g.

E: ID_BTRFS_NUM_DEVICES=4


-- 
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Greg KH]

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.
> https://github.com/storaged-project/udisks/pull/838#issuecomment-768372627

It's not up to udev to report that, but rather have either the kernel
export that, or have the tool that udev calls determine that.

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] udev and btrfs multiple devices

[Chris Murphy]

Is it possible for a udev rule to have a timeout? For example:
/usr/lib/udev/rules.d/64-btrfs.rules

This udev rule will wait indefinitely for a missing device to appear.
It'd be better if it gives up at some point and drops to a dracut
shell. Is that possible? The only alternative right now is the user
has to force power off, and boot with something like
rd.break=pre-mount, although I'm not 100% certain that'll break soon
enough to avoid the hang.

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.
https://github.com/storaged-project/udisks/pull/838#issuecomment-768372627


Thanks,

-- 
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev rules for interfaces

[Greg KH]

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
> attr{bDeviceClass} but there is attr{bInterfaceClass} only when I specify
> the interface number.
> 
> 
> How is it possible to set the rules against its interfaces too?

Yes, interfaces are "devices" according to the kernel, that is what
drivers are bound to.

But, again, please just use USBGuard, it handles all of this for you
automatically.

good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Udev rules for interfaces

[Adi Ml]

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
attr{bDeviceClass} but there is attr{bInterfaceClass} only when I specify
the interface number.


How is it possible to set the rules against its interfaces too?

Thank you
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev rules on reboot

[Mantas Mikulėnas]

On Sun, Dec 20, 2020, 21:37 Adi Ml  wrote:

> Yes. Thats exactly what I mean (what mantas said)- ATTR{authorized}="0".
> I would like to have a usb whitelist via udev and want it to be enforced on
> devices which connected pre boot too.
>
> authorized_default=0- it seems the same like
> ATTR{authorized}="0", isnt it?
>

Not quite – I guess there is a very small window of time between connection
and udev processing where the device is still authorized, before udev
removes the authorization.

So having authorized_default=0,  and then setting all allowed devices to
authorized=1  (allow only approved devices, block the rest) is probably
slightly safer technically.

(Actually maybe you should just use USBGuard instead of writing custom
rules?)

This is what I used to have a long time ago:

ACTION!="add", GOTO="deauthorize_end"
SUBSYSTEM!="usb", GOTO="deauthorize_end"

TEST=="authorized_default", ATTR{authorized_default}="0",
GOTO="deauthorize_end"

ENV{ID_VENDOR}=="Yubico", ENV{ID_MODEL}=="Yubikey_NEO*",
ATTR{authorized}="1", GOTO="deauthorize_end"

ENV{ID_VENDOR}=="Zubico", ENV{ID_MODEL}=="Zubikey_GEO*",
ATTR{authorized}="1", GOTO="deauthorize_end"

LABEL="deauthorize_end"
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev rules on reboot

[Adi Ml]

Yes. Thats exactly what I mean (what mantas said)- ATTR{authorized}="0". I
would like to have a usb whitelist via udev and want it to be enforced on
devices which connected pre boot too.

authorized_default=0- it seems the same like
ATTR{authorized}="0", isnt it?

בתאריך יום א׳, 20 בדצמ׳ 2020, 15:59, מאת Mantas Mikulėnas ‏<
graw...@gmail.com>:

> On Sun, Dec 20, 2020 at 3:49 PM Lennart Poettering 
> wrote:
>
>> On Sa, 19.12.20 15:37, Adi Ml (maladi1...@gmail.com) wrote:
>>
>> > I see. so if I have a rule against a certain usb in udev, it should be
>> > blocked automatically during the boot.
>>
>> Hmm, "blocked"? What do you mean by that? I am not following...
>>
>
> I suspect they mean something like ATTR{authorized}="0", which tells the
> kernel to completely ignore that USB device.
>
> (Though it's more common to set authorized_default=0 on all hubs, then
> allow only trusted devices, like USBGuard does.)
>
> --
> Mantas Mikulėnas
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev rules on reboot

[Mantas Mikulėnas]

On Sun, Dec 20, 2020 at 3:49 PM Lennart Poettering 
wrote:

> On Sa, 19.12.20 15:37, Adi Ml (maladi1...@gmail.com) wrote:
>
> > I see. so if I have a rule against a certain usb in udev, it should be
> > blocked automatically during the boot.
>
> Hmm, "blocked"? What do you mean by that? I am not following...
>

I suspect they mean something like ATTR{authorized}="0", which tells the
kernel to completely ignore that USB device.

(Though it's more common to set authorized_default=0 on all hubs, then
allow only trusted devices, like USBGuard does.)

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev rules on reboot

[Lennart Poettering]

On Sa, 19.12.20 15:37, Adi Ml (maladi1...@gmail.com) wrote:

> I see. so if I have a rule against a certain usb in udev, it should be
> blocked automatically during the boot.

Hmm, "blocked"? What do you mean by that? I am not following...

>
> בתאריך שבת, 19 בדצמ׳ 2020, 15:31, מאת Lennart Poettering ‏<
> lenn...@poettering.net>:
>
> > On Sa, 19.12.20 15:26, Adi Ml (maladi1...@gmail.com) wrote:
> >
> > > Hi,
> > >
> > > Is there a way to enforce udev rules on all connected devices (which were
> > > connected pre-boot) after a reboot?
> > > I have tried udevadm trigger and seems like its not  working
> >
> > udevadm trigger is invoked atuomatically at boot, in order to
> > "coldplug" devices that have been found by the kernel already during
> > earlier boot. It's what the systemd-udev-trigger.service unit is
> > doing.
> >
> > Triggering means all udev rules are run again.
> >
> > Lennart
> >
> > --
> > Lennart Poettering, Berlin
> >

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev rules on reboot

[Adi Ml]

I see. so if I have a rule against a certain usb in udev, it should be
blocked automatically during the boot.

בתאריך שבת, 19 בדצמ׳ 2020, 15:31, מאת Lennart Poettering ‏<
lenn...@poettering.net>:

> On Sa, 19.12.20 15:26, Adi Ml (maladi1...@gmail.com) wrote:
>
> > Hi,
> >
> > Is there a way to enforce udev rules on all connected devices (which were
> > connected pre-boot) after a reboot?
> > I have tried udevadm trigger and seems like its not  working
>
> udevadm trigger is invoked atuomatically at boot, in order to
> "coldplug" devices that have been found by the kernel already during
> earlier boot. It's what the systemd-udev-trigger.service unit is
> doing.
>
> Triggering means all udev rules are run again.
>
> Lennart
>
> --
> Lennart Poettering, Berlin
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev rules on reboot

[Lennart Poettering]

On Sa, 19.12.20 15:26, Adi Ml (maladi1...@gmail.com) wrote:

> Hi,
>
> Is there a way to enforce udev rules on all connected devices (which were
> connected pre-boot) after a reboot?
> I have tried udevadm trigger and seems like its not  working

udevadm trigger is invoked atuomatically at boot, in order to
"coldplug" devices that have been found by the kernel already during
earlier boot. It's what the systemd-udev-trigger.service unit is
doing.

Triggering means all udev rules are run again.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Udev rules on reboot

[Adi Ml]

Hi,

Is there a way to enforce udev rules on all connected devices (which were
connected pre-boot) after a reboot?
I have tried udevadm trigger and seems like its not  working

Thank you
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev ATTR can have double dots and help writing a rule

[Lennart Poettering]

On Di, 01.12.20 02:17, Konomi (konomikit...@gmail.com) wrote:

> So this is the eventual rule I ended up writing after having a lot of
> trouble writing a udev rule:
>
> `ACTION=="add", SUBSYSTEM=="ata_port", KERNEL=="ata[0-9]",
> TEST=="../../power/control" ATTR{../../power/control}="auto"`
>
> Here is the rule working:
>
> ```
> Dec 01 01:33:16 arch systemd-udevd[267]: ata1:
> /etc/udev/rules.d/user-powertop-tunables.rules:5 ATTR
> '/sys/devices/pci:00/:00:13.0/ata1/ata_port/ata1/../../power/control'
> writing 'auto'
> Dec 01 01:33:16 arch systemd-udevd[258]: ata2:
> /etc/udev/rules.d/user-powertop-tunables.rules:5 ATTR
> '/sys/devices/pci:00/:00:13.0/ata2/ata_port/ata2/../../power/control'
> writing 'auto'
> ```
>
> Is this a good udev rule or even valid or is using `..` something that
> shouldn't be possible?

No, that's OK, we do that from time to time too. Of course, I'd avoid
it unless there's no better way to match the device. i.e. if you can
recognize a device by its own properties it's typically much better
than recognizing some subdevice further down and then making change
up-top again.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev hardening

[Lennart Poettering]

On Mo, 14.12.20 14:54, Adi Ml (maladi1...@gmail.com) 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?

We apply system call filters to all long running services included in
systemd by default — but we don't for udev because we cannot. It's
more of an "application server" if you so will, that can run other
code, as people can drop in rules of any kind if they wish. And we
don't know what that'll be and what it wants to use. Hence we don't.

In specific setups that only supports very specific software you can
of course put together your own rules, but that's only something you
can do, if you know the stuff you run.

You may use "SystemCallLog=" (added in v247) in the udev unit file to
make the kernel log all system calls that are done by a service.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev hardening

[Greg KH]

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 code - I have seen that they list a group
> of system calls and restrict the usage to them only.

That restriction is for the usbguard daemon, has nothing to do with what
a USB device can or can not do.

I recommend using that program for what you want to accomplish, as that
is exactly what it is designed to do.

good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev hardening

[Adi Ml]

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 code - I have seen that they list a group
of system calls and restrict the usage to them only.

Anyway, I understand, the system calls that udev use are mentioned in its
configuration files and are also the system calls used in scripts ran when
a rule is been trigerred (the rules writer have to specify the scripts in
the rules file of course) .



בתאריך יום ב׳, 14 בדצמ׳ 2020, 17:41, מאת Greg KH ‏<
gre...@linuxfoundation.org>:

> 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 vid/pids can be made to be whatever they want to be, be careful
> about triggering off of them to prevent specific things from happening,
> that way is tough.  It's easier to whitelist valid devices that you know
> are correct, and then only allow specific actions to happen on them.
>
> You might want to look into using https://usbguard.github.io/ for how to
> do this "properly".
>
> > I want to filter system calls anyway because I
> > dont know which devices are entered and I want to avoid devices which
> will
> > do unusual things like rubber ducky.
>
> devices do not make system calls directly, and if you plug a rubber
> ducky in that acts like a keyboard, that is not going to create things
> in udev's process context.
>
> > What do you mean by filtering system calls in   scripts- is it needed
> when
> > the user can influence actions commited in the script ?
>
> Look at the programs / scripts that udev calls out to in the udev
> configuration files for examples of these.  A user does not directly
> influence them, except if they are allowed to create/remove hardware.
>
> Hope this helps,
>
> greg k-h
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev hardening

[Greg KH]

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 vid/pids can be made to be whatever they want to be, be careful
about triggering off of them to prevent specific things from happening,
that way is tough.  It's easier to whitelist valid devices that you know
are correct, and then only allow specific actions to happen on them.

You might want to look into using https://usbguard.github.io/ for how to
do this "properly".

> I want to filter system calls anyway because I
> dont know which devices are entered and I want to avoid devices which will
> do unusual things like rubber ducky.

devices do not make system calls directly, and if you plug a rubber
ducky in that acts like a keyboard, that is not going to create things
in udev's process context.

> What do you mean by filtering system calls in   scripts- is it needed when
> the user can influence actions commited in the script ?

Look at the programs / scripts that udev calls out to in the udev
configuration files for examples of these.  A user does not directly
influence them, except if they are allowed to create/remove hardware.

Hope this helps,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev hardening

[Adi Ml]

I am using udev in order to create a kiosk mode. I want to block devices
which fit a certain vid pid. I want to filter system calls anyway because I
dont know which devices are entered and I want to avoid devices which will
do unusual things like rubber ducky.

What do you mean by filtering system calls in   scripts- is it needed when
the user can influence actions commited in the script ?

בתאריך יום ב׳, 14 בדצמ׳ 2020, 16:45, מאת Greg KH ‏<
gre...@linuxfoundation.org>:

> 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
> properly?
>
> > I do not use any script, I just echo 0 to the authorized file in the
> device
> > connected in order to disable it when it is not the wanted device (the
> > match is based on serial number, vid, pid)
>
> Udev calls loads of helper tools in order to generate persistent names.
> If you don't have any udev rules that call anything, then what do you
> need udev for?
>
> thanks,
>
> greg k-h
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev hardening

[Greg KH]

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
properly?

> I do not use any script, I just echo 0 to the authorized file in the device
> connected in order to disable it when it is not the wanted device (the
> match is based on serial number, vid, pid)

Udev calls loads of helper tools in order to generate persistent names.
If you don't have any udev rules that call anything, then what do you
need udev for?

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev hardening

[Adi Ml]

Hi,
Is there some way to detect which system calls, I am using in udev (in
order to filter it)?

I do not use any script, I just echo 0 to the authorized file in the device
connected in order to disable it when it is not the wanted device (the
match is based on serial number, vid, pid)

Thank you

בתאריך יום ב׳, 14 בדצמ׳ 2020, 15:40, מאת Greg KH ‏<
gre...@linuxfoundation.org>:

> 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 want udev to be able
> to call.  That's up to your and your specific hardware configuration.
>
> good luck!
>
> greg k-h
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev hardening

[Greg KH]

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 want udev to be able
to call.  That's up to your and your specific hardware configuration.

good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Udev hardening

[Adi Ml]

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?

Thank you!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] udev ATTR can have double dots and help writing a rule

[Konomi]

So this is the eventual rule I ended up writing after having a lot of
trouble writing a udev rule:

`ACTION=="add", SUBSYSTEM=="ata_port", KERNEL=="ata[0-9]",
TEST=="../../power/control" ATTR{../../power/control}="auto"`

Here is the rule working:

```
Dec 01 01:33:16 arch systemd-udevd[267]: ata1:
/etc/udev/rules.d/user-powertop-tunables.rules:5 ATTR
'/sys/devices/pci:00/:00:13.0/ata1/ata_port/ata1/../../power/control'
writing 'auto'
Dec 01 01:33:16 arch systemd-udevd[258]: ata2:
/etc/udev/rules.d/user-powertop-tunables.rules:5 ATTR
'/sys/devices/pci:00/:00:13.0/ata2/ata_port/ata2/../../power/control'
writing 'auto'
```

Is this a good udev rule or even valid or is using `..` something that
shouldn't be possible?

Before settling on the above rule I was using:

`ACTION=="add", DEVPATH=="/devices/pci:00/:00:13.0",
ATTR{ata1/power/control}="auto"`

Here was that rule working:

`Nov 30 18:26:02 arch systemd-udevd[264]: ata1:
/etc/udev/rules.d/user-powertop-tunables.rules:4 ATTR
'/sys/devices/pci:00/:00:13.0/ata1/ata_port/ata1/power/control'
writing 'auto'`

Obviously I'd need to add the `TEST` and then I run into the problem
that I have to write a rule for every single number.

So can anyone help me figure this all out?

Some udevadm info commands:

```
udevadm info -q all --path=/sys/bus/pci/devices/:00:13.0/ata1/ata_port/ata1
P: /devices/pci:00/:00:13.0/ata1/ata_port/ata1
L: 0
E: DEVPATH=/devices/pci:00/:00:13.0/ata1/ata_port/ata1
E: SUBSYSTEM=ata_port
```

```
$ udevadm info -a --path=/sys/bus/pci/devices/:00:13.0/ata1/ata_port/ata1

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/pci:00/:00:13.0/ata1/ata_port/ata1':
KERNEL=="ata1"
SUBSYSTEM=="ata_port"
DRIVER==""
ATTR{idle_irq}=="0"
ATTR{nr_pmp_links}=="0"
ATTR{port_no}=="1"
ATTR{power/async}=="disabled"
ATTR{power/control}=="auto"
ATTR{power/runtime_active_kids}=="0"
ATTR{power/runtime_active_time}=="0"
ATTR{power/runtime_enabled}=="disabled"
ATTR{power/runtime_status}=="unsupported"
ATTR{power/runtime_suspended_time}=="0"
ATTR{power/runtime_usage}=="0"

  looking at parent device '/devices/pci:00/:00:13.0/ata1':
KERNELS=="ata1"
SUBSYSTEMS==""
DRIVERS==""
ATTRS{power/async}=="enabled"
ATTRS{power/control}=="auto"
ATTRS{power/runtime_active_kids}=="1"
ATTRS{power/runtime_active_time}=="1713418"
ATTRS{power/runtime_enabled}=="enabled"
ATTRS{power/runtime_status}=="active"
ATTRS{power/runtime_suspended_time}=="0"
ATTRS{power/runtime_usage}=="0"

  looking at parent device '/devices/pci:00/:00:13.0':
KERNELS==":00:13.0"
SUBSYSTEMS=="pci"
DRIVERS=="ahci"
ATTRS{ari_enabled}=="0"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x010601"
ATTRS{consistent_dma_mask_bits}=="64"
ATTRS{d3cold_allowed}=="1"
ATTRS{device}=="0x22a3"
ATTRS{devspec}==""
ATTRS{dma_mask_bits}=="64"
ATTRS{driver_override}=="(null)"
ATTRS{enable}=="1"
ATTRS{irq}=="117"
ATTRS{local_cpulist}=="0-3"
ATTRS{local_cpus}=="f"
ATTRS{msi_bus}=="1"
ATTRS{msi_irqs/117}=="msi"
ATTRS{numa_node}=="-1"
ATTRS{power/async}=="enabled"
ATTRS{power/control}=="auto"
ATTRS{power/runtime_active_kids}=="1"
ATTRS{power/runtime_active_time}=="1716855"
ATTRS{power/runtime_enabled}=="enabled"
ATTRS{power/runtime_status}=="active"
ATTRS{power/runtime_suspended_time}=="0"
ATTRS{power/runtime_usage}=="1"
ATTRS{power/wakeup}=="disabled"
ATTRS{power/wakeup_abort_count}==""
ATTRS{power/wakeup_active}==""
ATTRS{power/wakeup_active_count}==""
ATTRS{power/wakeup_count}==""
ATTRS{power/wakeup_expire_count}==""
ATTRS{power/wakeup_last_time_ms}==""
ATTRS{power/wakeup_max_time_ms}==""
ATTRS{power/wakeup_prevent_sleep_time_ms}==""
ATTRS{power/wakeup_total_time_ms}==""
ATTRS{revision}=="0x35"
ATTRS{subsystem_device}=="0x074d"
ATTRS{subsystem_vendor}=="0x1028"
ATTRS{vendor}=="0x8086"

  looking at parent device '/devices/pci:00':
KERNELS=="pci:00"
SUBSYSTEMS==""
DRIVERS==""
ATTRS{power/async}=="enabled"
ATTRS{power/control}=="auto"
ATTRS{power/runtime_active_kids}=="7"
ATTRS{power/runtime_active_time}=="0"
ATTRS{power/runtime_enabled}=="disabled"
ATTRS{power/runtime_status}=="unsupported"
ATTRS{power/runtime_suspended_time}=="0"
ATTRS{power/runtime_usage}=="0"
```

```
$ udevadm info -q all --path=/sys/bus/pci/devices/:00:13.0/ata1
P: /devices/pci:00/:00:13.0/ata1
```

```
$ udevadm info -a --path=/sys/bus/pci/devices/:00:13.0/ata1

Re: [systemd-devel] [udev] Scanner rule not applied during boot

[Marcin Kocur]

W dniu 21.10.2020 o 08:52, Lennart Poettering pisze:

On Di, 20.10.20 23:16, Marcin Kocur (marcin2...@gmail.com) wrote:


Lennart,

I'm using outdated lxdm with Xfce.

I just disabled lxmd, copied fresh /etc/X11/xinit/xinitrc to ~/.xinitrc
(adding my environment exec command there) and started my environment from
startx: ACLs didn't change.


~/.xinitrc runs:
/etc/X11/xinit/xinitrc.d/50-systemd-user.sh
#!/bin/sh

systemctl --user import-environment DISPLAY XAUTHORITY

if command -v dbus-update-activation-environment >/dev/null 2>&1; then
     dbus-update-activation-environment DISPLAY XAUTHORITY

fi


Those variables are:
[mk@linux ~]$ echo $DISPLAY
:0.0
[mk@linux ~]$ echo $XAUTHORITY

/home/mk/.Xauthority

I also tried out SDDM login manager: ACLs weren't applied.

Maybe pam_systemd is missing from your PAM stacks? This smells like a
distro integration thing to me, might make sense to inquire your
distro maintainers about this.

Consider logging in, and using "loginctl" to check if your session is
properly recognized and tracked.


Hmm for me it looks perfectly fine:

[mk@linux ~]$ loginctl session-status
1 - mk (1000)
   Since: Wed 2020-10-21 19:53:10 CEST; 3h 30min ago
  Leader: 533 (lxdm-session)
    Seat: seat0; vc1
 TTY: tty1
 Service: lxdm; type x11; class user
   State: active
    Unit: session-1.scope
  ├─  533 /usr/lib/lxdm/lxdm-session
  ├─  542 xfce4-session
  ├─  628 /usr/bin/ssh-agent -s
  ├─  633 xfwm4
  ├─  655 xfsettingsd
  ├─  656 xfce4-panel
  ├─  668 Thunar --daemon
  ├─  673 xfdesktop

[mk@linux ~]$ echo $XDG_SESSION_ID
1

[mk@linux ~]$journalctl -xe |grep systemd-logind

[...]

Oct 21 19:53:10 linux systemd-logind[450]: New session 1 of user mk

[mk@linux ~]$ echo $XDG_SESSION_ID
1
[mk@linux ~]$ echo $XDG_SESSION_TYPE
x11
[mk@linux ~]$ echo  $XDG_SESSION_CLASS
user
[mk@linux ~]$ echo  $XDG_SESSION_DESKTOP

[mk@linux ~]$ echo  $XDG_SEAT
seat0
[mk@linux ~]$ echo  $XDG_VTNR
1

[mk@linux ~]$ cat '/etc/pam.d/system-login'
#%PAM-1.0

auth   required   pam_shells.so
auth   requisite  pam_nologin.so
auth   include    system-auth

account    required   pam_access.so
account    required   pam_nologin.so
account    include    system-auth

password   include    system-auth

session    optional   pam_loginuid.so
session    optional   pam_keyinit.so   force revoke
session    include    system-auth
session    optional   pam_motd.so  motd=/etc/motd
session    optional   pam_mail.so  dir=/var/spool/mail standard 
quiet

-session   optional   pam_systemd.so
session    required   pam_env.so   user_readenv=


I can surely report to Arch bugtracker, but I can't find what to report. 
Everything seems to be fine, except it's not working ;) I need something 
to go on...


--
Pozdrawiam / Greetings
Marcin Kocur █

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [udev] Scanner rule not applied during boot

[Lennart Poettering]

On Di, 20.10.20 23:16, Marcin Kocur (marcin2...@gmail.com) wrote:

> Lennart,
>
> I'm using outdated lxdm with Xfce.
>
> I just disabled lxmd, copied fresh /etc/X11/xinit/xinitrc to ~/.xinitrc
> (adding my environment exec command there) and started my environment from
> startx: ACLs didn't change.
>
>
> ~/.xinitrc runs:
> /etc/X11/xinit/xinitrc.d/50-systemd-user.sh
> #!/bin/sh
>
> systemctl --user import-environment DISPLAY XAUTHORITY
>
> if command -v dbus-update-activation-environment >/dev/null 2>&1; then
>     dbus-update-activation-environment DISPLAY XAUTHORITY
>
> fi
>
>
> Those variables are:
> [mk@linux ~]$ echo $DISPLAY
> :0.0
> [mk@linux ~]$ echo $XAUTHORITY
>
> /home/mk/.Xauthority
>
> I also tried out SDDM login manager: ACLs weren't applied.

Maybe pam_systemd is missing from your PAM stacks? This smells like a
distro integration thing to me, might make sense to inquire your
distro maintainers about this.

Consider logging in, and using "loginctl" to check if your session is
properly recognized and tracked.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [udev] Scanner rule not applied during boot

[Marcin Kocur]

W dniu 20.10.2020 o 20:05, Lennart Poettering pisze:

On Di, 20.10.20 18:47, Marcin Kocur (marcin2...@gmail.com) wrote:


I don't how how this uaccess tag works, but I can assume that my scanner
which is libsane_matched (as set by
/usr/lib/udev/rules.d/49-sane.rules) gets ACL permission added somewhere
later thanks to this uaccess tag.

The question is if it works on manual trigger, why doesn't on boot time?

Devices that are marked with "uaccess" get an ACL installed that
always points to the user who owns the foreground session. This should
be applied whenever you log in or switch foreground session.

If this doesn't work at login time there must be something borked with
your display manager, or possibly systemd-logind.

Which systemd version is this? Which distro? Which display manager?

Lennart

--
Lennart Poettering, Berlin



Lennart,

I'm using outdated lxdm with Xfce.

I just disabled lxmd, copied fresh /etc/X11/xinit/xinitrc to ~/.xinitrc 
(adding my environment exec command there) and started my environment 
from startx: ACLs didn't change.



~/.xinitrc runs:
/etc/X11/xinit/xinitrc.d/50-systemd-user.sh
#!/bin/sh

systemctl --user import-environment DISPLAY XAUTHORITY

if command -v dbus-update-activation-environment >/dev/null 2>&1; then
    dbus-update-activation-environment DISPLAY XAUTHORITY

fi


Those variables are:
[mk@linux ~]$ echo $DISPLAY
:0.0
[mk@linux ~]$ echo $XAUTHORITY

/home/mk/.Xauthority

I also tried out SDDM login manager: ACLs weren't applied.

My software is:
systemd: 246.6-1
linux: 5.8.14.arch1-1
sane: 1.0.31-1
libusb: 1.0.23-2
distro: Archlinux

--
Pozdrawiam / Greetings
Marcin Kocur █

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [udev] Scanner rule not applied during boot

[Lennart Poettering]

On Di, 20.10.20 18:47, Marcin Kocur (marcin2...@gmail.com) wrote:

> I don't how how this uaccess tag works, but I can assume that my scanner
> which is libsane_matched (as set by
> /usr/lib/udev/rules.d/49-sane.rules) gets ACL permission added somewhere
> later thanks to this uaccess tag.
>
> The question is if it works on manual trigger, why doesn't on boot time?

Devices that are marked with "uaccess" get an ACL installed that
always points to the user who owns the foreground session. This should
be applied whenever you log in or switch foreground session.

If this doesn't work at login time there must be something borked with
your display manager, or possibly systemd-logind.

Which systemd version is this? Which distro? Which display manager?

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [udev] Scanner rule not applied during boot

[Marcin Kocur]

W dniu 20.10.2020 o 13:44, Lennart Poettering pisze:

On Mo, 19.10.20 21:19, Marcin Kocur (marcin2...@gmail.com) wrote:


Hello systemd devs and users,

I need an advice regarding USB scanner which rule is not(?) processed at
boot time. When I trigger it manually, the scanner device file gets proper
permissions.

Here's the rule:

cat /usr/lib/udev/rules.d/49-sane.rules |grep -A1 '1200 TA'
# Mustek BearPaw 1200 CS | Mustek BearPaw 1200 TA
ATTRS{idVendor}=="055f", ATTRS{idProduct}=="021e", MODE="0664",
GROUP="scanner", ENV{libsane_matched}="yes"

Here it is how it looks like directly after the boot:

lsusb
Bus 001 Device 003: ID 055f:021e Mustek Systems, Inc. BearPaw 1200 TA/CS


getfacl /dev/bus/usb/001/003
# file: dev/bus/usb/001/007
# owner: root
# group: scanner
user::rw-
group::rw-
other::r--

And this is how it looks after triggering manually:
udevadm trigger -c add /dev/bus/usb/001/003:

getfacl /dev/bus/usb/001/003
# file: dev/bus/usb/001/007
# owner: root
# group: scanner
user::rw-
user:mk:rw-    NOW MY USER IS HERE

And?

It's still owned by the "scanner" group like before, which the line
three up shows you.

The extra ACL entry probably comes from some "uaccess" rule somebody
sets on the device. But I don#t now what rules you added or what sane
sets there precisely.

Lennart

--
Lennart Poettering, Berlin


Hi Lennart, thanks for your answer.

You're probably right, this rule sets different permissions than what is 
set on the device. So it must be some other rule.


I found via

udevadm test /dev/bus/usb/001/003

that there is a file /usr/lib/udev/rules.d/70-uaccess.rules which says:

# SCSI and USB scanners

ENV{libsane_matched}=="yes", TAG+="uaccess"

I don't how how this uaccess tag works, but I can assume that my scanner 
which is libsane_matched (as set by
/usr/lib/udev/rules.d/49-sane.rules) gets ACL permission added somewhere 
later thanks to this uaccess tag.


The question is if it works on manual trigger, why doesn't on boot time?

--
Pozdrawiam / Greetings
Marcin Kocur █

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [udev] Scanner rule not applied during boot

[Lennart Poettering]

On Mo, 19.10.20 21:19, Marcin Kocur (marcin2...@gmail.com) wrote:

>
> Hello systemd devs and users,
>
> I need an advice regarding USB scanner which rule is not(?) processed at
> boot time. When I trigger it manually, the scanner device file gets proper
> permissions.
>
> Here's the rule:
>
> cat /usr/lib/udev/rules.d/49-sane.rules |grep -A1 '1200 TA'
> # Mustek BearPaw 1200 CS | Mustek BearPaw 1200 TA
> ATTRS{idVendor}=="055f", ATTRS{idProduct}=="021e", MODE="0664",
> GROUP="scanner", ENV{libsane_matched}="yes"
>
> Here it is how it looks like directly after the boot:
>
> lsusb
> Bus 001 Device 003: ID 055f:021e Mustek Systems, Inc. BearPaw 1200 TA/CS
>
>
> getfacl /dev/bus/usb/001/003
> # file: dev/bus/usb/001/007
> # owner: root
> # group: scanner
> user::rw-
> group::rw-
> other::r--
>
> And this is how it looks after triggering manually:
> udevadm trigger -c add /dev/bus/usb/001/003:
>
> getfacl /dev/bus/usb/001/003
> # file: dev/bus/usb/001/007
> # owner: root
> # group: scanner
> user::rw-
> user:mk:rw-    NOW MY USER IS HERE

And?

It's still owned by the "scanner" group like before, which the line
three up shows you.

The extra ACL entry probably comes from some "uaccess" rule somebody
sets on the device. But I don#t now what rules you added or what sane
sets there precisely.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [udev] Scanner rule not applied during boot

[Marcin Kocur]

Hello systemd devs and users,

I need an advice regarding USB scanner which rule is not(?) processed at 
boot time. When I trigger it manually, the scanner device file gets 
proper permissions.


Here's the rule:

cat /usr/lib/udev/rules.d/49-sane.rules |grep -A1 '1200 TA'
# Mustek BearPaw 1200 CS | Mustek BearPaw 1200 TA
ATTRS{idVendor}=="055f", ATTRS{idProduct}=="021e", MODE="0664", 
GROUP="scanner", ENV{libsane_matched}="yes"


Here it is how it looks like directly after the boot:

lsusb
Bus 001 Device 003: ID 055f:021e Mustek Systems, Inc. BearPaw 1200 TA/CS


getfacl /dev/bus/usb/001/003
# file: dev/bus/usb/001/007
# owner: root
# group: scanner
user::rw-
group::rw-
other::r--

And this is how it looks after triggering manually:
udevadm trigger -c add /dev/bus/usb/001/003:

getfacl /dev/bus/usb/001/003
# file: dev/bus/usb/001/007
# owner: root
# group: scanner
user::rw-
user:mk:rw-    NOW MY USER IS HERE
group::rw-
mask::rw-
other::r--

Of course this is the effect I expect to happen directly after boot. It 
changed most likely after I upgraded my PC hardware. I tried to 
downgrade systemd, kernel and sane without any positive effect. This was 
working for me this way for past 12 years ;)


I enabled udev debug level and browsed whole journalctl but haven't 
found there anything about my device (except the fact that it's detected 
by kernel):

journalctl -b |grep '021e'

Oct 19 20:06:26 linux kernel: usb 1-6: New USB device found, 
idVendor=055f, idProduct=021e, bcdDevice= 1.00


I'm attaching the zipped log from systemd-udev.service.


My hardware:
Archlinux
systemd: 246.6-1
linux: 5.8.14.arch1-1
sane: 1.0.31-1
libusb: 1.0.23-2
Motherboard: Gibabyte B550M AORUS PRO (rev. 1.0)
Scanner: Mustek BearPaw 1200 TA
CPU: AMD Ryzen 3 PRO 4350G with Radeon Graphics

Many thanks for every tip I get to resolve this problem!

--
Pozdrawiam / Greetings
Marcin Kocur █



<>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev and probing of eMMC partition devices

[Lennart Poettering]

On Mi, 30.09.20 13:57, Alan Perry (al...@snowmoose.com) wrote:

>
>
> On 9/23/20 9:29 AM, Lennart Poettering wrote:
> > On Di, 22.09.20 10:06, Alan Perry (al...@snowmoose.com) wrote:
> >
> > > > > device add events will get stuck at the probe step.
> > > > "Get stuck"? What does that mean? What is it actually doing? What does
> > > > a stack trace say? Anything in the logs?
> > > When this happens, the last thing seen in the log for those devices is the
> > > probe ("probe /dev/mmcblk0 raid offset=0").
> > This debug log message is generated by udev-builtin-blkid.c, right
> > after opening the block device, and right before issuing the probe,
> > i.e. reading the fs label/partition table signatures off disk. If
> > things hang there, and the blkid prober worker process freezes then
> > this really looks like a hw/driver problem, i.e. IO access from the
> > block device just hangs.
> >
>
> It does seem to be a hw/driver problem. From what I have seen searching the
> web, this seems to be something that sometimes happens with eMMC devices.
>
> In our experience, the problem resolves itself and subsequent reads and
> probes succeed. However, the systemd job is still around, hung, and stopping
> boot from completing. I think that changing udev-builtin-blkid to be able to
> timeout and end the job gracefully when this happens is the right thing to
> do here. But what is a suitable timeout and what does a graceful exit here
> look like?

udev kills workers after a while. You can configure that with
event_timeout= in udev.conf. Defaults to 2min.

But note that disk IO sleeps in the kernel usually are
non-interruptible, i.e. you cannot kill processes hanging in
them. Hence, YMMV.

Driver bugs are kernel bugs. Fix them in the kernel, working around
them in userspace is ultimately never going to make anyone happy.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev and probing of eMMC partition devices

[Alan Perry]

On 9/23/20 9:29 AM, Lennart Poettering wrote:

On Di, 22.09.20 10:06, Alan Perry (al...@snowmoose.com) wrote:


device add events will get stuck at the probe step.

"Get stuck"? What does that mean? What is it actually doing? What does
a stack trace say? Anything in the logs?

When this happens, the last thing seen in the log for those devices is the
probe ("probe /dev/mmcblk0 raid offset=0").

This debug log message is generated by udev-builtin-blkid.c, right
after opening the block device, and right before issuing the probe,
i.e. reading the fs label/partition table signatures off disk. If
things hang there, and the blkid prober worker process freezes then
this really looks like a hw/driver problem, i.e. IO access from the
block device just hangs.



It does seem to be a hw/driver problem. From what I have seen searching 
the web, this seems to be something that sometimes happens with eMMC 
devices.


In our experience, the problem resolves itself and subsequent reads and 
probes succeed. However, the systemd job is still around, hung, and 
stopping boot from completing. I think that changing udev-builtin-blkid 
to be able to timeout and end the job gracefully when this happens is 
the right thing to do here. But what is a suitable timeout and what does 
a graceful exit here look like?


alan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev and probing of eMMC partition devices

[Lennart Poettering]

On Di, 22.09.20 10:06, Alan Perry (al...@snowmoose.com) wrote:

> > > device add events will get stuck at the probe step.
> > "Get stuck"? What does that mean? What is it actually doing? What does
> > a stack trace say? Anything in the logs?
>
> When this happens, the last thing seen in the log for those devices is the
> probe ("probe /dev/mmcblk0 raid offset=0").

This debug log message is generated by udev-builtin-blkid.c, right
after opening the block device, and right before issuing the probe,
i.e. reading the fs label/partition table signatures off disk. If
things hang there, and the blkid prober worker process freezes then
this really looks like a hw/driver problem, i.e. IO access from the
block device just hangs.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev and probing of eMMC partition devices

[Alan Perry]

On 9/22/20 7:44 AM, Lennart Poettering wrote:

On Mo, 21.09.20 19:03, Alan Perry (al...@snowmoose.com) wrote:


Hi,

I am trying to understand behavior that I am seeing with udev and eMMC
partition devices and was hoping that someone here could help.

The system that I am running has an eMMC device with something like 7-8
partitions. The kernel does add block events for the device and each of it
partitions and the logs show them being queued up by udevd. Then things get
interesting. Sometimes processing of the add event for the device itself
gets to a probe step and, in the time frame of the logs that I have, never
gets further in that processing and the add block device events for the
partitions are never processed. However, usually, it will process the add
block device event for the entire device and after that (as per the
implementation of is_devpath_busy()) start processing the add block events
for the partition devices. Often times, the processing of the partition
device add events will get stuck at the probe step.

"Get stuck"? What does that mean? What is it actually doing? What does
a stack trace say? Anything in the logs?


When this happens, the last thing seen in the log for those devices is 
the probe ("probe /dev/mmcblk0 raid offset=0").


I have been given a bunch of logs and have yet to be able to reproduce 
the problem myself. I got additional hints for reproducing the problem 
last night and am putting together a systemd with additional diagnostic 
output in the code that does the probe.



The partition devices
stuck at the probe are then "waiting" and the services that depend on them
blocked.

Can anyone here give me some insight into what is going on, in particular,
how there is such difference in behavior between test runs on the same
system?

Have you checked the logs?
Yes. I have been trying to debug the problem by log output and code 
analysis.


I had initially thought that the problem was somewhere else, but now the 
logs are pointing me towards the probe.


Please always start with saying which systemd version this is, and
which distro, otherwise it's very hard to grok what your setup is
like?


Good point. Sorry. I think it is v239 systemd plus a lot of patches. The 
distro is an internal Microsoft one based on the 5.4 kernel.




Maybe the eMMC driver has issues and simply hangs? dmesg might show
something in that case.


Thanks. I don't have dmesg output associated with most of the logs. But 
I will be sure to look there once I am able to reproduce it myself.


alan



Lennart

--
Lennart Poettering, Berlin


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev and probing of eMMC partition devices

[Lennart Poettering]

On Mo, 21.09.20 19:03, Alan Perry (al...@snowmoose.com) wrote:

>
> Hi,
>
> I am trying to understand behavior that I am seeing with udev and eMMC
> partition devices and was hoping that someone here could help.
>
> The system that I am running has an eMMC device with something like 7-8
> partitions. The kernel does add block events for the device and each of it
> partitions and the logs show them being queued up by udevd. Then things get
> interesting. Sometimes processing of the add event for the device itself
> gets to a probe step and, in the time frame of the logs that I have, never
> gets further in that processing and the add block device events for the
> partitions are never processed. However, usually, it will process the add
> block device event for the entire device and after that (as per the
> implementation of is_devpath_busy()) start processing the add block events
> for the partition devices. Often times, the processing of the partition
> device add events will get stuck at the probe step.

"Get stuck"? What does that mean? What is it actually doing? What does
a stack trace say? Anything in the logs?

> The partition devices
> stuck at the probe are then "waiting" and the services that depend on them
> blocked.
>
> Can anyone here give me some insight into what is going on, in particular,
> how there is such difference in behavior between test runs on the same
> system?

Have you checked the logs?

Please always start with saying which systemd version this is, and
which distro, otherwise it's very hard to grok what your setup is
like?

Maybe the eMMC driver has issues and simply hangs? dmesg might show
something in that case.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] udev and probing of eMMC partition devices

[Alan Perry]

Hi,

I am trying to understand behavior that I am seeing with udev and eMMC 
partition devices and was hoping that someone here could help.


The system that I am running has an eMMC device with something like 7-8 
partitions. The kernel does add block events for the device and each of 
it partitions and the logs show them being queued up by udevd. Then 
things get interesting. Sometimes processing of the add event for the 
device itself gets to a probe step and, in the time frame of the logs 
that I have, never gets further in that processing and the add block 
device events for the partitions are never processed. However, usually, 
it will process the add block device event for the entire device and 
after that (as per the implementation of is_devpath_busy()) start 
processing the add block events for the partition devices. Often times, 
the processing of the partition device add events will get stuck at the 
probe step. The partition devices stuck at the probe are then "waiting" 
and the services that depend on them blocked.


Can anyone here give me some insight into what is going on, in 
particular, how there is such difference in behavior between test runs 
on the same system?


Thanks,

alan perry
Microsoft

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev Regex

[Lennart Poettering]

On Mi, 06.05.20 12:15, Boyce, Kevin P [US] (AS) (kevin.bo...@ngc.com) wrote:

> Good Morning List,
>
> Does anyone know how complicated of a regular expression can be
> utilized in a udev rule?

udev supports shell-style globbing for matching, but no regular
expressions. The man page says that pretty clearly, no?

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev Regex

[Andrei Borzenkov]

On Wed, May 6, 2020 at 3:23 PM Boyce, Kevin P [US] (AS)
 wrote:
>
> Good Morning List,
>
>
>
> Does anyone know how complicated of a regular expression can be utilized in a 
> udev rule?
>

I would ask udev manual page :)

>
>
> For instance I have a system with a lot of drives (sda through z aren’t 
> enough) and I want to write a rule that will match the physical block devices 
> for one rule and then a separate rule for partitions.
>
>
>
> Something like this, however the rules don’t seem to fire except when I 
> remove the ‘+’ from the rules:
>
> ACTION==”add”, SUBSYSTEM==”block”, KERNEL==”sd[a-z]+”, 
> SYMLINK+=”some_device_%k”
>
> ACTION==”add”, SUBSYSTEM==”block”, KERNEL==”sd[a-z]+[0-9]+”, 
> SYMLINK+=”some_device_%k”
>
>
>
> I am running systemd version 219-67.
>
>
>
> Kind Regards,
>
> Kevin
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Udev Regex

[Boyce, Kevin P [US] (AS)]

Good Morning List,

Does anyone know how complicated of a regular expression can be utilized in a 
udev rule?

For instance I have a system with a lot of drives (sda through z aren't enough) 
and I want to write a rule that will match the physical block devices for one 
rule and then a separate rule for partitions.

Something like this, however the rules don't seem to fire except when I remove 
the '+' from the rules:
ACTION=="add", SUBSYSTEM=="block", KERNEL=="sd[a-z]+", SYMLINK+="some_device_%k"
ACTION=="add", SUBSYSTEM=="block", KERNEL=="sd[a-z]+[0-9]+", 
SYMLINK+="some_device_%k"

I am running systemd version 219-67.

Kind Regards,
Kevin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] UDEV popen/system returns error if called from the program (RUN option)

[Ilya Matveychikov]

> On Mar 3, 2020, at 3:43 PM, Josef Moellers  wrote:
> 
> On 03.03.20 12:26, Ilya Matveychikov wrote:
>> Dear Lennart,
>> 
>> Thank you for the reply.
>> 
>>> On Mar 3, 2020, at 12:54 PM, Lennart Poettering  
>>> wrote:
>>> 
>>> On Mo, 02.03.20 00:35, Ilya Matveychikov (matvejchi...@gmail.com) wrote:
>>> 
 Hey guys,
 
 I’m not sure is it the right place to ask about the UDEV or not.
 
 Anyways, I have a problem with running custom program from the UDEV rule 
 (RUN+= option).
 The problem is somehow related to fork/exec, I can’t tell for sure.
 
 My code (this custom “RUN+=“-binary) using popen() to call external program
 and get the result using stream. Once I run this custom program alone it 
 works
 perfectly well. But once it is executed under the systemd/udev via the rule
 this popen() returns error with the code ENOMEM which is very strange for 
 me
 as the system has like 32Gb of RAM.
 
 The same happen with system() ...
 
 Do you guys have any glue of what the heck is going on?
 Are there any constraints on what can be done in “programs”?
>>> 
>>> We enforce a limit on the number of processes/threads forked off
>>> services, and udevd has a limt set like that too, via the TasksMax=
>>> setting in its unit file. Maybe you are leaking processes/threads
>>> somehow and hit that limit?
>> 
>> I don’t do any multithreading in my program, except some popen()’s ..
>> 
>> My system (archlinux) has "TasksMax=infinity” line in file:
>> /usr/lib/systemd/system/sysinit.target.wants/systemd-udev.service
>> 
>> Any other tips?
> Just a shot in the dark: do you pclose() all popen()s?

I hope I do pclose() all of them. Anyway, the same behavior I’m getting
with trying to do system(“ls -al / >/xxx”) before any popen(), just in
the beginning of the program. It fails! 

> 
> Josef
> -- 
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5
> 90409 Nürnberg
> Germany
> 
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] UDEV popen/system returns error if called from the program (RUN option)

[Josef Moellers]

On 03.03.20 12:26, Ilya Matveychikov wrote:
> Dear Lennart,
> 
> Thank you for the reply.
> 
>> On Mar 3, 2020, at 12:54 PM, Lennart Poettering  
>> wrote:
>>
>> On Mo, 02.03.20 00:35, Ilya Matveychikov (matvejchi...@gmail.com) wrote:
>>
>>> Hey guys,
>>>
>>> I’m not sure is it the right place to ask about the UDEV or not.
>>>
>>> Anyways, I have a problem with running custom program from the UDEV rule 
>>> (RUN+= option).
>>> The problem is somehow related to fork/exec, I can’t tell for sure.
>>>
>>> My code (this custom “RUN+=“-binary) using popen() to call external program
>>> and get the result using stream. Once I run this custom program alone it 
>>> works
>>> perfectly well. But once it is executed under the systemd/udev via the rule
>>> this popen() returns error with the code ENOMEM which is very strange for me
>>> as the system has like 32Gb of RAM.
>>>
>>> The same happen with system() ...
>>>
>>> Do you guys have any glue of what the heck is going on?
>>> Are there any constraints on what can be done in “programs”?
>>
>> We enforce a limit on the number of processes/threads forked off
>> services, and udevd has a limt set like that too, via the TasksMax=
>> setting in its unit file. Maybe you are leaking processes/threads
>> somehow and hit that limit?
> 
> I don’t do any multithreading in my program, except some popen()’s ..
> 
> My system (archlinux) has "TasksMax=infinity” line in file:
> /usr/lib/systemd/system/sysinit.target.wants/systemd-udev.service
> 
> Any other tips?
Just a shot in the dark: do you pclose() all popen()s?

Josef
-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nürnberg
Germany

(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] UDEV popen/system returns error if called from the program (RUN option)

[Ilya Matveychikov]

Dear Lennart,

Thank you for the reply.

> On Mar 3, 2020, at 12:54 PM, Lennart Poettering  
> wrote:
> 
> On Mo, 02.03.20 00:35, Ilya Matveychikov (matvejchi...@gmail.com) wrote:
> 
>> Hey guys,
>> 
>> I’m not sure is it the right place to ask about the UDEV or not.
>> 
>> Anyways, I have a problem with running custom program from the UDEV rule 
>> (RUN+= option).
>> The problem is somehow related to fork/exec, I can’t tell for sure.
>> 
>> My code (this custom “RUN+=“-binary) using popen() to call external program
>> and get the result using stream. Once I run this custom program alone it 
>> works
>> perfectly well. But once it is executed under the systemd/udev via the rule
>> this popen() returns error with the code ENOMEM which is very strange for me
>> as the system has like 32Gb of RAM.
>> 
>> The same happen with system() ...
>> 
>> Do you guys have any glue of what the heck is going on?
>> Are there any constraints on what can be done in “programs”?
> 
> We enforce a limit on the number of processes/threads forked off
> services, and udevd has a limt set like that too, via the TasksMax=
> setting in its unit file. Maybe you are leaking processes/threads
> somehow and hit that limit?

I don’t do any multithreading in my program, except some popen()’s ..

My system (archlinux) has "TasksMax=infinity” line in file:
/usr/lib/systemd/system/sysinit.target.wants/systemd-udev.service

Any other tips?


> 
> Lennart
> 
> --
> Lennart Poettering, Berlin

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] UDEV popen/system returns error if called from the program (RUN option)

[Lennart Poettering]

On Mo, 02.03.20 00:35, Ilya Matveychikov (matvejchi...@gmail.com) wrote:

> Hey guys,
>
> I’m not sure is it the right place to ask about the UDEV or not.
>
> Anyways, I have a problem with running custom program from the UDEV rule 
> (RUN+= option).
> The problem is somehow related to fork/exec, I can’t tell for sure.
>
> My code (this custom “RUN+=“-binary) using popen() to call external program
> and get the result using stream. Once I run this custom program alone it works
> perfectly well. But once it is executed under the systemd/udev via the rule
> this popen() returns error with the code ENOMEM which is very strange for me
> as the system has like 32Gb of RAM.
>
> The same happen with system() ...
>
> Do you guys have any glue of what the heck is going on?
> Are there any constraints on what can be done in “programs”?

We enforce a limit on the number of processes/threads forked off
services, and udevd has a limt set like that too, via the TasksMax=
setting in its unit file. Maybe you are leaking processes/threads
somehow and hit that limit?

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] UDEV popen/system returns error if called from the program (RUN option)

[Ilya Matveychikov]

Hey guys,

I’m not sure is it the right place to ask about the UDEV or not.

Anyways, I have a problem with running custom program from the UDEV rule (RUN+= 
option).
The problem is somehow related to fork/exec, I can’t tell for sure.

My code (this custom “RUN+=“-binary) using popen() to call external program
and get the result using stream. Once I run this custom program alone it works
perfectly well. But once it is executed under the systemd/udev via the rule
this popen() returns error with the code ENOMEM which is very strange for me
as the system has like 32Gb of RAM.

The same happen with system() ...

Do you guys have any glue of what the heck is going on?
Are there any constraints on what can be done in “programs”?

Ilya.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev can fail to read stdout of processes spwaned in udev_event_spawn

[Paul Davey]

On Fri, 2019-11-01 at 10:13 +0100, Michal Sekletar wrote:
> On Fri, Nov 1, 2019 at 1:49 AM Paul Davey
>  wrote:
> 
> > 
> > What is the best way to fix this issue?  I have locally had success
> > just calling the on_spawn_io callback in the process success branch
> > of
> > on_spawn_sigchld, but I am unsure if this is an acceptable fix.
> In the callback, we call read() only once and I don't think we have
> any guarantee that kernel will give us the entire output of the child
> process in one go. I figure we should drain the file descriptor in a
> loop.

I shall add a function to drain the file descriptors and call it in the
sigchld callback.  How should I submit a patch?

Thanks,
Paul
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev can fail to read stdout of processes spwaned in udev_event_spawn

[Michal Sekletar]

On Fri, Nov 1, 2019 at 1:49 AM Paul Davey
 wrote:

> What is the best way to fix this issue?  I have locally had success
> just calling the on_spawn_io callback in the process success branch of
> on_spawn_sigchld, but I am unsure if this is an acceptable fix.

In the callback, we call read() only once and I don't think we have
any guarantee that kernel will give us the entire output of the child
process in one go. I figure we should drain the file descriptor in a
loop.

Michal

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] udev can fail to read stdout of processes spwaned in udev_event_spawn

[Paul Davey]

Hi,

In tracking down an issue we are having with usb-modeswitch I found
that the root cause is an issue in udev where when the rule sets
a PROGRAM= and uses the result it will sometimes receive an empty
result even when the program did produce output.

This appears to be because the on_spawn_sigchld handler used
by spawn_wait is not checking if there is output in the stdout pipe
when the program exits and thus there is a race between this event and
the io event to read the output.

What is the best way to fix this issue?  I have locally had success
just calling the on_spawn_io callback in the process success branch of
on_spawn_sigchld, but I am unsure if this is an acceptable fix.

Thanks,
Paul
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] udev rule with SYSTEMD_WANTS not working if included in initramfs

[Marcin Szewczyk]

Hi,

I have a problem with a udev rule which should start a service if a
device (ttyS0) is detected. It uses the SYSTEMD_WANTS env.

When the rule is present in /etc/udev/rules.d/ but not in the initramfs
-- the service is properly activated.

When the rule is present in both /etc/udev/rules.d/ and the initramfs --
the service is not activated (loaded inactive dead). In this case
systemd's log says[1]:

systemd[1]: sys-devices-pnp0-00:03-tty-ttyS0.device: 
sys-devices-pnp0-00:03-tty-ttyS0.device lost dependency Wants=foobar.service
systemd[1]: foobar.service: foobar.service lost dependency 
WantedBy=sys-devices-pnp0-00:03-tty-ttyS0.device
systemd[1]: foobar.service: foobar.service lost dependency 
ReferencedBy=sys-devices-pnp0-00:03-tty-ttyS0.device
systemd[1]: sys-devices-pnp0-00:03-tty-ttyS0.device: 
sys-devices-pnp0-00:03-tty-ttyS0.device lost dependency 
References=foobar.service

The rule worked for me with systemd v232 on an older Debian. Now with
Debian Buster and systemd v241 it doesn't. I think it may be associated
with a change introduced by a commit[2] described as:

core: remove SYSTEMD_WANTS udev property configured dependencies at the 
right moment

…and more generally with PR #7186 [3].

What does "the right moment" mean? Do I violate some implicit assumption
by adding the udev rule to initramfs? BTW, it happens automatically
because initramfs-tools copy all files from /etc/udev/rules.d/ to
initramfs. Having the rule at such an early stage was not my objective.
Should I move the rules file to some other location so it's not copied
to initramfs? Should I add some other criterion to disable the rule
during initramfs and allow it to execute during a later booting phase?

Nevertheless, I am most interested in understanding why it does not
work. Maybe the failure just correlates with the rule's presence in the
initramfs but the direct cause is different?


[1]: 
https://github.com/systemd/systemd/commit/c999cf385aee08295dc204d98585cb4001d08ade
[2]: 
https://github.com/systemd/systemd/commit/38b9b72ec10fa8875b1b7c93bc7ca6b8a2d5486e
[3]: https://github.com/systemd/systemd/pull/7186

-- 
Marcin Szewczyk
http://wodny.org
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev: Access permission of fw character device in which fw node includes unit handled by ALSA

[Takashi Sakamoto]

Hi Lennart,

Thanks for your reply, and notice to this legacy and minor issue ;)

On Mon, Jun 17, 2019, at 22:26, Lennart Poettering wrote:
> On Mo, 20.05.19 21:27, Takashi Sakamoto (o-taka...@sakamocchi.jp) wrote:
> 
> > Hi all,
> >
> > I'm an ALSA developer, mainly committing to drivers for audio and
> > music units on IEEE 1394 bus (yes, it's legacy FireWire). I have a
> > concern about access permission for fw character device.
> 
> I am not sure I understand firewire well enough to say something too
> smart. But if I understand correctly, then we (in systemd upstream)
> currently only have these four firewire specific rules in our tree:
> 
>   SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x00010*", GROUP="video"
>   SUBSYSTEM=="firewire", ATTR{units}=="*0x00b09d:0x00010*", GROUP="video"
>   SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x010001*", GROUP="video"
>   SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x014001*", GROUP="video"
> 
> And all of these are handled by some firewire core driver?

Although it's probable that some of them are handled by in-kernel
driver (perhaps firedtv.ko), they're just for userspace applications.
The in-kernel driver adds another device to system (in this case
video character device) and access rules to it are apart from the one
for fw character device, as long as all features are implemented in
the in-kernel driver.

In a case of drivers in ALSA firewire stack, we decided to implement
a part of features in userspace application, due to the complexity of
vendor-dependent protocols. The in-kernel drivers just implement
isochronous packet streaming for PCM frames and MIDI messages, and
tells userspace applications the related fw character device via
ALSA hwdep interface[1].

> The devices you care about, how would the rules look like for this?

Here, I'd like to explain about the relationships between instances on
IEEE 1394 bus topology and fw character device, modalias on in-kernel
driver.

```
IEEE 1394 bus
 + node A(=fw character device, /dew/fw0)
+ unit A1(=modalias on in-kernel driver, fw0.0)
+ unit B2(=modalias on in-kernel driver, fw0.1)
+ ...
 + node B(=fw character device, /dev/fw1)
+ unit B1(=modalias on in-kernel driver, fw1.0)
+ unit B2(=modalias on in-kernel driver, fw1.1)
+ ...
 + ...
```

The relationship between node/unit is similar to device/interface in
USB case. One node can includes several units which represent
actual functionalities, and any in-kernel driver is bound to one of the
units. On the other hand, fw character device is added for each node.
The node is subject of communication.

When any driver in ALSA firewire stack is bound to one of units in a node,
I expect udevd to change group of the corresponding fw character device to
'audio', and expect logind to assign ACL to it.

 + node A(fw character device with 'audio' group, +uaccess)
   + unit A1 (any driver in ALSA firewire stack is bound to)

In current framework of udev rule, this seems to be difficult to achieve,
in my opinion. Thus, if I managed to achieve it by rule framework,
I would add and maintain many entries generated from my registry[2].

> In general, when it comes to auto-loading of drivers we usually expect
> the kernel to add modalias metadata to .ko files.
>
> In the hwdb usually mostly only "auxiliary" data is stored, i.e. stuff
> that is great to have but is not essential for a device to work
> basically.
>
> Rules files should generally be kept short. i.e. if you add 3 more
> rules for the devices you care about, that'd be fine — if you add 100,
> then that's not so great however, and another approach should be
> found.

Yes. I'd like to avoid increasing maintenance cost of anybody including
myself...

> Anyway, given that I am not a firewire pro, I figure you have to
> decide yourself what the best approach is, and then prep a PR and we
> can have a look. Without looking at an (maybe just RFC) patch I am not
> sure I grok enugh to properly comment on it.

Okay. I'll attempt to post several RFC patches. It takes me a bit long
time because this is my first attempt to commit systemd, but I'm happy
if you review and comment to them.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/sound/firewire.h#n93
[2] https://github.com/takaswie/am-config-roms


Thanks

Takashi Sakamoto
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev: Access permission of fw character device in which fw node includes unit handled by ALSA

[Lennart Poettering]

On Mo, 20.05.19 21:27, Takashi Sakamoto (o-taka...@sakamocchi.jp) wrote:

> Hi all,
>
> I'm an ALSA developer, mainly committing to drivers for audio and
> music units on IEEE 1394 bus (yes, it's legacy FireWire). I have a
> concern about access permission for fw character device.

I am not sure I understand firewire well enough to say something too
smart. But if I understand correctly, then we (in systemd upstream)
currently only have these four firewire specific rules in our tree:

  SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x00010*", GROUP="video"
  SUBSYSTEM=="firewire", ATTR{units}=="*0x00b09d:0x00010*", GROUP="video"
  SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x010001*", GROUP="video"
  SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x014001*", GROUP="video"

And all of these are handled by some firewire core driver? The devices
you care about, how would the rules look like for this?

In general, when it comes to auto-loading of drivers we usually expect
the kernel to add modalias metadata to .ko files.

In the hwdb usually mostly only "auxiliary" data is stored, i.e. stuff
that is great to have but is not essential for a device to work
basically.

Rules files should generally be kept short. i.e. if you add 3 more
rules for the devices you care about, that'd be fine — if you add 100,
then that's not so great however, and another approach should be
found.

Anyway, given that I am not a firewire pro, I figure you have to
decide yourself what the best approach is, and then prep a PR and we
can have a look. Without looking at an (maybe just RFC) patch I am not
sure I grok enugh to properly comment on it.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] udev: Access permission of fw character device in which fw node includes unit handled by ALSA

[Takashi Sakamoto]

Hi all,

I'm an ALSA developer, mainly committing to drivers for audio and
music units on IEEE 1394 bus (yes, it's legacy FireWire). I have a
concern about access permission for fw character device.

In the last few years 9 drivers have been added to support 120 models
around[1]. The drivers allow ALSA applications to transfer audio data
frames and MIDI messages, but they expect userspace application to
use fw character device for operations of the other functionalities
such as physical volume controls.

At present, for some models, udevd configures fw character device for
good access permission to userspace applications. On the other hand,
for the other models, udevd doesn't. In my opinion, for one half of
supported models, fw character device is configured with root:root/0500.

I'd like to change this inconvenience, changing group ownership of the
special file to 'audio', and add ACL +uaccess when logging in.

For your information, I prepare a repository including image of
configuration ROM from supported devices[2]. At present, 80 images are
added.  You can parse the image by crpp in linux-firewire-utils
repository[3].

At present I assume three options:

1. Add entries into udev rules for each of device

This is an enhancement of existent rules[4][5] and simple solution.
But developers always take care of adding new entries when users suggests,
perhaps.

2. Reconfigure fw character device when ALSA firewire driver is attached
   to unit

IEEE 1394 specification refers to IEEE 1212 to represent device and its
functionalities. Each device is represented as 'node' and its
functionalities are represented as 'unit'. The information about 'node'
and 'unit' is in configuration ROM.

Linux firewire subsystem reads content of the ROM, parses
it and adds fw character device to system for 'node', then binds in-kernel
driver to 'unit'. Kevents for the node and unit are generated separately.

If udevd handles unit kevent to seek binding driver then configures fw
character device, developers don't need to maintain rule list. Although
one node is allowed to have several units, nut the most of supported
models have only one unit, except for Applie iSight[6].

3. Fulfill hwdb to have supplemental information

I'm not good at hwdb, but according to its name, hwdb is good to store
device dependent information. If adding some hints to database and
using the information, this issue might be solved.

I'm happy to receive your comments to improve this situation.

As a mockup of such control application, I wrote libhinawa[7] and
hinawa-utils[8]. They're my (rough) private work and out of ALSA project,
but for future I wish to propose better implementation to ALSA project
as a control server program.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/firewire/Kconfig
[2] https://github.com/takaswie/am-config-roms/
[3] https://github.com/cladisch/linux-firewire-utils
[4] 
https://github.com/systemd/systemd/blob/master/rules/50-udev-default.rules.in
[5] https://github.com/systemd/systemd/blob/master/src/login/70-uaccess.rules.m4
This rule refers to a rule optionally added by FFADO project.
[6] This device has four units; IIDC, Audio, vendor-dependent and IRIS.
[7] https://github.com/takaswie/libhinawa/
[8] https://github.com/takaswie/hinawa-utils/


Regards

Takashi Sakamoto
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev - device nodes removed even if created/copied from /lib/udev/devices/

[Mantas Mikulėnas]

On Mon, Apr 8, 2019, 20:15 Dr. Todor Dimitrov 
wrote:

> > Support for /lib/dev/devices has been removed in systemd 183, see NEWS
> > file, i.e. in 2012, seven years ago.
> >
> > Support for "ignore_remove" has been removed in udev 152, nine years
> > ago, see its announcement back then.
>
> We are working with a system from 2010 (kernel 2.6.34, udev 161).
> Unfortunately, it cannot be updated!
>
> > You can use tmpfiles.d/ snippets to create device nodes manually if
> > you like. if you do, they are created from userspace and then not
> > deleted by the kernel, since the kernel doesn't remove device nodes
> > created from userspace. Also, udev itself never deletes device nodes
> > either.
> >
> > But do note that using tmpfiles.d/ for this is racy: if the device
> > already exists, tmpfiles.d won't delete it and reacreated it, hence
> > depending on initialization timing it sometimes is the kernel that
> > created the device node, and sometimes userspace, and hence you know.
>
> I guess tmpfiles.d/ is not a thing on such an old system.
>
> > Moreover, do note that device node major/minor are generally assumed
> > to be entirely dynamic these days, hence it's problematic to
> > pre-create most device nodes these days, in particular on hotpluggy
> > subsystems which operate with fully dynamic major/minors.
> >
> > Hence, it's not really a great idea to do what you do. Interfering
> > from userspace into an allocation scheme and naming scheme owned by
> > the kernel is problematic. Yes, you can get away with a certain amount
> > of akwardness but it's ugly in any case. Doing the tmpfiles.d/ thing
> > to create device nodes is fully safe only on subsystems that never got
> > updated to the driver model properly (which I think is the lp0 driver
> > but nothing of relevance today, except nvidia drivers).
>
>
> The device nodes are not created by the kernel (modules) but rather by
> udev. The usb-serial driver allocates minor numbers sequentially, nothing
> fancy there. Moreover, it will reuse them when they are freed, i.e. when a
> device is unplugged.
>

If the device numbers are sufficiently static that you can hardcode them in
/lib/udev/devices, why not avoid udev's and/or the kernel's handling of
that node entirely by using a different non-conflicting filename for it?
They shouldn't be creating nor removing /dev/ttyUSB0static, for example.


> > Why would you bind mount a device node that references a non-existing
> > device into a container?
>
> This is necessary for unprivileged containers (run by an unprivileged
> user), which are not able to create device nodes after boot. So these have
> to be bind mounted on start, even if the nodes are not "occupied". This
> works perfectly fine. In this particular case, we can probably work around
> this issue since the kernel is way too old for running unprivileged
> containers.
>

If that's the *only* purpose of the device node's existence, then it
doesn't have to live in /dev in the first place, does it? It could be bound
from /dev/containerstuff or even directly from /lib.



> I’ve looked inside the udev 161 code and it seems that the device nodes
> will be removed no matter what. I wonder whether there is some other way to
> prevent udev from deleting the device nodes. Maybe somehow stop the event
> propagation?
>
> Thanks,
> Todor
>

IMO, just build a local version with the code disabled. (If you have to
maintain such an old version, chances are it's something you'll need to do
sooner or later anyway...)

>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev - device nodes removed even if created/copied from /lib/udev/devices/

[Dr. Todor Dimitrov]

> Support for /lib/dev/devices has been removed in systemd 183, see NEWS
> file, i.e. in 2012, seven years ago.
> 
> Support for "ignore_remove" has been removed in udev 152, nine years
> ago, see its announcement back then.

We are working with a system from 2010 (kernel 2.6.34, udev 161). 
Unfortunately, it cannot be updated!

> You can use tmpfiles.d/ snippets to create device nodes manually if
> you like. if you do, they are created from userspace and then not
> deleted by the kernel, since the kernel doesn't remove device nodes
> created from userspace. Also, udev itself never deletes device nodes
> either.
> 
> But do note that using tmpfiles.d/ for this is racy: if the device
> already exists, tmpfiles.d won't delete it and reacreated it, hence
> depending on initialization timing it sometimes is the kernel that
> created the device node, and sometimes userspace, and hence you know.

I guess tmpfiles.d/ is not a thing on such an old system.

> Moreover, do note that device node major/minor are generally assumed
> to be entirely dynamic these days, hence it's problematic to
> pre-create most device nodes these days, in particular on hotpluggy
> subsystems which operate with fully dynamic major/minors.
> 
> Hence, it's not really a great idea to do what you do. Interfering
> from userspace into an allocation scheme and naming scheme owned by
> the kernel is problematic. Yes, you can get away with a certain amount
> of akwardness but it's ugly in any case. Doing the tmpfiles.d/ thing
> to create device nodes is fully safe only on subsystems that never got
> updated to the driver model properly (which I think is the lp0 driver
> but nothing of relevance today, except nvidia drivers).


The device nodes are not created by the kernel (modules) but rather by udev. 
The usb-serial driver allocates minor numbers sequentially, nothing fancy 
there. Moreover, it will reuse them when they are freed, i.e. when a device is 
unplugged.

> Why would you bind mount a device node that references a non-existing
> device into a container?

This is necessary for unprivileged containers (run by an unprivileged user), 
which are not able to create device nodes after boot. So these have to be bind 
mounted on start, even if the nodes are not "occupied". This works perfectly 
fine. In this particular case, we can probably work around this issue since the 
kernel is way too old for running unprivileged containers.

I’ve looked inside the udev 161 code and it seems that the device nodes will be 
removed no matter what. I wonder whether there is some other way to prevent 
udev from deleting the device nodes. Maybe somehow stop the event propagation?

Thanks,
Todor

> On 8. Apr 2019, at 18:04, Lennart Poettering  wrote:
> 
> On Mo, 08.04.19 15:59, Dr. Todor Dimitrov (dimit...@technology.de) wrote:
> 
>> Hello,
>> 
>> we are observing a weird problem with udev, where the nodes
>> /dev/ttyUSB* are removed as soon as the corresponding devices are
>> unplugged, although they have been statically created using
>> /lib/udev/devices/. According to the documentation/change logs, this
>> should not happen:
> 
> Support for /lib/dev/devices has been removed in systemd 183, see NEWS
> file, i.e. in 2012, seven years ago.
> 
> Support for "ignore_remove" has been removed in udev 152, nine years
> ago, see its announcement back then.
> 
> You can use tmpfiles.d/ snippets to create device nodes manually if
> you like. if you do, they are created from userspace and then not
> deleted by the kernel, since the kernel doesn't remove device nodes
> created from userspace. Also, udev itself never deletes device nodes
> either.
> 
> But do note that using tmpfiles.d/ for this is racy: if the device
> already exists, tmpfiles.d won't delete it and reacreated it, hence
> depending on initialization timing it sometimes is the kernel that
> created the device node, and sometimes userspace, and hence you know.
> 
> Moreover, do note that device node major/minor are generally assumed
> to be entirely dynamic these days, hence it's problematic to
> pre-create most device nodes these days, in particular on hotpluggy
> subsystems which operate with fully dynamic major/minors.
> 
> Hence, it's not really a great idea to do what you do. Interfering
> from userspace into an allocation scheme and naming scheme owned by
> the kernel is problematic. Yes, you can get away with a certain amount
> of akwardness but it's ugly in any case. Doing the tmpfiles.d/ thing
> to create device nodes is fully safe only on subsystems that never got
> updated to the driver model properly (which I think is the lp0 driver
> but nothing of relevance today, except nvidia drivers).
> 
>> Any help or suggestions are highly appreciated. We need the device
>> nodes to be static since we are bind mounting them inside a
>> container.
> 
> Why would you bind mount a device node that references a non-existing
> device into a container?
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin

Re: [systemd-devel] udev - device nodes removed even if created/copied from /lib/udev/devices/

[Lennart Poettering]

On Mo, 08.04.19 15:59, Dr. Todor Dimitrov (dimit...@technology.de) wrote:

> Hello,
>
> we are observing a weird problem with udev, where the nodes
> /dev/ttyUSB* are removed as soon as the corresponding devices are
> unplugged, although they have been statically created using
> /lib/udev/devices/. According to the documentation/change logs, this
> should not happen:

Support for /lib/dev/devices has been removed in systemd 183, see NEWS
file, i.e. in 2012, seven years ago.

Support for "ignore_remove" has been removed in udev 152, nine years
ago, see its announcement back then.

You can use tmpfiles.d/ snippets to create device nodes manually if
you like. if you do, they are created from userspace and then not
deleted by the kernel, since the kernel doesn't remove device nodes
created from userspace. Also, udev itself never deletes device nodes
either.

But do note that using tmpfiles.d/ for this is racy: if the device
already exists, tmpfiles.d won't delete it and reacreated it, hence
depending on initialization timing it sometimes is the kernel that
created the device node, and sometimes userspace, and hence you know.

Moreover, do note that device node major/minor are generally assumed
to be entirely dynamic these days, hence it's problematic to
pre-create most device nodes these days, in particular on hotpluggy
subsystems which operate with fully dynamic major/minors.

Hence, it's not really a great idea to do what you do. Interfering
from userspace into an allocation scheme and naming scheme owned by
the kernel is problematic. Yes, you can get away with a certain amount
of akwardness but it's ugly in any case. Doing the tmpfiles.d/ thing
to create device nodes is fully safe only on subsystems that never got
updated to the driver model properly (which I think is the lp0 driver
but nothing of relevance today, except nvidia drivers).

> Any help or suggestions are highly appreciated. We need the device
> nodes to be static since we are bind mounting them inside a
> container.

Why would you bind mount a device node that references a non-existing
device into a container?

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] udev - device nodes removed even if created/copied from /lib/udev/devices/

[Dr. Todor Dimitrov]

Hello,

we are observing a weird problem with udev, where the nodes /dev/ttyUSB* are 
removed as soon as the corresponding devices are unplugged, although they have 
been statically created using /lib/udev/devices/. According to the 
documentation/change logs, this should not happen:

---
udev 152

Bugfixes.

...

The option "ignore_remove" was removed from udev. With devtmpfs
udev passed control over device nodes to the kernel. This option
should not be needed, or can not work as advertised. Neither
udev nor the kernel will remove device nodes which are copied from
the /lib/udev/devices/ directory.
---

Upon start, the device nodes are properly created/copied from 
/lib/udev/devices/. When a USB device is plugged, it is correctly wired to the 
ttyUSB0. Unfortunately, when the device is unplugged, the /dev/ttyUSB0 is 
removed. Note that this only happens if udevd is running. If the udev daemon is 
not running, the device node remains after unplugging and can be later reused.

In an older revision (2202), we found the following change in 
etc/udev/rules.d/50-udev-default.rules:

---
# do not delete static device nodes
ACTION=="remove", NAME=="?*", TEST=="/lib/udev/devices/$name", 
OPTIONS+="ignore_remove"
---

But since "ignore_remove" has been removed in udev 152, it seems that this 
functionality has not been reimplemented.

Any help or suggestions are highly appreciated. We need the device nodes to be 
static since we are bind mounting them inside a container.

Thanks in advance,
Todor

smime.p7s
Description: S/MIME cryptographic signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev “PROGRAM/RUN” command not working properly for “REMOVE” action

[Lennart Poettering]

On Di, 05.02.19 13:08, Martin Wilck (mwi...@suse.de) wrote:

> On Mon, 2019-02-04 at 13:19 +0100, Lennart Poettering wrote:
> >
> > reading sysfs attrs is problematics from "remove" rules, as the sysfs
> > device is likely to have vanished by then, as rules are executed
> > asynchronously to the events they are run for.
> >
> > udev will import the udev db from the last event it has seen on a
> > device on "remove", but sysfs attrs are not stored in the udev
> > db. hence, consider testing against udev db props here, not sysfs
> > attrs.
>
> Right. Then, maybe, udev should treat & report attempts to refer to
> sysfs attributes in rules for "remove" events as errors in the first
> place?

Checking that is not trivial. After all the language knows GOTO and
negative comparisons, and whatnot. Hence it's not trivially
determinable whether some rule will run in ACTION=="remove"...

But if you can come up with a crisp patch for this, but all means,
submit as PR and we can review it.

(I do fear that as soon as if we'd turn this on then this will
complain about a major chunk of rules files. Hence should be a
warning, not an error, and might still be controversial then)

Lennart

--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev “PROGRAM/RUN” command not working properly for “REMOVE” action

[Martin Wilck]

On Mon, 2019-02-04 at 13:19 +0100, Lennart Poettering wrote:
> 
> reading sysfs attrs is problematics from "remove" rules, as the sysfs
> device is likely to have vanished by then, as rules are executed
> asynchronously to the events they are run for.
> 
> udev will import the udev db from the last event it has seen on a
> device on "remove", but sysfs attrs are not stored in the udev
> db. hence, consider testing against udev db props here, not sysfs
> attrs.

Right. Then, maybe, udev should treat & report attempts to refer to
sysfs attributes in rules for "remove" events as errors in the first
place?

Regards,
Martin



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev “PROGRAM/RUN” command not working properly for “REMOVE” action

[Ziemowit Podwysocki]

On 04.02.2019 13:19, Lennart Poettering wrote:
> On Do, 31.01.19 14:46, Ziemowit Podwysocki 
> (ziemowit.podwyso...@globallogic.com) wrote:
>
>> Hello,
>>
>> I have multiple exactly same USB devices. Each device enumerates
>> multiply ttyACM ports under /dev directory. Each port has it unique
>> purpose, one is for handling some commands, another is diagnostic, etc.
>> What I want is to alias tty's for particular device by creating symlinks
>> with the ability to distinguish to which device this port belongs.
>>
>> For example:
>>
>> /    DEVICE_UNIQUENUM_PURPOSE/
>>
>> /    /dev/MODULE_0_DIAG
>>     /dev/MODULE_0_CMD
>>     /dev/MODULE_1_DIAG
>>     /dev/MODULE_1_CMD/
>>
>> To achieve this I started working with udev to write rules for my
>> device. I learned that udev is not able to enumerate symlinks for the
>> same device in the sophisticated way I want it. So I decided to write
>> bash script which do all the work. Here are the rules:
>>
>> /    ACTION=="add", KERNEL=="ttyACM[0-9]*", SUBSYSTEM=="tty",
>> SUBSYSTEMS=="usb", ATTRS{idVendor}=="1e2d", ATTRS{idProduct}=="0063",
>> PROGRAM="/bin/bash /home/user/script.sh %k", SYMLINK+="%c"
>>     ACTION=="remove", SUBSYSTEM=="usb", DRIVER=="usb",
>> ATTRS{idVendor}=="1e2d", ATTRS{idProduct}=="0063", PROGRAM="/bin/bash
>> /home/user/script.sh"/
> reading sysfs attrs is problematics from "remove" rules, as the sysfs
> device is likely to have vanished by then, as rules are executed
> asynchronously to the events they are run for.
>
> udev will import the udev db from the last event it has seen on a
> device on "remove", but sysfs attrs are not stored in the udev
> db. hence, consider testing against udev db props here, not sysfs
> attrs.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat

Hello Lennart,

you are correct. I've already managed to found it by myself. sysfs
device indeed is not present during udev remove rules being resolved.
After referring to udev environmental variables everything started
working properly.

BR,

Ziemowit


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev “PROGRAM/RUN” command not working properly for “REMOVE” action

[Lennart Poettering]

On Do, 31.01.19 14:46, Ziemowit Podwysocki 
(ziemowit.podwyso...@globallogic.com) wrote:

> Hello,
>
> I have multiple exactly same USB devices. Each device enumerates
> multiply ttyACM ports under /dev directory. Each port has it unique
> purpose, one is for handling some commands, another is diagnostic, etc.
> What I want is to alias tty's for particular device by creating symlinks
> with the ability to distinguish to which device this port belongs.
>
> For example:
>
> /    DEVICE_UNIQUENUM_PURPOSE/
>
> /    /dev/MODULE_0_DIAG
>     /dev/MODULE_0_CMD
>     /dev/MODULE_1_DIAG
>     /dev/MODULE_1_CMD/
>
> To achieve this I started working with udev to write rules for my
> device. I learned that udev is not able to enumerate symlinks for the
> same device in the sophisticated way I want it. So I decided to write
> bash script which do all the work. Here are the rules:
>
> /    ACTION=="add", KERNEL=="ttyACM[0-9]*", SUBSYSTEM=="tty",
> SUBSYSTEMS=="usb", ATTRS{idVendor}=="1e2d", ATTRS{idProduct}=="0063",
> PROGRAM="/bin/bash /home/user/script.sh %k", SYMLINK+="%c"
>     ACTION=="remove", SUBSYSTEM=="usb", DRIVER=="usb",
> ATTRS{idVendor}=="1e2d", ATTRS{idProduct}=="0063", PROGRAM="/bin/bash
> /home/user/script.sh"/

reading sysfs attrs is problematics from "remove" rules, as the sysfs
device is likely to have vanished by then, as rules are executed
asynchronously to the events they are run for.

udev will import the udev db from the last event it has seen on a
device on "remove", but sysfs attrs are not stored in the udev
db. hence, consider testing against udev db props here, not sysfs
attrs.

Lennart

--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev “PROGRAM/RUN” command not working properly for “REMOVE” action

[Martin Wilck]

On Thu, 2019-01-31 at 14:46 +0100, Ziemowit Podwysocki wrote:
> 
> ACTION=="remove", SUBSYSTEM=="usb", DRIVER=="usb",
> ATTRS{idVendor}=="1244", ATTRS{idProduct}=="206d", RUN+="/bin/touch
> /home/user/udev/%k"
> 
> This one suppose to create file named after "KERNEL" param of the
> device. This is also not happening! But for action "add" it works!

Have you tried udev debugging (udevadm control -l debug)?

I'd do that, and that I'd remove some conditions and see if one of them
is not (or unreliably) set on remove events, and thus causing your rule
not to be run. E.g. start with 

  ACTION=="remove", RUN+="..."

and then add the original conditions one by one.

Regards
Martin


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] udev “PROGRAM/RUN” command not working properly for “REMOVE” action

[Ziemowit Podwysocki]

Hello,

I have multiple exactly same USB devices. Each device enumerates
multiply ttyACM ports under /dev directory. Each port has it unique
purpose, one is for handling some commands, another is diagnostic, etc.
What I want is to alias tty's for particular device by creating symlinks
with the ability to distinguish to which device this port belongs.

For example:

/    DEVICE_UNIQUENUM_PURPOSE/

/    /dev/MODULE_0_DIAG
    /dev/MODULE_0_CMD
    /dev/MODULE_1_DIAG
    /dev/MODULE_1_CMD/

To achieve this I started working with udev to write rules for my
device. I learned that udev is not able to enumerate symlinks for the
same device in the sophisticated way I want it. So I decided to write
bash script which do all the work. Here are the rules:

/    ACTION=="add", KERNEL=="ttyACM[0-9]*", SUBSYSTEM=="tty",
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1e2d", ATTRS{idProduct}=="0063",
PROGRAM="/bin/bash /home/user/script.sh %k", SYMLINK+="%c"
    ACTION=="remove", SUBSYSTEM=="usb", DRIVER=="usb",
ATTRS{idVendor}=="1e2d", ATTRS{idProduct}=="0063", PROGRAM="/bin/bash
/home/user/script.sh"/

Basically script starts by checking what action did occur "add" or
"remove" and takes next steps based on that. The tricky part is that
rule for "add" will fire script multiple times at once cause there are
multiple tty devices handled at the same time. So to synchronize my
script I implemented simple mutex based on creating directory at some
place. If directory is present then other scripts will wait until they
can create one. Moving forward, add operation:

1.  Creates temporary database if not present
2.  Based on information passed by udev it determines what type of
device is that and what unique number it should give it.
3.  Writes record to database for this particular tty

Remove operation:

1.  Based on serial number passed from udev it should remove all
records for matching tty devices.

Now the problem. For some reason action "remove" is not triggering my
script properly. For action "add" all works flawlessly. Upon device plug
in records are written to database file correctly for each tty. When I
plug out device script most of the time won't even run. Sometimes it
will. Previously I had almost same rule for action "remove" as for "add":

/    ACTION=="remove", KERNEL=="ttyACM[0-9]*", SUBSYSTEM=="tty",
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1e2d", ATTRS{idProduct}=="0063",
PROGRAM="/bin/bash /home/user/script.sh %k"/

This one sometimes run script for one tty, sometimes for more.
Completely nondeterministicly. I have no idea why is this behaving like
this.

When I'm using "udevadm test" utility to simulate action "remove" for
device then it works perfectly every time. But for real plug out it is
not. I also checked with "udevadm monitor" what events are occuring and
"remove" actions are present for device so everything looks correct.

Another thing I tried was to change "PROGRAM" command to "RUN" command
but it did not helped.

After that I decided to do the simplest test possible. I have written
this rule:

/    ACTION=="remove", SUBSYSTEM=="usb", DRIVER=="usb",
ATTRS{idVendor}=="1244", ATTRS{idProduct}=="206d", RUN+="/bin/touch
/home/user/udev/%k"/

This one suppose to create file named after "KERNEL" param of the
device. This is also not happening! But for action "add" it works!

This drives me nuts. Am I missing something? I know udev specifies that
only short tasks should be runned via "PROGRAM/RUN" but if this is not
short task then what is? Also everything works for action "add". I'm
simply out of ideas. Maybe this is udev flaw?

Thanks,

Ziemowit Podwysocki

 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev script can't resolve host name

[Jonathan Kamens]

Thanks for the pointer. It turns out that Ubuntu puts IPAddressDeny=all 
in systemd-udevd.service. I suppose I could remove that (reducing 
protection, as you note) or add an IPAddressAllow setting to allow 
access to the DNS server and remote URL I want to hit, but then I have 
to worry about keeping that in sync with the IP address associated with 
the host name in the URL. I think it's probably just easier to do this 
with a timer that runs a polling script every five seconds, rather than 
using udev.


  jik

On 8/15/18 7:13 AM, Sietse van Zanen wrote:

Jonathan,


Yes that is exactly the case. Look inside he unit filre, systemd-udevd.service. 
It contains lines like:

PrivateMounts=yes
MemoryDenyWriteExecute=yes
RestrictRealtime=yes
RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
SystemCallFilter=@system-service @module @raw-io
SystemCallErrorNumber=EPERM
SystemCallArchitectures=native
LockPersonality=yes

I think the SystemCallFilter is your culplrit here. Removing it will probably 
make your script work, but it may also remove important protection.


-Sietse



From: systemd-devel  on behalf of 
Jonathan Kamens 
Sent: Wednesday, August 15, 2018 10:31
To: systemd-devel@lists.freedesktop.org
Subject: [systemd-devel] udev script can't resolve host name


Hi,

If I understand correctly, this mailing list can be used for questions about udev as well 
as about systemd. If that's not correct, somebody please let me know and I will go 
elsewhere (and if you know where that "elsewhere" should be, please let me 
know, that would be helpful!); I don't mean to use the list incorrectly.

I want to call a webhook inside a script run via a RUN directive in a udev rule.

When I try to do this, curl says it's unable to resolve the host name of the 
URL I am asking it to fetch.

To collect more data about the cause of this issue, I also tried doing a "ping -c 1 
8.8.8.8" inside the script, and it gets, "sendmsg: Operation not permitted."

I assume this means udev scripts are running inside some sort of restricted 
environment or something, but I can't figure out what controls the restrictions 
on that environment, whether I can loosen them, or how.

I'm on Ubuntu 18.04.

Any advice?

Thank you,

Jonathan Kamens

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev script can't resolve host name

[Michael Biebl]

Am Mi., 15. Aug. 2018 um 11:09 Uhr schrieb Jonathan Kamens :
>
> Hi,
>
> If I understand correctly, this mailing list can be used for questions about 
> udev as well as about systemd. If that's not correct, somebody please let me 
> know and I will go elsewhere (and if you know where that "elsewhere" should 
> be, please let me know, that would be helpful!); I don't mean to use the list 
> incorrectly.
>
> I want to call a webhook inside a script run via a RUN directive in a udev 
> rule.

Consider using SYSTEMD_WANTS instead of calling (potentially long
running or privileged) tasks from udev rules.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev script can't resolve host name

[Sietse van Zanen]

Jonathan,


Yes that is exactly the case. Look inside he unit filre, systemd-udevd.service. 
It contains lines like:

PrivateMounts=yes
MemoryDenyWriteExecute=yes
RestrictRealtime=yes
RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
SystemCallFilter=@system-service @module @raw-io
SystemCallErrorNumber=EPERM
SystemCallArchitectures=native
LockPersonality=yes

I think the SystemCallFilter is your culplrit here. Removing it will probably 
make your script work, but it may also remove important protection.


-Sietse



From: systemd-devel  on behalf of 
Jonathan Kamens 
Sent: Wednesday, August 15, 2018 10:31
To: systemd-devel@lists.freedesktop.org
Subject: [systemd-devel] udev script can't resolve host name


Hi,

If I understand correctly, this mailing list can be used for questions about 
udev as well as about systemd. If that's not correct, somebody please let me 
know and I will go elsewhere (and if you know where that "elsewhere" should be, 
please let me know, that would be helpful!); I don't mean to use the list 
incorrectly.

I want to call a webhook inside a script run via a RUN directive in a udev rule.

When I try to do this, curl says it's unable to resolve the host name of the 
URL I am asking it to fetch.

To collect more data about the cause of this issue, I also tried doing a "ping 
-c 1 8.8.8.8" inside the script, and it gets, "sendmsg: Operation not 
permitted."

I assume this means udev scripts are running inside some sort of restricted 
environment or something, but I can't figure out what controls the restrictions 
on that environment, whether I can loosen them, or how.

I'm on Ubuntu 18.04.

Any advice?

Thank you,

Jonathan Kamens
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] udev script can't resolve host name

[Jonathan Kamens]

Hi,

If I understand correctly, this mailing list can be used for questions 
about udev as well as about systemd. If that's not correct, somebody 
please let me know and I will go elsewhere (and if you know where that 
"elsewhere" should be, please let me know, that would be helpful!); I 
don't mean to use the list incorrectly.


I want to call a webhook inside a script run via a RUN directive in a 
udev rule.


When I try to do this, curl says it's unable to resolve the host name of 
the URL I am asking it to fetch.


To collect more data about the cause of this issue, I also tried doing a 
"ping -c 1 8.8.8.8" inside the script, and it gets, "sendmsg: Operation 
not permitted."


I assume this means udev scripts are running inside some sort of 
restricted environment or something, but I can't figure out what 
controls the restrictions on that environment, whether I can loosen 
them, or how.


I'm on Ubuntu 18.04.

Any advice?

Thank you,

Jonathan Kamens

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev rules

[Dmitry Torokhov]

On Tue, Jan 23, 2018 at 2:08 AM, Michael  wrote:
> Hi
> why can't the Udev rules be automated or removed? As described here users
> only need to paste infos from lsusb etc.
> https://forums.x-plane.org/index.php?/forums/topic/72733-writing-and-debugging-udev-rules/=2
> But such a huge pain in the ass that no other os needs.

Umm, no. The other OSes need similar things, as it is very hard (read:
impossible) to accurately classify devices based only on information
in their HID descriptors (and many hardware vendors put extra stuff in
the HID descriptors because they cut and paste bits of firmware code
from one project to another). You do not see these quirks because they
are hidden from you by vendor drivers, etc, etc. Here you simply have
visibility.

> It really holds off many potential new Linux users if they can't get their
> USB Joysticks working out of the box.
> Thanks for fixing and make Linux competitive to other os.
> I remember around a decade ago my joysticks simply worked out of the box
> before we got Udev.

Decade ago the world was much simpler.

Thanks.

-- 
Dmitry
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev rules

[Lennart Poettering]

On Di, 23.01.18 10:08, Michael (scrat_h...@yahoo.com) wrote:

> Hiwhy can't the Udev rules be automated or removed? As described
> here users only need to paste infos from lsusb
> etc.https://forums.x-plane.org/index.php?/forums/topic/72733-writing-and-debugging-udev-rules/=2But
> such a huge pain in the ass that no other os needs.It really holds
> off many potential new Linux users if they can't get their USB
> Joysticks working out of the box.Thanks for fixing and make Linux
> competitive to other os.I remember around a decade ago my joysticks
> simply worked out of the box before we got Udev.

The default udev rules should set up access to the joystick devices
the right way automatically: the user on the console as well as all
users in the "input" group should get access to it automatically.

Writing such udev rules should not be necessary.

Anyway, this is not an upstream systemd issue. If you have trouble
with how your distribution handles joystick devices by default, please
ping your downstream distribution and not us upstream.

Thank you very much for understanding,

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Udev rules

[Michael]

Hiwhy can't the Udev rules be automated or removed? As described here users 
only need to paste infos from lsusb 
etc.https://forums.x-plane.org/index.php?/forums/topic/72733-writing-and-debugging-udev-rules/=2But
 such a huge pain in the ass that no other os needs.It really holds off many 
potential new Linux users if they can't get their USB Joysticks working out of 
the box.Thanks for fixing and make Linux competitive to other os.I remember 
around a decade ago my joysticks simply worked out of the box before we got 
Udev.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev

[David Henderson]

On 11/1/17, Mike Gilbert  wrote:
> On Wed, Nov 1, 2017 at 10:49 AM, David Henderson
>  wrote:
>> On 11/1/17, Greg KH  wrote:
>>> On Wed, Nov 01, 2017 at 10:36:16AM -0400, David Henderson wrote:
 Is there a place to just get the udev code instead of all of systemD?
>>>
>>> No.
>>>
 I tried looking online, but it appears that the only solo versions are
 old.  I guess this got merged into systemD for some reason?
>>>
>>> Yes, it all got merged many many years ago for the obvious reasons that
>>> you will find out if you try to tear them apart :)
>>
>> lol Thanks Greg, I will give it another shot later today to see if I
>> can get things resolved with some of the suggestions provided!
>
> On the topic of ripping udev out of systemd:
>
> Some Gentoo people actually forked udev out of systemd a while ago.
> You might consider using their "eudev" fork if it meets your needs. We
> use this as the default udev implementation for Gentoo systems that do
> not use systemd. Just don't ask for support for it on this mailing
> list. ;-)
>
> https://wiki.gentoo.org/wiki/Project:Eudev
>
> https://github.com/gentoo/eudev
>

Thanks Mike, that might be a better solution for me than attempting
the systemD version!  I will give that a shot later today as well!

Dave
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev

[Mike Gilbert]

On Wed, Nov 1, 2017 at 10:49 AM, David Henderson
 wrote:
> On 11/1/17, Greg KH  wrote:
>> On Wed, Nov 01, 2017 at 10:36:16AM -0400, David Henderson wrote:
>>> Is there a place to just get the udev code instead of all of systemD?
>>
>> No.
>>
>>> I tried looking online, but it appears that the only solo versions are
>>> old.  I guess this got merged into systemD for some reason?
>>
>> Yes, it all got merged many many years ago for the obvious reasons that
>> you will find out if you try to tear them apart :)
>
> lol Thanks Greg, I will give it another shot later today to see if I
> can get things resolved with some of the suggestions provided!

On the topic of ripping udev out of systemd:

Some Gentoo people actually forked udev out of systemd a while ago.
You might consider using their "eudev" fork if it meets your needs. We
use this as the default udev implementation for Gentoo systems that do
not use systemd. Just don't ask for support for it on this mailing
list. ;-)

https://wiki.gentoo.org/wiki/Project:Eudev

https://github.com/gentoo/eudev
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev

[David Henderson]

On 11/1/17, Greg KH  wrote:
> On Wed, Nov 01, 2017 at 10:36:16AM -0400, David Henderson wrote:
>> Is there a place to just get the udev code instead of all of systemD?
>
> No.
>
>> I tried looking online, but it appears that the only solo versions are
>> old.  I guess this got merged into systemD for some reason?
>
> Yes, it all got merged many many years ago for the obvious reasons that
> you will find out if you try to tear them apart :)

lol Thanks Greg, I will give it another shot later today to see if I
can get things resolved with some of the suggestions provided!

Dave
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev

[David Henderson]

On 11/1/17, Lennart Poettering  wrote:
> On Di, 31.10.17 14:49, David Henderson (dhender...@digital-pipe.com) wrote:
>
>> Good afternoon all.  So is there another place I can get help for
>> this problem?
>
> Sorry, but this isn't really the right forum for help regarding
> building your distribution. Most of us just base our work on the work
> established distributions already did for us in this regard. If that
> doesn't work for you, then please contact a community such as LFS,
> whose focus it explicitly is to build a distribution from scratch,
> without resuing any work from other distributions. I am pretty sure
> they have more experience with putting together their own working
> build tool chain than us.
>
> Sorry,
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>

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 about this, they would direct me to this
communication channel since this is where the people who build and
support the programs are located.  As a side question, is there a
place to just acquire the udev portion without all the other parts or
did that get merged into this suite only?

Thanks,
Dave
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev

[Greg KH]

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 about this, they would direct me to this
> communication channel since this is where the people who build and
> support the programs are located.  As a side question, is there a
> place to just acquire the udev portion without all the other parts or
> did that get merged into this suite only?

Again, I would look at how Gentoo does it in their build scripts.
That's your best bet, and if that doesn't work, you really are on your
own as the source code is not set up to only extract one program from
the whole system, for obvious reasons.

good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev

[Lennart Poettering]

On Di, 31.10.17 14:49, David Henderson (dhender...@digital-pipe.com) wrote:

> Good afternoon all.  So is there another place I can get help for
> this problem?

Sorry, but this isn't really the right forum for help regarding
building your distribution. Most of us just base our work on the work
established distributions already did for us in this regard. If that
doesn't work for you, then please contact a community such as LFS,
whose focus it explicitly is to build a distribution from scratch,
without resuing any work from other distributions. I am pretty sure
they have more experience with putting together their own working
build tool chain than us.

Sorry,

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev

[David Henderson]

Good afternoon all.  So is there another place I can get help for this problem?

Thanks,
Dave


On 10/30/17, David Henderson  wrote:
> Good morning all!  Just following up with this!
>
> Thanks,
> Dave
>
>
> On 10/26/17, David Henderson  wrote:
>> On 10/26/17, David Henderson  wrote:
>>> So I am using the compile flags as suggested, however, I have noticed
>>> two errors.  I tried passing '--enable-static' to 'configure' and end
>>> up with:
>>>
>>> checking if libtool supports shared libraries... yes
>>> checking whether to build shared libraries... yes
>>> checking whether to build static libraries... yes
>>> configure: error: --enable-static is not supported by systemd
>>>
>>> Without it, I get passed that error in favor of another one:
>>>
>>> checking if libtool supports shared libraries... yes
>>> checking whether to build shared libraries... yes
>>> checking whether to build static libraries... no
>>> checking for intltool-merge... yes
>>> checking whether NLS is requested... yes
>>> checking for intltool >= 0.40.0... 0.51.0 found
>>> checking for intltool-update... /usr/local/bin/intltool-update
>>> checking for intltool-merge... /usr/local/bin/intltool-merge
>>> checking for intltool-extract... /usr/local/bin/intltool-extract
>>> checking for xgettext... /usr/local/bin/xgettext
>>> checking for msgmerge... /usr/local/bin/msgmerge
>>> checking for msgfmt... /usr/local/bin/msgfmt
>>> checking for gmsgfmt... /usr/local/bin/msgfmt
>>> /usr/local/bin/xgettext: error while loading shared libraries:
>>> libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
>>> file or directory
>>> /usr/local/bin/msgmerge: error while loading shared libraries:
>>> libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
>>> file or directory
>>> /usr/local/bin/msgfmt: error while loading shared libraries:
>>> libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
>>> file or directory
>>> configure: error: GNU gettext tools not found; required for intltool
>>>
>>> However, I have verified that the file does in fact exist and is
>>> located in /usr/local/lib.  I tried adding '-L/usr/local/lib' to the
>>> LDFLAGS variable, but no change.  Is it an issue with needing to be a
>>> newer version or something?
>>>
>>
>> So it appears that the binaries were looking for the lib in /lib,
>> although they were actually in /usr/local/lib.  A few symlinks
>> corrected that issue.  However, I have no run into another issue:
>>
>> checking for qemu-system-x86_64... no
>> checking for /usr/share/qemu/bios-ovmf.bin... no
>> checking for /usr/share/qemu-ovmf/bios.bin... no
>> checking that generated files are newer than configure... done
>> configure: creating ./config.status
>> config.status: creating Makefile
>> config.status: error: cannot find input file: `po/Makefile.in.in'
>>
>> Checking the config.log says:
>>
>> ## -- ##
>> ## Running config.status. ##
>> ## -- ##
>>
>> This file was extended by systemd config.status 234, which was
>> generated by GNU Autoconf 2.69.  Invocation command line was
>>
>>   CONFIG_FILES=
>>   CONFIG_HEADERS  =
>>   CONFIG_LINKS=
>>   CONFIG_COMMANDS =
>>   $ ./config.status
>>
>> on b46de142dd54
>>
>> config.status:1555: creating Makefile
>> config.status:1541: error: cannot find input file: `po/Makefile.in.in'
>>
>>
>> I have installed glib2-dev and gettext-dev and intltool which each has
>> a Makefile.in.in file:
>>
>> /usr/local/share/gettext/po/Makefile.in.in
>> /usr/local/share/glib-2.0/gettext/po/Makefile.in.in
>> /usr/local/share/intltool/Makefile.in.in
>>
>> It doesn't appear to be the last one since the file isn't located in
>> the 'po' directory.  Any thoughts?
>>
>> Thanks,
>> Dave
>>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev

[David Henderson]

Good morning all!  Just following up with this!

Thanks,
Dave


On 10/26/17, David Henderson  wrote:
> On 10/26/17, David Henderson  wrote:
>> So I am using the compile flags as suggested, however, I have noticed
>> two errors.  I tried passing '--enable-static' to 'configure' and end
>> up with:
>>
>> checking if libtool supports shared libraries... yes
>> checking whether to build shared libraries... yes
>> checking whether to build static libraries... yes
>> configure: error: --enable-static is not supported by systemd
>>
>> Without it, I get passed that error in favor of another one:
>>
>> checking if libtool supports shared libraries... yes
>> checking whether to build shared libraries... yes
>> checking whether to build static libraries... no
>> checking for intltool-merge... yes
>> checking whether NLS is requested... yes
>> checking for intltool >= 0.40.0... 0.51.0 found
>> checking for intltool-update... /usr/local/bin/intltool-update
>> checking for intltool-merge... /usr/local/bin/intltool-merge
>> checking for intltool-extract... /usr/local/bin/intltool-extract
>> checking for xgettext... /usr/local/bin/xgettext
>> checking for msgmerge... /usr/local/bin/msgmerge
>> checking for msgfmt... /usr/local/bin/msgfmt
>> checking for gmsgfmt... /usr/local/bin/msgfmt
>> /usr/local/bin/xgettext: error while loading shared libraries:
>> libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
>> file or directory
>> /usr/local/bin/msgmerge: error while loading shared libraries:
>> libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
>> file or directory
>> /usr/local/bin/msgfmt: error while loading shared libraries:
>> libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
>> file or directory
>> configure: error: GNU gettext tools not found; required for intltool
>>
>> However, I have verified that the file does in fact exist and is
>> located in /usr/local/lib.  I tried adding '-L/usr/local/lib' to the
>> LDFLAGS variable, but no change.  Is it an issue with needing to be a
>> newer version or something?
>>
>
> So it appears that the binaries were looking for the lib in /lib,
> although they were actually in /usr/local/lib.  A few symlinks
> corrected that issue.  However, I have no run into another issue:
>
> checking for qemu-system-x86_64... no
> checking for /usr/share/qemu/bios-ovmf.bin... no
> checking for /usr/share/qemu-ovmf/bios.bin... no
> checking that generated files are newer than configure... done
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: error: cannot find input file: `po/Makefile.in.in'
>
> Checking the config.log says:
>
> ## -- ##
> ## Running config.status. ##
> ## -- ##
>
> This file was extended by systemd config.status 234, which was
> generated by GNU Autoconf 2.69.  Invocation command line was
>
>   CONFIG_FILES=
>   CONFIG_HEADERS  =
>   CONFIG_LINKS=
>   CONFIG_COMMANDS =
>   $ ./config.status
>
> on b46de142dd54
>
> config.status:1555: creating Makefile
> config.status:1541: error: cannot find input file: `po/Makefile.in.in'
>
>
> I have installed glib2-dev and gettext-dev and intltool which each has
> a Makefile.in.in file:
>
> /usr/local/share/gettext/po/Makefile.in.in
> /usr/local/share/glib-2.0/gettext/po/Makefile.in.in
> /usr/local/share/intltool/Makefile.in.in
>
> It doesn't appear to be the last one since the file isn't located in
> the 'po' directory.  Any thoughts?
>
> Thanks,
> Dave
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev

[David Henderson]

On 10/26/17, David Henderson  wrote:
> So I am using the compile flags as suggested, however, I have noticed
> two errors.  I tried passing '--enable-static' to 'configure' and end
> up with:
>
> checking if libtool supports shared libraries... yes
> checking whether to build shared libraries... yes
> checking whether to build static libraries... yes
> configure: error: --enable-static is not supported by systemd
>
> Without it, I get passed that error in favor of another one:
>
> checking if libtool supports shared libraries... yes
> checking whether to build shared libraries... yes
> checking whether to build static libraries... no
> checking for intltool-merge... yes
> checking whether NLS is requested... yes
> checking for intltool >= 0.40.0... 0.51.0 found
> checking for intltool-update... /usr/local/bin/intltool-update
> checking for intltool-merge... /usr/local/bin/intltool-merge
> checking for intltool-extract... /usr/local/bin/intltool-extract
> checking for xgettext... /usr/local/bin/xgettext
> checking for msgmerge... /usr/local/bin/msgmerge
> checking for msgfmt... /usr/local/bin/msgfmt
> checking for gmsgfmt... /usr/local/bin/msgfmt
> /usr/local/bin/xgettext: error while loading shared libraries:
> libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
> file or directory
> /usr/local/bin/msgmerge: error while loading shared libraries:
> libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
> file or directory
> /usr/local/bin/msgfmt: error while loading shared libraries:
> libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
> file or directory
> configure: error: GNU gettext tools not found; required for intltool
>
> However, I have verified that the file does in fact exist and is
> located in /usr/local/lib.  I tried adding '-L/usr/local/lib' to the
> LDFLAGS variable, but no change.  Is it an issue with needing to be a
> newer version or something?
>

So it appears that the binaries were looking for the lib in /lib,
although they were actually in /usr/local/lib.  A few symlinks
corrected that issue.  However, I have no run into another issue:

checking for qemu-system-x86_64... no
checking for /usr/share/qemu/bios-ovmf.bin... no
checking for /usr/share/qemu-ovmf/bios.bin... no
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: error: cannot find input file: `po/Makefile.in.in'

Checking the config.log says:

## -- ##
## Running config.status. ##
## -- ##

This file was extended by systemd config.status 234, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  CONFIG_FILES=
  CONFIG_HEADERS  =
  CONFIG_LINKS=
  CONFIG_COMMANDS =
  $ ./config.status

on b46de142dd54

config.status:1555: creating Makefile
config.status:1541: error: cannot find input file: `po/Makefile.in.in'


I have installed glib2-dev and gettext-dev and intltool which each has
a Makefile.in.in file:

/usr/local/share/gettext/po/Makefile.in.in
/usr/local/share/glib-2.0/gettext/po/Makefile.in.in
/usr/local/share/intltool/Makefile.in.in

It doesn't appear to be the last one since the file isn't located in
the 'po' directory.  Any thoughts?

Thanks,
Dave
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev

[David Henderson]

So I am using the compile flags as suggested, however, I have noticed
two errors.  I tried passing '--enable-static' to 'configure' and end
up with:

checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: error: --enable-static is not supported by systemd

Without it, I get passed that error in favor of another one:

checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for intltool-merge... yes
checking whether NLS is requested... yes
checking for intltool >= 0.40.0... 0.51.0 found
checking for intltool-update... /usr/local/bin/intltool-update
checking for intltool-merge... /usr/local/bin/intltool-merge
checking for intltool-extract... /usr/local/bin/intltool-extract
checking for xgettext... /usr/local/bin/xgettext
checking for msgmerge... /usr/local/bin/msgmerge
checking for msgfmt... /usr/local/bin/msgfmt
checking for gmsgfmt... /usr/local/bin/msgfmt
/usr/local/bin/xgettext: error while loading shared libraries:
libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
file or directory
/usr/local/bin/msgmerge: error while loading shared libraries:
libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
file or directory
/usr/local/bin/msgfmt: error while loading shared libraries:
libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
file or directory
configure: error: GNU gettext tools not found; required for intltool

However, I have verified that the file does in fact exist and is
located in /usr/local/lib.  I tried adding '-L/usr/local/lib' to the
LDFLAGS variable, but no change.  Is it an issue with needing to be a
newer version or something?

Thanks,
Dave
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel