You are not logged in.
Hi,
I use gummiboot as my boot manager with Arch Linux in my UEFI enabled laptop.
When I do a systemd-analyze, I see that I get a little more than 4s in the firmware, and rest of the process takes little less than 4 sec. I use a SSD drive.
Is this normal or can I reduce the time spent in the firmware ?
Thanks, Debasish
Keep Calm, And Enjoy Life
Offline
You can look for fastboot settings in the setup. However, I have never seen UEFI firmware booting in less than 4 seconds.
Offline
Thanks brain0 for the response.
Could you explain where do I find fastboot settings? Are u refering to the UEFI settings or some settings from the arch linux ?
Keep Calm, And Enjoy Life
Offline
fastboot is a setting in your firmware/bios
Offline
I don't have any fast boot setting in the my firmware, although I can see secure boot in UEFI. My model is Sony Vaio SVT14113CN.
Anyone with SSD and firmware boot time less than 4s ?
Thanks
Keep Calm, And Enjoy Life
Offline
why would you expect the time spent in firmware to be affected by a ssd? at that point in the boot process the only interaction between these two things is the machine code equivalent of FW:'anyone there?' ssd:'me me me' (grossly oversimplified)
edit: add boot time as requested below https://bbs.archlinux.org/viewtopic.php … 1#p1389691
Last edited by the_shiver (2014-03-07 17:04:15)
Offline
@the_shiver : It would have made sense if you would have posted the time your computer takes to boot up firmware . I didn't understand how your comment is going to be of any help for the question I asked.
Keep Calm, And Enjoy Life
Offline
@Debasish Patra, that was a direct answer as to why you cannot really do anything about what your firmware is doing. I'm not quite sure what you seemed to read there, but to me he gave you a nice simple explanantion of what is going on.
Offline
What the_shiver is trying to explain, is the fact that those 4 seconds of firmware booting is nothing else then firmware detecting hardware. You are not booting
from the ssd itself yet. So the speed of the ssd at this point in the booting proces is irrelevant.
Edit: As Wonderwoofy wrote, the_shiver put it down very nice and simple
Last edited by henk (2014-03-07 16:46:14)
Offline
I know that it has nothing to do wth ssd. I asked if it is possible to reduce time at firmware stage by any means other than tweaking our firmware setting. It seems henk provided me with an appropriate answer. Adding ssd in the comment really confused many Thanks henk.
Last edited by Debasish Patra (2014-03-07 16:57:08)
Keep Calm, And Enjoy Life
Offline
What bothers me is below output of systemd-analyze and 3.643 sec in my firmware alone?
d@d-machine ~]$ systemd-analyze
Startup finished in 3.643s (firmware) + 132ms (loader) + 3.145s (kernel) + 622ms (userspace) = 7.543s
Here is my systemd-analyze blame
[d@d-machine ~]$ systemd-analyze blame
371ms NetworkManager.service
88ms udisks2.service
86ms lightdm.service
59ms systemd-udev-trigger.service
54ms upower.service
39ms systemd-logind.service
35ms systemd-tmpfiles-setup-dev.service
34ms systemd-remount-fs.service
33ms accounts-daemon.service
22ms polkit.service
22ms systemd-user-sessions.service
20ms user@1000.service
20ms systemd-rfkill@rfkill0.service
17ms systemd-sysctl.service
16ms systemd-rfkill@rfkill1.service
12ms systemd-backlight@backlight:acpi_video0.service
11ms tmp.mount
10ms sys-kernel-debug.mount
9ms bluetooth.service
8ms systemd-backlight@backlight:intel_backlight.service
7ms kmod-static-nodes.service
7ms systemd-tmpfiles-setup.service
6ms dev-mqueue.mount
6ms systemd-readahead-replay.service
6ms rtkit-daemon.service
6ms dev-hugepages.mount
5ms systemd-journal-flush.service
5ms wpa_supplicant.service
5ms sys-kernel-config.mount
5ms systemd-rfkill@rfkill2.service
4ms systemd-tmpfiles-clean.service
4ms systemd-vconsole-setup.service
4ms systemd-readahead-collect.service
4ms systemd-hostnamed.service
4ms systemd-random-seed.service
3ms systemd-udevd.service
2ms systemd-update-utmp.service
2ms systemd-readahead-done.service
2ms sys-fs-fuse-connections.mount
Is there any scope of improvement in boot times ?
Keep Calm, And Enjoy Life
Offline
If you use systemd in place of udev (and optionally base) in the initramfs, it should speed things up a bit. But more importantly, it will give you distinct times for the kernel load time and the initramfs, instead of lumping it all into the 'kernel'.
There is a whole thread on systemd boot times. Throughout it are quite a few tips and tricks in how to improve boot time. But unless you are doing it for the sake of learning, there is not much to be gained from trying to improve things. You figure the time you spend trying to fix things up will far exceed the time you actually save in the long run.
Right off the bat though, I see you are using the readahead services with an SSD. This is probably not optimal since SSDs have negligible seek times.
Offline
Thanks WonderWoofy, that was helpful for me to get started
Keep Calm, And Enjoy Life
Offline