Bug 11811

Summary: lsblk (util-linux) should depend on libudev if available
Product: buildroot Reporter: Pete Morici <pmorici>
Component: OtherAssignee: unassigned
Status: RESOLVED FIXED    
Severity: normal CC: buildroot
Priority: P5    
Version: 2019.02.2   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Host: Target:
Build:
Attachments: modified pc EFI defconfig

Description Pete Morici 2019-04-30 03:02:40 UTC
Several of the output columns of lsblk such as SERIAL and WWN are incorrectly reported as empty strings. ie: 'lsblk -do SERIAL'  

The cause is that lsblk uses libudev to obtain this information but the util-linux package doesn't list the udev package as a dependency if it is selected. If util-linux gets built before udev then many parts of lsblk return empty strings for various fields.

Adding the following to packages/util-linux/util-linux.mk fixes the problem.

 ifeq ($(BR2_PACKAGE_UDEV),y)
 UTIL_LINUX_DEPENDENCIES += udev
 endif
Comment 1 Thomas Petazzoni 2019-04-30 07:00:08 UTC
I don't think the fix can be that simple: it causes a circular dependency.

Indeed "udev" is provided either by the "eudev" or "systemd" packages. And both eudev and systemd depend on util-linux:

EUDEV_DEPENDENCIES = host-gperf host-pkgconf util-linux kmod

SYSTEMD_DEPENDENCIES = \
        $(if $(BR2_PACKAGE_BASH_COMPLETION),bash-completion) \
        host-gperf \
        host-intltool \
        kmod \
        libcap \
        util-linux

So, by adding a dependency on udev in util-linux, you create a circular dependency.

I'm not sure how we can break this circular dependency, unfortunately :-/
Comment 2 Pete Morici 2019-04-30 12:34:52 UTC
Yeah, I spoke too soon.  Doing a dirclean on util-linux and rebuilding after a full build corrects the issue but that isn't a solution.  

Could libudev be broken out into a separate package that can be built before the whole?  I'm not familiar enough with buildroot yet to know what a good way to approach this is.
Comment 3 Pete Morici 2019-04-30 12:56:35 UTC
Do systemd and eudev only need libblkid from util-linux? Can that be broken out into a separate package that they depend on?  It looks like you can select to only build libblkid  using the configure line, "./configure --disable-all-programs --enable-libblkid" for util-linux
Comment 4 Carlos Santos 2019-05-03 12:10:49 UTC
I'm taking this bug.
Comment 5 Carlos Santos 2019-05-03 12:19:58 UTC
(In reply to Pete Morici from comment #3)

It would be possible to have a util-linux-libs package providing libblkid and a util-linux package with the utilities, only. Another solution would be doing the same as Fedora, on which libeudev is provided by a systemd-libs package on which util-linux depends.

I will investigate both solutions and post the results as soon as possible.
Comment 6 Carlos Santos 2019-05-05 00:15:20 UTC
I investigated the problem and was unable to reproduce the problem on my test hardware: 

# lsblk -do NAME,SERIAL
NAME         SERIAL
sda          
mmcblk0      0x439da3eb
mmcblk0boot0 
mmcblk0boot1 

Could you please post a defconfig, preferably based on one of the already existing qemu defconfig's, with which the problem happens?
Comment 7 Pete Morici 2019-05-05 02:15:56 UTC
Created attachment 8021 [details]
modified pc EFI defconfig
Comment 8 Pete Morici 2019-05-05 02:21:52 UTC
I've attached my config it is a modified version of the included pc/efi def config.

Looking at your output though I think you have reproduced the problem.  The serial column for your sda device is blank.  You can also get the serial by running the utility "/lib/udev/ata_id /dev/sda"  If that returns something where lsblk returns a blank then that is the problem.  I've not tested this with MMC or SD devices so it might be limited to SATA and USB drives.

Another way to see the difference is to do a full build followed by a "make util-linux-dirclean" and then "make" again that will cause lsblk to link against libudev and report the serial number correctly.
Comment 9 Carlos Santos 2019-05-07 16:57:56 UTC
I just sent for review a patch that fixes the problem:

    https://patchwork.ozlabs.org/patch/1096436/

The solution requires a quite invasive patch to avoid building and installing the util-linux libraries twice.
Comment 10 Carlos Santos 2019-05-09 17:19:28 UTC
I submitted  a new patch using a slightly different approach:

    https://patchwork.ozlabs.org/patch/1097541/
Comment 11 Peter Korsgaard 2020-11-04 21:57:13 UTC
This has now finally been merged in https://git.buildroot.org/buildroot/commit/?id=8bafc6dc8ad13000a58af980650ff59a78399ae2, thanks