Hello!
I’m having this problem:
After pc boots up and loads XFCE completely, if I press ALT+CTRL+F1-F6 all ttys will be unusable (no login prompt, some of them contain other info).
TTY1 says this:
“Creating device nodes with UDEV”
This message stays there for about 3-4 minutes, only after that the login prompt appears.
No login prompt on any TTY until I wait 3-4 minutes, then they all appear. In the mean time I can use the XFCE session without problems.
I read somewhere to try and boot up with acpi=off, this only made the “Creating device nodes with UDEV” message go away sooner, but the TTYs still lag.
What could be causing this? I googled a lot but found nothing relevant, please help.
Don’t know if it’s possibly a related issue or not but, I’ve posted something similar in this forum:“NetworkManager.service takes 25 secoonds at boot-time - GLib-GObject-CRITICAL after 23 seconds”
I’m noticing something similar to the issue raised here: the KDM Greeter appears quite quickly but, access to the TTYs is first possible when the Network Manager startup has completed.
And, in my case, there’s possibly also a D-Bus issue here due to the KDE misbehaviour if one logs in before the Network Manager has completely started and the TTYs are available.
And, all that on a Laptop in “normal” Laptop mode – no Ethernet cable and WLAN access first after a KDE session starts and the Network Manager begins looking for user controlled WLAN access. Linux 3.16.7-24-desktop x86_64 – AMD A10-5750M Quad-Core APU – Qualcomm Atheros AR9485 Wireless Network Adapter
KDE Desktop – Lenovo G505s Laptop
I doubt that de-installing the various NetworkManager packages is a good idea – from a systemd point of view, something has to manage the network interfaces.
Basically, in YaST in the “Network devices” section and “Network set-up” you have a choice between “NetworkManager” and “wicked” to manage the network interfaces.The YaST help indicates which choice should be made.
And, in any case, if you wish to see if NetworkManager is the culprit you can simply disable all the systemd NetworkManager services with “systemctl” before rebooting.
We don’t have very much information about your system – except the point that you have chosen Xfce as your Desktop Environment.
How many, and which, of the following Xfce patterns have you chosen?
patterns-openSUSE-xfce
patterns-openSUSE-xfce_basis
patterns-openSUSE-xfce_laptop
patterns-openSUSE-xfce_office
Because I’m not an Xfce user, I have absolutely no idea if any of these patterns are mutually exclusive. >:) ]
Have you set any of the NETCONFIG_DNS_STATIC parameters in the /etc/sysconfig/network/config file?
**Hello back,
I switched in YaST from NetworkManager to Wicd, then I uninstalled NetworkManager completely.
The behaviour hasn’t changed, TTYs still take a lot to become available, long after my X session is usable, In fact, as I write this, they’re still not up.
I haven’t set any static DNS.
I have the patterns-openSUSE-xfce & xfce_basis & xfce_office, no laptop since I’m on a desktop machine. I have installed other packages manually as well, since I needed more apps than only the basic ones, some from gnome.
But I don’t think the problem is with XFCE, no matter what X session I run (LXDE, Openbox, XFCE) I get the same problem.
I believe it has something to do with lower level services, especially since the last message on TTY1 while it loads is “Creating device nodes with udev”
I have run the commands you indicated and the output is pretty much similar to what you put up as example.
The only thing I notice that may be wrong is that two versions of systemd-udevd appear to be started (see the final command)
# systemctl | grep -i udev
systemd-udev-root-symlink.service loaded active exited Rule generator for /dev/root symlink
systemd-udev-settle.service loaded active exited udev Wait for Complete Device Initialization
systemd-udev-trigger.service loaded active exited udev Coldplug all Devices
systemd-udevd.service loaded active running udev Kernel Device Manager
systemd-udevd-control.socket loaded active running udev Control Socket
systemd-udevd-kernel.socket loaded active running udev Kernel Socket
# systemctl status systemd-udev-settle.service systemd-udev-trigger.service systemd-udev-root-symlink.service systemd-udevd.service
systemd-udev-settle.service - udev Wait for Complete Device Initialization
Loaded: loaded (/usr/lib/systemd/system/systemd-udev-settle.service; static)
Active: active (exited) since Tue 2015-11-03 20:00:48 EET; 54s ago
Docs: man:udev(7)
man:systemd-udevd.service(8)
Process: 315 ExecStart=/usr/bin/udevadm settle (code=exited, status=0/SUCCESS)
Main PID: 315 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/systemd-udev-settle.service
systemd-udev-trigger.service - udev Coldplug all Devices
Loaded: loaded (/usr/lib/systemd/system/systemd-udev-trigger.service; static)
Active: active (exited) since Tue 2015-11-03 20:00:46 EET; 56s ago
Docs: man:udev(7)
man:systemd-udevd.service(8)
Process: 309 ExecStart=/usr/bin/udevadm trigger --type=devices --action=add (code=exited, status=0/SUCCESS)
Process: 293 ExecStart=/usr/bin/udevadm trigger --type=subsystems --action=add (code=exited, status=0/SUCCESS)
Main PID: 309 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/systemd-udev-trigger.service
systemd-udev-root-symlink.service - Rule generator for /dev/root symlink
Loaded: loaded (/usr/lib/systemd/system/systemd-udev-root-symlink.service; static)
Active: active (exited) since Tue 2015-11-03 20:00:46 EET; 56s ago
Process: 265 ExecStart=/usr/lib/udev/rootsymlink-generator (code=exited, status=0/SUCCESS)
Main PID: 265 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/systemd-udev-root-symlink.service
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
systemd-udevd.service - udev Kernel Device Manager
Loaded: loaded (/usr/lib/systemd/system/systemd-udevd.service; static)
Active: active (running) since Tue 2015-11-03 20:00:46 EET; 56s ago
Docs: man:systemd-udevd.service(8)
man:udev(7)
Main PID: 289 (systemd-udevd)
CGroup: /system.slice/systemd-udevd.service
└─289 /usr/lib/systemd/systemd-udevd
Nov 03 20:00:46 bogPC systemd-udevd[289]: starting version 210
Nov 03 20:00:46 bogPC mtp-probe[357]: checking bus 2, device 2: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1"
Nov 03 20:00:46 bogPC mtp-probe[357]: bus: 2, device: 2 was not an MTP device
Nov 03 20:00:46 bogPC mtp-probe[365]: checking bus 3, device 2: "/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-2"
Nov 03 20:00:46 bogPC mtp-probe[365]: bus: 3, device: 2 was not an MTP device
Nov 03 20:00:47 bogPC mtp-probe[399]: checking bus 1, device 3: "/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-3"
Nov 03 20:00:47 bogPC mtp-probe[399]: bus: 1, device: 3 was not an MTP device
# journalctl -b 0 | grep -i udev
Nov 03 20:00:46 bogPC systemd-udevd[108]: starting version 195
Nov 03 20:00:46 bogPC systemd-udevd[289]: starting version 210
I am also thinking of the possibility that not udev is guilty for my problem, but some other service that starts right after udev but which doesn’t output anything on TTY1, so the last thing I see is “creating udev nodes”
The PID of the version 195 udev is very low: 108On this machine the systemd-udev daemon is currently running with PID 467.
It’s possible that your system is attempting to start an outdated (3 year old) udev version which is not compatible with the current systemd version.
It may be a good idea to check everything in “/usr/lib/systemd/system/” and also, to check the systemd unit files:
Then there’s only one way out: “# systemd-analyze plot > a-file-name.svg”
On this system, the following is happening at around about udev initialisation time:
OK, that’s an interesting command.
I looked at the produced svg file an I can now point out the culprit: rc-local.service takes 2min 18 sec to complete. It seems that’s the one holding back getty@tty1.service and getty.target
Also wicked.service takes about 30 seconds but that’s ok I guess.
Alas I cannot attach the svg to the post, I guess I don’t have the necessary privilege.
Now what could be causing rc-local.service to take so much time to load?
Hi bog2k3 – your issue seems to be easier to solve as my Network Manager issue!! :)With my Network Manager issue systemd is only reporting that NM needs about 23 seconds (haven’t managed to investigate further)
On this machine the rc-local.service is completing in 17ms and it performs ‘ExecStart’ on “/etc/init.d/boot.local” and passes the argument ‘start’ to that script file.On this machine “/etc/init.d/boot.local” is, apart from comments, empty . . .
I’ve removed those fstrim commands from /etc/init.d/boot.local and all is fine now!
It appears those were added there by me a long time ago in order to TRIM the SSD, but now i’ve moved them into a cron.weekly script and the boot process goes one fine now.
Hi,
I used to have an SSD trim script in /etc/cron.monthly/ but with 13.2 I haven’t bothered to restore the thing (very occasionally manually trim):
The mount is simply "/dev/sda1 on / type ext4 (rw,noatime,data=ordered)
".
I haven’t yet added the “discard” option to the SSD mount – there was a discussion in this forum during 2011 with respect to possible performance issues with this option.
Cheers
DCu
I read about the “discard” mount option, and it will indeed make sure the file system is trimmed automatically in real-time but what that means is whenever you delete something, it will have to be zeroed on the SSD completely, not only marked as free in the file system, which will indeed impact your performance severely. So it’s wiser not to use discard unless you have a really good (security-related perhaps?) reason to do so.
On this machine – openSUSE 13.2 (Harlequin) (x86_64); AMD A10-5750M APU with Radeon™ HD Graphics; Richland [Radeon HD 8650G] – the TTY wait on boot disappeared with today’s (2015-11-20) 13.2 update:
Have to admit that I also changed NetworkManager-wait-online.service from ‘masked’ to ‘disabled’.Doesn’t really matter, the issue has disappeared . . .
