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
> 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...
> 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.
Created attachment 713298 [details] udevd.log without delay
Created attachment 713301 [details] udevd_delay.log with delay (using debug and 'exit' after 3 seconds in each cmd prompt)
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
I can confirm this bug also when using ZFS as root device. Udev does not generate /dev/zfs before trying to import my zpools.
@flo, does the delay help?
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.
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)
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.
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?
> I can confirm with udev.children-max=1 setting trim always helps. s/helps/works
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 :(
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"
