Hi Dennis Lee,
Thank You very much for Your detailed reply with useful explanations and links.
From Your reply, I could understand that, we cannot reduce the boot time much by disabling startup programs. Most of this services are required for normal functionality.
Let me have a try by using iot image and emmc boot and check how much boot time, shall be reduced with it.
Thanks & Regards,
Sajeevan.K
Hi Robert Nelson,
Thank You very much for Your exact reply.
Now I am using lxqt image(bone-debian-8.7-lxqt-4gb-armhf-2017-03-19-4gb.img)
and this image is loaded in an SD card. And BBB is booting from SD card.As per Your reply, what I understood is, for getting a boot time of around
15seconds, I should use an iot image(which does not have graphical desktop),
and BBB should boot from emmc.
No, the "IOT" image isn't required.. You could use the lxqt image,
but it's eaiser to start minimal and build up, then removed a few
hundred applications in the lxqt image..
At this point, I have the following doubts.
By just using iot image(instead of lxqt image) and booting from emmc(instead
of SD card boot), is it possible to reduce the boot time around 15 seconds ?
Actually the 8-bit eMMC is slower then some of my 4-bit microSD card's...
15 seconds on microSD would not be a problem..
Even without graphical desktop like lxqt, can I run qt gui applications in
Beaglebone black with startx command and x window manager?
In my case i'm using openbox/xorg.
Is ssh through USB is supported with iot image?
all images..
Earlier I also was using emmc. I shifted to SD card, because 4GB was
insufficient for installing some packages and all.But now I just require to install qt-sdk, and even with that the flash usage
is only around 3.5G.
So "build" your application on one beagle with teh sdk, and then
transfer it to the other beagle with the minimal xorg setup...
Please clarify these points, so that I can have a try, for getting a lesser
boot time, with emmc boot and iot image.
Regards,
The big thing you need to remember, the "example" images are just
that. Example with everything enabled, so any user can just jump in..
Start with the small iot image and build up, then it's pretty easy to
minimize boot times..
Here's another one i'm working on:
root@arm:~# systemd-analyze
Startup finished in 1.543s (kernel) + 7.661s (userspace) = 9.204s
root@arm:~# uname -r
4.14.54-ti-r63
We are still getting killed by the fix for CVE-2018-1108 in v4.14.x
root@arm:~# dmesg | grep random:
[ 0.000000] random: get_random_bytes called from
start_kernel+0xac/0x460 with crng_init=0
[ 0.992879] random: fast init done
[ 1.676263] random: systemd: uninitialized urandom read (16 bytes read)
[ 1.679747] random: systemd: uninitialized urandom read (16 bytes read)
[ 1.875247] random: systemd-sysv-ge: uninitialized urandom read (16
bytes read)
[ 119.839484] random: crng init done
[ 119.839507] random: 7 urandom warning(s) missed due to ratelimiting
2 minute delay for "random: crng init done" so many userspace
applications get stuck waiting for that...
Regards,
On Fri, 13 Jul 2018 06:15:41 -0700 (PDT),
ksajeevan1975@gmail.com declaimed the
following:
Let me have a try by using iot image and emmc boot and check how much boot
time, shall be reduced with it.
Though you may have to start with an older IoT image, given R. Nelson's
comments about some "fix" killing boot times
https://access.redhat.com/security/cve/cve-2018-1108
(Hmmm, wonder if that affects the haveged process too)
I spent some time this weekend trying to reduce the boot times for my pocketbeagle based things. A few things I discovered:
The existence of an initrd in /boot adds 19 seconds to the boot. This is seen in the dmesg logs where the “EXT4-fs (mmcblk0p1): mounted filesystem” line is at the 20 second mark instead of the 1.1 second mark. No idea why, but since the initrd isn’t needed with the ext4 roots, just deleting it is huge. Too bad update_kernel creates it.
generic-board-startup.service takes up a HUGE amount of time, over 40 seconds. I started debugging into it and 30 seconds of that is just calling “systemctl start serial-getty@ttyGS0.service || true”. Changing that to “systemctl start serial-getty@ttyGS0.service &” drops boot time by almost 30 seconds. Is that something we could just “systemctl enable” and let systemd start it if ttyGS0 is found and not have to deal with it in the generic-board-startup? It’s a lot of time saved.
“config-pin -f pins.txt” also takes several seconds when configuring all 55 GPIO pins. I might look at optimizing that a bit for my use case by not using config-pin and just use the /sys/class/gpio stuff directly in my own script. Only a couple seconds though.
I spent some time this weekend trying to reduce the boot times for my
pocketbeagle based things. A few things I discovered:1) The existence of an initrd in /boot adds 19 seconds to the boot. This
is seen in the dmesg logs where the "EXT4-fs (mmcblk0p1): mounted
filesystem" line is at the 20 second mark instead of the 1.1 second mark.
No idea why, but since the initrd isn't needed with the ext4 roots, just
deleting it is huge. Too bad update_kernel creates it.
This is only needed for kernels: 3.8 -> 4.3.x-ish (uuid mmc id) and
3.8 -> 4.1.x (kernel overlays)..
I'm thinking of nuking the initrd by default going forward..
2) generic-board-startup.service takes up a HUGE amount of time, over 40
seconds. I started debugging into it and 30 seconds of that is just calling
"systemctl start serial-getty@ttyGS0.service || true". Changing that to
"systemctl start serial-getty@ttyGS0.service &" drops boot time by almost 30
seconds. Is that something we could just "systemctl enable" and let systemd
start it if ttyGS0 is found and not have to deal with it in the
generic-board-startup? It's a lot of time saved.
Good point, no reason to not fork that. 
"config-pin -f pins.txt" also takes several seconds when configuring all 55
GPIO pins. I might look at optimizing that a bit for my use case by not
using config-pin and just use the /sys/class/gpio stuff directly in my own
script. Only a couple seconds though.
Regards,
Hi Robert Nelson, Dennis Lee & Daniel Kulp,
Thank You very much for the reply and support.
I have been little busy with some other tasks. So I couldn’t test with the iot image.
I am hopeful in the idea of starting from iot image and build up from it.
Will the fix for CVE-2018-1108, affect the normal booting of Beaglebone black? Is there a chance that normal applications access random data at boot time?
Is this fix applied only for Kernel 4.14. Can we avoid this problem by using kernel 4.4 or 4.9(I think Our application does not require that much big security). What about building a minimal image for beaglebone black with kernel 4.4 or 4.9 as shown in
https://eewiki.net/display/linuxonarm/BeagleBone+Black.
Thanks & Regards,
Sajeevan.K
Even with the fix for that CVE, v4.14.x is still faster then v4.9.x..
It just use to be 'way' faster..
Regards,
Hi Robert Nelson,
I shall start with v4.14 iot image and build up from it. Thank You very much.
Thanks & Regards,
Sajeevan.K
Hi everybody, it seems 2 years passed from the last message, I hope Robert Nelson can see that message and help me too.
I have the similar problem, but mine is a bit different.
Similar to FLIR, I want to run just one qt app. But I also need TCA8418 keypad driver, which is not compiled et any of the brebuiled image kernel. Therefore, i tried to build my own kernel with that driver selected at the configurator. It worked good, but boot time is so much. (2:40). Acording to this topic, i understand that reducing this time is a bit difficult if i use mine image. If i strt to use IoT image sources, while building my image then it would be better. But i can not find any information that tells how an IoT iamge is produced.
By the way, i am not sure the selected way is the correct one. May be adding the driver to the prebuild image would be a better choice. But i do not know how to do.
Thanks in advance,
18 Temmuz 2018 Çarşamba tarihinde saat 17:57:58 UTC+3 itibarıyla sajeevan k şunları yazdı:
Hi Robert,
Awesome work with the Beaglebone OS and tools. Entry point for a beginier is so much simplified using the tools you provide.
I know this topic is OLD.
I have been trying to get my boot times with a BBB down from about 50s to 20s
I have started with a Debian Stretch 9.12 console image. Upgraded it to realtime kernel 4.19. Booting from EMMC.
Trying to get a single console app or X11 app open in less than 20-25s
This is my output for systemd-analyze blame
debian@beaglebone:~$ systemd-analyze
Startup finished in 1.690s (kernel) + 50.841s (userspace) = 52.532s
debian@beaglebone:~$ systemd-analyze blame
1min 15.560s dev-mmcblk1p1.device
8.459s generic-board-startup.service
4.654s systemd-udev-trigger.service
3.188s loadcpufreq.service
2.620s networking.service
2.157s keyboard-setup.service
1.791s systemd-logind.service
1.711s dnsmasq.service
1.631s ssh.service
1.529s rsyslog.service
1.429s user@1001.service
1.418s systemd-journald.service
1.204s cpufrequtils.service
1.071s systemd-timesyncd.service
918ms systemd-fsck-root.service
597ms systemd-udevd.service
528ms dev-mqueue.mount
515ms sys-kernel-debug.mount
495ms systemd-tmpfiles-setup-dev.service
469ms systemd-tmpfiles-setup.service
451ms systemd-sysctl.service
417ms systemd-modules-load.service
400ms systemd-user-sessions.service
388ms sys-fs-fuse-connections.mount
369ms systemd-journal-flush.service
355ms slim.service
324ms systemd-update-utmp.service
311ms sys-kernel-config.mount
303ms kmod-static-nodes.service
300ms systemd-remount-fs.service
238ms console-setup.service
210ms systemd-random-seed.service
140ms systemd-update-utmp-runlevel.service
debian@beaglebone:~$ uname -a
Linux beaglebone 4.19.94-ti-rt-r63 #1stretch SMP PREEMPT RT Fri May 14 16:42:35 UTC 2021 armv7l GNU/Linux
Any advise you can give to reduce the userspace time further?
IT would be really helpful if you could list the optimizations you did for the FLIR demo app.
Regards,
amit
Hi Amit,
Interesting. 4.19.94 is a only a little bit faster than 4.14.108. Is there a document somewhere that explains what to do to even just speed up both start up and shut down?
What did you do to get it to 50 seconds?
John
debian@ebb:~$ uname -a
Linux ebb 4.14.108-ti-r136 #1stretch SMP PREEMPT Mon Jun 8 15:38:30 UTC 2020 armv7l GNU/Linux
debian@ebb:~$ systemd-analyze
Startup finished in 40.059s (kernel) + 1min 27.889s (userspace) = 2min 7.948s
debian@ebb:~$ systemd-analyze blame
1min 47.177s dev-mmcblk0p1.device
1min 13.819s generic-board-startup.service
debian@beaglebone:~$ uname -a
Linux beaglebone 4.19.94-ti-r63 #1buster SMP PREEMPT Fri May 14 16:42:32 UTC 2021 armv7l GNU/Linux
debian@beaglebone:~$ systemd-analyze
Startup finished in 26.608s (kernel) + 1min 32.506s (userspace) = 1min 59.114s
graphical.target reached after 1min 32.205s in userspace
debian@beaglebone:~$ systemd-analyze blame
1min 20.997s generic-board-startup.service
1min 4.519s dev-mmcblk0p1.device
11.344s udisks2.service
Just to add a data point: Buster IoT image on uSD card...
debian@beaglebone:~$ uname -a
Linux beaglebone 4.19.94-ti-r48 #1buster SMP PREEMPT Wed Aug 19 17:38:55
UTC 2020 armv7l GNU/Linux
debian@beaglebone:~$ systemd-analyze
Startup finished in 10.915s (kernel) + 1min 961ms (userspace) = 1min
11.877s
graphical.target reached after 1min 668ms in userspace
That's odd -- Did I leave the LXQT image in the board (I have uSD for
both IoT and LXQT)
debian@beaglebone:~$ systemd-analyze blame
51.745s generic-board-startup.service
40.798s dev-mmcblk0p1.device
4.064s nginx.service
3.587s systemd-udev-trigger.service
From DMESG one finds such ...
[ 1.668861] ALSA device list:
[ 1.668877] #0: TI BeagleBone Black
[ 1.675450] Freeing unused kernel memory: 1024K
[ 1.676178] Run /init as init process
[ 2.664089] [drm] Cannot find any crtc or sizes
[ 10.155042] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data
mode. Opts: (null)
[ 10.955497] systemd[1]: System time before build time, advancing clock.
EIGHT seconds mounting file system
[ 13.203659] EXT4-fs (mmcblk0p1): re-mounted. Opts: errors=remount-ro
[ 14.816264] systemd-journald[893]: Received request to flush runtime
journal from PID 1
[ 21.928916] net eth0: initializing cpsw version 1.12 (0)
[ 22.000769] SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver
[SMSC LAN8710/LAN8720] (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)
SEVEN seconds initializing eth0
[ 27.071692] configfs-gadget gadget: high-speed config #1: c
[ 27.072147] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
[ 27.277845] IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready
[ 69.566416] remoteproc remoteproc0: wkup_m3 is available
[ 69.658941] remoteproc remoteproc0: powering up wkup_m3
[ 69.658973] remoteproc remoteproc0: Booting fw image
am335x-pm-firmware.elf, size 217168
FORTY seconds preparing the PRUs with remoteproc
Let me switch uSD card...
debian@beaglebone:~$ uname -a
Linux beaglebone 4.19.94-ti-r48 #1buster SMP PREEMPT Wed Aug 19 17:38:55
UTC 2020 armv7l GNU/Linux
debian@beaglebone:~$ systemd-analyze
Bootup is not yet finished
(org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0).
Please try again later.
Hint: Use 'systemctl list-jobs' to see active jobs
debian@beaglebone:~$ systemctl list-jobs
JOB UNIT TYPE STATE
89 getty.target start waiting
69 generic-board-startup.service start running
97 serial-getty@ttyGS0.service start waiting
2 multi-user.target start waiting
1 graphical.target start waiting
81 systemd-update-utmp-runlevel.service start waiting
98 dev-ttyGS0.device start running
7 jobs listed.
Hmmm, looks like I need to attach an HDMI cable and monitor to
determine which has the LXQT image...
debian@beaglebone:~$ systemctl list-jobs
No jobs running.
debian@beaglebone:~$ systemd-analyze
Startup finished in 11.355s (kernel) + 1min 24.913s (userspace) = 1min
36.268s
graphical.target reached after 1min 24.632s in userspace
debian@beaglebone:~$ systemd-analyze blame
1min 15.551s generic-board-startup.service
1min 1.691s dev-mmcblk0p1.device
9.380s udisks2.service
DMESG output snippets
[ 1.928371] Run /init as init process
[ 2.920215] [drm] Cannot find any crtc or sizes
[ 10.473694] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data
mode. Opts: (null)
[ 11.394359] systemd[1]: System time before build time, advancing clock.
SEVEN and a half seconds mounting filesystem
[ 14.116062] EXT4-fs (mmcblk0p1): re-mounted. Opts: errors=remount-ro
[ 15.517709] systemd-journald[901]: Received request to flush runtime
journal from PID 1
[ 22.417276] net eth0: initializing cpsw version 1.12 (0)
[ 22.532858] SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver
[SMSC LAN8710/LAN8720]
SEVEN on eth0
[ 29.411733] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
[ 29.769247] IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready
[ 93.327879] remoteproc remoteproc0: wkup_m3 is available
[ 93.335402] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc handle
[ 93.484677] remoteproc remoteproc0: powering up wkup_m3
SIXTY on PRU remoteproc stuff.
Hi Amit,
Interesting. 4.19.94 is a only a little bit faster than 4.14.108. Is there a document somewhere that explains what to do to even just speed up both start up and shut down?
What did you do to get it to 50 seconds?
John
Hi John,
I did not do much actually to get to 50s.
Started from a console Image : https://rcn-ee.com/rootfs/bb.org/testing/2020-05-02/stretch-console/bone-eMMC-flasher-debian-9.12-console-armhf-2020-05-02-1gb.img.xz
replaced the kernel:
cd /opt/scripts/tools/
sudo su
git pull
./update_kernel.sh --ti-rt-channel --lts-4_19
removed wpasupplicant and connman and old kernel
sudo apt-get purge linux-image-4.14.108-ti-r134 wpasupplicant connman
debian@beaglebone:~$ systemd-analyze
Startup finished in 13.502s (kernel) + 36.686s (userspace) = 50.188s
I then removed the initrd file in /boot directory (From what I understand this kernel does not necessarily need initrd).
debian@beaglebone:/boot$ sudo mv initrd.img-4.19.94-ti-rt-r63 moved-initrd.img-4.19.94-ti-rt-r63
Removing the initrd gives the max speedup for kernel. From 10s-13s with initrd, it reduces to 1s-2s
debian@beaglebone:~$ systemd-analyze
Startup finished in 1.663s (kernel) + 36.385s (userspace) = 38.048s
debian@beaglebone:~$ systemd-analyze blame
1min 4.266s dev-mmcblk1p1.device
26.360s generic-board-startup.service
3.847s systemd-udev-trigger.service
2.824s loadcpufreq.service
2.215s networking.service
1.647s ssh.service
1.396s user@1000.service
1.209s rsyslog.service
1.189s systemd-journald.service
999ms dnsmasq.service
897ms cpufrequtils.service
855ms systemd-timesyncd.service
674ms systemd-fsck-root.service
642ms systemd-logind.service
505ms systemd-udevd.service
445ms systemd-user-sessions.service
408ms systemd-tmpfiles-setup-dev.service
389ms systemd-update-utmp.service
375ms hostapd.service
365ms systemd-modules-load.service
326ms dev-mqueue.mount
324ms systemd-random-seed.service
312ms sys-kernel-config.mount
291ms systemd-tmpfiles-setup.service
274ms sys-kernel-debug.mount
236ms kmod-static-nodes.service
231ms sys-fs-fuse-connections.mount
200ms systemd-remount-fs.service
190ms systemd-journal-flush.service
185ms systemd-sysctl.service
145ms systemd-update-utmp-runlevel.service
130ms systemd-tmpfiles-clean.service
Next point to attack is the generic-board-startup.service. The main time that process spends is in the file /opt/scripts/boot/am335x_evm.sh
This takes care of the USB flash, Serial and network gadgets that are initialized. Remove items which are not needed. It also has a lot of generic selections for Beagle family boards which can be removed. I am working on my version for just beaglebone black with only network over USB support.
Some ideas can be found here (generic-board-startup.service takes a long time to run, contributing to slow boot time. · Issue #10 · RobertCNelson/boot-scripts · GitHub)
Hope that helps.
-amit
Thanks. Yes. It does.
John
removed wpasupplicant and connman and old kernel
sudo apt-get purge linux-image-4.14.108-ti-r134 wpasupplicant connman
debian@beaglebone:~$ systemd-analyze
Startup finished in 13.502s (kernel) + 36.686s (userspace) = 50.188s
I then removed the initrd file in /boot directory (From what I understand this kernel does not necessarily need initrd).
debian@beaglebone:/boot$ sudo mv initrd.img-4.19.94-ti-rt-r63 moved-initrd.img-4.19.94-ti-rt-r63Removing the initrd gives the max speedup for kernel. From 10s-13s with initrd, it reduces to 1s-2s
debian@beaglebone:~$ systemd-analyze
Startup finished in 1.663s (kernel) + 36.385s (userspace) = 38.048s
debian@beaglebone:~$ systemd-analyze blame
1min 4.266s dev-mmcblk1p1.device
26.360s generic-board-startup.service
3.847s systemd-udev-trigger.service
2.824s loadcpufreq.service
You can nuke this ^, it's really only for am57xx, so we can
downclock.. But on am335x, let it run at full speed as these are set:
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
2.215s networking.service
1.647s ssh.service
1.396s user@1000.service
1.209s rsyslog.service
1.189s systemd-journald.service
999ms dnsmasq.service
897ms cpufrequtils.service
Same as above..
855ms systemd-timesyncd.service
674ms systemd-fsck-root.service
642ms systemd-logind.service
505ms systemd-udevd.service
445ms systemd-user-sessions.service
408ms systemd-tmpfiles-setup-dev.service
389ms systemd-update-utmp.service
375ms hostapd.service
You nuked wpasupplicant, get rid of hostapd..
Thanks a lot Robert. Your help is most appreciated.
I have implemented your suggestions and removed the following services
loadcpufreq.service
cpufrequtils.service
hostapd.service
My current boot time still ranges between 48s to 52s
debian@beaglebone:~$ systemd-analyze
Startup finished in 1.751s (kernel) + 48.369s (userspace) = 50.120s
debian@beaglebone:~$ systemd-analyze blame
1min 14.318s dev-mmcblk1p1.device
9.419s generic-board-startup.service
5.353s systemd-udev-trigger.service
2.470s keyboard-setup.service
2.438s networking.service
2.423s ssh.service
2.161s dnsmasq.service
1.718s systemd-logind.service
1.613s systemd-journald.service
1.018s systemd-timesyncd.service
969ms systemd-fsck-root.service
730ms systemd-udevd.service
595ms user@1001.service
589ms rsyslog.service
549ms slim.service
500ms sys-kernel-debug.mount
488ms systemd-tmpfiles-setup-dev.service
479ms systemd-update-utmp.service
469ms dev-mqueue.mount
456ms systemd-sysctl.service
451ms systemd-tmpfiles-setup.service
384ms systemd-modules-load.service
380ms sys-kernel-config.mount
352ms systemd-journal-flush.service
344ms systemd-user-sessions.service
319ms systemd-update-utmp-runlevel.service
310ms systemd-random-seed.service
284ms kmod-static-nodes.service
257ms sys-fs-fuse-connections.mount
250ms systemd-remount-fs.service
227ms console-setup.service
Any suggestions to bring it down further?
I am using a X desktop with slim as the login manager with autologin on LCD.
From the generic board startup services, I am using network over USB (not the serial over USB and flash over USB) parts.
What else should I be able to nuke to get the time faster?
Regards,
-amit
Hi Robert,
I just realized that I need to use an overlayfs (via overlayroot) to protect the emmc / OS from crashing on sudden power off.Now overlaytroot needs the initrd image to work.
So I had to enable the /boot/initrd.img-4.19.94-ti-rt-r63 file.
Re-enablingthe initird file in /boot added about 48 to 50s to the kernel boot time ;-(
Any ideas on how to mitigate that? how to get the booting time down?
Thanks & Regards,
-amit
debian@beaglebone:/$ systemd-analyze
Startup finished in 58.454s (kernel) + 49.641s (userspace) = 1min 48.096s
debian@beaglebone:/$ systemd-analyze blame
1min 21.167s dev-mmcblk1p1.device
10.477s generic-board-startup.service
5.278s systemd-udev-trigger.service
2.907s networking.service
2.684s ssh.service
2.328s keyboard-setup.service
1.940s dnsmasq.service
1.661s systemd-journald.service
1.101s systemd-user-sessions.service
895ms systemd-udevd.service
845ms user@1001.service
785ms systemd-random-seed.service
766ms systemd-timesyncd.service
754ms systemd-tmpfiles-setup-dev.service
725ms systemd-modules-load.service
670ms systemd-update-utmp.service
657ms systemd-logind.service
645ms sys-kernel-config.mount
641ms sys-kernel-debug.mount
603ms systemd-tmpfiles-setup.service
572ms kmod-static-nodes.service
518ms rsyslog.service
515ms systemd-sysctl.service
408ms systemd-remount-fs.service
358ms slim.service
351ms console-setup.service
324ms systemd-journal-flush.service
280ms sys-fs-fuse-connections.mount
272ms systemd-tmpfiles-clean.service
228ms systemd-update-utmp-runlevel.service
223ms dev-mqueue.mount
Hi
I am working for the boot time optimization for the beagle bone green wireless board
Now with some above mentioned suggestions, I am able to reduce the boot time from 90 sec to 45 sec.
But I want to further reduce it to 30 sec.
Please guide me the further points where I can optimize it.
The current detail of my board is as below
Startup finished in 4.295s (kernel) + 38.147s (userspace) = 42.442s
ubuntu@arm:~$ systemd-analyze -blaim
systemd-analyze: invalid option – ‘b’
ubuntu@arm:~$ systemd-analyze blame
25.275s console-setup.service
17.904s dev-mmcblk1p1.device
15.945s postfix.service
12.165s generic-board-startup.service
8.654s apache2.service
7.635s systemd-logind.service
6.160s avahi-daemon.service
5.594s systemd-hwdb-update.service
5.568s ondemand.service
5.432s loadcpufreq.service
4.968s bb-wl18xx-bluetooth.service
4.578s led-status.service
3.547s networking.service
2.981s capemgr.service
2.412s hostapd.service
2.389s rsyslog.service
2.073s cpufrequtils.service
1.535s ssh.service
1.477s systemd-user-sessions.service
1.389s pppd-dns.service
1.151s systemd-udev-trigger.service
1.040s archive_log.service
1.011s systemd-journal-flush.service
979ms rc-local.service
860ms brltty.service
653ms keyboard-setup.service
629ms systemd-journald.service
609ms tacread-keymap.service
499ms rename-bluetooth-hardware.service
494ms systemd-update-utmp.service
462ms systemd-udevd.service
451ms resolvconf.service
437ms dev-mqueue.mount
437ms sys-kernel-debug.mount
Thanks
Karishma Jaiswal
15.945s postfix.service
Do you need a mail delivery service? http://www.postfix.org/ You have
scripts sending emails?
12.165s generic-board-startup.service
8.654s apache2.service
Do you need a web-server -- and if you do, does it have to be Apache?
Consider that nginx is installed as part of the normal Debian images.
7.635s systemd-logind.service
6.160s avahi-daemon.service
"""
avahi-daemon.service is supposed to provide zero-configuration network
discovery, and make it super-easy to find printers and other hosts on your
network. I always disable it and don’t miss it.
"""
5.594s systemd-hwdb-update.service
5.568s ondemand.service
5.432s loadcpufreq.service
4.968s bb-wl18xx-bluetooth.service
4.578s led-status.service
3.547s networking.service
2.981s capemgr.service
2.412s hostapd.service
Do you need to have the unit operate as a WiFi hotspot (Access Point)?
Note: not sure if the authentication feature is used for regular connection
/to/ an access point (WiFi Router). hostapd(8) - OpenBSD manual pages
2.389s rsyslog.service
2.073s cpufrequtils.service
1.535s ssh.service
1.477s systemd-user-sessions.service
1.389s pppd-dns.service
Same web site:
"""
pppd-dns.service is a relic of the dim past. If you use dial-up Internet,
keep it. Otherwise, you don’t need it.
"""
1.151s systemd-udev-trigger.service
1.040s archive_log.service
1.011s systemd-journal-flush.service
979ms rc-local.service
860ms brltty.service
Ditto:
"""
brltty.service provides Braille device support, for example, Braille
displays.
"""
653ms keyboard-setup.service
629ms systemd-journald.service
609ms tacread-keymap.service
Can't find any information on "tacread" via Google... Nor via apt
search in Buster IoT release.