[SOLVED] Slow Boot

[Don B. Cilly]

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:

[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:

[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.

[Snowhog]

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.

[Don B. Cilly]

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.

[Snowhog]

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.

[Don B. Cilly]

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.

[Don B. Cilly]

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:

not@all:/etc/modprobe.d$ grep btrfs *
not@all:/etc/modprobe.d$

[oshunluvr]

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

[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;

[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.

[oshunluvr]

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.

[Don B. Cilly]

lsmod:

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

  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.

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):

# <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

[oshunluvr]

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...

[Don B. Cilly]

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?

[oshunluvr]

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

[Don B. Cilly]

Well, it went rather painlessly. Took all of two seconds (or less).
Now gdisk says:

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

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 ;·)

[Snowhog]

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.

[oshunluvr]

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?