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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [systemd-devel] udev

[David Henderson]

On 10/26/17, Mantas Mikulėnas  wrote:
> On Thu, Oct 26, 2017, 18:26 David Henderson 
> wrote:
>
>> Good afternoon all!  I have been looking for the udev source code to
>> compile the library and utilities and it appears it is bundled in the
>> systemd software.  I have run autoreconf to generate a configure
>> script (using version 233 since I don't have meson), but could not see
>> a way to just compile this software.  How do I accomplish this?
>>
>
> You could run `make systemd-udevd libudev.so`.
>
> I'm not sure how to package just udevd. Maybe take a look at how distros
> like Gentoo achieve this.
>
> Note that sooner or later you *will* need to install meson. The overall
> process will be similar though, with `ninja` also accepting individual
> targets to build.
>

Thanks for the tip Mantas!  So I suppose there is no 'make install
udevd libudev' style syntax to handle that aspect.  If not, no
worries.  I am creating a profile for a software builder I made that
can handle the installation of those files otherwise.

Currently I am building a software repository for a Linux distro I
have built (XiniX) that started as a fork of another distro, but their
own repo is a disaster.  Neither theirs nor mine has the meson
builder.  IIRC, I think I briefly looked at creating a package for it,
but ran into issues.  I'm sure you are aware that rebuilding a repo
from scratch is no small feat so I moved on to others since it does
not appear that a lot of software uses it.  I do have plans to add it
at some point, but in the instances that a software project does use
it, typically the prior version from the most current does not use it
(which is what I end up using).

Although I need to upload the latest version, if you're interested,
the builder can be found at:
https://sourceforge.net/projects/software-builder/?source=directory

XiniX OS:
https://sourceforge.net/projects/xinix/?source=navbar

Info about the repo:
https://forums.cliquesoft.org/index.php?topic=31.0

Thanks again for your help!
Dave
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev

[David Henderson]

lol thanks for the links Mike!  Using the build system I developed, I
more or less have hooks to external scripts that can be called to
perform various tasks during the build process.  Once I get the
profile built, I can give it to you if you are interested to see how
it works.  Compiling is as simple as:

builder -n udev -a i64

Dave


On 10/26/17, Mike Gilbert  wrote:
> On Thu, Oct 26, 2017 at 11:45 AM, Mantas Mikulėnas 
> wrote:
>> On Thu, Oct 26, 2017, 18:26 David Henderson 
>> wrote:
>>>
>>> Good afternoon all!  I have been looking for the udev source code to
>>> compile the library and utilities and it appears it is bundled in the
>>> systemd software.  I have run autoreconf to generate a configure
>>> script (using version 233 since I don't have meson), but could not see
>>> a way to just compile this software.  How do I accomplish this?
>>
>>
>> You could run `make systemd-udevd libudev.so`.
>>
>> I'm not sure how to package just udevd. Maybe take a look at how distros
>> like Gentoo achieve this.
>
> For reference:
>
> https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-fs/udev/udev-233.ebuild?id=2f9f0fbb62866409b8ae0252a2b280d148dd9d73
>
> It's pretty ugly. We build around a dozen targets, and (ab)use
> automake install targets to selectively install bits and pieces. See
> the multilib_src_compile and multilib_src_install functions.
>
> Here's the meson version, for comparison. It's still pretty ugly, and
> we have to install things manually since there are no partial install
> targets.
>
> https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-fs/udev/udev-235.ebuild?id=2f9f0fbb62866409b8ae0252a2b280d148dd9d73
>
> Anyway, if you have any questions, feel free to ping me (floppym) on
> Freenode.
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev

[Mike Gilbert]

On Thu, Oct 26, 2017 at 11:45 AM, Mantas Mikulėnas  wrote:
> On Thu, Oct 26, 2017, 18:26 David Henderson 
> wrote:
>>
>> Good afternoon all!  I have been looking for the udev source code to
>> compile the library and utilities and it appears it is bundled in the
>> systemd software.  I have run autoreconf to generate a configure
>> script (using version 233 since I don't have meson), but could not see
>> a way to just compile this software.  How do I accomplish this?
>
>
> You could run `make systemd-udevd libudev.so`.
>
> I'm not sure how to package just udevd. Maybe take a look at how distros
> like Gentoo achieve this.

For reference:

https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-fs/udev/udev-233.ebuild?id=2f9f0fbb62866409b8ae0252a2b280d148dd9d73

It's pretty ugly. We build around a dozen targets, and (ab)use
automake install targets to selectively install bits and pieces. See
the multilib_src_compile and multilib_src_install functions.

Here's the meson version, for comparison. It's still pretty ugly, and
we have to install things manually since there are no partial install
targets.

https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-fs/udev/udev-235.ebuild?id=2f9f0fbb62866409b8ae0252a2b280d148dd9d73

Anyway, if you have any questions, feel free to ping me (floppym) on Freenode.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev

[Mantas Mikulėnas]

On Thu, Oct 26, 2017, 18:26 David Henderson 
wrote:

> Good afternoon all!  I have been looking for the udev source code to
> compile the library and utilities and it appears it is bundled in the
> systemd software.  I have run autoreconf to generate a configure
> script (using version 233 since I don't have meson), but could not see
> a way to just compile this software.  How do I accomplish this?
>

You could run `make systemd-udevd libudev.so`.

I'm not sure how to package just udevd. Maybe take a look at how distros
like Gentoo achieve this.

Note that sooner or later you *will* need to install meson. The overall
process will be similar though, with `ninja` also accepting individual
targets to build.

> --

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

Re: [systemd-devel] udev hwdb add unknown button

[Lennart Poettering]

On Fri, 09.06.17 10:23, Floris (jkflo...@dds.nl) wrote:
1;4602;0c
> I have an older ASUS R2E UMPC[1], which has a couple of media buttons. One
> button isn't recognized and print:
> 
> asus_laptop: Unknown key 9a pressed
> 
> I tried to add this button with an udev hwdb rule in
> /etc/udev/hwdb.d/99-keyboard.hwdb
> 
> evdev:name:Asus Laptop extra buttons:dmi:bvn*:bvr*:bd*:svnASUS:pn*pvr*
>  KEYBOARD_KEY_95=keyboard <-- This one is added for testing 
> purposes
>  KEYBOARD_KEY_9a=screen
> 
> 
> after an udevadm update and trigger, udevadm info /dev/input/event5 reports
> the buttons:
> ...
> E: ID_PATH_TAG=platform-asus_laptop
> E: KEYBOARD_KEY_6b=f21<-- This one is a 
> default udev hwdb rule
> E: KEYBOARD_KEY_95=keybaord
> E: KEYBOARD_KEY_9a=screen
> E: LIBINPUT_DEVICE_GROUP=19/0/0/0:asus_laptop
> ...
> 
> So far everything works as expected, but evtest doesn't show the remap of
> the 9a key
> ...
> type 4 (EV_MSC), code 4 (MSC_SCAN), value 95
> type 1 (EV_KEY), code 374 (KEY_KEYBOARD), value 1 <-- This one is 
> modified
> as expected
> ...
> type 4 (EV_MSC), code 4 (MSC_SCAN), value 9a
> type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1  <-- Why isn't 
> this one
> modified?
> ...
> 
> Only after adding {KE_KEY, 0x9a, { KEY_SCREEN } }, to asus-laptop.c line 355
> [2] and rebuild the kernel module, I am able to remap and use the media
> button on the laptop.
> 
> Is this a flaw in the kernel module or in udev?

Not all input devices permit overriding the scancode mappings, and
maybe your laptop driver is one of them?

Other than that, the only thing I can suggest is checking whether
issuing the scancode redifinition ioctls directly without udev's
involvement works. Not sure which tool to use for that, but I am sure
there's one.

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 rule to mount ext4 with data=journal

[Pascal K]

To clear things up a bit:

I build a Image using Buildroot running Busybox on top. I have SystemVinit.

Is there something else commonly used out there? Otherwise I just create my
own daemon.

Best regards,
Pascal


Lennart Poettering  schrieb am Mi., 14. Juni 2017
um 11:23 Uhr:

> On Wed, 14.06.17 08:44, Pascal K (pascalkra...@gmail.com) wrote:
>
> > As I am on a embedded device I am trying to avoid the usage of systemd
> due
> > to serveral reasons.
>
> Not sure I follow the logic in the above, but if you don't want to use
> systemd, then you should probably run something else that can do most
> basic disk management for you.
>
> udev isn't really the right tool for the job.
>
> 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 rule to mount ext4 with data=journal

[Lennart Poettering]

On Wed, 14.06.17 08:44, Pascal K (pascalkra...@gmail.com) wrote:

> As I am on a embedded device I am trying to avoid the usage of systemd due
> to serveral reasons.

Not sure I follow the logic in the above, but if you don't want to use
systemd, then you should probably run something else that can do most
basic disk management for you.

udev isn't really the right tool for the job.

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 rule to mount ext4 with data=journal

[Michael Biebl]

2017-06-14 10:44 GMT+02:00 Pascal K :
> As I am on a embedded device I am trying to avoid the usage of systemd due
> to serveral reasons.

Does that mean you are not using systemd as PID 1?

-- 
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 rule to mount ext4 with data=journal

[Pascal K]

As I am on a embedded device I am trying to avoid the usage of systemd due
to serveral reasons.

@Lennart

I try to follow your point:

> Note that we run udevd in its own mount namespace through MountFlags=,
> and this means no mounts will ever appear on the host anyway.

Am I right that this means that with setting ENV{mount_options} I am
setting a variable from udevd namespace, therefore "...mount -o
%E{mount_options}..." should try to run /sbin/mount with the options I
selected before?

Best regards,
Pascal

Lennart Poettering  schrieb am Mi., 14. Juni 2017
um 10:30 Uhr:

> On Wed, 14.06.17 08:11, Pascal K (pascalkra...@gmail.com) wrote:
>
> > I try to achieve that regardless the device plugged to my embedded system
> > the mount will be in folder /media/"name_of_volume".
> >
> > If I understand correctly for the usage of fstab I have to give a static
> > name for the mount point.
>
> It appears to me "systemd-mount" is the functionality you want to use
> for this. It will automatically derive a usable name from the device
> metadata and install an automount instance for it, so that there's the
> best chance for the device's file system to always stay in a clean state.
>
> You can invoke systemd-mount directly from the udev rule.
>
> 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 rule to mount ext4 with data=journal

[Lennart Poettering]

On Wed, 14.06.17 08:11, Pascal K (pascalkra...@gmail.com) wrote:

> I try to achieve that regardless the device plugged to my embedded system
> the mount will be in folder /media/"name_of_volume".
> 
> If I understand correctly for the usage of fstab I have to give a static
> name for the mount point.

It appears to me "systemd-mount" is the functionality you want to use
for this. It will automatically derive a usable name from the device
metadata and install an automount instance for it, so that there's the
best chance for the device's file system to always stay in a clean state.

You can invoke systemd-mount directly from the udev rule.

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 rule to mount ext4 with data=journal

[Lennart Poettering]

On Wed, 14.06.17 07:30, Pascal K (pascalkra...@gmail.com) wrote:

> Hello everyone,
> 
> I am new to this list and to udev (used mdev before).
> 
> My goal: Mount a CFast card partioned with 2 partitions one FAT32 and one
> EXT4, the EXT4 I would like to mount with option "data=journal"
> 
> The Problem: from the console using mount the partition can be mounted with
> mount -o "data=journal" ... but not from my udev rule. My rule results in
> only the FAT32 partition being mounted.

Note that we run udevd in its own mount namespace through MountFlags=,
and this means no mounts will ever appear on the host anyway.

Note that it is sufficient to mark mounts as "auto,nofail" in
/etc/fstab to make sure they are mounted automatically as they appear
without making the boot wait for it.

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 rule to mount ext4 with data=journal

[Pascal K]

I try to achieve that regardless the device plugged to my embedded system
the mount will be in folder /media/"name_of_volume".

If I understand correctly for the usage of fstab I have to give a static
name for the mount point.

Thanks for pointing out the "nofail" option.

Best regards,
Pascal


Lennart Poettering  schrieb am Mi., 14. Juni 2017
um 10:06 Uhr:

> On Wed, 14.06.17 07:30, Pascal K (pascalkra...@gmail.com) wrote:
>
> > Hello everyone,
> >
> > I am new to this list and to udev (used mdev before).
> >
> > My goal: Mount a CFast card partioned with 2 partitions one FAT32 and one
> > EXT4, the EXT4 I would like to mount with option "data=journal"
> >
> > The Problem: from the console using mount the partition can be mounted
> with
> > mount -o "data=journal" ... but not from my udev rule. My rule results in
> > only the FAT32 partition being mounted.
>
> Note that we run udevd in its own mount namespace through MountFlags=,
> and this means no mounts will ever appear on the host anyway.
>
> Note that it is sufficient to mark mounts as "auto,nofail" in
> /etc/fstab to make sure they are mounted automatically as they appear
> without making the boot wait for it.
>
> 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 rule to mount ext4 with data=journal

[Michał Zegan]

Hmm, why not to place such things in /etc/fstab?

W dniu 14.06.2017 o 09:30, Pascal K pisze:
> Hello everyone, 
> 
> I am new to this list and to udev (used mdev before). 
> 
> My goal: Mount a CFast card partioned with 2 partitions one FAT32 and
> one EXT4, the EXT4 I would like to mount with option "data=journal"
> 
> The Problem: from the console using mount the partition can be mounted
> with mount -o "data=journal" ... but not from my udev rule. My rule
> results in only the FAT32 partition being mounted. 
> 
> My Rule: 
> 
> KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end"  
> # Import FS infos  
> IMPORT{program}="/sbin/blkid -o udev -p %N"  
> 
> # Global mount options  
> ACTION=="add", ENV{mount_options}="relatime"  
> 
> # Filesystem-specific mount options  
> ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs",
> ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"
> ACTION=="add", ENV{ID_FS_TYPE}=="ext4",
> ENV{mount_options}="$env{mount_options},data=journal" 
> 
> #Mount the Filesystems
> ACTION=="add", RUN+="/bin/mkdir -p /media/$env{ID_FS_LABEL}",
> RUN+="/bin/mount -o %E{mount_options} /dev/%k /media/$env{ID_FS_LABEL}" 
> 
> # Exit  
> LABEL="media_by_label_auto_mount_end"
> 
> Any help is highly appreciated, so far I can only mount with
> "data=ordered" since this seems to be the default option (for that the
> two lines matching "ENV{ID_FS_TYPE} are removed). 
> 
> Best regards
> Pascal
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev - ignore/hide persistent storage

[Lennart Poettering]

On Fri, 31.03.17 11:30, lejeczek (pelj...@yahoo.co.uk) wrote:

> > > sorry guys to bother you, but
> > >   I'll see myself going slowly mad next week, for I've been reading and
> > > tryingand trying..
> > > 
> > > and I fail to tell udev to ignore a device and not to create symlinks.
> > > I need someone to 100% confirm this should work in v.219.
> > > The way Ithink(or hope) it should work islike:
> > > 
> > > ENV{ID_SERIAL}=="c50033d225e1", ENV{UDISKS_IGNORE}="1"
> > udisks is not involved with creating device symlinks, that's all done
> > by udev itself.
> > 
> > To disable the persistent symlinks it shuld be sufficient to set the
> > UDEV_DISABLE_PERSISTENT_STORAGE_RULES_FLAG udev property early enough
> > in the rules, this then has the effect that
> > 60-persistent-storage.rules is skipped.
>
> apologies, there is quite a few webpages talking explicitly about udisk,
> take just that ENV I mentioned alone, plenty of docs suggesting above, so I
> thought..
> Is it just fedora/rhel do without udisk or those docs/posts with udisk are
> obsolete all together?
> thanks.

udisks is responsible for mounting file systems, but it isn't
responsible for creating device node symlinks

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 - ignore/hide persistent storage

[lejeczek]

On 31/03/17 08:00, Lennart Poettering wrote:

On Thu, 30.03.17 21:40, lejeczek (pelj...@yahoo.co.uk) wrote:


sorry guys to bother you, but
  I'll see myself going slowly mad next week, for I've been reading and
tryingand trying..

and I fail to tell udev to ignore a device and not to create symlinks.
I need someone to 100% confirm this should work in v.219.
The way Ithink(or hope) it should work islike:

ENV{ID_SERIAL}=="c50033d225e1", ENV{UDISKS_IGNORE}="1"

udisks is not involved with creating device symlinks, that's all done
by udev itself.

To disable the persistent symlinks it shuld be sufficient to set the
UDEV_DISABLE_PERSISTENT_STORAGE_RULES_FLAG udev property early enough
in the rules, this then has the effect that
60-persistent-storage.rules is skipped.

Lennart

apologies, there is quite a few webpages talking explicitly 
about udisk, take just that ENV I mentioned alone, plenty of 
docs suggesting above, so I thought..
Is it just fedora/rhel do without udisk or those docs/posts 
with udisk are obsolete all together?

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

Re: [systemd-devel] udev - ignore/hide persistent storage

[Lennart Poettering]

On Thu, 30.03.17 21:40, lejeczek (pelj...@yahoo.co.uk) wrote:

> sorry guys to bother you, but
>  I'll see myself going slowly mad next week, for I've been reading and
> tryingand trying..
> 
> and I fail to tell udev to ignore a device and not to create symlinks.
> I need someone to 100% confirm this should work in v.219.
> The way Ithink(or hope) it should work islike:
> 
> ENV{ID_SERIAL}=="c50033d225e1", ENV{UDISKS_IGNORE}="1"

udisks is not involved with creating device symlinks, that's all done
by udev itself.

To disable the persistent symlinks it shuld be sufficient to set the
UDEV_DISABLE_PERSISTENT_STORAGE_RULES_FLAG udev property early enough
in the rules, this then has the effect that
60-persistent-storage.rules is skipped.

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 virtio by-path naming

[Viktor Mihajlovski]

On 01.03.2017 20:23, Viktor Mihajlovski wrote:
> On 01.03.2017 19:44, Daniel P. Berrange wrote:
> [...]
> replying on the list, a bit lengthy
>>
>> Ok, my guest has 4 disks
>>
>>  - sda - virtio-scsi, over virtio-pci transport
>>  - sdb - virtio-scsi, over virtio-mmio transport
>>  - vda - virtio-scsi, over virtio-pci transport
>>  - vdb - virtio-scsi, over virtio-mmio transport
>>
>> with systemd 231 I get these links
>>
>>   
>> platform-3f00.pcie-pci-:00:01.1-virtio-pci-:02:00.0-scsi-0:0:0:0 
>> -> ../../sda
>>   platform-3f00.pcie-pci-:00:01.3-virtio-pci-:04:00.0 -> 
>> ../../vda
> this is somewhat suprising (the pcie-pci- part), could you once more
> do me a favor and run
>  udevadm info -a /dev/vda
> and paste the output?
nevermind, I think I get it now, the PCI bus is a child to the platform
bus, and the virtio PCI functions are connected via PCI bridges
:00:01.1 and :00:01.3
>>   virtio-pci-a003c00.virtio_mmio -> ../../vdb
>>   virtio-pci-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb
>>
>> after applying your patch I get these links:
>>
>>  
>> platform-3f00.pcie-pci-:00:01.1-virtio-pci-:02:00.0-scsi-0:0:0:0 
>> -> ../../sda
>>  platform-3f00.pcie-pci-:00:01.3-virtio-pci-:04:00.0 -> ../../vda
> well, these are probably stale links from the old systemd baked into
> your initrd
>>  platform-3f00.pcie-pci-:02:00.0-scsi-0:0:0:0 -> ../../sda
>>  platform-3f00.pcie-pci-:04:00.0 -> ../../vda
> I don't yet understand these, especially why the intermediate pci-
> id has vanished
that is then correct as well, because the PCI bridges don't contribute
to the path id, which is a bonus effect of removing the special virtio
handling
I think we're good with the patch as is.
[...]
-- 

Mit freundlichen Grüßen/Kind Regards
   Viktor Mihajlovski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

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

Re: [systemd-devel] udev virtio by-path naming

[Viktor Mihajlovski]

On 01.03.2017 19:44, Daniel P. Berrange wrote:
[...]
replying on the list, a bit lengthy
> 
> Ok, my guest has 4 disks
> 
>  - sda - virtio-scsi, over virtio-pci transport
>  - sdb - virtio-scsi, over virtio-mmio transport
>  - vda - virtio-scsi, over virtio-pci transport
>  - vdb - virtio-scsi, over virtio-mmio transport
> 
> with systemd 231 I get these links
> 
>   
> platform-3f00.pcie-pci-:00:01.1-virtio-pci-:02:00.0-scsi-0:0:0:0 
> -> ../../sda
>   platform-3f00.pcie-pci-:00:01.3-virtio-pci-:04:00.0 -> ../../vda
this is somewhat suprising (the pcie-pci- part), could you once more
do me a favor and run
 udevadm info -a /dev/vda
and paste the output?
>   virtio-pci-a003c00.virtio_mmio -> ../../vdb
>   virtio-pci-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb
> 
> after applying your patch I get these links:
> 
>  platform-3f00.pcie-pci-:00:01.1-virtio-pci-:02:00.0-scsi-0:0:0:0 
> -> ../../sda
>  platform-3f00.pcie-pci-:00:01.3-virtio-pci-:04:00.0 -> ../../vda
well, these are probably stale links from the old systemd baked into
your initrd
>  platform-3f00.pcie-pci-:02:00.0-scsi-0:0:0:0 -> ../../sda
>  platform-3f00.pcie-pci-:04:00.0 -> ../../vda
I don't yet understand these, especially why the intermediate pci-
id has vanished
>  platform-a003c00.virtio_mmio -> ../../vdb
>  platform-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb
these look as expected
>  virtio-pci-a003c00.virtio_mmio -> ../../vdb
>  virtio-pci-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb
stale
> 
> So that appears to be working as designed - the 4 backcompat symlinks are
> still there, and the new symlinks all live under the platform- prefix
> and don't have a bogus 'pci' in the name for mmio links
the patch only provide compat symlinks for the pci path ids
traditionally seen on x86 systems, but I think we don't want those for
platforms other than x86, right?
> 
> Regards,
> Daniel
> 


-- 

Mit freundlichen Grüßen/Kind Regards
   Viktor Mihajlovski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

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

Re: [systemd-devel] udev virtio by-path naming

[Daniel P. Berrange]

On Wed, Mar 01, 2017 at 07:28:46PM +0100, Viktor Mihajlovski wrote:
> On 01.03.2017 16:58, Daniel P. Berrange wrote:
> > given a basic Fedora 25 guest, with a virtio-mmio disk added as per the
> > guide above...
> > 
> >   looking at device 
> > '/devices/platform/a003e00.virtio_mmio/virtio3/block/vda':
> > KERNEL=="vda"
> > SUBSYSTEM=="block"
> > DRIVER==""
> > ATTR{alignment_offset}=="0"
> > ATTR{badblocks}==""
> > ATTR{cache_type}=="write back"
> > ATTR{capability}=="50"
> > ATTR{discard_alignment}=="0"
> > ATTR{ext_range}=="256"
> > ATTR{inflight}=="   00"
> > ATTR{range}=="16"
> > ATTR{removable}=="0"
> > ATTR{ro}=="0"
> > ATTR{serial}==""
> > ATTR{size}=="2097152"
> > ATTR{stat}=="  940 4208  28500  
> >   0 
> >00  100  280"
> > 
> >   looking at parent device '/devices/platform/a003e00.virtio_mmio/virtio3':
> > KERNELS=="virtio3"
> > SUBSYSTEMS=="virtio"
> > DRIVERS=="virtio_blk"
> > ATTRS{device}=="0x0002"
> > 
> > ATTRS{features}=="00101011011111
> > 00"
> > ATTRS{status}=="0x0007"
> > ATTRS{vendor}=="0x554d4551"
> > 
> >   looking at parent device '/devices/platform/a003e00.virtio_mmio':
> > KERNELS=="a003e00.virtio_mmio"
> > SUBSYSTEMS=="platform"
> > DRIVERS=="virtio-mmio"
> > ATTRS{driver_override}=="(null)"
> Since I can't do that on my box, would you be so kind to run
>  ls -l /dev/disk/by-path
> If it returns ids like
>   virtio-pci-a003e00.virtio_mmio[-partn]
> my suggested patch should be OK for ARM in that it will produce ids in
> the format
>   platform-a003e00.virtio_mmio[-partn]

Ok, my guest has 4 disks

 - sda - virtio-scsi, over virtio-pci transport
 - sdb - virtio-scsi, over virtio-mmio transport
 - vda - virtio-scsi, over virtio-pci transport
 - vdb - virtio-scsi, over virtio-mmio transport

with systemd 231 I get these links

  platform-3f00.pcie-pci-:00:01.1-virtio-pci-:02:00.0-scsi-0:0:0:0 
-> ../../sda
  platform-3f00.pcie-pci-:00:01.3-virtio-pci-:04:00.0 -> ../../vda
  virtio-pci-a003c00.virtio_mmio -> ../../vdb
  virtio-pci-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb

after applying your patch I get these links:

 platform-3f00.pcie-pci-:00:01.1-virtio-pci-:02:00.0-scsi-0:0:0:0 
-> ../../sda
 platform-3f00.pcie-pci-:00:01.3-virtio-pci-:04:00.0 -> ../../vda
 platform-3f00.pcie-pci-:02:00.0-scsi-0:0:0:0 -> ../../sda
 platform-3f00.pcie-pci-:04:00.0 -> ../../vda
 platform-a003c00.virtio_mmio -> ../../vdb
 platform-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb
 virtio-pci-a003c00.virtio_mmio -> ../../vdb
 virtio-pci-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb

So that appears to be working as designed - the 4 backcompat symlinks are
still there, and the new symlinks all live under the platform- prefix
and don't have a bogus 'pci' in the name for mmio links

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev virtio by-path naming

[Viktor Mihajlovski]

On 01.03.2017 16:58, Daniel P. Berrange wrote:
> On Wed, Mar 01, 2017 at 04:02:53PM +0100, Viktor Mihajlovski wrote:
>> On 01.03.2017 04:30, Zbigniew Jędrzejewski-Szmek wrote:
>>> On Tue, Feb 28, 2017 at 09:47:42AM +0100, Viktor Mihajlovski wrote:
 One could argue about back-level compatibility, but virtio by-path
 naming has changed multiple times. We have seen virtio-pci-virtio
 (not predictable), pci- and virtio-pci- already. It
 might be a good time now to settle on a common approach for all
 virtio types.

 For the reasons above, I'd vote for -, which
 would work for PCI and CCW, not sure about ARM MMIO though.
>>>
>>> It seems that there's agreement that - is the right
>>> approach.
>>>
>>> Ideally we would keep the virtio-pci- links as they appear
>>> right now, for backwards compatibility, just for the pci devices, and
>>> mark them as deprecated (dunno where, maybe just in NEWS), and add the
>>> code to make the links.
>>>
>>> I haven't looked at the code, maybe we just do this with the right
>>> udev rule, and also stick the deprecation comment there?
>>>
>>> Zbyszek
>>>
>> I've posted a github pull request [1], and would appreciate review
>> feedback. As I am lacking an ARM setup, it would also be nice if someone
>> with ARM skills could have a look as well.
> 
> FYI you can install ARM7 guests on an x86_64 host, using pre-built Fedora
> images
> 
>   https://fedoraproject.org/wiki/QA:Testcase_Virt_ARM_on_x86
> 
> NB, this will install the guest using virtio-pci. So if you want to
> see virtio-mmio in action, you'll need to edit the libvirt XML config
> afterwards to add another disk, eg
> 
> 
>   
>   
>   
>   
> 
> 
> 
I might be stuck with a too old QEMU binary, the guest panics as soon as
the virtio-mmio module is loaded. If I drop to the dracut debug shell I
can see at least a number of mmio address slots(?)
ranging from a00.virtio_mmio to a003e00.virtio_mmio.
>> If wanted, I can take a stab at virtio-mmio, but would need the output
>> of udevadm -a /dev/vda from a virtio-mmio system.
> 
> Presumably you mean 'udevadm info -a /dev/vda' ?  That reports the following,
yes, I always have to type the command twice :-(
> given a basic Fedora 25 guest, with a virtio-mmio disk added as per the
> guide above...
> 
>   looking at device '/devices/platform/a003e00.virtio_mmio/virtio3/block/vda':
> KERNEL=="vda"
> SUBSYSTEM=="block"
> DRIVER==""
> ATTR{alignment_offset}=="0"
> ATTR{badblocks}==""
> ATTR{cache_type}=="write back"
> ATTR{capability}=="50"
> ATTR{discard_alignment}=="0"
> ATTR{ext_range}=="256"
> ATTR{inflight}=="   00"
> ATTR{range}=="16"
> ATTR{removable}=="0"
> ATTR{ro}=="0"
> ATTR{serial}==""
> ATTR{size}=="2097152"
> ATTR{stat}=="  940 4208  28500
> 0 
>00  100  280"
> 
>   looking at parent device '/devices/platform/a003e00.virtio_mmio/virtio3':
> KERNELS=="virtio3"
> SUBSYSTEMS=="virtio"
> DRIVERS=="virtio_blk"
> ATTRS{device}=="0x0002"
> 
> ATTRS{features}=="00101011011111
> 00"
> ATTRS{status}=="0x0007"
> ATTRS{vendor}=="0x554d4551"
> 
>   looking at parent device '/devices/platform/a003e00.virtio_mmio':
> KERNELS=="a003e00.virtio_mmio"
> SUBSYSTEMS=="platform"
> DRIVERS=="virtio-mmio"
> ATTRS{driver_override}=="(null)"
Since I can't do that on my box, would you be so kind to run
 ls -l /dev/disk/by-path
If it returns ids like
  virtio-pci-a003e00.virtio_mmio[-partn]
my suggested patch should be OK for ARM in that it will produce ids in
the format
  platform-a003e00.virtio_mmio[-partn]
> 
>   looking at parent device '/devices/platform':
> KERNELS=="platform"
> SUBSYSTEMS==""
> DRIVERS==""
> 
> 
> 
> Regards,
> Daniel
> 


-- 

Mit freundlichen Grüßen/Kind Regards
   Viktor Mihajlovski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

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

Re: [systemd-devel] udev virtio by-path naming

[Daniel P. Berrange]

On Wed, Mar 01, 2017 at 03:58:12PM +, Daniel P. Berrange wrote:
> On Wed, Mar 01, 2017 at 04:02:53PM +0100, Viktor Mihajlovski wrote:
> > If wanted, I can take a stab at virtio-mmio, but would need the output
> > of udevadm -a /dev/vda from a virtio-mmio system.
> 
> Presumably you mean 'udevadm info -a /dev/vda' ?  That reports the following,
> given a basic Fedora 25 guest, with a virtio-mmio disk added as per the
> guide above...
> 
>   looking at device '/devices/platform/a003e00.virtio_mmio/virtio3/block/vda':

BTW, the hex digits in here are the virtio mmio address which changes per
device eg if i have 3 virtio-mmio backed disks, I get

  looking at device '/devices/platform/a003a00.virtio_mmio/virtio3/block/vda':
  looking at device '/devices/platform/a003c00.virtio_mmio/virtio4/block/vdb':
  looking at device '/devices/platform/a003e00.virtio_mmio/virtio5/block/vdc':


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev virtio by-path naming

[Daniel P. Berrange]

On Wed, Mar 01, 2017 at 04:02:53PM +0100, Viktor Mihajlovski wrote:
> On 01.03.2017 04:30, Zbigniew Jędrzejewski-Szmek wrote:
> > On Tue, Feb 28, 2017 at 09:47:42AM +0100, Viktor Mihajlovski wrote:
> >> One could argue about back-level compatibility, but virtio by-path
> >> naming has changed multiple times. We have seen virtio-pci-virtio
> >> (not predictable), pci- and virtio-pci- already. It
> >> might be a good time now to settle on a common approach for all
> >> virtio types.
> >>
> >> For the reasons above, I'd vote for -, which
> >> would work for PCI and CCW, not sure about ARM MMIO though.
> > 
> > It seems that there's agreement that - is the right
> > approach.
> > 
> > Ideally we would keep the virtio-pci- links as they appear
> > right now, for backwards compatibility, just for the pci devices, and
> > mark them as deprecated (dunno where, maybe just in NEWS), and add the
> > code to make the links.
> > 
> > I haven't looked at the code, maybe we just do this with the right
> > udev rule, and also stick the deprecation comment there?
> > 
> > Zbyszek
> > 
> I've posted a github pull request [1], and would appreciate review
> feedback. As I am lacking an ARM setup, it would also be nice if someone
> with ARM skills could have a look as well.

FYI you can install ARM7 guests on an x86_64 host, using pre-built Fedora
images

  https://fedoraproject.org/wiki/QA:Testcase_Virt_ARM_on_x86

NB, this will install the guest using virtio-pci. So if you want to
see virtio-mmio in action, you'll need to edit the libvirt XML config
afterwards to add another disk, eg


  
  
  
  



> If wanted, I can take a stab at virtio-mmio, but would need the output
> of udevadm -a /dev/vda from a virtio-mmio system.

Presumably you mean 'udevadm info -a /dev/vda' ?  That reports the following,
given a basic Fedora 25 guest, with a virtio-mmio disk added as per the
guide above...

  looking at device '/devices/platform/a003e00.virtio_mmio/virtio3/block/vda':
KERNEL=="vda"
SUBSYSTEM=="block"
DRIVER==""
ATTR{alignment_offset}=="0"
ATTR{badblocks}==""
ATTR{cache_type}=="write back"
ATTR{capability}=="50"
ATTR{discard_alignment}=="0"
ATTR{ext_range}=="256"
ATTR{inflight}=="   00"
ATTR{range}=="16"
ATTR{removable}=="0"
ATTR{ro}=="0"
ATTR{serial}==""
ATTR{size}=="2097152"
ATTR{stat}=="  940 4208  285000 
   00  100  280"

  looking at parent device '/devices/platform/a003e00.virtio_mmio/virtio3':
KERNELS=="virtio3"
SUBSYSTEMS=="virtio"
DRIVERS=="virtio_blk"
ATTRS{device}=="0x0002"
ATTRS{features}=="00101011011111
00"
ATTRS{status}=="0x0007"
ATTRS{vendor}=="0x554d4551"

  looking at parent device '/devices/platform/a003e00.virtio_mmio':
KERNELS=="a003e00.virtio_mmio"
SUBSYSTEMS=="platform"
DRIVERS=="virtio-mmio"
ATTRS{driver_override}=="(null)"

  looking at parent device '/devices/platform':
KERNELS=="platform"
SUBSYSTEMS==""
DRIVERS==""



Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev virtio by-path naming

[Viktor Mihajlovski]

On 01.03.2017 04:30, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Feb 28, 2017 at 09:47:42AM +0100, Viktor Mihajlovski wrote:
>> One could argue about back-level compatibility, but virtio by-path
>> naming has changed multiple times. We have seen virtio-pci-virtio
>> (not predictable), pci- and virtio-pci- already. It
>> might be a good time now to settle on a common approach for all
>> virtio types.
>>
>> For the reasons above, I'd vote for -, which
>> would work for PCI and CCW, not sure about ARM MMIO though.
> 
> It seems that there's agreement that - is the right
> approach.
> 
> Ideally we would keep the virtio-pci- links as they appear
> right now, for backwards compatibility, just for the pci devices, and
> mark them as deprecated (dunno where, maybe just in NEWS), and add the
> code to make the links.
> 
> I haven't looked at the code, maybe we just do this with the right
> udev rule, and also stick the deprecation comment there?
> 
> Zbyszek
> 
I've posted a github pull request [1], and would appreciate review
feedback. As I am lacking an ARM setup, it would also be nice if someone
with ARM skills could have a look as well.
If wanted, I can take a stab at virtio-mmio, but would need the output
of udevadm -a /dev/vda from a virtio-mmio system.

[1] https://github.com/systemd/systemd/pull/5500

-- 

Mit freundlichen Grüßen/Kind Regards
   Viktor Mihajlovski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

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