# I hate udev

## Cyker

Summary: 1 - Udev missing /dev/disk/by-path; 2 - NIC renaming problem due to existing name

Intro:

Ahh, I haven't been here for a while so hey all! o/

I have been running a Gentoo system that hasn't been emerge --sync'd for nearly 3 years, but have gotten the itch again and recently built a new system to replace it, this time with 64 bits!! :O

However, one of the reasons I stopped updating my old system was specifically the constant changes in udev and that is biting me in the proverbial now; 

Problem:

1) In my old IDE+SATA system, I had a stable naming system based around the ports (HDA=PriMaster, HDB=PriSlav etc.); The SATAs were auto-mounting RAID so I didn't care about their assigned order.

As we know, you don't get this stable per-port naming with SATA, but while I was installing Gentoo using Knoppix, I noticed that Knoppix has /dev/disk/by-path which, while not perfect (so lengthy!), gives me what I want in terms of per-port assignment.

However, on finishing the chroot-stage of the Stage 3 install and rebooting, the /dev/disk-by-path stuff has disappeared.

I can see there is the persistent-storage rules in /lib/udev/rules.d which contain rules for /disk/by-path but they don't seem to be executing or something??

How can I get disk/by-path back; What am I missing?!

2) This is more annoying and I suspect it is a regression in udev; The FM2+ mobo I have has one NIC, which udev wants to name enp1s0 for some reason; I don't like this and so I added my own rules to /etc/udev/rules.d/10-mynet.rules to assign it eth0 based on its MAC address.

That was fine, but later I added a 4-port NIC and now that rule has stopped working and the onboard NIC gets named eth4!

After about 3 hours of prodding, I realised that the expansion NIC is being assigned eth[0-3] by the kernel, before my rules assign it eth1[a-d], and I suspect the fact that one of them has eth0 is blocking udev from renaming the onboard NIC to eth0.

The old udev on my old server auto-renamed any conflicting names to an alt or intermediate name, but it seems like this doesn't happen here.

Any suggestions how I can fix that here to get my eth0 back??

----------

## Hu

Interface renaming to use names that may be used by the kernel was sometimes racy, so the udev developers completely removed support for it and added a crazy alternate scheme, which is switched on by default.  This stunt has earned them quite a bit of dislike.  Read about "predictable network interface names" if you want the full story.

If you do not mind using other names, you can still use interface renaming.  You will need to use names that the kernel would never generate on its own.  If you prefer just to disable interface renaming, you can do that by following the instructions in the associated news item.  In short, add net.ifnames=0 to your kernel command line.  This will keep the names picked by the kernel.  Some systems have fully predictable name ordering when the kernel assigns names.  Some do not.

----------

## s4e8

1. ATA device by-path name disabled by newer udev.  You should switch to /dev/by-id/ata-<model> or /dev/by-id/wwn-<wwn>

2. compile addon driver as module

----------

## Cyker

I've been reading up on udev changes; Good grief, I thought things were supposed to become more able over time, not less!

It seems like they have been catering for potential edge-case problems at the expense of functionality  :Sad: 

What alternatives are there to udev? Or am I basically stuck with forced naming conventions now? I have stumbled across references to mdev and eudev but precious little information on differences/what they do...

The more I read about udev the more worried I am about its direction - It is supposed to be a highly cohesive core system but it has gotten so complex it needs access to things in /usr or it can make the system unbootable, but apparently this is considered not only okay, but desirable?!

Have I been away so long that it's been forgotten why there is a split between the /bin, /lib and /sbin in / and /usr??

----------

## mv

There was a lot of discussion about all this stuff, and I don't think we need a new one. Please look it up in the forums.

Just very briefly, eudev is a fork of udev with the aim of providing the stability you require.

Concerning your disk naming issue: If you use a file system which does support label (most linux fs do), I would suggest using label  and /dev/disk-by-label. There is even a LABEL=... syntax possible as a path in /etc/fstab. To get a defined root partition when booting the kernel, you can now pass PARTUUID=... to the kernel even on DOS partiitioned disks and without using a ramdisk.

----------

## khayyam

 *Cyker wrote:*   

> What alternatives are there to udev? Or am I basically stuck with forced naming conventions now? I have stumbled across references to mdev and eudev but precious little information on differences/what they do...

 

Cyker ... eudev is a fork of udev initiated by some gentoo devs, its a drop in replacement ... you should be able to unmerge udev and emerge eudev without issues. mdev is the busybox device manager, there are two methods of using/installing it, the first is via the 'mdev' useflag on sys-apps/busybox, and the second is via sys-apps/mdev-bb::foo-overlay and sys-fs/mdev-like-a-boss::foo-overlay, the latter comes with various 'helper' scripts (mdev-like-a-boss) and xorg-conf.d/ for use with x11-base/xorg-server[-udev]. There are some steps to install/setup mdev/mdev-bb as some packages (like xorg) need rebuilt, x11-drivers/xf86-input-evdev removed, INPUT_DEVICES changes (see: mdev-like-a-boss).

 *Cyker wrote:*   

> Have I been away so long that it's been forgotten why there is a split between the /bin, /lib and /sbin in / and /usr??

 

Apparently "this has been broken for a long time", and udev is just the messenger :)

best ... khay

----------

## Cyker

@mv - The thing is, I *want* to assign names based on what port the disk is plugged in; In the old days, I was told this was impossible with SATA because that information wasn't exposed, but I can see in dmesg that the kernel can see SATA ports 1-8, and can see which ports are populated so clearly the information is there.

The fact that disk/by-path/ existed means it is possible to do this - I do not understand why it has been removed, and don't really care - I want to know how to put it back in!!!

@khayyam - Thanks! Do you know of any others?

Also, some specific questions: From what I've read so far, eudev is basically udev without the systemd bits, but otherwise has all the same problems as udev (i.e. won't let me get disk by path, won't do 2-step renaming etc.) - Is that an accurate assessment?

With mdev, it seems very cut down; Does it still support things like custom rules for renaming device nodes etc.?

----------

## s4e8

A custom rule restore ata path-id:

file /etc/udev/rules/59-ata-path-id.rules:

```
KERNEL=="sd*[!0-9]", SUBSYSTEMS=="scsi",  ATTRS{vendor}=="ATA", IMPORT{program}="/usr/local/sbin/ata-path-id.pl"
```

file /usr/local/sbin/ata-path-id.pl:

```
#!/usr/bin/perl

print "ID_PATH=pci-$1-scsi-$2\n" if $ENV{DEVPATH} =~ m{/([^/]*)/ata.*/([^/]*)/block/sd[a-z]};
```

another /usr/local/sbin/ata-path-id.pl using name pci-<busid>-ata-<port>:

```
#!/usr/bin/perl

sub readfile($) {

        my $fn = shift;

        open FILE, "<$fn" or return undef;

        my $v = <FILE>;

        close FILE;

        chomp($v);

        return $v;

}

if($ENV{DEVPATH} =~ m{^(.*)/([^/]*)/(ata\d+)/.*/(\d+:(\d+):\d+:\d+)/block/sd[a-z]}) {

        my $dir="/sys$1/$2/$3/ata_port/$3";

        my $port = readfile("$dir/port_no");

        if($port ne '') {

                my $pmp = readfile("$dir/nr_pmp_links");

                if($pmp) {

                        print "ID_PATH=pci-$2-ata-$port:$5\n";

                } else {

                        print "ID_PATH=pci-$2-ata-$port\n";

                }

        } else {

                print "ID_PATH=pci-$2-scsi-$4\n";

        }

}
```

----------

## SamuliSuominen

 *khayyam wrote:*   

> 
> 
>  *Cyker wrote:*   Have I been away so long that it's been forgotten why there is a split between the /bin, /lib and /sbin in / and /usr?? 
> 
> Apparently "this has been broken for a long time", and udev is just the messenger 

 

That's nonsense. Both sys-fs/udev and sys-fs/eudev install to / and don't require anything from /usr.

It's the *other applications*, like bluez for bluetooth keyboards that live in /usr, and keymaps for sys-apps/kbd, and so forth.

----------

## khayyam

 *ssuominen wrote:*   

>  *khayyam wrote:*    *Cyker wrote:*   Have I been away so long that it's been forgotten why there is a split between the /bin, /lib and /sbin in / and /usr?? 
> 
> Apparently "this has been broken for a long time", and udev is just the messenger :) 
> 
> That's nonsense. Both sys-fs/udev and sys-fs/eudev install to / and don't require anything from /usr.

 

ssuominen ... I never said that udev installs to /usr, only that separate-usr-is-broken. I'm directly answering to the question posed. That document states that the seperation is "broken", and "systemd (sive udev) is meerly the messenger". So, if its "nonsense" then its someone elses nonsense.

best ... khay

----------

## SamuliSuominen

 *khayyam wrote:*   

>  *ssuominen wrote:*    *khayyam wrote:*    *Cyker wrote:*   Have I been away so long that it's been forgotten why there is a split between the /bin, /lib and /sbin in / and /usr?? 
> 
> Apparently "this has been broken for a long time", and udev is just the messenger  
> 
> That's nonsense. Both sys-fs/udev and sys-fs/eudev install to / and don't require anything from /usr. 
> ...

 

right, that applies only to systemd if used as an init system, never the systemd-udevd part of it (except if you install some 3rd party udev rules that call programs from /usr)

----------

## Cyker

Say, does anyone know what the last version of udev that supported /dev/disk/by-path and intermediate network device renaming is?

(And also if there is any reason that I shouldn't switch to it!)

I think rather than banging my head against a wall and attempting increasingly dodgy workarounds to restore lost functionality, just downgrading to a working version would be a better solution, aye?

Edit: What is the current popular thread for flaming about this /usr issue? I don't want to hijack my own thread  :Wink: 

----------

## SamuliSuominen

 *Cyker wrote:*   

> Say, does anyone know what the last version of udev that supported /dev/disk/by-path and intermediate network device renaming is?
> 
> (And also if there is any reason that I shouldn't switch to it!)
> 
> I think rather than banging my head against a wall and attempting increasingly dodgy workarounds to restore lost functionality, just downgrading to a working version would be a better solution, aye?
> ...

 

s4e8 already explained there was no functionality removal, only functionality renaming, that you should switch to /dev/by-id/ata-<model> or /dev/by-id/wwn-<wwn> 

last version of udev that supported intermediate network interface renaming (as in, USE="rule_generator") was sys-fs/udev-196 (which had number of other problems), not to mention the rule_generator was a loop hack to begin with that never worked correctly

for all systems

also separate /usr has been broken for about 10 years now, like for example sys-apps/kbd has installed it's keymaps always to /usr, like https://bugs.gentoo.org/show_bug.cgi?id=338082, it's just that people are rehashing this

ancient issue after reading http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/

the solution has been use of initramfs (or not using separate /usr to begin with) and council only confirmed it, even if they hadn't confirmed it, it wouldn't have automatically meant that separate /usr would have been a functional entity, far from it

so why not adapt to current features? you never said what's wrong with the current methods

----------

## Cyker

Thanks! I'll try that out and see how I get on  :Smile: 

What do you mean by no functionality removal? The by-id and by-wwn do not appear to be replacements for by-path, but merely variations on what by-label does (i.e. identify individual disk, not socket).

As for why not adapt, I guess it's for the same reasons I'm not using Windows Server or FreeBSD for this project - I like the familiar. Also, traditionally Linux and Gentoo in particular has been is about the freedom to choose and I like that; I've always had a resistance when pushed toward something I don't want.

I had been running the same Gentoo-based server for nearing a decade; It started off as a P200MMX and eventually became an Opteron 180. Throughout this time, the Gentoo install has been the same all the way through, just adapted to the new hardware, but the naming conventions, base-line device positions etc. have remained the same throughout.

I had to stop updating udev for that system a long time ago because it broke all that, but that was fine because I also stopped emerge --sync'ing because so much stuff was being broken.

Now, I had the itch for a newer system and wanted to go 64-bit. Now, AMD64 is a new platform, so I sadly can't just swap mobos and keep the old system like I have been doing, but I want to try and match things back as much as I can for the familiar and ease of use (Esp. when I start copying my 5TB /home over!!).

I really want to get the baseline system built 'just right', then I can start installing everything else.

As for /usr, it is not /usr that is broken, but people abusing /usr.

EVERYTHING the system needs to boot properly is SUPPOSED to go in /

/usr was originally for user data and programs, to be brought up once the system entered multiuser mode. For whatever reasons, user data was moved to /home, but the programs remained.

Now, this is not always possible due to the complexity and increasing layer-violations, but that is, ideally, how things should be.

If you're going to ignoring that separation, why have /usr at all? It is redundant! You may as well just stick everything in / !! Why not make like Windows and assume that the whole system is on a single drive partition? After all, /var is surely important for boot logs and there may be service-specific user dirs in /home and what if there is some proprietary driver module resources in /opt?

When I hear of e.g. /bin and /sbin being symlinked to /usr/[bin, sbin] it just shows a fundamental misunderstanding of why the layout is the way it is.

If you're going to do stuff like that, why follow this system at all?

There are surely better filesystem layouts we could use if you are going to break away from the traditional filesystem hierarchy.

I remember thinking the GoboLinux idea quite compelling, although not without issues.

I dunno, I just like things being a certain way. I don't consider myself a stick-in-the-mud, but making arbitrary changes to accommodate bad practice just seems like a slippery slope we should avoid...

----------

## Cyker

Woo!

Right, I was going to downgrade udev but I decided to try eudev instead and it seems to do what I need \o/

Left default useflags set and the network card renaming seems to be working again.

I have 'unpatched' the disk-by-path thing so it'll be interesting to see if that works.

On a side-note, it turns out there is a cool trick that's been kept quiet that allows you to patch ebuilds without copying them into an overlay. Dunno when it first appeared but it is a very cool trick  :Smile: 

I just had to make a .patch file containing this

```
--- eudev-1.5.3/src/udev/udev-builtin-path_id.c 2014-01-18 19:07:17.000000000 +0000

+++ eudev-1.5.3.patched/src/udev/udev-builtin-path_id.c 2014-07-16 23:57:17.361365294 +0100

@@ -385,12 +385,14 @@

          *

          * Until all that is solved at the kernel level, there are no by-path/

          * links for ATA devices.

-         */

+         *

         if (strstr(name, "/ata") != NULL) {

                 parent = NULL;

                 goto out;

         }

-

+       * BELAY THAT ORDER!

+       */

+

         if (strstr(name, "/vmbus_") != NULL) {

                 parent = handle_scsi_hyperv(parent, path);

                 goto out;

```

and save it into /etc/portage/patches/sys-fs/eudev/thingy.patch and it auto-patches when you "emerge eudev"!  :Very Happy: 

Awesome!  :Very Happy:   :Very Happy: 

----------

## khayyam

 *Cyker wrote:*   

> On a side-note, it turns out there is a cool trick that's been kept quiet that allows you to patch ebuilds without copying them into an overlay. Dunno when it first appeared but it is a very cool trick :)

 

Cyker ... that is 'epatch_user' it's available wherever 'inherit eutils' is in use.

best ... khay

----------

## SamuliSuominen

 *khayyam wrote:*   

>  *Cyker wrote:*   On a side-note, it turns out there is a cool trick that's been kept quiet that allows you to patch ebuilds without copying them into an overlay. Dunno when it first appeared but it is a very cool trick  
> 
> Cyker ... that is 'epatch_user' it's available wherever 'inherit eutils' is in use.
> 
> best ... khay

 

Not everywhere where 'inherit eutils' is in use, only where 'epatch_user' is defined in src_prepare() explicitely.

----------

## krinn

 *ssuominen wrote:*   

> Not everywhere where 'inherit eutils' is in use, only where 'epatch_user' is defined in src_prepare() explicitely.

 

Is there some bugs that check ebuild for missing epatch_user function?

It seems it should be mandatory in ebuild no?

----------

## SamuliSuominen

 *krinn wrote:*   

>  *ssuominen wrote:*   Not everywhere where 'inherit eutils' is in use, only where 'epatch_user' is defined in src_prepare() explicitely. 
> 
> Is there some bugs that check ebuild for missing epatch_user function?
> 
> It seems it should be mandatory in ebuild no?

 

They get reported as bugs to https://bugs.gentoo.org/ when they are missing, as "enchancement" level bugs

I tend to add it to new ebuilds thesedays, but I don't proactively change old ebuilds without requests, and I suppose nobody else is either

----------

## krinn

 *ssuominen wrote:*   

>  *krinn wrote:*    *ssuominen wrote:*   Not everywhere where 'inherit eutils' is in use, only where 'epatch_user' is defined in src_prepare() explicitely. 
> 
> Is there some bugs that check ebuild for missing epatch_user function?
> 
> It seems it should be mandatory in ebuild no? 
> ...

 

I was also seeing it as some kind of "need with new EAPI"... or something to force it default on new ebuild so it propagate with time.

----------

## SamuliSuominen

 *krinn wrote:*   

>  *ssuominen wrote:*    *krinn wrote:*    *ssuominen wrote:*   Not everywhere where 'inherit eutils' is in use, only where 'epatch_user' is defined in src_prepare() explicitely. 
> 
> Is there some bugs that check ebuild for missing epatch_user function?
> 
> It seems it should be mandatory in ebuild no? 
> ...

 

The problem is the placing of the epatch_user, since it should go before eautoreconf, but after official Gentoo patches, and there are some exceptions even to this

Putting it in new EAPI would require implementing epatch from eutils.eclass into Portage's code as well as creating new phases like src_autotools() or something like that

This has been discussed on the mailing list extensively, so I don't want to repeat it all here, please search for it  :Razz: 

----------

## mv

 *Cyker wrote:*   

> Left default useflags set and the network card renaming seems to be working again.

 

Just to prevent you from problems: There is a reason why this was removed in udev, namely a race problem.

Avoiding this bugfix means that you remain on a system with this race problem.

Therefore, I would strongly advice you to use a different namespace which avoids this problem. This is completely independent of whether you use eudev, udev, or mdev.

----------

## SamuliSuominen

 *Cyker wrote:*   

> Right, I was going to downgrade udev but I decided to try eudev instead and it seems to do what I need \o/
> 
> I just had to make a .patch file containing this
> 
> ```
> ...

 

Looks like they have been disabled for ATA transport starting with version 182 because they are broken, I opened (and closed):

https://bugs.gentoo.org/show_bug.cgi?id=517668

----------

## steveL

 *ssuominen wrote:*   

> The problem is the placing of the epatch_user, since it should go before eautoreconf, but after official Gentoo patches, and there are some exceptions even to this
> 
> Putting it in new EAPI would require implementing epatch from eutils.eclass into Portage's code as well as creating new phases like src_autotools() or something like that

 

No it wouldn't; as discussed on the mailing list, at mangler (ebuild.sh) level you simply check whether it's been run at the end of src_prepare, and run it if it hasn't. Similarly autotools.eclass can run it before (ie as prelude to) eautoreconf. This is made simpler by having the function itself do the check, so it only runs once, meaning eautoreconf and ebuild.sh can run it unconditionally.

That way if the ebuild or eclass author needs to place it, they can; it only runs once, after Gentoo patches have been done, so that the user is always patching against the distro, which makes filtering back to upstream a lot easier, as well as eliminating unknown interactions, since the ordering is defined.

----------

