Announcement

Collapse
No announcement yet.

How Intel's Clear Linux Team Cut The Kernel Boot Time From 3 Seconds To 300 ms

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by V1tol View Post

    Actually you can boot into UEFI in this case - Windows 10 has a special button in Settings app On Linux Google says
    Code:
    systemctl reboot --firmware-setup
    can do that also.
    That is nice to see, will try it in the weekend.

    Comment


    • #42
      Originally posted by hotaru View Post

      while you can disable the ~3 second timeout for entering setup, those 3 seconds are insignificant compared to the 15 or more seconds the firmware takes regardless of the quick boot setting.
      That is a extreme case. None of my personal systems takes 15 seconds until grub show up. I'm not saying you haven't a system like that, but not all of them are as bad as this.

      Comment


      • #43
        Originally posted by Michael View Post

        Why not just use Clear Linux itself?
        Because - as you yourself said in your review - it has some nuisances and drawbacks. For a personal use system, I want something a bit more polished and put-together, with the ability to install the stuff I want to install, without having to do a ton of manual config work via command line, hacks, or text file configs.

        Comment


        • #44
          Originally posted by TheLexMachine View Post

          Because - as you yourself said in your review - it has some nuisances and drawbacks. For a personal use system, I want something a bit more polished and put-together, with the ability to install the stuff I want to install, without having to do a ton of manual config work via command line, hacks, or text file configs.
          It's getting fairly polished these days, even more so since switching to it myself they introduced their new installer / developer edition and other enhancements. More than likely Intel would better polish Clear Linux itself than the chances of someone else creating a downstream of it and trying to get it all polished into a better state.
          Michael Larabel
          http://www.michaellarabel.com/

          Comment


          • #45
            Originally posted by andyprough View Post
            My sysvinit antiX system boots in a lot less than minutes. Not sure why it would take so long unless you purposely or incompetently set it up that way.
            Ok, ok, that's a special case, you can get away with less if your hardware is more powerful.

            Those times are from an embedded device running Debian. Kirkwood SoC. Not terribly powerful ARMv5 (armel Debian arch), and OS is on a flash drive that isn't particularly fast. Took 1 minute and something to fully boot the OS and the 2-3 services I needed it to do.
            And no it was not just sitting there waiting for ethernet connection.

            Switched to systemd on the same system when Debian did the switch, boom. 20 seconds of OS boot time, like a boss.

            Comment


            • #46
              Originally posted by [email protected] View Post
              That is nice to see, will try it in the weekend.
              GRUB is also able to do that with the "grub commands", in UEFI systems there is a command to reboot to UEFI setup, "fwsetup".
              You can add them as GRUB menu options or by getting into GRUB commandline and writing the command directly
              https://wiki.archlinux.org/index.php/GRUB#GRUB_commands

              Also rEFInd boot loader/manager can do that (and offers it by default).

              If the above does not work (many want UEFI to not be like that, but it do), there is a more manual way with efibootmgr (that writes this in UEFI vars) from inside the booted system.

              It's usually

              sudo efibootmgr -n 0

              as the "0" boot option is commonly the UEFI setup menu or a boot menu where you can then select to go in UEFI setup, but check what options you actually have in your system.

              sudo efibootmgr

              See the following example for a HP laptop
              Code:
              BootCurrent: 000A
              Timeout: 0 seconds
              BootOrder: 000A,000B,000E,000F,0010,000D,000C,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,0011
              Boot0000  Startup Menu
              Boot0001  System Information
              Boot0002  Bios Setup
              Boot0003  3rd Party Option ROM Management
              Boot0004  System Diagnostics
              Boot0005  System Diagnostics
              Boot0006  System Diagnostics
              Boot0007  System Diagnostics
              Boot0008  Boot Menu
              Boot0009  HP Recovery
              Boot000A* opensuse-secureboot
              Boot000B* Windows Boot Manager
              Boot000C* Samsung SSD 850 EVO 1TB
              Boot000D* WDC WD5000LPCX-60VHAT0
              Boot000E* Samsung SSD 850 EVO 1TB

              Comment


              • #47
                Originally posted by starshipeleven View Post
                If the above does not work
                The command for rebooting into UEFI settings given earlier was because when using a feature like UltraFastBoot, Grub or rEFInd become unresponsive to input devices, the system needs to get past that and start booting the OS.

                Comment


                • #48
                  Originally posted by polarathene View Post

                  The command for rebooting into UEFI settings given earlier was because when using a feature like UltraFastBoot, Grub or rEFInd become unresponsive to input devices, the system needs to get past that and start booting the OS.
                  Ok.

                  In that case you can ask GRUB to boot a specific entry on next boot by
                  sudo grub-editenv - set next_entry=X
                  where X is the menu entry you want to boot next time.

                  List available entries with
                  Code:
                  sudo  awk -F\' '$1=="menuentry " || $1=="submenu " {print i++ " : " $2}; /\tmenuentry / {print "\t" i-1">"j++ " : " $2};' /boot/grub2/grub.cfg
                  or
                  Code:
                  sudo  awk -F\' '$1=="menuentry " || $1=="submenu " {print i++ " : " $2}; /\tmenuentry / {print "\t" i-1">"j++ " : " $2};' /boot/grub/grub.cfg
                  or edit the last path to point to where your distro places grub.cfg.

                  an example.

                  Code:
                  0 : openSUSE Tumbleweed
                  1 : Advanced options for openSUSE Tumbleweed
                          1>0 : openSUSE Tumbleweed, with Linux 5.2.11-1-default
                          1>1 : openSUSE Tumbleweed, with Linux 5.2.11-1-default (recovery mode)
                          1>2 : openSUSE Tumbleweed, with Linux 5.2.10-1-default
                          1>3 : openSUSE Tumbleweed, with Linux 5.2.10-1-default (recovery mode)
                  2 : Windows Boot Manager (on /dev/sdc2)
                  On OpenSUSE there is grub2-once that is basically a Perl script wrapper for the above and is a bit more advanced because OpenSUSE has snapshots and stuff and you might need to do this to rollback.
                  This is what I can also do with GRUB interface.
                  Code:
                  sudo  grub2-once --list
                       0 openSUSE Tumbleweed
                       1 Advanced options for openSUSE Tumbleweed>openSUSE Tumbleweed, with Linux 5.2.11-1-default
                       2 Advanced options for openSUSE Tumbleweed>openSUSE Tumbleweed, with Linux 5.2.11-1-default (recovery mode)
                       3 Advanced options for openSUSE Tumbleweed>openSUSE Tumbleweed, with Linux 5.2.10-1-default
                       4 Advanced options for openSUSE Tumbleweed>openSUSE Tumbleweed, with Linux 5.2.10-1-default (recovery mode)
                       5 Windows Boot Manager (on /dev/sdc2)
                       6 Start bootloader from a read-only snapshot> openSUSE Tumbleweed  (5.2.11-1,2019-09-11T08:31,post,zypp(packagekitd))
                       7 Start bootloader from a read-only snapshot> openSUSE Tumbleweed  (5.2.11-1,2019-09-11T08:29,post,yast snapper)
                       8 Start bootloader from a read-only snapshot> openSUSE Tumbleweed  (5.2.11-1,2019-09-11T08:29,pre,yast snapper)
                       9 Start bootloader from a read-only snapshot> openSUSE Tumbleweed  (5.2.11-1,2019-09-11T08:27,pre,zypp(packagekitd))
                      10 Start bootloader from a read-only snapshot> openSUSE Tumbleweed  (5.2.11-1,2019-09-09T07:13,post,zypp(zypper))
                      11 Start bootloader from a read-only snapshot> openSUSE Tumbleweed  (5.2.11-1,2019-09-09T07:10,pre,zypp(zypper))
                      12 Start bootloader from a read-only snapshot>*openSUSE Tumbleweed  (5.2.11-1,2019-09-05T16:10,post,zypp(zypper))
                      13 Start bootloader from a read-only snapshot>*openSUSE Tumbleweed  (5.2.10-1,2019-09-05T16:06,pre,zypp(zypper))

                  This is useful for rebooting to UEFI settings if you added the menu entry as said above, and also for changing the kernel, or boot any other menu entry too, as you cannot do that anymore if you can't use the keyboard on boot.

                  I don't know about a similar functioanlity in rEFInd, but quite frankly if you have rEFInd you are not going to have UltraFastBoot enabled.
                  Last edited by starshipeleven; 09-12-2019, 11:10 AM.

                  Comment


                  • #49
                    Originally posted by mlau View Post
                    It seems there's still a lot to gain by throwing away old x86 baggage (UEFI, ACPI). 500ms just to get linux to load is a lot of time when the CPU runs at >2GHz.
                    Hell yes. Also get rid of weird instruction set, overcomplicated overgrown CPU cores full of funny legacy like 16-bit mode, simplify design, add reasonable firmware ... and it maybe would look like ... er, ARM or RISC-V with something like u-boot (maybe only SPL part of it, if speed is all we care of - dumb as hell, not configurable, but FAST and does what it supposed to - without exposing gazillion of firmware bugs that nobody would ever fix anyway to Linux, like it usually happens on x86).
                    Last edited by SystemCrasher; 09-12-2019, 11:21 AM.

                    Comment


                    • #50
                      Can someone provides a list of modules that should be run in parallel to speed up boot? amdgpu?
                      driver_async_probe=[list]

                      Comment

                      Working...
                      X