Announcement

Collapse
No announcement yet.

Boot delay dmesg info

Collapse
This topic is closed.
X
X
Collapse
 
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts
Previous template Next
    #1

    Boot delay dmesg info

    Noticed a delay in boot and not the normal kubuntu splash
    I have a bios splash then a very brief kubuntu which then switches back to the bios splash. Then eventually I get the login
    Normally I would expect cold boot to login in not many seconds with a SSD
    However, this install is running around 50 sec

    I pulled a big delay section from dmesg
    Code:
    [FONT=monospace][COLOR=#18B218][    2.864895] [/COLOR][COLOR=#B26818]logitech-hidpp-device 0003:046D:4054.0003[/COLOR]: input,hidraw2: USB HID v1.11 Mouse [Logitech Wireless M
ouse] on usb-0000:00:14.0-4/input1:2
[COLOR=#18B218][   31.882734] [/COLOR][COLOR=#B26818]ata1.00[/COLOR][COLOR=#B21818]: exception Emask 0x0 SAct 0x1000000 SErr 0x0 action 0x6 frozen[/COLOR]
[COLOR=#18B218][   31.882737] [/COLOR][COLOR=#B26818]ata1.00[/COLOR][COLOR=#B21818]: failed command: READ FPDMA QUEUED[/COLOR]
[COLOR=#18B218][   31.882740] [/COLOR][COLOR=#B26818]ata1.00[/COLOR][COLOR=#B21818]: cmd 60/08:c0:00:00:00/00:00:00:00:00/40 tag 24 ncq dma 4096 in[/COLOR]
[COLOR=#B21818]                        res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)                              [/COLOR] 
[COLOR=#18B218][   31.882741] [/COLOR][COLOR=#B26818]ata1.00[/COLOR][COLOR=#B21818]: status: { DRDY }[/COLOR]
[COLOR=#18B218][   31.882743] [/COLOR][COLOR=#B26818]ata1[/COLOR]: hard resetting link
[COLOR=#18B218][   32.197582] [/COLOR][COLOR=#B26818]ata1[/COLOR]: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[COLOR=#18B218][   32.198217] [/COLOR][COLOR=#B26818]ata1.00[/COLOR]: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded
[COLOR=#18B218][   32.198219] [/COLOR][COLOR=#B26818]ata1.00[/COLOR]: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
[COLOR=#18B218][   32.198220] [/COLOR][COLOR=#B26818]ata1.00[/COLOR]: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out
[COLOR=#18B218][   32.199148] [/COLOR][COLOR=#B26818]ata1.00[/COLOR]: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded
[COLOR=#18B218][   32.199149] [/COLOR][COLOR=#B26818]ata1.00[/COLOR]: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
[COLOR=#18B218][   32.199150] [/COLOR][COLOR=#B26818]ata1.00[/COLOR]: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out
[COLOR=#18B218][   32.199387] [/COLOR][COLOR=#B26818]ata1.00[/COLOR]: configured for UDMA/133
[COLOR=#18B218][   32.209917] [/COLOR][COLOR=#B26818]ata1.00[/COLOR][B]: device reported invalid CHS sector 0[/B]
[COLOR=#18B218][   32.209923] [/COLOR][COLOR=#B26818]ata1[/COLOR]: EH complete
[COLOR=#18B218][   32.212993] [/COLOR][COLOR=#B26818] sda[/COLOR]: sda1 sda2 sda3

[/FONT]
    kubuntu 20.10
    Tags: boot, dmesg
    • Top
    • Bottom
    #2
    The messages/errors are coming from the sata controller. It could be a problem with the controller, or a failing drive. Although it could also be something as simple as bad cables/cable connections.
    (Although it is a bit strange if this only happens during boot, have you tried running smartctl [package 'smartmontools'] for the drive?)

    I'd check the cables first (use known good ones if you have them). I'd also backup the data from the drive, just in case it is the drive itself.
    After that, you can google the different error messages you see in dmesg for possible solutions.
    • Top
    • Bottom

    Comment

      #3
      I ran smart on the drive and it checks out fine
      I have a feeling now it could be related to a 200GB SD card I have. I just pulled it and rebooted and all went well. I need to trial a bit further
      kubuntu 20.10
      • Top
      • Bottom

      Comment

        #4
        Inconclusive so far as several reboot and power off / power up later, with and without SD card and no boot delay and dmesg is all good
        It had been a while since a reboot when this delay happened so now I'm wondering if Trim is having something to do with it.
        kubuntu 20.10
        • Top
        • Bottom

        Comment

          #5
          You really shouldn't have trim running all the time anyway. I believe the default nowadays is a weekly cronjob, which wouldn't effect boot time. I recommend against setting trim or discard as a mount option. I also have noticed a long boot because I have an NVMS drive, 2 SSDs, and 2 HDs that I was mounting at boot. Now I only mount the boot device (NVMS) and the others mount when needed. Lowered my boot time considerably.

          Please Read Me
          • Top
          • Bottom

          Comment

            #6
            Trim is default
            As I said it was some time since a reboot, probably well over a week which was why I was thinking that way
            kubuntu 20.10
            • Top
            • Bottom

            Comment

              #7
              Just because it's default (not really sure what you mean) doesn't mean it's the best idea. But whatever, it's your system.

              Please Read Me
              • Top
              • Bottom

              Comment

                #8
                Originally posted by oshunluvr View Post
                Just because it's default (not really sure what you mean) doesn't mean it's the best idea. But whatever, it's your system.
                Default in kubuntu / ubuntu is weekly
                kubuntu 20.10
                • Top
                • Bottom

                Comment

                  #9
                  Originally posted by kernelbasher View Post
                  Trim is default
                  As I said it was some time since a reboot, probably well over a week which was why I was thinking that way
                  Your're right, trim is default, and so is the timing for it. It is set up automatically for SSD's when you install BTRFS.
                  Code:
                  [B]:~$ systemctl list-timers[/B]
NEXT                         LEFT          LAST                         PASSED       UNIT                         ACTIVATES
Sat 2020-01-25 21:30:53 CST  17min left    Sat 2020-01-25 20:32:53 CST  40min ago    anacron.timer                anacron.service
Sun 2020-01-26 00:00:00 CST  2h 46min left Sat 2020-01-25 14:47:17 CST  6h ago       logrotate.timer              logrotate.service
Sun 2020-01-26 00:00:00 CST  2h 46min left Sat 2020-01-25 14:47:17 CST  6h ago       man-db.timer                 man-db.service
Sun 2020-01-26 03:10:43 CST  5h 57min left Sun 2020-01-19 11:33:30 CST  6 days ago   e2scrub_all.timer            e2scrub_all.service
Sun 2020-01-26 06:20:58 CST  9h left       Sat 2020-01-25 15:24:21 CST  5h 49min ago apt-daily-upgrade.timer      apt-daily-upgrade.service
Sun 2020-01-26 08:59:37 CST  11h left      Sat 2020-01-25 18:11:58 CST  3h 1min ago  motd-news.timer              motd-news.service
Sun 2020-01-26 09:26:02 CST  12h left      Sat 2020-01-25 20:31:08 CST  42min ago    apt-daily.timer              apt-daily.service
Sun 2020-01-26 16:54:00 CST  19h left      Sat 2020-01-25 19:18:15 CST  1h 55min ago fwupd-refresh.timer          fwupd-refresh.service
Sun 2020-01-26 17:36:08 CST  20h left      Sat 2020-01-25 17:36:08 CST  3h 37min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.se>
[B]Mon 2020-01-27 00:00:00 CST  1 day 2h left Mon 2020-01-20 11:08:41 CST  5 days ago   fstrim.timer                 fstrim.service[/B]
                  As you can see in the fstrimer.service script below, it is once a week. Trimming too much is detrimental to SSD's and not trimming at all is even worse. It depends on how much writing you are doing so somewhere between once a week and once a month.

                  Here is the fstrimer.service script:
                  Code:
                  [Unit]
Description=[B]Discard unused blocks once a week[/B]
Documentation=man:fstrim
ConditionVirtualization=!container


[Timer]
OnCalendar=weekly
AccuracySec=1h
Persistent=true


[Install]
WantedBy=timers.target
                  Last edited by GreyGeek; Jan 25, 2020, 09:26 PM.
                  "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
                  – John F. Kennedy, February 26, 1962.
                  • Top
                  • Bottom

                  Comment

                    #10
                    I have no btrfs partitions.
                    Mon 2020-01-27 00:00:00 CET 15h left Mon 2020-01-20 08:18:50 CET 5 days ago fstrim.timer fstrim.service
                    and I didn't set it up.
                    • Top
                    • Bottom

                    Comment

                      #11
                      Originally posted by Don B. Cilly View Post
                      I have no btrfs partitions.
                      Mon 2020-01-27 00:00:00 CET 15h left Mon 2020-01-20 08:18:50 CET 5 days ago fstrim.timer fstrim.service
                      and I didn't set it up.
                      It isn't related to or exclusive to btrfs, it comes from util-linux package and will run on any filesystem on an ssd
                      • Top
                      • Bottom

                      Comment

                        #12
                        My comment regarding trim was related to the OPs comment that the boot delay might be related to trim. Since trim is not run a boot time by default (as several of us have already pointed out), I made the assumption that the OP had enabled it via fstab, thus activating the process at boot time and therefore making it a suspect of the boot delay. Obviously, if this is not the case is seems impossible that trim could be related to lengthening the boot time.

                        Please Read Me
                        • Top
                        • Bottom

                        Comment

                          #13
                          Back to the issue: rather than stating the smart reports "checks out fine" how about attaching it to a post? There might be something you missed. So far I'd say Kubicle probably has is right. If the drive is, in fact, not failing then it has to be the cable or controller. I've seen both fail, but the cable is the most likely culprit and luckily the least expensive or difficult to replace.

                          Please Read Me
                          • Top
                          • Bottom

                          Comment

                          Previous template Next
                          Working...
                          X