# /dev/disk/by-id is empty [solved: use systemd-212-r4]

## mv

As the subject says: after some reboot, /dev/disk/by-id suddenly does not show any link to /dev/sda* anymore (which originally had  been wwn.* in my case); it still shows some link to some /dev/sdb device.

Also /dev/disk/by-path only contains a link to /dev/sdb but not to /dev/sda (altohugh I do not remember whether the latter was ever the case).

The /dev/sda* do exist and can be used (in fact, it is my only disk; /dev/sdb is shown as "Multi-Flash-reader" although I was not even aware that I had some).

All remaining directories in /dev/disk/by-* do contain links to /de/sda* partitions (but no link to /dev/sda itself).

The logs show nothing strange.

The only change on the machine which might be related between the two boots (when it was working and when it was not) was an update of systemd-212-r2 to *-r3 with gcc-4.9. However, I rebuilt all previous systemd-212-r2 versions (even with a gcc-4.8.2 which I rebuilt only for this purpose), rebuilt also dbus - nothing helped.

I have absolutely no clue what might have broken so suddenly. Could it be some hardware issue (but then, why do all other /dev/disk/by-* still work and nothing is shown in logs)?Last edited by mv on Sat May 03, 2014 7:14 pm; edited 1 time in total

----------

## Zanfib

Hi, I've a similar problem to boot today because a missing link for lvm parts !! I've the same updates of systemd and dbus yesterday, maybe a problem with a rule file in udev subsystem ?

----------

## Randy Andy

Interestingly mv.

I did some trials here on two different machines 32 and 64 ~x86bit arch, both are using OpenRC, udev- 212-r1 and kernel 3.14.2 and that's what I found out:

Seems not systemd related, cause I have nearly the same behaviour.

On the 64bit PC I use 4 internal hard disks sda-sdd, but none of those are listed in /dev/disk/by-path/ only

The only entry I have here is:

```
ls -l /dev/disk/by-path/

insgesamt 0

lrwxrwxrwx 1 root root 9  3. Mai 10:35 pci-0000:00:1a.7-usb-0:2.4:1.0-scsi-0:0:0:0 -> ../../sde
```

Which is listed by 

```
ls -l /dev/disk/by-id/ beside all the other devices too as:

usb-Generic_STORAGE_DEVICE_000000009802-0:0 -> ../../sde
```

 This is my USB-Hub, which is permanently connected, with 3 external USB Hard Drives, which are powerless by a remote switch.

If I switch on these, I get:

```

 ls -l /dev/disk/by-path/

insgesamt 0

lrwxrwxrwx 1 root root  9  3. Mai 10:35 pci-0000:00:1a.7-usb-0:2.4:1.0-scsi-0:0:0:0 -> ../../sde

lrwxrwxrwx 1 root root  9  3. Mai 13:41 pci-0000:00:1d.7-usb-0:3.5.1:1.0-scsi-0:0:0:0 -> ../../sdg

lrwxrwxrwx 1 root root 10  3. Mai 13:41 pci-0000:00:1d.7-usb-0:3.5.1:1.0-scsi-0:0:0:0-part1 -> ../../sdg1

lrwxrwxrwx 1 root root  9  3. Mai 13:41 pci-0000:00:1d.7-usb-0:3.5.2:1.0-scsi-0:0:0:0 -> ../../sdh

lrwxrwxrwx 1 root root 10  3. Mai 13:41 pci-0000:00:1d.7-usb-0:3.5.2:1.0-scsi-0:0:0:0-part1 -> ../../sdh1

lrwxrwxrwx 1 root root  9  3. Mai 13:41 pci-0000:00:1d.7-usb-0:3.5.3:1.0-scsi-0:0:0:0 -> ../../sdf

lrwxrwxrwx 1 root root 10  3. Mai 13:41 pci-0000:00:1d.7-usb-0:3.5.3:1.0-scsi-0:0:0:0-part1 -> ../../sdf1
```

Similar behaviour on my 32 Bit Netbook, which has a built in Card reader which is not shown nor is there an existing by-path entry at all:

```
ls -l /dev/disk/by-                                                                                                      

by-id/        by-label/     by-partlabel/ by-partuuid/  by-uuid/
```

But when I plug in a SD-Card e.g. into the slot, then I get:

```
/dev/disk/by-path:

insgesamt 0

lrwxrwxrwx 1 root root  9  3. Mai 13:05 pci-0000:00:1d.7-usb-0:6:1.0-scsi-0:0:0:0 -> ../../sdb

lrwxrwxrwx 1 root root 10  3. Mai 13:05 pci-0000:00:1d.7-usb-0:6:1.0-scsi-0:0:0:0-part1 -> ../../sdb1
```

Conclusion:

These entries would be created dynamically if they exist, but only for removable devices, otherwise our internal had been listed there too.  :Wink: 

This seems to work also in a different way and also for internal devices, as I found out during this test. It's a little bit like reverse engineering and hopefully there exist a documentation which confirms my assumptions...

Only on my 32bit pc, I named my devices also by PARTLABEL, so only on it exist the following additional entry

by-partlabel/ ,as you can see on the list of the 32bit Netbook above, where the by-path entry doesn't exist until I plugged in the SD card.

My 64 bit PC doesn't show this entry, cause there is no device labelled by PARTLABEL, but by PARTUUID too:

```
ls -l /dev/disk/by-

by-id/       by-label/    by-partuuid/ by-path/     by-uuid/
```

So it seems to be no fault on your machine. 

Would be interesting to know when these change came into the system. I guess it's more kernel related instead of udev.

Eventually any other could bring more light into it, or someone has already studied the kernel.log.  :Wink: 

Nevertheless interestingly at all. Which kernel do you use actually?

[Edit, after reading the message of Zanfib]

Ok, guys. I've also done on yesterday on both boxes the updates to sys-apps/dbus-1.8.2. But I didn't reboot the 32 bit box. Shouldn't dbus use the old version out of the memory, or would it be reloaded. How could I test it while running. The box still compile libreoffice.  :Wink: 

Best, Andy.

----------

## mv

I observed now the same behaviour on another machine which still worked yesterday.

In fact, on this machine there is now no /dev/disk/by-id anymore, at all.

However, I had updated yesterday about 50 packages and the kernel on that machine, so this is not a good setting to find the cause.

It might be that the dbus update is the culprit, although I think that I had booted succesfully after that update ('though I am not completely sure).

@Randy Andy: When I mentioned systemd, I mean here its udev part which is responsible of filling /dev/disk/by-*. I get the same behaviour, of course, when I boot with openrc.

My guess is now that it is perhaps some timing issue (perhaps related with the new dbus): Somehow the early "messages" of the kernel about the attached disks seem to get lost, and so udev does not build these symlinks. The other devices (usb) get probably initialized later when udev and dbus are already running in "normal" mode.

For this reason, it might be that by accident I booted succesfully once, although the dbus update is the "culprit". I will try with downgraded dbus when I have time and report back.

----------

## mv

Nope, downgrading dbus did not help. Here is a summary of the involved failing versions:

sys-kernel/hardened-sources-3.14.2  (whether compiled with gcc-4.8.2 or gcc-4.9 makes no difference)

sys-apps/systemd-212-r2 (1st and 3rd variant of CVS) and -r3 (with gcc-4.8.2 or gcc-4.9; neither makes a difference)

sys-apps/dbus-1.8.0 and 1.8.2 (the latter compiled with gcc-4.8.2 and gcc-4.9, the latter only with gcc-4.9)

I am rather sure that with exactly the same combinations, I had also a running system...

I do not expect that the gcc version is actually related - in fact, so far I had no regressions with gcc-4.9; I just tried it, because by accident I upgraded gcc just a few days ago and was hunting for any cause I could imagine.

Edit: The first system was amd64 the second x86; so the behavior is not architecture dependent.

----------

## Anon-E-moose

Have you tried it with another version of the kernel? Either an earlier 3.14 or some earlier version.

----------

## Randy Andy

Hi Folks,

I just tried to boot from my oldest available version, but the symptoms are still the same with kernel-3.13.6 and dbus-1.8.0.

Sorry, can't go further back at this moment.

Anyone else here?

----------

## Anon-E-moose

Is everyone that is having problems running some variation of the 212 version?

----------

## mv

 *Anon-E-moose wrote:*   

> Have you tried it with another version of the kernel? Either an earlier 3.14 or some earlier version.

 

Yes, I tried also with 3.14.1 with the same failure. However, it worked for some days also with 3.14.2, before it failed.

Here is the excerpt from qlop -l what was emerged between the last working and first non-working boot (probably the list is too long, but just to be sure):

```
dev-util/android-sdk-update-manager-22.6.1

www-client/firefox-29.0

media-video/mpv-0.3.0

www-plugins/classic-theme-restorer-1.1.8

sys-apps/dbus-1.8.2

sys-apps/install-xattr-0.1

app-crypt/gnupg-2.0.22

app-misc/tmux-1.9a

media-video/vcdimager-0.7.24

sci-libs/gsl-1.16

sys-apps/net-tools-1.60_p20130513023548

sys-apps/install-xattr-0.1

sys-apps/systemd-212-r2

sys-apps/portage-2.2.10

sys-apps/systemd-212-r3
```

Except for systemd and dbus nothing seems to be related here. (Of course, things like upgrading to gcc-4.9 quite a while ago might have implicitly changed something.)

The version of systemd which was there before (when it was working) was the "first" variant of systemd-212-r2 (but as mentioned, I downgraded again to this versoin fetched from CVS); I do not remember which dbus version was there before (corresponding logs are already cleaned).

----------

## mv

 *Anon-E-moose wrote:*   

> Is everyone that is having problems running some variation of the 212 version?

 

I just downgraded to 208 - still the same problem.

However, I just realized that there is 212-r4 in the tree. This fixes the issue!

----------

## Zanfib

Same fixes from 212-r4 version, no problem on reboot !

The directory /dev/disk/by-id/ is completely populated this time.

The Changelog in systemd 212-r4 is about MY_UDEVDIR correction with bug #509454. Thanks to the devs to solve this issue so quickly !  :Wink: 

----------

