[DESKTOP] From Grub II to loading Plasma takes about 2 minutes now

[steve7233]

Yesterday I applied the big update and rebooted. It took a while but I figured that was probably due to redoing some stuff to finish the update. Today I turned on my machine and got the same delay! I wonder if the fact that I am having to use a larger boot sector size for Grub II to boot my newer tech SSD's might be the cause. Maybe some of the commands that the Ubuntu devs use might be too old and aren't working correctly for the newer tech SSD's.

[oshunluvr]

No, boot sector size is not a delay factor IME. Actually, I'm not sure what you even mean by that. A boot sector is only 512b. period. Try

systemd-analyze blame

to see what the delay is. Most likely, excessive mount times or networking.

[Don B. Cilly]

Try
systemd-analyze blame
to see what the delay is. Most likely, excessive mount times or networking.

Or if that doesn't help (much), dmesg -T - or turning off (eliminating) QUIET SPLASH in /etc(default/grub (and re-updating grub) ;·)

[jglen490]

Same update applied here.

john@john-desktop:~/Downloads$ systemd-analyze
Startup finished in 11.614s (firmware) + 5.530s (loader) + 2.692s (kernel) + 9.797s (userspace) = 29.635s
graphical.target reached after 9.791s in userspace

No change. It's something else.

[steve7233]

I was referring to the fact that the default of 1024 sectors at the beginning of the boot partition is not big enough for Grub II to install and you have to manually change it to 2048 in order to have enough space to install Grub II on these newer tech SSD's.

[steve7233]

Be back later. Watching NASA, Space X demo 2 flight readiness review.

[jglen490]

Essentially, when I went from spinners to SSDs, boot time no longer mattered. Boot went from on the order of minutes, to being measured in seconds. And the current systemd-analyze time is about half what it was on my old MB right before it blew chunks ...

I have a cheap ASRock MB (not all of them are!), and it's what I wanted for an immediate replacement (from Amazon) of the old MB (died Wednesday, completely back up on Saturday) because it took all my other components. I'm working on the list for my next setup, which will be much better

And to Steve7233's statement about expanding the "boot partition" from 1024 to 2048. It almost sounds like legacy boot on a GPT partition table. If so, then this would be a perfect candidate for straight up UEFI and an ESP which can be sized to anything.

[Don B. Cilly]

Yes, my boot times (on a six-year-old mobo, and a barely decent SSD) are fast enough for me.
I boot back and forth all the time, no problem.

Personally, I'm just curious about them.

My last boot:

09:38 not@all:~$ systemd-analyze
Startup finished in 7.623s (firmware) + 8.880s (loader) + 6.168s (kernel) + 6.833s (userspace) = 29.505s
graphical.target reached after 6.808s in userspace

But then I only have
4.902s systemd-networkd-wait-online.service
compared to the 12 seconds or so I used to have with NetworkManager-wait-online.service... that probably is a slight advantage :·)

[jglen490]

Slight advantage ...

But the real question is, "advantage" for what? I was distinctly underwhelmed by the couple of seconds that systemd-analyze indicated that I'd saved from chasing apt-daily.service out of the boot stream. In reality, wall clock time is the only thing that matters, and if it's good ("from on the order of minutes", "to seconds") that's good enough.

[oshunluvr]

I was referring to the fact that the default of 1024 sectors at the beginning of the boot partition is not big enough for Grub II to install and you have to manually change it to 2048 in order to have enough space to install Grub II on these newer tech SSD's.

OK, gotcha. You've sort of mixed a couple things together. Let me split some hairs for you (lol):

The "boot sector", actually "Master Boot Record" (MBR) is now and always has been 512 bytes (34 sectors) as you can see here: https://en.wikipedia.org/wiki/Master...#Sector_layout . The newer and better partitioning scheme, "GUID Partition Table" (GPT) uses the same 512 byte space https://en.wikipedia.org/wiki/GUID_Partition_Table. Both of these take only 512 bytes and reserve sectors 0 or 1 to 33 (I'm not entirely sure if they start at 0 or 1).

The reason we start partitions at sector 2048 by default when partitioning has nothing to do with GRUB. It has everything to do with sector and partition alignment and changes to drive geometry, which happens to be rather critical to SSD performance. Starting off-sync with the SSD "borders" causes a real slow-down in read/write - and that's why we bought SSD's right? Platter drives hardly notice the difference, but SSDs really show it. So the default starting sector for all formatting was changed to 2048 because most people don't have the skill or knowledge to adjust that, plus, it's a real pain if you start out wrong and have to reformat. So now when we start our partitions at sector 2048 to align them properly, the sectors between the MBR/GPT and the first partition - sectors 34-2047 - normally go unused - about 1MB. The old default starting sector was 63 for some reason.

Then there was a change to GRUB that occurred when we went to GRUB2 from Legacy GRUB several years back - before GPT was in common use like it is now. The amount of available space in the 512B boot sector changes when you use GPT formatting instead of MBR formatting. The GPT boot sector isn't big enough to hold all that is needed for the GPT stuff AND GRUB, so we accommodate GRUB with a "BIOS boot partition" - partition type EF02. This is explained particularly well here in the section referencing GRUB 2. When using Extensible Firmware Interface (EFI) instead of old-fashioned BIOS, we use an EFI system partition (ESP) instead, partition type EF00. Both of these just to make room for GRUB2 Stage 2.

If you are using GRUB and GPT but not EFI, you can squeeze the needed EF02 partition into the unused space at sectors 34-2047 by following this guide I wrote. This does not hurt SSD performance because you only read the EF02 partition at boot time.

Now that I've gotten that off my chest - none of the above would slow down your boot time.

[steve7233]

Ever since the microcode update from Jun 9th, 2020, boot times have been a lot faster and is now about half a minute or so from GRUB II. The mouse pointer stays frozen for about two minutes both before and after the update, -I counted-. I suspect the Linux kernel module -driver-, needs some tweaking for the Logitech G602. Also the mouse battery still never shows up in Battery and brightness in the tray. The keyboard does and sometimes Firefox does. The way the app behaves I suspect it is a bit bugged.

EDIT: I forgot to add that I fully charged the mouse batteries last night -Rechargeable double A's- and also turned the computer so the dongle was closer to the mouse. It stopped the mouse stutter but DID NOTHING to help the about 2-minute frozen mouse.

[jlittle]

EDIT: I forgot to add that I fully charged the mouse batteries last night -Rechargeable double A's-...

Conceivably, the lower voltage of some rechargeable batteries (1.2 V) is causing trouble. But, other than lasting longer on non-rechargeable batteries I wouldn't expect it to help.

Logitech keeps doing this to us. A long time ago I had one that needed a driver tweak to work properly, and I had to build it myself until it reached Ubuntu. And this year I forgot and bought a G300S, but fortunately someone has reverse engineered it and written something for it, for just the G300 and G300S.

If you have access to a windows install, even in a VM, it might be worth using the Logitech software from there to do some set up of the mouse, it might be better behaved after that.

Otherwise, the libratbag project says it supports the G602. You could install "piper", I see it in muon.

[steve7233]

Tried Piper:


Tried rebooting.

I added issue 542 to Piper's github project:
Logitech G602 not detected #542

[steve7233]

Is there a package yet for the 5.5 or newer Linux Kernel in the Ubuntu repos for 20.04? Someone on GitHub thinks that might be the problem. The kernel might not have the needed abilities. Apparently Logitech likes to include new techs faster than other companies.

[steve7233]

I think git hub figured it out as several people have this problem. It looks like Logitech made a new version of its multi-device wireless receiver/transmitter so the values for the dongle have changed and the ratbag project needs to update then it should work. It looks like testing is complete. We just have to get the Ubuntu devs to package it and add it to the repos for 20.04.