How to diagnose/fix very slow boot on Ubuntu 18.04












40















There is a long time where SSD does nothing.




  • How can I find the fault and fix it ?

  • Already checked /etc/fstab, no swap or anything wrong there (32GB of RAM, no swap)




[    2.173492] usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2.173497] usb 2-1.6: Product: DW375 Bluetooth Module
[ 2.173501] usb 2-1.6: Manufacturer: Dell Computer Corp
[ 2.173511] usb 2-1.6: SerialNumber: 7CE9D3C0713B
[ 2.323728] ata4: SATA link down (SStatus 0 SControl 300)
[ 2.441062] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input6
[ 2.640309] ata5: SATA link down (SStatus 0 SControl 300)
[ 2.954947] ata6: SATA link down (SStatus 0 SControl 300)
[ 3.068090] clocksource: Switched to clocksource tsc
[ 36.584826] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[ 36.726117] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 36.732610] systemd[1]: systemd 237 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +AC
L +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
[ 36.751996] systemd[1]: Detected architecture x86-64.
[ 36.753867] systemd[1]: Set hostname to <latitude-e5520>.
[ 36.868561] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[ 36.868594] systemd[1]: Reached target Remote File Systems.
[ 36.868751] systemd[1]: Created slice User and Session Slice.
[ 36.868869] systemd[1]: Created slice System Slice.
[ 36.868948] systemd[1]: Listening on udev Control Socket.
[ 36.868957] systemd[1]: Reached target Slices.
[ 36.868996] systemd[1]: Listening on udev Kernel Socket.
[ 36.895156] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
[ 36.898185] lp: driver loaded but no devices found
[ 36.903941] ppdev: user-space parallel port driver









share|improve this question




















  • 3





    Is this a fresh install? with lvm? perhaps this bug : bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1768230 ?

    – pim
    May 2 '18 at 4:53













  • To see the WARNING:Failed to connect to lvmetad. Falling back to device scanning. message, you should disable the spash/quiet boot (see : askubuntu.com/a/289/454520)

    – pim
    May 2 '18 at 5:46











  • It's about long network.service booting. Solution from this answer helped me.

    – gyr9i
    Jun 6 '18 at 7:59
















40















There is a long time where SSD does nothing.




  • How can I find the fault and fix it ?

  • Already checked /etc/fstab, no swap or anything wrong there (32GB of RAM, no swap)




[    2.173492] usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2.173497] usb 2-1.6: Product: DW375 Bluetooth Module
[ 2.173501] usb 2-1.6: Manufacturer: Dell Computer Corp
[ 2.173511] usb 2-1.6: SerialNumber: 7CE9D3C0713B
[ 2.323728] ata4: SATA link down (SStatus 0 SControl 300)
[ 2.441062] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input6
[ 2.640309] ata5: SATA link down (SStatus 0 SControl 300)
[ 2.954947] ata6: SATA link down (SStatus 0 SControl 300)
[ 3.068090] clocksource: Switched to clocksource tsc
[ 36.584826] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[ 36.726117] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 36.732610] systemd[1]: systemd 237 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +AC
L +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
[ 36.751996] systemd[1]: Detected architecture x86-64.
[ 36.753867] systemd[1]: Set hostname to <latitude-e5520>.
[ 36.868561] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[ 36.868594] systemd[1]: Reached target Remote File Systems.
[ 36.868751] systemd[1]: Created slice User and Session Slice.
[ 36.868869] systemd[1]: Created slice System Slice.
[ 36.868948] systemd[1]: Listening on udev Control Socket.
[ 36.868957] systemd[1]: Reached target Slices.
[ 36.868996] systemd[1]: Listening on udev Kernel Socket.
[ 36.895156] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
[ 36.898185] lp: driver loaded but no devices found
[ 36.903941] ppdev: user-space parallel port driver









share|improve this question




















  • 3





    Is this a fresh install? with lvm? perhaps this bug : bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1768230 ?

    – pim
    May 2 '18 at 4:53













  • To see the WARNING:Failed to connect to lvmetad. Falling back to device scanning. message, you should disable the spash/quiet boot (see : askubuntu.com/a/289/454520)

    – pim
    May 2 '18 at 5:46











  • It's about long network.service booting. Solution from this answer helped me.

    – gyr9i
    Jun 6 '18 at 7:59














40












40








40


14






There is a long time where SSD does nothing.




  • How can I find the fault and fix it ?

  • Already checked /etc/fstab, no swap or anything wrong there (32GB of RAM, no swap)




[    2.173492] usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2.173497] usb 2-1.6: Product: DW375 Bluetooth Module
[ 2.173501] usb 2-1.6: Manufacturer: Dell Computer Corp
[ 2.173511] usb 2-1.6: SerialNumber: 7CE9D3C0713B
[ 2.323728] ata4: SATA link down (SStatus 0 SControl 300)
[ 2.441062] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input6
[ 2.640309] ata5: SATA link down (SStatus 0 SControl 300)
[ 2.954947] ata6: SATA link down (SStatus 0 SControl 300)
[ 3.068090] clocksource: Switched to clocksource tsc
[ 36.584826] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[ 36.726117] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 36.732610] systemd[1]: systemd 237 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +AC
L +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
[ 36.751996] systemd[1]: Detected architecture x86-64.
[ 36.753867] systemd[1]: Set hostname to <latitude-e5520>.
[ 36.868561] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[ 36.868594] systemd[1]: Reached target Remote File Systems.
[ 36.868751] systemd[1]: Created slice User and Session Slice.
[ 36.868869] systemd[1]: Created slice System Slice.
[ 36.868948] systemd[1]: Listening on udev Control Socket.
[ 36.868957] systemd[1]: Reached target Slices.
[ 36.868996] systemd[1]: Listening on udev Kernel Socket.
[ 36.895156] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
[ 36.898185] lp: driver loaded but no devices found
[ 36.903941] ppdev: user-space parallel port driver









share|improve this question
















There is a long time where SSD does nothing.




  • How can I find the fault and fix it ?

  • Already checked /etc/fstab, no swap or anything wrong there (32GB of RAM, no swap)




[    2.173492] usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2.173497] usb 2-1.6: Product: DW375 Bluetooth Module
[ 2.173501] usb 2-1.6: Manufacturer: Dell Computer Corp
[ 2.173511] usb 2-1.6: SerialNumber: 7CE9D3C0713B
[ 2.323728] ata4: SATA link down (SStatus 0 SControl 300)
[ 2.441062] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input6
[ 2.640309] ata5: SATA link down (SStatus 0 SControl 300)
[ 2.954947] ata6: SATA link down (SStatus 0 SControl 300)
[ 3.068090] clocksource: Switched to clocksource tsc
[ 36.584826] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[ 36.726117] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 36.732610] systemd[1]: systemd 237 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +AC
L +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
[ 36.751996] systemd[1]: Detected architecture x86-64.
[ 36.753867] systemd[1]: Set hostname to <latitude-e5520>.
[ 36.868561] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[ 36.868594] systemd[1]: Reached target Remote File Systems.
[ 36.868751] systemd[1]: Created slice User and Session Slice.
[ 36.868869] systemd[1]: Created slice System Slice.
[ 36.868948] systemd[1]: Listening on udev Control Socket.
[ 36.868957] systemd[1]: Reached target Slices.
[ 36.868996] systemd[1]: Listening on udev Kernel Socket.
[ 36.895156] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
[ 36.898185] lp: driver loaded but no devices found
[ 36.903941] ppdev: user-space parallel port driver






boot 18.04






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jul 29 '18 at 18:37









wjandrea

9,29842664




9,29842664










asked May 2 '18 at 4:31









user105939user105939

5573719




5573719








  • 3





    Is this a fresh install? with lvm? perhaps this bug : bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1768230 ?

    – pim
    May 2 '18 at 4:53













  • To see the WARNING:Failed to connect to lvmetad. Falling back to device scanning. message, you should disable the spash/quiet boot (see : askubuntu.com/a/289/454520)

    – pim
    May 2 '18 at 5:46











  • It's about long network.service booting. Solution from this answer helped me.

    – gyr9i
    Jun 6 '18 at 7:59














  • 3





    Is this a fresh install? with lvm? perhaps this bug : bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1768230 ?

    – pim
    May 2 '18 at 4:53













  • To see the WARNING:Failed to connect to lvmetad. Falling back to device scanning. message, you should disable the spash/quiet boot (see : askubuntu.com/a/289/454520)

    – pim
    May 2 '18 at 5:46











  • It's about long network.service booting. Solution from this answer helped me.

    – gyr9i
    Jun 6 '18 at 7:59








3




3





Is this a fresh install? with lvm? perhaps this bug : bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1768230 ?

– pim
May 2 '18 at 4:53







Is this a fresh install? with lvm? perhaps this bug : bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1768230 ?

– pim
May 2 '18 at 4:53















To see the WARNING:Failed to connect to lvmetad. Falling back to device scanning. message, you should disable the spash/quiet boot (see : askubuntu.com/a/289/454520)

– pim
May 2 '18 at 5:46





To see the WARNING:Failed to connect to lvmetad. Falling back to device scanning. message, you should disable the spash/quiet boot (see : askubuntu.com/a/289/454520)

– pim
May 2 '18 at 5:46













It's about long network.service booting. Solution from this answer helped me.

– gyr9i
Jun 6 '18 at 7:59





It's about long network.service booting. Solution from this answer helped me.

– gyr9i
Jun 6 '18 at 7:59










5 Answers
5






active

oldest

votes


















52














I upgraded to 18.04 today and encountered the same issue. I was able to fix it by booting the kernel with the noresume parameter.



Like you, I also have no swap space. At some point during the upgrade, the initramfs config was modified, adding a line pointing to a nonexistent swap partition. The slow boot was because it was looking for this partition and then timing out after 30 seconds.



To update GRUB so that it passes this option to the kernel automatically on boot:





  1. Edit the file /etc/default/grub file so that the string noresume is included in the GRUB_CMDLINE_LINUX_DEFAULT line, for example:



    GRUB_CMDLINE_LINUX_DEFAULT="quiet splash noresume"



  2. Run this command to update GRUB:



    sudo update-grub


  3. Reboot the computer







share|improve this answer





















  • 1





    noresume fixed it, nothing strange in initramfs.

    – user105939
    May 4 '18 at 7:15






  • 1





    I upgraded to 18.04 yesterday and I had the same problem (it took 52 seconds to boot). After setting the "noresume" parameter, it took 21 seconds.

    – Erol
    May 4 '18 at 15:06






  • 1





    You could improve your already good answer with instructions on updating grub.

    – WinEunuuchs2Unix
    May 9 '18 at 0:44






  • 7





    Please note that this is a workaroud, since it will prevent resuming a hibernated system.

    – pim
    May 9 '18 at 13:52






  • 2





    I'm worried that this might prevent me from using hibernation. However this worked for me: askubuntu.com/questions/1013830/… (editing /etc/initramfs-tools/conf.d/resume, changing RESUME=none from the UUID and running update-initramfs -u)

    – Grey Panther
    Jul 11 '18 at 20:33



















15














$ systemd-analyze blame


Look to see which processes are taking the most time of the boot process.






share|improve this answer





















  • 3





    systemd-analyze blame will not show kernel time, and for this problem. systemd-analyse time will show that it's the kernel that is stuck searching for the filesystem.

    – pim
    May 2 '18 at 5:36






  • 1





    good hint, but the longest process took only 1.6seconds, so this tool did not help.

    – user105939
    May 4 '18 at 7:16






  • 1





    @Pim systemd-analyse time has a typo, it should have a z

    – RobAu
    Nov 20 '18 at 8:18











  • systemd-analyze critical-chain is even better than blame

    – user535733
    Dec 9 '18 at 22:14



















9














What worked for me was to run sudo rm /etc/initramfs-tools/conf.d/resume followed by sudo update-initramfs -u . This seems to be a regression from an upgrade (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861151).






share|improve this answer

































    3














    I upgraded to 18.04 from 16.04. Boot time was more than 10 minutes.

    Tried from "No splash screen to Kernel" to find which processes are taking the most time for booting.



    A start job is running for Raise network interfaces (1min 26s / 5min 24s)


    So, we need to reduce time for this process to save boot time. To do so,



    You have to edit,



    sudo nano /etc/systemd/system/network-online.target.wants/networking.service


    Find



    TimeoutStartSec=5min


    Change to



    TimeoutStartSec=5s


    and reboot






    share|improve this answer

































      0














      Time Start Job and Stop Jobs
      ∘ "acpi int3400 unsupported event" ERRORS OVER 285 FARG!@#$ING Times



      sudo gedit /etc/systemd/system.conf



      Change/or Add a Different line that's Uncommented (from 90 seconds to 5 {I Like}) and Uncomment




      #DefaultTimeoutStartSec=90s



      DefaultTimeoutStartSec=5s




      and the other




      #DefaultTimeoutStopSec=90s



      DefaultTimeoutStopSec=5s




      sudo update-initramfs -u






      share|improve this answer






















        protected by Community Jul 21 '18 at 1:54



        Thank you for your interest in this question.
        Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



        Would you like to answer one of these unanswered questions instead?














        5 Answers
        5






        active

        oldest

        votes








        5 Answers
        5






        active

        oldest

        votes









        active

        oldest

        votes






        active

        oldest

        votes









        52














        I upgraded to 18.04 today and encountered the same issue. I was able to fix it by booting the kernel with the noresume parameter.



        Like you, I also have no swap space. At some point during the upgrade, the initramfs config was modified, adding a line pointing to a nonexistent swap partition. The slow boot was because it was looking for this partition and then timing out after 30 seconds.



        To update GRUB so that it passes this option to the kernel automatically on boot:





        1. Edit the file /etc/default/grub file so that the string noresume is included in the GRUB_CMDLINE_LINUX_DEFAULT line, for example:



          GRUB_CMDLINE_LINUX_DEFAULT="quiet splash noresume"



        2. Run this command to update GRUB:



          sudo update-grub


        3. Reboot the computer







        share|improve this answer





















        • 1





          noresume fixed it, nothing strange in initramfs.

          – user105939
          May 4 '18 at 7:15






        • 1





          I upgraded to 18.04 yesterday and I had the same problem (it took 52 seconds to boot). After setting the "noresume" parameter, it took 21 seconds.

          – Erol
          May 4 '18 at 15:06






        • 1





          You could improve your already good answer with instructions on updating grub.

          – WinEunuuchs2Unix
          May 9 '18 at 0:44






        • 7





          Please note that this is a workaroud, since it will prevent resuming a hibernated system.

          – pim
          May 9 '18 at 13:52






        • 2





          I'm worried that this might prevent me from using hibernation. However this worked for me: askubuntu.com/questions/1013830/… (editing /etc/initramfs-tools/conf.d/resume, changing RESUME=none from the UUID and running update-initramfs -u)

          – Grey Panther
          Jul 11 '18 at 20:33
















        52














        I upgraded to 18.04 today and encountered the same issue. I was able to fix it by booting the kernel with the noresume parameter.



        Like you, I also have no swap space. At some point during the upgrade, the initramfs config was modified, adding a line pointing to a nonexistent swap partition. The slow boot was because it was looking for this partition and then timing out after 30 seconds.



        To update GRUB so that it passes this option to the kernel automatically on boot:





        1. Edit the file /etc/default/grub file so that the string noresume is included in the GRUB_CMDLINE_LINUX_DEFAULT line, for example:



          GRUB_CMDLINE_LINUX_DEFAULT="quiet splash noresume"



        2. Run this command to update GRUB:



          sudo update-grub


        3. Reboot the computer







        share|improve this answer





















        • 1





          noresume fixed it, nothing strange in initramfs.

          – user105939
          May 4 '18 at 7:15






        • 1





          I upgraded to 18.04 yesterday and I had the same problem (it took 52 seconds to boot). After setting the "noresume" parameter, it took 21 seconds.

          – Erol
          May 4 '18 at 15:06






        • 1





          You could improve your already good answer with instructions on updating grub.

          – WinEunuuchs2Unix
          May 9 '18 at 0:44






        • 7





          Please note that this is a workaroud, since it will prevent resuming a hibernated system.

          – pim
          May 9 '18 at 13:52






        • 2





          I'm worried that this might prevent me from using hibernation. However this worked for me: askubuntu.com/questions/1013830/… (editing /etc/initramfs-tools/conf.d/resume, changing RESUME=none from the UUID and running update-initramfs -u)

          – Grey Panther
          Jul 11 '18 at 20:33














        52












        52








        52







        I upgraded to 18.04 today and encountered the same issue. I was able to fix it by booting the kernel with the noresume parameter.



        Like you, I also have no swap space. At some point during the upgrade, the initramfs config was modified, adding a line pointing to a nonexistent swap partition. The slow boot was because it was looking for this partition and then timing out after 30 seconds.



        To update GRUB so that it passes this option to the kernel automatically on boot:





        1. Edit the file /etc/default/grub file so that the string noresume is included in the GRUB_CMDLINE_LINUX_DEFAULT line, for example:



          GRUB_CMDLINE_LINUX_DEFAULT="quiet splash noresume"



        2. Run this command to update GRUB:



          sudo update-grub


        3. Reboot the computer







        share|improve this answer















        I upgraded to 18.04 today and encountered the same issue. I was able to fix it by booting the kernel with the noresume parameter.



        Like you, I also have no swap space. At some point during the upgrade, the initramfs config was modified, adding a line pointing to a nonexistent swap partition. The slow boot was because it was looking for this partition and then timing out after 30 seconds.



        To update GRUB so that it passes this option to the kernel automatically on boot:





        1. Edit the file /etc/default/grub file so that the string noresume is included in the GRUB_CMDLINE_LINUX_DEFAULT line, for example:



          GRUB_CMDLINE_LINUX_DEFAULT="quiet splash noresume"



        2. Run this command to update GRUB:



          sudo update-grub


        3. Reboot the computer








        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited May 9 '18 at 15:24









        Zanna

        50.9k13137241




        50.9k13137241










        answered May 3 '18 at 18:08









        ClifforusClifforus

        63622




        63622








        • 1





          noresume fixed it, nothing strange in initramfs.

          – user105939
          May 4 '18 at 7:15






        • 1





          I upgraded to 18.04 yesterday and I had the same problem (it took 52 seconds to boot). After setting the "noresume" parameter, it took 21 seconds.

          – Erol
          May 4 '18 at 15:06






        • 1





          You could improve your already good answer with instructions on updating grub.

          – WinEunuuchs2Unix
          May 9 '18 at 0:44






        • 7





          Please note that this is a workaroud, since it will prevent resuming a hibernated system.

          – pim
          May 9 '18 at 13:52






        • 2





          I'm worried that this might prevent me from using hibernation. However this worked for me: askubuntu.com/questions/1013830/… (editing /etc/initramfs-tools/conf.d/resume, changing RESUME=none from the UUID and running update-initramfs -u)

          – Grey Panther
          Jul 11 '18 at 20:33














        • 1





          noresume fixed it, nothing strange in initramfs.

          – user105939
          May 4 '18 at 7:15






        • 1





          I upgraded to 18.04 yesterday and I had the same problem (it took 52 seconds to boot). After setting the "noresume" parameter, it took 21 seconds.

          – Erol
          May 4 '18 at 15:06






        • 1





          You could improve your already good answer with instructions on updating grub.

          – WinEunuuchs2Unix
          May 9 '18 at 0:44






        • 7





          Please note that this is a workaroud, since it will prevent resuming a hibernated system.

          – pim
          May 9 '18 at 13:52






        • 2





          I'm worried that this might prevent me from using hibernation. However this worked for me: askubuntu.com/questions/1013830/… (editing /etc/initramfs-tools/conf.d/resume, changing RESUME=none from the UUID and running update-initramfs -u)

          – Grey Panther
          Jul 11 '18 at 20:33








        1




        1





        noresume fixed it, nothing strange in initramfs.

        – user105939
        May 4 '18 at 7:15





        noresume fixed it, nothing strange in initramfs.

        – user105939
        May 4 '18 at 7:15




        1




        1





        I upgraded to 18.04 yesterday and I had the same problem (it took 52 seconds to boot). After setting the "noresume" parameter, it took 21 seconds.

        – Erol
        May 4 '18 at 15:06





        I upgraded to 18.04 yesterday and I had the same problem (it took 52 seconds to boot). After setting the "noresume" parameter, it took 21 seconds.

        – Erol
        May 4 '18 at 15:06




        1




        1





        You could improve your already good answer with instructions on updating grub.

        – WinEunuuchs2Unix
        May 9 '18 at 0:44





        You could improve your already good answer with instructions on updating grub.

        – WinEunuuchs2Unix
        May 9 '18 at 0:44




        7




        7





        Please note that this is a workaroud, since it will prevent resuming a hibernated system.

        – pim
        May 9 '18 at 13:52





        Please note that this is a workaroud, since it will prevent resuming a hibernated system.

        – pim
        May 9 '18 at 13:52




        2




        2





        I'm worried that this might prevent me from using hibernation. However this worked for me: askubuntu.com/questions/1013830/… (editing /etc/initramfs-tools/conf.d/resume, changing RESUME=none from the UUID and running update-initramfs -u)

        – Grey Panther
        Jul 11 '18 at 20:33





        I'm worried that this might prevent me from using hibernation. However this worked for me: askubuntu.com/questions/1013830/… (editing /etc/initramfs-tools/conf.d/resume, changing RESUME=none from the UUID and running update-initramfs -u)

        – Grey Panther
        Jul 11 '18 at 20:33













        15














        $ systemd-analyze blame


        Look to see which processes are taking the most time of the boot process.






        share|improve this answer





















        • 3





          systemd-analyze blame will not show kernel time, and for this problem. systemd-analyse time will show that it's the kernel that is stuck searching for the filesystem.

          – pim
          May 2 '18 at 5:36






        • 1





          good hint, but the longest process took only 1.6seconds, so this tool did not help.

          – user105939
          May 4 '18 at 7:16






        • 1





          @Pim systemd-analyse time has a typo, it should have a z

          – RobAu
          Nov 20 '18 at 8:18











        • systemd-analyze critical-chain is even better than blame

          – user535733
          Dec 9 '18 at 22:14
















        15














        $ systemd-analyze blame


        Look to see which processes are taking the most time of the boot process.






        share|improve this answer





















        • 3





          systemd-analyze blame will not show kernel time, and for this problem. systemd-analyse time will show that it's the kernel that is stuck searching for the filesystem.

          – pim
          May 2 '18 at 5:36






        • 1





          good hint, but the longest process took only 1.6seconds, so this tool did not help.

          – user105939
          May 4 '18 at 7:16






        • 1





          @Pim systemd-analyse time has a typo, it should have a z

          – RobAu
          Nov 20 '18 at 8:18











        • systemd-analyze critical-chain is even better than blame

          – user535733
          Dec 9 '18 at 22:14














        15












        15








        15







        $ systemd-analyze blame


        Look to see which processes are taking the most time of the boot process.






        share|improve this answer















        $ systemd-analyze blame


        Look to see which processes are taking the most time of the boot process.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited May 2 '18 at 22:47









        ubashu

        2,39121837




        2,39121837










        answered May 2 '18 at 5:24









        ManojManoj

        1835




        1835








        • 3





          systemd-analyze blame will not show kernel time, and for this problem. systemd-analyse time will show that it's the kernel that is stuck searching for the filesystem.

          – pim
          May 2 '18 at 5:36






        • 1





          good hint, but the longest process took only 1.6seconds, so this tool did not help.

          – user105939
          May 4 '18 at 7:16






        • 1





          @Pim systemd-analyse time has a typo, it should have a z

          – RobAu
          Nov 20 '18 at 8:18











        • systemd-analyze critical-chain is even better than blame

          – user535733
          Dec 9 '18 at 22:14














        • 3





          systemd-analyze blame will not show kernel time, and for this problem. systemd-analyse time will show that it's the kernel that is stuck searching for the filesystem.

          – pim
          May 2 '18 at 5:36






        • 1





          good hint, but the longest process took only 1.6seconds, so this tool did not help.

          – user105939
          May 4 '18 at 7:16






        • 1





          @Pim systemd-analyse time has a typo, it should have a z

          – RobAu
          Nov 20 '18 at 8:18











        • systemd-analyze critical-chain is even better than blame

          – user535733
          Dec 9 '18 at 22:14








        3




        3





        systemd-analyze blame will not show kernel time, and for this problem. systemd-analyse time will show that it's the kernel that is stuck searching for the filesystem.

        – pim
        May 2 '18 at 5:36





        systemd-analyze blame will not show kernel time, and for this problem. systemd-analyse time will show that it's the kernel that is stuck searching for the filesystem.

        – pim
        May 2 '18 at 5:36




        1




        1





        good hint, but the longest process took only 1.6seconds, so this tool did not help.

        – user105939
        May 4 '18 at 7:16





        good hint, but the longest process took only 1.6seconds, so this tool did not help.

        – user105939
        May 4 '18 at 7:16




        1




        1





        @Pim systemd-analyse time has a typo, it should have a z

        – RobAu
        Nov 20 '18 at 8:18





        @Pim systemd-analyse time has a typo, it should have a z

        – RobAu
        Nov 20 '18 at 8:18













        systemd-analyze critical-chain is even better than blame

        – user535733
        Dec 9 '18 at 22:14





        systemd-analyze critical-chain is even better than blame

        – user535733
        Dec 9 '18 at 22:14











        9














        What worked for me was to run sudo rm /etc/initramfs-tools/conf.d/resume followed by sudo update-initramfs -u . This seems to be a regression from an upgrade (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861151).






        share|improve this answer






























          9














          What worked for me was to run sudo rm /etc/initramfs-tools/conf.d/resume followed by sudo update-initramfs -u . This seems to be a regression from an upgrade (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861151).






          share|improve this answer




























            9












            9








            9







            What worked for me was to run sudo rm /etc/initramfs-tools/conf.d/resume followed by sudo update-initramfs -u . This seems to be a regression from an upgrade (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861151).






            share|improve this answer















            What worked for me was to run sudo rm /etc/initramfs-tools/conf.d/resume followed by sudo update-initramfs -u . This seems to be a regression from an upgrade (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861151).







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited May 15 '18 at 6:26









            ubashu

            2,39121837




            2,39121837










            answered May 15 '18 at 6:17









            user7081858user7081858

            991




            991























                3














                I upgraded to 18.04 from 16.04. Boot time was more than 10 minutes.

                Tried from "No splash screen to Kernel" to find which processes are taking the most time for booting.



                A start job is running for Raise network interfaces (1min 26s / 5min 24s)


                So, we need to reduce time for this process to save boot time. To do so,



                You have to edit,



                sudo nano /etc/systemd/system/network-online.target.wants/networking.service


                Find



                TimeoutStartSec=5min


                Change to



                TimeoutStartSec=5s


                and reboot






                share|improve this answer






























                  3














                  I upgraded to 18.04 from 16.04. Boot time was more than 10 minutes.

                  Tried from "No splash screen to Kernel" to find which processes are taking the most time for booting.



                  A start job is running for Raise network interfaces (1min 26s / 5min 24s)


                  So, we need to reduce time for this process to save boot time. To do so,



                  You have to edit,



                  sudo nano /etc/systemd/system/network-online.target.wants/networking.service


                  Find



                  TimeoutStartSec=5min


                  Change to



                  TimeoutStartSec=5s


                  and reboot






                  share|improve this answer




























                    3












                    3








                    3







                    I upgraded to 18.04 from 16.04. Boot time was more than 10 minutes.

                    Tried from "No splash screen to Kernel" to find which processes are taking the most time for booting.



                    A start job is running for Raise network interfaces (1min 26s / 5min 24s)


                    So, we need to reduce time for this process to save boot time. To do so,



                    You have to edit,



                    sudo nano /etc/systemd/system/network-online.target.wants/networking.service


                    Find



                    TimeoutStartSec=5min


                    Change to



                    TimeoutStartSec=5s


                    and reboot






                    share|improve this answer















                    I upgraded to 18.04 from 16.04. Boot time was more than 10 minutes.

                    Tried from "No splash screen to Kernel" to find which processes are taking the most time for booting.



                    A start job is running for Raise network interfaces (1min 26s / 5min 24s)


                    So, we need to reduce time for this process to save boot time. To do so,



                    You have to edit,



                    sudo nano /etc/systemd/system/network-online.target.wants/networking.service


                    Find



                    TimeoutStartSec=5min


                    Change to



                    TimeoutStartSec=5s


                    and reboot







                    share|improve this answer














                    share|improve this answer



                    share|improve this answer








                    edited Jul 7 '18 at 19:49









                    lrkwz

                    165115




                    165115










                    answered May 10 '18 at 6:22









                    krigekrige

                    785




                    785























                        0














                        Time Start Job and Stop Jobs
                        ∘ "acpi int3400 unsupported event" ERRORS OVER 285 FARG!@#$ING Times



                        sudo gedit /etc/systemd/system.conf



                        Change/or Add a Different line that's Uncommented (from 90 seconds to 5 {I Like}) and Uncomment




                        #DefaultTimeoutStartSec=90s



                        DefaultTimeoutStartSec=5s




                        and the other




                        #DefaultTimeoutStopSec=90s



                        DefaultTimeoutStopSec=5s




                        sudo update-initramfs -u






                        share|improve this answer




























                          0














                          Time Start Job and Stop Jobs
                          ∘ "acpi int3400 unsupported event" ERRORS OVER 285 FARG!@#$ING Times



                          sudo gedit /etc/systemd/system.conf



                          Change/or Add a Different line that's Uncommented (from 90 seconds to 5 {I Like}) and Uncomment




                          #DefaultTimeoutStartSec=90s



                          DefaultTimeoutStartSec=5s




                          and the other




                          #DefaultTimeoutStopSec=90s



                          DefaultTimeoutStopSec=5s




                          sudo update-initramfs -u






                          share|improve this answer


























                            0












                            0








                            0







                            Time Start Job and Stop Jobs
                            ∘ "acpi int3400 unsupported event" ERRORS OVER 285 FARG!@#$ING Times



                            sudo gedit /etc/systemd/system.conf



                            Change/or Add a Different line that's Uncommented (from 90 seconds to 5 {I Like}) and Uncomment




                            #DefaultTimeoutStartSec=90s



                            DefaultTimeoutStartSec=5s




                            and the other




                            #DefaultTimeoutStopSec=90s



                            DefaultTimeoutStopSec=5s




                            sudo update-initramfs -u






                            share|improve this answer













                            Time Start Job and Stop Jobs
                            ∘ "acpi int3400 unsupported event" ERRORS OVER 285 FARG!@#$ING Times



                            sudo gedit /etc/systemd/system.conf



                            Change/or Add a Different line that's Uncommented (from 90 seconds to 5 {I Like}) and Uncomment




                            #DefaultTimeoutStartSec=90s



                            DefaultTimeoutStartSec=5s




                            and the other




                            #DefaultTimeoutStopSec=90s



                            DefaultTimeoutStopSec=5s




                            sudo update-initramfs -u







                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered Jan 27 at 17:33









                            markackerman8-gmail.commarkackerman8-gmail.com

                            787612




                            787612

















                                protected by Community Jul 21 '18 at 1:54



                                Thank you for your interest in this question.
                                Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



                                Would you like to answer one of these unanswered questions instead?



                                Popular posts from this blog

                                Human spaceflight

                                Can not write log (Is /dev/pts mounted?) - openpty in Ubuntu-on-Windows?

                                張江高科駅