LL4.2 load time (5min+ No V Box) is 16 times longer than LL3.8 -ToshibaSatellite

[Yardvark]

LL4.2 load time (5min+ No V Box) is 16 times longer than LL3.8   


I have attached a page showing errors that appear during loading.

I am another Linux Newbie, and loved LL3.8. Unfortunately, LL4.x to date is a great disappointment.
On an SSD I have to wait 16 times as long for LL4.x to load as LL3.8 as timed from GRUB to Desktop.       
Virtual Box services have been removed as recommended and no longer, show in systemd-analyze blame.

I own a Toshiba Satellite A200-06V made around 2007. Vista era.
CPU=Intel Core2Duo T5250 @1.5GHz, I have upgraded from HDD to SSD and RAM from 1GB to 4GB.
Storage device load times > (NOTE: LL4.2 has V Box services removed)
              HDD                       SSD
LL3.8 0 min. 54sec.               0 min. 18sec. (SSD takes 33% of time of HDD)
LL4.2 334sec. (5min.34sec.) 293sec. (4min.53sec.) (SSD takes 88% of time of HDD)

With LL4 the HDD/SSD activity light shows remarkably little activity – mostly none at all.

I then tried an installation of LL4.x on a Dell Vostro_1400 (2x Intel Core2 Duo CPU T7250 @ 2.00GHz). The results were similar to those above.

- - - - - - - - - - - - - - - - - - - - -
Finally I installed LL4.2 in an HP Pavilion dv6500 (dv6627ca) laptop with dreamed of results - Fabulous.
This has an AMD chipset. CPU=AMD Turion 64x2  TL-58 @ 1.9GHz, RAM=2GB 
The HDD activity light was very busy. Load times from grub to desktop were:
Storage device load times > (NOTE: LL4.2 has V Box services removed)
            HDD       SSD
LL3.8 68 sec.         18 sec.
LL4.2 76 sec. 21sec (Not the 293 sec. 4m:53sec with the Toshiba\Intel chipset)

- - - - - - - - - - - - - - - - - - - - -
LL4.x runs beautifully on both computers once it has loaded but who will wait 5+ min. for the OS to load.

Last September I visited a local Linux Community group. Three Linux sages concluded that it was a Kernel problem vis-à-vis my Intel chipset and that my problem would probably be resolved with updates before very long. I have updated the Kernel from 4.15.0-24-generic #26-Ubuntu to 4.16.0 to 4.17.0  to 4.20.0 (Lite Tweaks) with no noticeable  improvement in load time.

I know this problem is not unique but I have not found an answer to my problem in this Forum.
I tried this below as best as I could. Neither 1 nor 2 made any difference.
https://askubuntu.com/questions/893817/b...per-errors

Advice on this subject would be much appreciated, as I would dearly love to be able to use LL4.x
Thanks In anticipation.
Yardvark

See Attachment: LL4.2-Toshiba loading errors.txt

[TheDead]

Hi,

I have seen this in the past regarding OS trying to access a non existent volume / swap .
Also, if your computer has bluetooth, this could be the culprit.

Try running these commands from terminal to pin down what is causing the problems :

systemd-analyze blame

and

systemd-analyze time

Cheers!

[Valtam]

Setting a static ip address can also greatly speed up boot, it could be sitting on dhcp waiting for an ip to be assigned.

[Yardvark]

Hi "TheDead"
Thanks for your suggestion to check Systemd-analyze time and Systemd-analyze blame.
...time reads Startup finished in 2min 11s (kernel) + 35.35s  (userspace) =2min 46.5sec graphical.target reached after 35.34s in userspace. I don't know what this should look like.

I see nothing unusual in ... blame except to say that the virtual box service (which was the most time-consuming item) has been removed as recommended.
Now I have
11.8s  udisks2.service
11.2s  dev-sda1
followed by 9s, 7s, 7s, 6s, on down to line 69/69 = 6ms  openVpn.service

There is no sign of anything repetitive (would that happen if OS was trying to access a non-existent volume?)

Selecting Recovery Mode gets me the Recovery Menu but where I should go from there I don't know. Also, it seems to me Recovery with the existing OS as it is on my computer is not what I want. Something needs to be changed.

[Valtam]

Might pay to copy ALL of the output from the terminal to here. That way members can help you with each systemd service.

[Yardvark]

Thanks, Jerry for your suggestion. Here is systemd-analyze as of the moment.
systemd-analyze blame
        11.126s udisks2.service
        10.424s dev-sda1.device
          9.984s networkd-dispatcher.service
          7.706s apparmor.service
          6.608s systemd-journal-flush.service
          5.612s NetworkManager.service
          5.300s ModemManager.service
          5.154s grub-common.service
          5.038s lightdm.service
          5.028s plymouth-quit-wait.service
          4.905s NetworkManager-wait-online.service
          4.870s accounts-daemon.service
          4.124s lvm2-monitor.service
          3.739s networking.service
          3.601s ufw.service
          3.196s systemd-udevd.service
          3.068s nmbd.service
          3.034s thermald.service
          2.805s wpa_supplicant.service
          2.264s apport.service
          1.862s avahi-daemon.service
          1.843s gpu-manager.service
          1.739s systemd-tmpfiles-setup-dev.service
          1.684s rsyslog.service
          1.679s systemd-rfkill.service
          1.348s polkit.service
          1.299s motd-news.service
          1.274s keyboard-setup.service
          1.193s smbd.service
          1.082s systemd-modules-load.service
          1.022s console-kit-log-system-start.service
          1.016s systemd-tmpfiles-setup.service
          899ms [email protected]
          853ms systemd-logind.service
          841ms systemd-timesyncd.service
          801ms systemd-resolved.service

Your suggestion to use a static IP address will take a while as I find out how to do it. I did find instructions in the Help Manual. In the past, I have not tried that as it seemed it would be a nuisance with mobile WiFi but if it helps solve the problem it will be worth it.

Thanks

[Valtam]

With a static IP, looking at your above information, you could potentially save 15+ seconds here.

[TheDead]

Hi,

Forgot to ask in my first post if you have use the driver search option.
If you have other drivers available maybe something will help there.
Also, for the network card(s), if not on a manual IP, try and disable IPv6 to see.

Blarg... can't find the Bluetooth info I was searching for but if you have bluetooth I think it was related to the bluez update mentionned on this here interweeb site :
https://medium.com/@overcode/fixing-bluetooth-in-ubuntu-pop-os-18-04-d4b8dbf7ddd6
Special Happy Bonus :  virtualbox has more than one service... just in case you only disable one
sudo apt purge virtualbox*
sudo systemctl stop vboxadd.service
sudo systemctl stop vboxadd-service.service
sudo systemctl disable vboxadd.service
sudo systemctl disable vboxadd-service.service

[Yardvark]

Hi – Thanks for your continuing help.
Thanks for indicating that a static IP address might save me about 15+ seconds.
To solve the problem (as I see it) I am looking to save in the order of 4 minutes in load time so saving a few seconds, here and there, looks more like a fine-tuning project for another day.
Do the error messages that show at the start of every LL4.x load that I attached to the original message indicate the general source of the problem?

I have attached a copy of today’s syslog in the hope that this in conjunction with the load error messages may be helpful. At this time I am particularly aware of my own weaknesses in availing myself of troubleshooting resources provided in the OS.

“TheDeath”  -- I’m not sure what drivers you have in mind that could, to advantage, be changed here.
Early on I did disable all 5 VBox services + untick VBoxclient in “Application Autostart” per Jerry’s advice.
Re Bluetooth – No adaptors are installed = No Bluetooth.
Thanks again
Yardvark

[Valtam]

Google 'drm:drm_atomic_helper' the first result should point to an Ubuntu 16.04 thread. Try the bug fix there.

Sent from my Mobile phone using Tapatalk