Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 790005 - sys-kernel/genkernel: additional udev rules don't load properly
Summary: sys-kernel/genkernel: additional udev rules don't load properly
Status: UNCONFIRMED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: genkernel (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Genkernel Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-05-13 17:31 UTC by Dmitry Baranov
Modified: 2021-09-02 09:07 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
udevd.log (udevd.log,385.32 KB, text/plain)
2021-06-02 12:36 UTC, Dmitry Baranov
Details
udevd_delay.log (udevd_delay.log,381.85 KB, text/plain)
2021-06-02 12:38 UTC, Dmitry Baranov
Details
udevd.log (udev.children-max=1) (udevd.log,402.04 KB, text/plain)
2021-08-08 07:42 UTC, Dmitry Baranov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Baranov 2021-05-13 17:31:25 UTC
I use an external SSD device for the root filesystem. Unfortunately, for some reason, the Linux kernel developers don't include trim support for such devices by default.

To enable trim, I have to create an additional udev rule and include it in the initramfs image. It is necessary to include this rule in the image, otherwise, during the initial initialization of LUKS, a trim for the root fs isn't available.

/etc/genkernel.conf:
INITRAMFS_OVERLAY="/etc/genkernel.d"

/etc/genkernel.d/etc/udev/rules.d/10-usb-storage.rules:
ACTION=="add|change", ATTRS{idVendor}=="152d", ATTRS{idProduct}=="0580", SUBSYSTEM=="scsi_disk", ATTR{manage_start_stop}="1", ATTR{provisioning_mode}="unmap"

The problem is that there is no delay between loading kernel modules and starting udev. And at the end of the boot, I see the following:

# lsblk -o NAME,SIZE,TYPE,DISC-GRAN,DISC-MAX /dev/sdd
NAME             SIZE TYPE  DISC-GRAN DISC-MAX
sdd            953.9G disk         0B       4G
└─sdd1         953.9G part         0B       4G
  └─root       953.9G crypt        0B       0B
    ├─vg1-root    32G lvm          0B       0B
    ├─vg1-var     64G lvm          0B       0B
    └─vg1-mnt  857.9G lvm          0B       0B

To work around the problem, I use the genkernel's "debug" option. When starting the debug shell for the first time, I wait about 3 seconds, type exit, and after that I see the normal state of the disks at the end of the boot:

# lsblk -o NAME,SIZE,TYPE,DISC-GRAN,DISC-MAX /dev/sdd
NAME             SIZE TYPE  DISC-GRAN DISC-MAX
sdd            953.9G disk         4K       4G
└─sdd1         953.9G part         4K       4G
  └─root       953.9G crypt        4K       4G
    ├─vg1-root    32G lvm          4K       4G
    ├─vg1-var     64G lvm          4K       4G
    └─vg1-mnt  857.9G lvm          4K       4G

To solve this problem, I propose to make it possible to set an additional delay immediately before starting the udev (or to move sdelay to this place):

https://github.com/gentoo/genkernel/blob/cdaef312247a3ed18c9fdcea084058e5f25a7f3e/defaults/linuxrc#L577

Reproducible: Always
Comment 1 Thomas Deutschmann gentoo-dev Security 2021-05-13 23:41:23 UTC
> The problem is that there is no delay between loading kernel modules
> and starting udev.
I don't understand this. UDEV is responsible for module loading. What is happening in the delay you add before UDEV is starting? Anything in dmesg?

Are we really talking about a kernel module or is the USB device just taking some time?

Could you please try adding gk.hw.use-modules_load=yes to your kernel command-line to see if it makes any difference?

Please also boot twice with gk.udev.debug=yes set in kernel command-line and share /run/initramfs/udevd.log: Once a normal boot where trim is missing and once with your delay. I am curious what will be the difference...
Comment 2 Dmitry Baranov 2021-06-02 12:31:41 UTC
> Could you please try adding gk.hw.use-modules_load=yes to your kernel command-line to see if it makes any difference?
I've tested this option and it gives a positive result (4K/4G all fs).

>Please also boot twice with gk.udev.debug=yes set in kernel command-line and share /run/initramfs/udevd.log: Once a normal boot where trim is missing and once with your delay. I am curious what will be the difference...
Please see attached logs.
Comment 3 Dmitry Baranov 2021-06-02 12:36:25 UTC
Created attachment 713298 [details]
udevd.log

without delay
Comment 4 Dmitry Baranov 2021-06-02 12:38:52 UTC
Created attachment 713301 [details]
udevd_delay.log

with delay (using debug and 'exit' after 3 seconds in each cmd prompt)
Comment 5 Dave Hughes 2021-06-02 23:55:00 UTC
I've been loading custom udev rules via initramfs-overlay and they appear to be working with no delay required, nor gk.hw.use-modules_load=yes
Comment 6 flo 2021-06-05 18:21:58 UTC
I can confirm this bug also when using ZFS as root device.
Udev does not generate /dev/zfs before trying to import my zpools.
Comment 7 Dmitry Baranov 2021-06-05 18:57:53 UTC
@flo, does the delay help?
Comment 8 Thomas Deutschmann gentoo-dev Security 2021-07-06 03:18:26 UTC
Could you please retry with

  gk.udev.debug=yes udev.children-max=1

added to your kernel command-line? Please attach a new log with that setting.

And please tell us if your USB driver is built-in or not.
Comment 9 Dmitry Baranov 2021-08-08 07:42:40 UTC
Created attachment 731257 [details]
udevd.log (udev.children-max=1)

(In reply to Thomas Deutschmann from comment #8)
> Could you please retry with
> 
>   gk.udev.debug=yes udev.children-max=1
> 
> added to your kernel command-line? Please attach a new log with that setting.
> 
> And please tell us if your USB driver is built-in or not.

Please see a new log. I have seen a normal trim state after this setting (DISC-GRAN DISC-MAX 4K/4G)
Comment 10 Dmitry Baranov 2021-08-08 07:51:18 UTC
Regarding USB driver:
I tried various options - built-in (=y) and external (=m) uasp driver. This does not affect the boot result. Trim discards still disabled.
Also I have switched from eudev to udev on my system (after that I rebuilt the genkernel's ramdisk). It also had no effect.
Comment 11 Dmitry Baranov 2021-08-20 10:35:23 UTC
I can confirm with udev.children-max=1 setting trim always helps.
At the same time, there is no need to create any additional delays.

@Thomas Deutschmann,
are there any new thoughts?
Comment 12 Dmitry Baranov 2021-08-20 10:36:32 UTC
> I can confirm with udev.children-max=1 setting trim always helps.
s/helps/works
Comment 13 Thomas Deutschmann gentoo-dev Security 2021-08-27 13:21:52 UTC
So the question is why this rule will run into problems when udev is using multiple children. Maybe it can be rewritten to avoid that problem, maybe it's a bug in (e)udev.

I can't help you with debugging this because I have no setup where I can replicate the problem yet :(
Comment 14 Dmitry Baranov 2021-09-02 09:07:22 UTC
I doubt there is a problem with my udev rules. I've tried various ways of writing. manage_start_stop/provisioning_mode variables are always enabled after boot (cat /sys/*/{manage_start_stop,provisioning_mode} to check). But the output of lsblk is bad without udev.children-max=1 or extra delay.

My current udev file:

# cat /etc/genkernel.d/etc/udev/rules.d/10-usb-storage.rules 
ACTION=="add", SUBSYSTEM=="scsi_disk", ATTRS{idVendor}=="8564", ATTRS{idProduct}=="1000", ATTRS{serial}=="0000000000000000", LABEL="edisk"
ACTION=="add", SUBSYSTEM=="scsi_disk", ATTRS{idVendor}=="152d", ATTRS{idProduct}=="0580", ATTRS{serial}=="0000000000000", LABEL="edisk"

LABEL="edisk", DRIVERS=="usb", ATTR{manage_start_stop}="1"
LABEL="edisk", DRIVERS=="uas", ATTR{provisioning_mode}="unmap"