Christoph Pleger | 26 Mar 11:04 2015

create /etc/udev/rules.d/70-persistent-net.rules


I hope that this is a right place fur udev questions.

My problem is that I need to create a file
/etc/udev/rules.d/70-persistent-net.rules on a PXE-Booted computer with an
NFS-Rootfilesystem. Unfortunately, that file ist not created automatically
at boot time, also "echo add > /sys/class/net/*/uevent" did not work,
though it did an another, disk-booted computer where I had deleted the
file before.

So, how can I create /etc/udev/rules.d/70-persistent-net.rules on a
netbooted computer, if possible without using tools like ifconfig, sed and


To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at>
More majordomo info at

Mr. Ibrahim | 25 Jan 10:19 2015

Re. Important.

Dear Donated Beneficiary,

You have been carefully selected as the sole beneficiary of the sum of 3,200.000.00 (USD)donated to you by
Mr. Ibrahim who Won the Euro Million Lottery 13th October 2014.

Kindly contact me for claims. Email: ibrahim <at>

Mr. Ibrahim.
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at>
More majordomo info at

hi | 3 Dec 19:49 2014


iphone 6,  380euro,
nous avons aussi samsung s5, seulement  260euro, ...
Si Te: assroooo. com
Rajib Karmakar | 2 Dec 14:46 2014

udev not renaming interface if driver is built-in


My ethernet driver was built as a module and once it was probed, I can
see that udev renames the interface. but when I try to have the
ethernet driver as built-in. the driver is probed but udev no longer
renames the interface.

Can you please help me in this?

Thanks in advance.

To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at>
More majordomo info at

Angelo Dureghello | 13 Oct 15:19 2014

Re: udev error, ENOEXEC

On 13/10/2014 15:10, Andrei Borzenkov wrote:
> On Mon, Oct 13, 2014 at 5:06 PM, Angelo Dureghello <angelo70 <at>> wrote:
>> Dear all,
>> i am running kernel 3.19.0,
> Are you sure?
Sry, 3.17.0.

I solved.

This kernel needs:



To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at>
More majordomo info at

Angelo Dureghello | 13 Oct 15:06 2014

udev error, ENOEXEC

Dear all,

i am running kernel 3.19.0, Init 2.88 and udev 182

At boot i get this automount error:

VFS: Mounted root (ubifs filesystem) on device 0:14.
devtmpfs: mounted
Freeing unused kernel memory: 152K (c05de000 - c0604000)
INIT: version 2.88 booting
Please wait: booting...
Populating /dev using udev: udevd[1070]: starting version 182
davinci_wdt: disagrees about version of symbol module_layout
Starting System Watchdog service: random: nonblocking pool is initialized
udevd[1088]: failed to execute '/lib/udev/automount' 'automount add 
mmcsd /dev/mmcblk0p1': Exec format error

Mounting configuration partition...
Checking that all configuration is in place...
Inserting all the extra modules...

Tried hardly to find informations over the day, but still can't get out.
After login, if i execute the same "automount" command not launched from 
udev but from command prompt), mount works.
Same rootfs image with old kernel 3.5.1 was also working.

(Continue reading)

Jiang Liu | 19 Sep 07:18 2014

[Patch Part3 V6 0/8] Enable support of Intel DMAR device hotplug

When hot plugging a descrete IOH or a physical processor with embedded
IIO, we need to handle DMAR(or IOMMU) unit in the PCIe host bridge if
DMAR is in use. This patch set tries to enhance current DMAR/IOMMU/IR
drivers to support hotplug and is based on latest Linus master branch.

All prerequisite patches to support DMAR device hotplug have been merged
into the mainstream kernel, and this is the last patch set to enable
DMAR device hotplug.

You may access the patch set at: iommu/hotplug_v6

This patch set has been tested on Intel development machine.
Appreciate any comments and tests.

1) Fix a race condition found during review
2) Refine dmar_walk_resources() to dmar_walk_remapping_entries()

Patch 1-4 enhances DMAR framework to support hotplug
Patch 5 enhances Intel interrupt remapping driver to support hotplug
Patch 6 enhances error handling in Intel IR driver
Patch 7 enhance Intel IOMMU to support hotplug
Patch 8 enhance ACPI pci_root driver to handle DMAR units

Jiang Liu (8):
  iommu/vt-d: Introduce helper function dmar_walk_resources()
  iommu/vt-d: Dynamically allocate and free seq_id for DMAR units
  iommu/vt-d: Implement DMAR unit hotplug framework
  iommu/vt-d: Search for ACPI _DSM method for DMAR hotplug
(Continue reading)

Brandon R Schwartz | 11 Sep 04:34 2014

Improper Naming in /dev/disk/by-id and Drives Offline


I'm working on a particular issue (possibly two separate issues) where
our HDDs are (1) getting mislabeled in /dev/disk/by-id and (2)
dropping offline even though drive and controller logs show that the
drive is communicating and working as expected.  I don't have much
knowledge on the udev side of things so it would be great if someone
could offer some insight into the way udev assigns device names and if
there are thoughts as to why the OS cannot see the drive in certain
cases (timing issue?).

The first issue, the mislabeling problem, is that on reboots or power
cycles we occasionally see our drives become mislabeled in
/dev/disk/by-id.  We expect to see something like:


But instead we see:


The "scsi" drive is assigned a drive letter and the OS can communicate
with the drive.  Drives logs and controller logs show the drive is
working properly, but for some reason it's getting labeled incorrectly
in /dev/disk/by-id.  We have looked through dmesg and enabled logging
in udev (udevadm control --log-priority=debug), but we have not seen
where these labels are coming from.

(Continue reading)

Patrick Hemmer | 16 Aug 01:46 2014

device symlinks being removed

It seems I have some sort of race condition when using udev rules to set
up some device symlinks, but I'm not sure why.
I'm building EC2 boxes, and immediately after they boot, they add some
udev rules to create symlinks, and then call `udevadm trigger` to
process the rules. The problem is that during this procedure, sometimes
some of the links are missing. The udev debug log indicates the links
were created, and then subsequently removed.

The complete system log can be viewed at
However I've grabbed what look like the interesting lines, and have
included them at the bottom. Notice the ones such as

    creating symlink '/dev/disk/ec2/vol-05b50706' to '../../xvda'


    update old name, '/dev/disk/ec2/vol-05b50706' no longer belonging to
    no reference left, remove '/dev/disk/ec2/vol-05b50706'

My udev rule looks like this:

    SUBSYSTEM=="block", SUBSYSTEMS=="xen", ATTR{capability}=="*",
ACTION=="add", PROGRAM="/ec2disks -A %k", SYMLINK+="%c"

My current process is:

    # create the file
    /bin/udevadm control --reload
    /bin/udevadm settle
(Continue reading)

Aniroop Mathur | 1 Aug 19:13 2014

[Question: Drivers/base/core.c] Why dev->init_name = NULL in device_add function ?

Dear Mr. Greg Kroah-Hartman and Linux Community,
Greetings of the day !! :)

I am Aniroop Mathur working on Linux Kernel for last two years.
I am stuck at one point and could not find the solution over internet.
I posted on too.
So I need your help and suggestion for it.

Can you please help in answering my query as below:

In function device_add of /drivers/base/core.c file, it is mentioned:
* for statically allocated devices, which should all be converted
* some day, we need to initialize the name. We prevent reading back
* the name, and force the use of dev_name()
if (dev->init_name) {
dev_set_name(dev, "%s", dev->init_name);
dev->init_name = NULL;

Except forcing the use of dev_name to read device name,
Is there any other reason to make init_name as NULL ?
And if it is not made NULL, is there any problem or side-effect ?


Link at
(Continue reading)

Sebastian Parschauer | 24 Jul 16:48 2014

udev 215 creates inactive MD devices upon stopping them


as discussed on linux-raid, please fix the bug that udev 215 creates
inactive MD devices upon stopping them.

Reported-by: Francis Moreau <francis.moro <at>>

An open() call to /dev/mdX after creating it with mknod is enough to
create such inactive MD device.

According to Artur the issue is caused by this change in udev:

> commit 3ebdb81ef088afd3b4c72b516beb5610f8c93a0d
> Author: Kay Sievers <kay at>
> Date:   Sun Apr 13 19:54:27 2014 -0700
>      udev: serialize/synchronize block device event handling with file locks
> It seems that they have already disabled this for dm for some reason,
> but not for md:
> commit e918a1b5a94f270186dca59156354acd2a596494
> Author: Kay Sievers <kay <at>>
> Date:   Tue Jun 3 16:49:38 2014 +0200
>     udev: exclude device-mapper from block device ownership event locking
(Continue reading)