LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   Arch UEFI loading pretty slow in Virtualbox? (https://www.linuxquestions.org/questions/linux-newbie-8/arch-uefi-loading-pretty-slow-in-virtualbox-4175554969/)

Feliks 10-01-2015 01:43 AM
Arch UEFI loading pretty slow in Virtualbox?
 
Just curious as I'm planning to put Arch Linux on a UEFI Triple boot system soon, but the loading times are pretty dang slow testing it through Virtualbox. Is this because of the Virtualbox (can I expect good, faster speeds when I actually install it to my triple boot system) or is Arch unusually slow for UEFI? (Which I'm pretty sure is supposed to be faster than BIOS to start with)

Head_on_a_Stick 10-01-2015 02:21 AM
I can boot my Arch systems in either UEFI or "BIOS" mode and the time appears to be identical for both methods (as reported by `systemd-analyze`).

The only difference is that the non-UEFI bootup usually involves a manufacturer splash screen for the firmware which may take a second or so to disappear.

Feliks 10-02-2015 12:54 PM
Thank you. How are the times compared to debian?

Head_on_a_Stick 10-03-2015 09:54 AM
Quote:
Originally Posted by Feliks (Post 5428928)
How are the times compared to debian?
Interestingly, Debian is consistently faster (~4.0 seconds vs. ~4.3 seconds).

Feliks 10-10-2015 06:09 PM
Quote:
Originally Posted by Head_on_a_Stick (Post 5429271)
Interestingly, Debian is consistently faster (~4.0 seconds vs. ~4.3 seconds).
That is interesting. I would think Arch ought to be faster, being more minimalistic & such. Is it noticeable faster then or only if you're looking for it?

Head_on_a_Stick 10-11-2015 10:26 AM
Quote:
Originally Posted by Feliks (Post 5432782)
Is it noticeable faster then or only if you're looking for it?
It's very close indeed and not at all noticeable.

That was from an old system that I managed to hose (botched btrfs conversion).

I have a new dual-boot Arch [testing]/Debian jessie set up now.

Here is the jessie time:
Code:
empty@jessie ~ % systemd-analyze
Startup finished in 3.019s (kernel) + 1.619s (userspace) = 4.639s
empty@jessie ~ % systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @1.616s
└─multi-user.target @1.616s
  └─nftables.service @346ms +1.270s
    └─basic.target @345ms
      └─timers.target @344ms
        └─systemd-tmpfiles-clean.timer @344ms
          └─sysinit.target @344ms
            └─systemd-backlight@backlight:intel_backlight.service @1.492s +1ms
              └─system-systemd\x2dbacklight.slice @1.491s
                └─system.slice @74ms
                  └─-.slice @73ms
That's using NetworkManager though -- I will probably switch to systemd-networkd and shave a second off that time.

I'll edit this with my Arch time later...

EDIT: From Arch:
Code:
empty@Arch ~ % systemd-analyze
Startup finished in 3.762s (firmware) + 429ms (loader) + 2.637s (kernel) + 1.936s (userspace) = 8.765s
empty@Arch ~ % systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @1.936s
└─multi-user.target @1.936s
  └─systemd-resolved.service @1.905s +30ms
    └─network.target @1.904s
      └─systemd-networkd.service @1.874s +30ms
        └─network-pre.target @1.873s
          └─nftables.service @1.574s +298ms
            └─basic.target @1.571s
              └─sockets.target @1.571s
                └─dbus.socket @1.571s
                  └─sysinit.target @1.571s
                    └─systemd-backlight@backlight:intel_backlight.service @535ms +1.035s
                      └─system-systemd\x2dbacklight.slice @535ms
                        └─system.slice @85ms
                          └─-.slice @81ms
The Arch system is controlling the boot process (with systemd-boot, Secure Boot enabled) so the `systemd-analyze` output shows the firmware & (systemd-boot, née gummiboot) loader times as well.

Just taking the "kernel" & "userspace" times shows a pretty much identical result (but with Debian using the slower NetworkManager.service).

On the stopwatch (ie, including the firmware & loader times for both systems), I can detect no difference between the two.

Feliks 10-11-2015 04:51 PM
Quote:
Originally Posted by Head_on_a_Stick (Post 5433007)
It's very close indeed and not at all noticeable.

That was from an old system that I managed to hose (botched btrfs conversion).

I have a new dual-boot Arch [testing]/Debian jessie set up now.

Here is the jessie time:
Code:
empty@jessie ~ % systemd-analyze
Startup finished in 3.019s (kernel) + 1.619s (userspace) = 4.639s
empty@jessie ~ % systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @1.616s
└─multi-user.target @1.616s
  └─nftables.service @346ms +1.270s
    └─basic.target @345ms
      └─timers.target @344ms
        └─systemd-tmpfiles-clean.timer @344ms
          └─sysinit.target @344ms
            └─systemd-backlight@backlight:intel_backlight.service @1.492s +1ms
              └─system-systemd\x2dbacklight.slice @1.491s
                └─system.slice @74ms
                  └─-.slice @73ms
That's using NetworkManager though -- I will probably switch to systemd-networkd and shave a second off that time.

I'll edit this with my Arch time later...

EDIT: From Arch:
Code:
empty@Arch ~ % systemd-analyze
Startup finished in 3.762s (firmware) + 429ms (loader) + 2.637s (kernel) + 1.936s (userspace) = 8.765s
empty@Arch ~ % systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @1.936s
└─multi-user.target @1.936s
  └─systemd-resolved.service @1.905s +30ms
    └─network.target @1.904s
      └─systemd-networkd.service @1.874s +30ms
        └─network-pre.target @1.873s
          └─nftables.service @1.574s +298ms
            └─basic.target @1.571s
              └─sockets.target @1.571s
                └─dbus.socket @1.571s
                  └─sysinit.target @1.571s
                    └─systemd-backlight@backlight:intel_backlight.service @535ms +1.035s
                      └─system-systemd\x2dbacklight.slice @535ms
                        └─system.slice @85ms
                          └─-.slice @81ms
The Arch system is controlling the boot process (with systemd-boot, Secure Boot enabled) so the `systemd-analyze` output shows the firmware & (systemd-boot, née gummiboot) loader times as well.

Just taking the "kernel" & "userspace" times shows a pretty much identical result (but with Debian using the slower NetworkManager.service).

On the stopwatch (ie, including the firmware & loader times for both systems), I can detect no difference between the two.
That was super informative, haha. Thank you! :) Cheers.


All times are GMT -5. The time now is 09:41 AM.