systemd doesn't see devices from udev #3446
Comments
|
Here is the affected fstab: I forgot to mention that there were no issues with Systemd from Debian Jessie. |
|
What you see is just a symptom. Systemd relies on udev to announce availability of device. Start with checking udev database (udevadm info --export-db) whether it contains entry for mmcblk0p1. Does it have SYSTEMD_READY=0 by any chance? Could you make output of udevadm available? And, BTW, you attempt to mount the same device on two different mount points. Is it intentional? |
|
Yes, mounting a device twice is intentional. I do not think this issue has anything to do with UDEV, since everything works properly as soon as I change mount options in fstab from I do not know about |
|
Does your kernel have CONFIG_FHANDLE set? If not, set it, it should fix your issue. Please verify the requirements from README regarding your local system and kernel options. Thanks. |
poettering
added
the
needs-reporter-feedback ❓
|
I am using the 4.4 kernel from Xilinx with some extra patches to devicetree code, I checked the mentioned config option and it is active: I have not checked the readme file yet. |
|
I appears that systemd on your system won't notice the relevant devices to appear, hence a lot of your stuff simply times out. If it's not the CONFIG_FHANDLE issue and the devices you have do carry the "systemd" tag in udev I don't really have much of a suggestion what might be the problem here. Does "systemctl" show any .device units pop up at all? If not, then it appears that systemd doesn't see any devices appear at all, and there's something wrong with the communication between udev and systemd there... |
poettering
changed the title
|
Hi, I will try to reproduce the issue by reverting back fstab, so I will be able to give a more detailed report. |
|
I am unable to reproduce the issue now, so I will assume something else went wrong. I will close this bug now, and only reopen it if I will be able to reproduce it. Thanks for your help. |
|
It seems that the cause was missing the I rebuild my image from scratch and the issue resurfaced, I attempted changes to fstab and to ttyPS0 unit links, but it did not help. So I went through the shell history and found |
|
What was your process in getting udev installed? I encountered the very same issue. Thanks! |
|
apt-get -y install udev I think nothing else was needed, at least I do not remember anything else among all the attempts to fix this. |
|
You did this on the Red Pitaya I presume during the OS build process? |
|
yes, it is performed by this script: |
|
Thanks this fixed my issue as well. Very helpful. |
|
Since this issue wasn't properly solved, I assume I hit this one today. A casual reboot ended up in emergency mode under systemd 232-19 (Debian stretch) due to and similar messages for all other partitions and their dire consequences leading up to In the emergency shell, |
|
Hit exact same problem today with Debian jessie (8.7), systemd package version 215-17+deb8u6 System boots as normal, times out waiting for LVM (as dev mapper or by-uuid) devices, drops into emergency shell. If allowed to continue, it mounts those devices as per fstab, but the system is in unusable state as network subsystem is not up and the only access is via IP/KVM or direct physical console udev package is in place (exactly the same package version as systemd itself) affected devices are present in udev db and do NOT have SYSTEMD_READY attribute at all but do have :systemd: tag The problem was solved after I spotted a weird error in journalctl output saying that systemctl-udev was "unable to rename eth0 to eth2: Success". Apparently during maintenance two NICs were swapped around, thus generating conflicting records in /etc/udev/rules.d/70-presistent-net.rules After deleting this file and rebooting everything was magically all right. The takeaway is:
|
|
I hit this problem too and can reproduce easily. Hardware: Lenovo V470 laptop, Core i5 2450M, 500GB HDD /etc/fstab: If I set If I set It seems |
|
Here is a doc from SUSE on this problem, which also suggests increasing |
|
@duanyao, you seem describe the documented timeout behavior, not a bug. This issue is about systemd device units not appearing after an arbitrarily long time, long after udev created the corresponding device nodes/links and settled. |
|
@wferi I think the bug is: systemd gives up too quickly, before the specified |
|
I have this issue, on arch linux, This device is clearly mounted, yet systemd can't seem to find it. |
|
Same issue here after upgrade to ubuntu 16.10. First I thought it is related to luks+lvm but not even the unencrypted boot partition (sda1) will be mounted. |
|
I have systemd on gentoo. 236-r5. When booting, all devices on /etc/fstab time out after 90 seconds. https://paste.pound-python.org/show/052zZS9XyVcS71ZB3LvB/ Relevent log snippet is: /etc/fstab is: |
There was an issue preventing the system to automatically boot because it was failing randomly with a dependency check with two HDD partitions. Now systemd should wait before it consider the disk dependency as a failure. Refs: * systemd/systemd#1401 * systemd/systemd#3446 * https://www.suse.com/support/kb/doc/?id=7018491
Submission type
systemd version the issue has been seen with
systemd 229
Used distribution
Ubuntu base 16.04 (armhf)
Behaviour
FSTAB rules for VFAT did not work properly, but the issue is probably not limited to VFAT, it also seems another generated unit was corrupted in the process. Here are more details from a longer report:
First I get the next during the boot process:
I tried to fix the TTY issue by following this post, there was a change but it did not help:
http://askubuntu.com/questions/76363...-tar-gz/766444
Then I enabled verbosity for systemd, and copied logs to the SD card using:
And this are the relevant lines from the log:
I can manually get network up with:
I can mount the SD card FAT partition, as the device exists:
And the serial console device also exists:
How to reproduce, possible sources
For now it seems the issue was the Systemd translation of fstab into units, in fstab VFAT was mounted with options
ro,defaultand it seems this created broken *.mount units, it also seems the same issue propagated to thettyPS0unit.I now wrote mount options as
default,roand it seems to work now, I also had to remove thettyPS0symbolic link "fix?", since it caused console instability (repeated text, logouts).It might be that
defaulttranslates into its basic options, among themrw, and this conflicts withrobeeing defined beforedefault.The text was updated successfully, but these errors were encountered: