Slow boot up time

Let me explain the situation here. I have a System76 Lemur Ultra Thin (lemu4) notebook PC and I installed OpenSuSE 64 bit 12.2 and I upgraded to Tumbleweed GNU/Linux as my primary and sole operating system of choice. Previously, I could cold boot OpenSuSE in less than 10 seconds from the time that I turned on the power to my PC to the time I reached the KDM log in screen. Now, it takes more than one minute. I have a Crucial M4 SATA-III 128 GB SSD and I have an Intel Core i5-3210M dual-core 2.5 GHz with Hyper Thread and Turbo Boost CPU and I have Corsair Vengeance 16 GB PC3-12800 SODIMM RAM.

I was messing around with VM Ware Workstation 9.0.0 64 bit and my Linux kernel. I deleted the vmware modules in /lib/modules/3.6.3-8-desktop/misc folder per the instructions to unload the modules from the kernel in order to apply a third party unofficial patch for Linux kernel 3.6.3-8-desktop which I currently use right now. Then, I deleted the .patched file in /usr/lib/vmware/source/.patched and the rest of the files in the ./source folder. I also deleted the source-backup files in the /usr/lib/vmware/source/source-backup folders and original vmware module backups.

I rebooted my System76 PC multiple times very quickly. Then, I noticed the slow down during the boot process. I can’t figure out why it is so slow.

Is this related to the data corruption bug for the Linux kernel 3.6.3-8-desktop and the /ext4 file system which I use? I checked my separate /home partition for data corruption issues and I can not seem to find anything wrong.

Why is my boot up so slow? I see the OpenSuSE splash screen and it takes forever to get past that screen and to the KDM log in screen.

How do I fix this problem?

Hit Esc to see the verbose text during boot process, what do you notice there

This is 99.99% not related to the ext4 bug (unless you use exactly the same unusual ext4 mount/umount options that trigger the bug).

What is the output of “systemd-analyze blame”?

wellywu@linux-pn0z:~> sudo su -
root’s password:
linux-pn0z:~ # systemd-analyze blame
1033ms xinetd.service
630ms SuSEfirewall2_setup.service
504ms postfix.service
302ms dkms_autoinstaller.service
290ms vboxdrv.service
236ms winbind.service
163ms apparmor.service
155ms systemd-vconsole-setup.service
147ms auditd.service
143ms SuSEfirewall2_init.service
135ms avahi-daemon.service
126ms systemd-logind.service
109ms storage-after-cryptsetup.service
99ms syslog.service
78ms fbset.service
77ms console-kit-log-system-start.service
72ms smb.service
59ms NetworkManager.service
58ms ntp.service
55ms localnet.service
54ms network-remotefs.service
52ms remount-rootfs.service
51ms lvm.service
50ms bluez-coldplug.service
49ms systemd-readahead-collect.service
46ms cpufreq.service
44ms systemd-modules-load.service
43ms xdm.service
43ms network.service
42ms systemd-readahead-replay.service
41ms cycle.service
40ms systemd-remount-api-vfs.service
39ms udev.service
39ms pald.service
36ms media.mount
35ms nmb.service
34ms var-lock.mount
31ms systemd-ask-password-wall.service
30ms udev-trigger.service
29ms udisks2.service
28ms vboxautostart-service.service
28ms var-run.mount
27ms systemd-user-sessions.service
25ms vboxballoonctrl-service.service
24ms dev-mqueue.mount
21ms dev-hugepages.mount
20ms vboxweb-service.service
18ms rc-local.service
17ms acpid.service
16ms sys-kernel-debug.mount
14ms systemd-sysctl.service
13ms systemd-tmpfiles-setup.service
12ms sys-kernel-security.mount
10ms boot.mount
10ms udev-root-symlink.service
9ms console-kit-daemon.service
6ms upower.service
6ms cryptsetup@cr_ata\x2dM4\x2dCT128M4SSD2_000000001223090C516C\x2dpart2_1.service
6ms home.mount
3ms rtkit-daemon.service
1ms sys-fs-fuse-connections.mount
linux-pn0z:~ #

I’m fairly new to OpenSuSE 64 bit Tumbleweed. What does this all mean? Why is boot up so slow now?

This shows how much milliseconds it took to start each service. And your numbers look pretty good, the boot process should not be too slow. You can now do what caf4926 wrote and look for the boot messages. (And you can also post the output of “systemd-analyze”).

I see quite a lot of services.
For example, I read about your VMware story, then again vboxdrv is running. Are you actually using both?

That doesn’t explain the difference. To be honest, if the things you did are according to VMware instructions, I’m puzzled, thinking that those days were over.