Announcement

Collapse
No announcement yet.

Slow Boot

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    [SOLVED] Slow Boot

    After having "fixed" the grub/EFI/UUID problems, my boot times have slowed down.
    Mind you, I can boot from the SSD, the "old" neon partition can be mounted separately, and everything works.

    But, grub-install still gives warning on six partition table entries.
    Like: GUID Partition Table Header signature is wrong: b14185eed2da66d8 != 5452415020494645
    repeated six times with different text for the first entry but with the same for the second (5452415020494645).
    It then says, Installation finished. No error reported.

    Ok, everything works. But the boot is slow.
    It goes reasonably fast, then hangs on "searching for Btrfs filesystems". 30 seconds, look:

    Code:
    [Thu Jun 20 15:09:50 2019] Btrfs loaded, crc32c=crc32c-intel
    [Thu Jun 20 15:10:21 2019] random: crng init done
    Dmesg does not report the "searching for Btrfs filesystems" but it's what it says when it hangs there.
    I really don't think I have any btrfs filesystems, BTW.

    Then it goes fast again and:

    Code:
    [Thu Jun 20 15:10:27 2019] audit: type=1400 audit(1561036228.196:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" pid=947 comm="apparmor_parser"
    [Thu Jun 20 15:11:54 2019] IPv6: ADDRCONF(NETDEV_UP): enp3s0: link is not ready
    One minute, 27 seconds! It used to boot the lot in less than that.
    Here again, dmesg does not mention it, but it hangs on a long message, of the sort:
    Start job is running for dev-disk-by\longhexstring.
    Then after a minute and a half (!), it says, Timed out waiting for device dev-disk-by\longhexstring.

    Now, they really look like disk-related problems.
    Maybe like, six GUID partition table header signatures being wrong?
    I've looked far and wide on how to "correct" that problem. All I could find looks like taking a flamethower to a bowl of petunias and hoping they will revive.

    Any suggestions?

    [BTW] none of the hex strings reported in the partition warnings seem to have any relation to the ones reported by blkid.
    Last edited by Don B. Cilly; Jun 20, 2019, 08:16 AM.

    #2
    The 'minute and 30 seconds' "hang" ("Start job is running for dev-disk-by\...") has been reported/documented, and with solutions given. I have a thread myself, here in KFN, about it. A search on "Start job is running for dev-disk-by" would be a place to start.
    Windows no longer obstructs my view.
    Using Kubuntu Linux since March 23, 2007.
    "It is a capital mistake to theorize before one has data." - Sherlock Holmes

    Comment


      #3
      Ok, that one is solved. Thanks.
      Actually, I had looked for it, but the phone rang, I ran out of gas, I had a flat tire, I didn't have enough money for cab fare, my tux didn't come back from the cleaners, an old friend came in from out of town, someone stole my car, there was an earthquake, a terrible flood, locusts... you know ;·)

      I still have to wait 30 seconds for the "Searching for Btrfs filesystems" though.
      And of course, the partition header warnings...

      [AH] It was the swap partition in fstab, I hadn't thought of that, cilly me.
      Last edited by Don B. Cilly; Jun 20, 2019, 09:10 AM.

      Comment


        #4
        Are you sure that it's reporting "Searching for Btrfs filesystem" and not "Scanning for Btrfs filesystem"? If it is the latter, then maybe this will shed some light on the problem.
        Last edited by Snowhog; Jun 20, 2019, 09:43 AM.
        Windows no longer obstructs my view.
        Using Kubuntu Linux since March 23, 2007.
        "It is a capital mistake to theorize before one has data." - Sherlock Holmes

        Comment


          #5
          It must be "Scanning".
          Still, that post says to modify /etc/initramfs-tools/conf.d/resume. No such file on my system.
          /etc/initramfs-tools/conf.d/ exists but is empty.
          Other posts I've found advise to remove btrfs-tools and/or btrfs-progs, but they don't seem to exist on my system either.
          I'll keep looking.

          Comment


            #6
            Tch. All the posts I've found (more that half an hour searching and parsing) advise to either edit /etc/initramfs-tools/conf.d/resume or remove btrfs-tools and/or btrfs-progs.
            Now, Muon says neither is installed. In fact, nothing with the btrfs string in it is installed.
            I has to be in the kernel. Someone suggests using: modprobe -r btrfs. Hmm.
            What do you people think? Shall I try? Considering that:
            Code:
            not@all:/etc/modprobe.d$ grep btrfs *
            not@all:/etc/modprobe.d$

            Comment


              #7
              btrfs should be loaded, but not in modprobe.d. Do "lsmod |grep btrfs"

              Code:
              [FONT=monospace][COLOR=#54FF54][B]stuart@office[/B][/COLOR][COLOR=#000000]:[/COLOR][COLOR=#54FFFF][B]~[/B][/COLOR][COLOR=#000000]$ lsmod |grep btrfs[/COLOR]
              [COLOR=#FF5454][B]btrfs[/B][/COLOR][COLOR=#000000]                1163264  3[/COLOR]
              xor                    24576  1 [COLOR=#FF5454][B]btrfs[/B][/COLOR]
              zstd_compress         163840  1 [COLOR=#FF5454][B]btrfs[/B][/COLOR]
              raid6_pq              114688  1 [COLOR=#FF5454][B]btrfs[/B][/COLOR]
              libcrc32c              16384  1 [COLOR=#FF5454][B]btrfs[/B][/COLOR]
              [/FONT]
              That first error about the GUID partition tables usually means your partition table is out of whack. gdisk should be able to detect that. Running "sudo gdisk <device name>" should return;
              Code:
              [FONT=monospace][COLOR=#54FF54][B]stuart@office[/B][/COLOR][COLOR=#000000]:[/COLOR][COLOR=#54FFFF][B]~[/B][/COLOR][COLOR=#000000]$ sudo gdisk /dev/sda[/COLOR]
              GPT fdisk (gdisk) version 1.0.3
              
              Partition table scan:
                MBR: protective
                BSD: not present
                APM: not present
                GPT: present
              
              Found valid GPT with protective MBR; using GPT.
              
              [/FONT]
              "systemd-analyze blame" should show you boot process times. BTW, there's no "btrfs" searching going on when I boot and I have many btrfs file systems.

              Please Read Me

              Comment


                #8
                BTW, I pretty much have all those messages in my dmesg output but they last less than a second. Sounds like something hardware related is hanging. Try not mounting anything in fstab except what you need to boot.

                Please Read Me

                Comment


                  #9
                  lsmod:
                  Code:
                  lsmod |grep btrfs
                  btrfs                1163264  0
                  xor                    24576  1 btrfs
                  zstd_compress         163840  1 btrfs
                  raid6_pq              114688  1 btrfs
                  libcrc32c              16384  2 btrfs,xfs
                  Anything worth killing/exterminating/excommunicating?

                  systemd-analyze blame
                  Code:
                    3.791s dev-sdb1.device
                    1.904s systemd-journal-flush.service
                    1.872s NetworkManager-wait-online.service
                    1.544s dev-loop0.device
                    1.536s dev-loop2.device
                    1.531s dev-loop1.device
                    1.425s dev-loop8.device
                    1.284s snapd.service
                    1.026s udisks2.service
                    1.014s dev-loop3.device
                    1.008s dev-loop4.device
                     986ms dev-loop5.device
                     983ms dev-loop6.device
                     963ms dev-loop7.device
                     452ms NetworkManager.service
                     372ms networkd-dispatcher.service
                     366ms keyboard-setup.service
                     351ms ModemManager.service
                     344ms systemd-udev-trigger.service
                     314ms avahi-daemon.service
                     306ms systemd-resolved.service
                     306ms upower.service
                     304ms lvm2-monitor.service
                     294ms systemd-logind.service
                     288ms thermald.service
                     288ms accounts-daemon.service
                     252ms apparmor.service
                     250ms gpu-manager.service
                     226ms lm-sensors.service
                     225ms wpa_supplicant.service
                     223ms pppd-dns.service
                     221ms systemd-journald.service
                     201ms systemd-timesyncd.service
                     192ms systemd-modules-load.service
                     155ms snap-wine\x2dplatform\x2druntime-6.mount
                     146ms systemd-udevd.service
                     144ms virtualbox.service
                     135ms snap-cnctsun-58.mount
                     130ms alsa-restore.service
                     125ms snap-core-6818.mount
                     125ms rsyslog.service
                     121ms snap-cnctsun-59.mount
                  What a wonderful command!
                  Now, I may be good at blaming, but analysing this sort of thing, I'm pretty useless at...

                  Gdisk, I've been through it a hundred times, looking for a solution to the partition table mess, but I can't understand really - I don't use GPT, just MBR - and again, no solution offered out there looked sensible or safe enough... to me.
                  Code:
                  GPT fdisk (gdisk) version 1.0.3
                  
                  Partition table scan:
                  MBR: MBR only
                  BSD: not present
                  APM: not present
                  GPT: not present
                  
                  ***************************************************************
                  Found invalid GPT and valid MBR; converting MBR to GPT format
                  in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by
                  typing 'q' if you don't want to convert your MBR partitions
                  to GPT format!
                  ***************************************************************
                  
                  Command (? for help): q
                  [AH] My fstab looks simple enough (and the partitions match blkid):
                  Code:
                  # <file system>             <mount point>  <type>  <options>  <dump>  <pass>
                  UUID=3331581b-e3a3-4976-86a3-bbfc025262be /              ext4    defaults,noatime 0 1
                  UUID=754B-22C4                            /boot/efi      vfat    defaults,noatime 0 2
                  UUID=bbb7dbfc-e767-43c9-8b99-614bbaab2cc5 swap           swap    defaults,noatime 0 2
                  Last edited by Don B. Cilly; Jun 20, 2019, 12:49 PM.

                  Comment


                    #10
                    Originally posted by Don B. Cilly View Post
                    What a wonderful command!
                    Now, I may be good at blaming, but analysing this sort of thing, I'm pretty useless at...
                    ROFL

                    No benefit to unloading any of those modules IMO. I'm not sure, but I think as long as you have EFI you must also use GPT which would be the source of the error and it ain't going away. I can't say if it's causing your slow boot, but maybe. For what it's worth, the GPT conversion should also image the MBR so nothing would break. I'd still probably make a backup of the boot record beforehand just in case.

                    The lack of long running processes in analyse blame may point at a hardware issue as I suggested before.

                    Make a backup...

                    Please Read Me

                    Comment


                      #11
                      Originally posted by oshunluvr View Post
                      The lack of long running processes in analyse blame may point at a hardware issue as I suggested before.
                      Well, if you add up the first 14 ones in that blame-list (and add a couple it may not be telling you about) they easily come to 30 seconds.
                      And they look disk-related, don't they?
                      Anyway,
                      Make a backup...
                      I've made one of the MBR. Two in fact, one of 446 bytes and one of 512.
                      And a note of how to restore it. Also copied the three files (two backups and a note) to an external disk.

                      I've also been perusing the hive-mind/knowledge-space/neural-netw... er, looking at quite a few discussions, but since I'm in no hurry to break the system irretrievably gain 30 seconds at boot, I might as well review the procedure before entering the operating theatre. So I would:
                      - Boot a live medium/separate OS.
                      - Start root gdisk (on the disk I want to convert).
                      - Type w and convert MBR to GPT.
                      - Verify.
                      - Reboot.

                      How does that look?

                      Comment


                        #12
                        Yeah, that's it. If you can still boot to sda, you could fix sdb while running from sda, and vice-versa

                        Please Read Me

                        Comment


                          #13
                          Well, it went rather painlessly. Took all of two seconds (or less).
                          Now gdisk says:
                          Code:
                          Partition table scan:
                          MBR: protective
                          BSD: not present
                          APM: not present
                          GPT: present
                          
                          Found valid GPT with protective MBR; using GPT.
                          But, after rebooting to neon, it still hung at the scanning thing for 30 seconds.
                          I reinstalled grub (never know) and rebooted. Still hangs there.

                          So I'm afraid it wasn't that.
                          And still, all the posts I've found advise to either edit /etc/initramfs-tools/conf.d/resume (which I don't have) or remove btrfs-tools and/or btrfs-progs (which I don't have either).

                          Or using: modprobe -r btrfs. So, considering
                          Code:
                          lsmod |grep btrfs
                          btrfs                1163264  0
                          xor                    24576  1 btrfs
                          zstd_compress         163840  1 btrfs
                          raid6_pq              114688  1 btrfs
                          libcrc32c              16384  2 btrfs,xfs
                          And that the scanning message (which does not appear in dmesg) occurs just after dmesg prints "Btrfs loaded, crc32c=crc32c-intel"... I don't know
                          One one hand I'd rather have 30 seconds delay at boot than break the system (again), on the other, it boots so fast from the SSD that 30 seconds look like an eternity.
                          Problem is, what I have here is a deer with no eyes, no legs and no... well, you know ;·)

                          Comment


                            #14
                            Well.....

                            When you turn your PC on, leave the room to go get glass of water. By the time you get back, you should be on your Desktop Login screen. You won't even notice the 30-seconds anymore.
                            Windows no longer obstructs my view.
                            Using Kubuntu Linux since March 23, 2007.
                            "It is a capital mistake to theorize before one has data." - Sherlock Holmes

                            Comment


                              #15
                              I don't think it's the btrfs driver loading that's the delay. It's the line after. What's the output of blkid?

                              Please Read Me

                              Comment

                              Working...
                              X