SUSE / openSUSEThis Forum is for the discussion of Suse Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Remove all unnecessary software and daemons (via yast)
Disable apparmour (via yast)
Disable the bootsplashtheme (via yast) and boot up in text mode
Have a look at you firewall configuration
...
Another solution is to stretch your patience-ability...
Recompile your kernel so only modules applicable to your hardware are loaded.
More specifically, recompile your kernel such that there are as few modules as possible (make options specifically applicable to your hardware built-in instead); try to make it so there is no need for an initial ramdisk.
Another thing you could do is try init-ng (or some other efficient, parallel init replacement). On one of my machines (a pretty simple one) it takes 7.3 seconds from GRUB prompt to text-login, with the greatest delay presented by DHCP (since its speed depends on the server).
init-ng would overwrite which initialization system I have on SuSE?
On a compiled-kernel, apparmor disabled and all the changes above, how many second +/- would it take to boot? For me, 35 seconds is more than good, although less time to boot is always good.
1) paralel initialization is a default setting in suse
2) re-compiling kernel will not help much (unless you upgade it to the newer version that has some enhancements or you will disable nonresponding/slow responding devices)
3) built-in vs modules in terms of speed is mostly wrong. If you build device into kernel, then irrelevant of device status, kernel will try to load it. When build as a module, it will not start unless active.
4) initng scripts are designed for gentoo, you may try runit if you really want to experiment.
so what you can do?
1) change fs from reiser to xfs. Another very fast is jfs however this requires some tweaking as jfs is not supported as boot fs.
reiser is the slowest fs from all available in linux in terms of mounting device.
2) definitely tweak fstab
3) kill system services (not used)
4) kill DE services (not used)
5) re-compiling kernel may save up to 5-8 sec, but you can get vanilla, patch it will performance patches and this way improve GUI responsiveness
6) hmmm.. switch to BSD? (slackware is using similar init)
next (before re-formating) try kernel 2.6.19x
It has new improvements that should definitely speed up reiser boot. If you will be satisfied, no need to reformat
remember that fs can be additionally speed up by adding extra flags to /etc/fstab.
hope this help.
how much faster? it depends on your hardware and how well you will optimize OS.
Hope this will help a little.
init-ng would overwrite which initialization system I have on SuSE?
On a compiled-kernel, apparmor disabled and all the changes above, how many second +/- would it take to boot? For me, 35 seconds is more than good, although less time to boot is always good.
Init-ng and regular inits can co-exist on the same system. All you have to do is pass a boot parameter at the lilo prompt (init=/sbin/initng or init=/sbin/init, depending on which one you want to make the default). The executables are mutually exclusive, as are the configuration files (although init-ng setup scripts will try to learn as much about your current init scripts as they can).
2) re-compiling kernel will not help much (unless you upgade it to the newer version that has some enhancements or you will disable nonresponding/slow responding devices)
3) built-in vs modules in terms of speed is mostly wrong. If you build device into kernel, then irrelevant of device status, kernel will try to load it. When build as a module, it will not start unless active.
But most default distro kernels (AFAIK) have almost everything compiled as a module. This often requires an initrd, which takes up a lot of time. Of course such things as USB storage, etc. should be built as modules and configured with udev.
It all depends on your situation, but (at least for me) there are many things that will not change on my desktop system, yet might be built as modules in a distribution. Using modprobe to load modules from within init scripts (even if done in "parallel") is slower than having khelper/kthread load the same code at startup.
Actually I had two kernels:
modules enabled and all in kernel. No difference in terms of speed.
initrd has not much to do with general module setup. It contains only info about disk and fs to allow loading kernel (you need these before kernel boots obviously) if fs and disk are build as a modules.
this is what my initrd contains:
Driver modules: ide-core ide-disk scsi_mod sd_mod piix libata ahci processor thermal fan ata_piix
Filesystem modules: xfs
Including: initramfs fsck.xfs
in other words if I would build kernel without initrd only the above would have to be build in the kernel (in my case -> specific hardware/fs setup). The rest can still be build as modules.
So to load initrd, you need very little time.
linux kernel is slow in terms of boot time when compared to BSD or windows (I assume some basic knowlege about windows).
For example default timeouts are quite long:
e.g. known issue with EHCI. If BIOS fail to handout EHCI to kernel, system waits 5 secs before timeout/giving up. This is super slow.
There is a lot of stuff that is pretty conservative (time wise). In some cases, this is good, in the other not so much.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.