nxtv2.0 Posted October 13, 2016 Posted October 13, 2016 Hi, I'm using the orange pi plus 2e with armbian server installed on eMMC via the built-in script,as the title says i want ways to reduce boot times. I only need ethernet and usb since i will be using it as a "virtualhere" server. Thanks, linux super noob. regards.
Drakoh Posted October 14, 2016 Posted October 14, 2016 Hi, you can get an overview of your system's startup with: # systemd-analyze blame or if you want to visualize it: # systemd-analyze plot > startup.svg In case you run a headless server, you should transfer this file to your pc, otherwise just open it on your Opi. Please be careful with disabling services you don't understand, make sure you have backups and read, read, read before doing anything. 1
nxtv2.0 Posted October 14, 2016 Author Posted October 14, 2016 Thank you will try it and report what services take alot of time to boot.
nxtv2.0 Posted October 14, 2016 Author Posted October 14, 2016 Ok here is a list after i removed a few: 1.669s networking.service 770ms systemd-logind.service 749ms systemd-udev-trigger.service 699ms rc-local.service 589ms systemd-user-sessions.service 569ms loadcpufreq.service 509ms systemd-setup-dgram-qlen.service 499ms systemd-modules-load.service 489ms kbd.service 479ms console-setup.service 409ms keymap.service 409ms systemd-random-seed.service 399ms systemd-remount-fs.service 389ms kmod-static-nodes.service 369ms systemd-tmpfiles-setup-dev.service 319ms cpufrequtils.service 299ms systemd-sysctl.service 281ms rsyslog.service 243ms dev-mqueue.mount 219ms systemd-tmpfiles-setup.service 202ms sys-kernel-debug.mount 150ms sys-fs-fuse-connections.mount 149ms systemd-rfkill@rfkill0.service 119ms udev-finish.service 119ms systemd-update-utmp.service 113ms systemd-update-utmp-runlevel.service 79ms sysfsutils.service 78ms user@0.service 57ms lirc.service 53ms systemd-udevd.service 10ms tmp.mount what services do i not need and are there other ways to reduce boot time.
Drakoh Posted October 15, 2016 Posted October 15, 2016 After u-boot loads the kernel, it boots under 2 sec, I don't see much stuff in there that you should disable., it's pretty lean as it is. How often do you reboot it anyway? Even if you reboot it everyday for some reason, saving 1sec wouldn't gain too much. Anyway, the faster the sdcard, the faster the OS can boot.
nxtv2.0 Posted October 15, 2016 Author Posted October 15, 2016 How do i start a service right after the kernel using systemd?
Drakoh Posted October 15, 2016 Posted October 15, 2016 Systemd starts services in parallel as soon as they can be started. What exactly are you trying to achieve?
nxtv2.0 Posted October 15, 2016 Author Posted October 15, 2016 Running virtualhere server as soon as kernel boots ~ 2.7s To decrease wait time before server is ready
Drakoh Posted October 15, 2016 Posted October 15, 2016 After the kernel, a lot of things have to be started in order to get a system on which applications can run. How do you start the service now?
nxtv2.0 Posted October 15, 2016 Author Posted October 15, 2016 (edited) Using my custom service: [Unit] Description=virtualhere After=system.slice DefaultDependencies=no [Service] ExecStart=/root/vhusbdarm Is there a way to make it faster , it takes about 20 secs for the client to see the server after power on. Update: What stuff runs before system.slice that makes it take time to boot? Edited October 15, 2016 by nxtv2.0
Drakoh Posted October 15, 2016 Posted October 15, 2016 AFAIK, with these settings systemd starts your service as soon as it can. One thing I still don't get is, you said you use your orangepi as a server, how often do you reboot your server?
nxtv2.0 Posted October 15, 2016 Author Posted October 15, 2016 I will be using this server to stream cameras in an rov and need to have it on very quick from cold boot. Is there a way to start a binary quicker than that and also what is taking systemd so long to run my serivce? Thanks in advance.
Drakoh Posted October 15, 2016 Posted October 15, 2016 At this point my only advice is a faster sdcard. Your other option would be a to seriously hack Armbian or build your own distro, but these are obviously not "noob-friendly" options. Maybe somebody else can help you out more.
arox Posted October 15, 2016 Posted October 15, 2016 For me, there are to possible approaches : - you use a linux distribution and never shut down the machine, witch is possible with low power fanless silent cards ... - you make an appliance : compile a light kernel, install a system like crux/lfs/gentoo with minimal software (without useless add-on and dependencies) and no initrd, no dynamic config and no udev and write your own init scripts in old BSD style (rc.boot / rc.local). Anyway, if your system needs udev and/or dbus you probably cannot cannot boot in less than 10 seconds ... It is a time-consuming project but not more than trying to do reverse engineering on freedesktop.org delirium ...
arox Posted October 16, 2016 Posted October 16, 2016 What is udev? The reason why your boot system is complex and takes a lot of time : in order to make the device drivers and other stuff "plugable" there is an awfully complex mechanic which receive events from the kernel and recreate all the pseudo-devices in /dev even if it is doing the same task ever and ever at each boot, although it is only useful if you add hardware. (A "pseudo-device" is basically just a pointer to the driver index and instance. Before it was simply added with mknod and only when installing unusual drivers). And there is little thing that can be finalize in boot process until this damned daemon has parsed all its "rules" files, waited for events and created the device nodes. It is totally stupid in a stable appliance system, and you could create and keep the nodes in the /dev directory of the root fs (as it was done before). But you need then to rewrite all the boot scripts, make a stripped kernel ... and all the wannabe windows-like software from freedesktop.org relying on dbus and soon on systemd will certainly not be usable anymore. The kernel needs 2 seconds to initialize. All the rest of the time is wasted to ensure distro management without manually editing the boot script(sssssssss), useless "services" organization, and "dynamic configuration". Anyway, you need to add the bios/uboot delay and the kernel load time. The kernel load time increase with its size and the unnecessary drivers and options - but it becomes more and more difficult to strip down the kernel. To give you an idea : you cannot remove the "huge file" support of ext4 in the kernel config : the system would not boot if (because) the rootfs was created (by default) with the "huge file" option. Same player shoot again ...
nxtv2.0 Posted October 16, 2016 Author Posted October 16, 2016 The kernel used to boot in 2.7s but when i reinstalled armbian on the eMMC again it now boots in almost 6s, how do i know what delays the kernel like that and what changed.i needed to reinstall as i had masked an important module and SSH wasn't connecting.
arox Posted October 16, 2016 Posted October 16, 2016 The kernel used to boot in 2.7s but when i reinstalled armbian on the eMMC again it now boots in almost 6s, how do i know what delays the kernel like that and what changed.i needed to reinstall as i had masked an important module and SSH wasn't connecting. - First you need a serial console - then you need to enable verbose in boot.cmd (legacy kernel images) - initrd is your enemy - firmware loading is your enemy - polling is your enemy - calibration is your enemy - dynamic network config and dhcp add delays and random behavior - not having a backup powered hardware clock is a big problem - stock kernels are your enemy Anyway, I never (and never will) try to fiddle with boot with "systemd" or parallel boot. Boot is a critical process and parallel processing makes it non deterministic.
Recommended Posts