Description of problem: long boot time with error message "Failed to start udev Wait for Complete Device Initialization" (see snapshots screnn as attached files) after logged in, I type the following commands: [root@magaux alain4]# systemctl status systemd-udev-settle.service ● systemd-udev-settle.service - udev Wait for Complete Device Initialization Loaded: loaded (/usr/lib/systemd/system/systemd-udev-settle.service; static; vendor preset: disabled) Active: failed (Result: exit-code) since Fri 2019-11-22 15:07:41 CET; 31min ago Docs: man:udev(7) man:systemd-udevd.service(8) Process: 954 ExecStart=/usr/bin/udevadm settle (code=exited, status=1/FAILURE) Main PID: 954 (code=exited, status=1/FAILURE) nov. 22 15:07:41 magaux systemd[1]: systemd-udev-settle.service: Main process exited, code=exited, status=1/FAILURE nov. 22 15:07:41 magaux systemd[1]: systemd-udev-settle.service: Failed with result 'exit-code'. nov. 22 15:07:41 magaux systemd[1]: Failed to start udev Wait for Complete Device Initialization. [root@magaux alain4]# systemctl restart systemd-udev-settle.service [root@magaux alain4]# systemctl status systemd-udev-settle.service ● systemd-udev-settle.service - udev Wait for Complete Device Initialization Loaded: loaded (/usr/lib/systemd/system/systemd-udev-settle.service; static; vendor preset: disabled) Active: active (exited) since Fri 2019-11-22 15:38:58 CET; 2s ago Docs: man:udev(7) man:systemd-udevd.service(8) Process: 29990 ExecStart=/usr/bin/udevadm settle (code=exited, status=0/SUCCESS) Main PID: 29990 (code=exited, status=0/SUCCESS) nov. 22 15:38:58 magaux systemd[1]: Starting udev Wait for Complete Device Initialization... nov. 22 15:38:58 magaux systemd[1]: Started udev Wait for Complete Device Initialization. [root@magaux alain4]# but the result is not persistent to the next boot Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3.
Created attachment 11371 [details] screen snapshot 1
Created attachment 11372 [details] screen snapshot 2
Created attachment 11373 [details] my file fstab
Created attachment 11374 [details] return of journalctl -b
Created attachment 11375 [details] return of journalctl -b -u systemd-udev-settle.service
The problem appears to be due to 15:05:40 magaux kernel: sd 21:0:0:0: [sdk] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB) 15:05:43 magaux systemd-udevd[1050]: Process 'ata_id --export /dev/sdk' failed with exit code 2. 15:06:43 magaux systemd-udevd[987]: sdk1: Worker [1050] processing SEQNUM=3467 is taking a long time It appears to finally become available at 15:08:18 magaux smartd[6912]: Device: /dev/sdk [USB Prolific], opened If I'm reading things correctly, this is a usb external drive. Does it have it's own power source? If not, perhaps it should.
CC: (none) => davidwhodgins
Thanks Dave for this perspicacious observation. Await the result.
CC: (none) => lewyssmith
(In reply to Dave Hodgins from comment #6) > The problem appears to be due to > 15:05:40 magaux kernel: sd 21:0:0:0: [sdk] 7814037168 512-byte logical > blocks: (4.00 TB/3.64 TiB) > 15:05:43 magaux systemd-udevd[1050]: Process 'ata_id --export /dev/sdk' > failed with exit code 2. > 15:06:43 magaux systemd-udevd[987]: sdk1: Worker [1050] processing > SEQNUM=3467 is taking a long time > > It appears to finally become available at > 15:08:18 magaux smartd[6912]: Device: /dev/sdk [USB Prolific], opened > > If I'm reading things correctly, this is a usb external drive. Does it have > it's own power source? If not, perhaps it should. both external usb drives (TOSHIBA_DT01ABA300 and TOSHIBA HDWQ140) have their individual power sources; furthermore, I used them even with mga6 for more one year and I didn't get such problem; this bug was also related for others distributions than mageia (https://access.redhat.com/discussions/4060221, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1730278, and some others) the question is: how to make systemd-udev-settle.service persistent? (type this on google and you find many examples)
(In reply to Lewis Smith from comment #7) > Thanks Dave for this perspicacious observation. Await the result. both external usb drives (TOSHIBA_DT01ABA300 and TOSHIBA HDWQ140) have their individual power sources; furthermore, I used them even with mga6 for more one year and I didn't get such problem; this bug was also related for others distributions than mageia (https://access.redhat.com/discussions/4060221, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1730278, and some others) the question is: how to make systemd-udev-settle.service persistent? (type this on google and you find many examples)
If you want to try changing the timeout for udev settle, copy the file /usr/lib/systemd/system/systemd-udev-settle.service to /etc/systemd/system and then edit that file to change the TimeoutSec from the current 180 seconds. To try and improve the drive start up time, check the attributes shown by "smartctl -a /dev/sdx" (replace sdx with the appropriate device name. I vaguely remember some drives having an option to delay their startup in order to reduce the initial draw on the power supply. Those drives may have such an option that can be modified using smartctl. See "man smartctl" for more details on it's usage.
(In reply to Dave Hodgins from comment #10) > If you want to try changing the timeout for udev settle, copy the file > /usr/lib/systemd/system/systemd-udev-settle.service to /etc/systemd/system > and then edit that file to change the TimeoutSec from the current 180 > seconds. in this case, I'll have two copies of systemd-udev-settle.service: one in /usr/lib/systemd/system/ and the other in /etc/systemd/system/: which of these copies have I to modify the TimeoutSec? both I guess; have I to decrease or increase the TimeoutSec? as attached file the return of lsblk -S > > To try and improve the drive start up time, check the attributes shown by > "smartctl -a /dev/sdx" (replace sdx with the appropriate device name. > > I vaguely remember some drives having an option to delay their startup in > order to reduce the initial draw on the power supply. Those drives may have > such an option that can be modified using smartctl. See "man smartctl" for > more details on it's usage.
Created attachment 11376 [details] return of lsblk -S
(In reply to peter lawford from comment #11) > (In reply to Dave Hodgins from comment #10) > > If you want to try changing the timeout for udev settle, copy the file > > /usr/lib/systemd/system/systemd-udev-settle.service to /etc/systemd/system > > and then edit that file to change the TimeoutSec from the current 180 > > seconds. > in this case, I'll have two copies of systemd-udev-settle.service: one in > /usr/lib/systemd/system/ and the other in /etc/systemd/system/: which of > these copies have I to modify the TimeoutSec? both I guess; have I to > decrease or increase the TimeoutSec? as attached file the return of lsblk -S > > > > To try and improve the drive start up time, check the attributes shown by > > "smartctl -a /dev/sdx" (replace sdx with the appropriate device name. > > > > I vaguely remember some drives having an option to delay their startup in > > order to reduce the initial draw on the power supply. Those drives may have > > such an option that can be modified using smartctl. See "man smartctl" for > > more details on it's usage. today, I've unplugged my two external USB drives before turning on my machine: indeed, the problem didn't occur; unfortunately, these drives are not pnp: if I want to use them for backup, they have to be plugged prior the boot
(In reply to Dave Hodgins from comment #10) > If you want to try changing the timeout for udev settle, copy the file > /usr/lib/systemd/system/systemd-udev-settle.service to /etc/systemd/system > and then edit that file to change the TimeoutSec from the current 180 > seconds. > > To try and improve the drive start up time, check the attributes shown by > "smartctl -a /dev/sdx" (replace sdx with the appropriate device name. > > I vaguely remember some drives having an option to delay their startup in > order to reduce the initial draw on the power supply. Those drives may have > such an option that can be modified using smartctl. See "man smartctl" for > more details on it's usage. I have copied the file /usr/lib/systemd/system/systemd-udev-settle.service to /etc/systemd/system/ and changed the TimeoutSec from 180s to 240s in both copies of this file, and rebooted: that didn't change anything
(In reply to Dave Hodgins from comment #6) > The problem appears to be due to > 15:05:40 magaux kernel: sd 21:0:0:0: [sdk] 7814037168 512-byte logical > blocks: (4.00 TB/3.64 TiB) > 15:05:43 magaux systemd-udevd[1050]: Process 'ata_id --export /dev/sdk' > failed with exit code 2. > 15:06:43 magaux systemd-udevd[987]: sdk1: Worker [1050] processing > SEQNUM=3467 is taking a long time > > It appears to finally become available at > 15:08:18 magaux smartd[6912]: Device: /dev/sdk [USB Prolific], opened > > If I'm reading things correctly, this is a usb external drive. Does it have > it's own power source? If not, perhaps it should. today morning, I've unplugged my two external USB drives (marked as sdj and sdk) before turning on my machine: indeed, the problem didn't occur; unfortunately, these drives are not pnp: if I want to use them for backup, they have to be plugged prior the boot
At least the problem area is identified; thanks for your experiments. Assigning to base system.
CC: lewyssmith => (none)Assignee: bugsquad => basesystem
(In reply to peter lawford from comment #15) > > today morning, I've unplugged my two external USB drives (marked as sdj and > sdk) before turning on my machine: indeed, the problem didn't occur; > unfortunately, these drives are not pnp: if I want to use them for backup, > they have to be plugged prior the boot Well, since they are usb disks, they are wery much pnp. So why would they not work for you ? If you want predictable mount points, you can for example label the backup disks with some special name, then before backup, mount /dev/disk/by-label/<backup_disk_label> /mnt/backup or something like that.. and unmount it after again...
CC: (none) => tmb
(In reply to Thomas Backlund from comment #17) > (In reply to peter lawford from comment #15) > > > > > today morning, I've unplugged my two external USB drives (marked as sdj and > > sdk) before turning on my machine: indeed, the problem didn't occur; > > unfortunately, these drives are not pnp: if I want to use them for backup, > > they have to be plugged prior the boot > > Well, since they are usb disks, they are wery much pnp. > > So why would they not work for you ? > > If you want predictable mount points, you can for example label the backup > disks with some special name, > > then before backup, mount /dev/disk/by-label/<backup_disk_label> /mnt/backup > or something like that.. and unmount it after again... they are both lvm2 encrypted: one is vgremote and the other vgremote1 (see my fstab here attached) but when I plugged them after booting, the command (for example): [alain4@mag6 ~]$ mount mnt/stockremote did return an error (fstab shows that the mountpoint /home/alain4/mnt/stockremote has an user option) on a general way, last year I had 10 internal hdd's and 2 external usb drives, and with mageia6 this little world fine worked without conflict it seems to me that mga7 is a severe regression vs mga6; it's a pity that I couldn't go back to mga1
(In reply to Thomas Backlund from comment #17) > (In reply to peter lawford from comment #15) > > > > > today morning, I've unplugged my two external USB drives (marked as sdj and > > sdk) before turning on my machine: indeed, the problem didn't occur; > > unfortunately, these drives are not pnp: if I want to use them for backup, > > they have to be plugged prior the boot > > Well, since they are usb disks, they are wery much pnp. > > So why would they not work for you ? > > If you want predictable mount points, you can for example label the backup > disks with some special name, > > then before backup, mount /dev/disk/by-label/<backup_disk_label> /mnt/backup > or something like that.. and unmount it after again... very strange! if I unplug the internal disk /dev/sdi (which is totally independant and is not part of the vg's of my system), the bug doesn't occur (of course, I have to wait 1mn30s for udev initialization)
Hi bug reporter and hi assignee and others involved, Please reopen this bug report if it is still valid for Mageia 8 or 9(cauldron), and change "Version:" in the upper left of this report accordingly. This report is being closed as OLD because it was filed against Mageia 7, for which support ended on June 30th 2021. Thanks, Marja
Status: NEW => RESOLVEDResolution: (none) => OLD