Strange Bios Messages, ubuntu taking several minutes to load.

mrmazda · 12-07-2022, 02:42 AM

Quote:

Originally Posted by Raxnic

When I run cat /var/log/Xorg.0.log | pastebinit in the terminal I get:
No such file or directory
Command 'pastebinit' not found, but can be installed with:
sudo apt install pastebinit

Just do it. Astute distros include it or an equivalent pastebinning tool by default. Check apropos pastebin to see if you already have an alternative.

Quote:

There is no Xorg.0.log or any other Xorg file in my /var/log directory.

/var/log/ is the traditional location for Xorg.0.log. Random distros have gotten the bright idea to move it into a hidden directory. Look for it in ~/.local/share/xorg/ if you don't find it in its traditional location.

Raxnic · 12-07-2022, 08:22 PM

Quote:

Originally Posted by mrmazda

Just do it. Astute distros include it or an equivalent pastebinning tool by default. Check apropos pastebin to see if you already have an alternative.

/var/log/ is the traditional location for Xorg.0.log. Random distros have gotten the bright idea to move it into a hidden directory. Look for it in ~/.local/share/xorg/ if you don't find it in its traditional location.

I installed pastebinit and ran: cat Xorg.0.log | pastebinit

https://paste.ubuntu.com/p/X8twkctsHY/

I found Xorg.0.log in /.local/share/xorg, should I just paste here?

Thanks.

mrmazda · 12-08-2022, 03:16 AM

The very last line in the log confirms something is wrong. It could be an issue in the kernel that would very likely be fixed by now if you were using a supported distro. Numbers such as [ 6405.572] at the beginning of the log's lines represent seconds since booting. If the pastebinned log was generated upon a fresh boot, its numbers are confirming slowness, more than 20 minutes between boot start and X startup finishing. Do you have any Linux DVDs or USB sticks with bootable Linux you could test to see how long they take to boot to a GUI desktop? Consider an upgrade to 22.04 LTS or 22.10 if yes and times are reasonable when not using 20.10.

What do sudo systemd-analyze critical-chain and sudo systemd-analyze blame report? Please post input/output here enclosed in code tags. Example:

Code:

# tail -n1 /var/log/Xorg.0.log
[    11.082] (II) modeset(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
# inxi -SGCM
System:
  Host: gb250 Kernel: 5.15.0-48-generic arch: x86_64 bits: 64 Desktop: Trinity
    Distro: Ubuntu 22.04.1 LTS (Jammy Jellyfish)
Machine:
  Type: Desktop System: Gigabyte product: B250M-D3H v: N/A serial: N/A
  Mobo: Gigabyte model: B250M-D3H-CF v: x.x serial: N/A
    UEFI: American Megatrends v: F10 date: 12/14/2018
CPU:
  Info: dual core model: Intel Core i3-7100T bits: 64 type: MT MCP cache:
    L2: 512 KiB
  Speed (MHz): avg: 800 min/max: 800/3400 cores: 1: 800 2: 800 3: 800 4: 800
Graphics:
  Device-1: Intel HD Graphics 630 driver: i915 v: kernel
  Display: server: X.org v: 1.21.1.3 driver: X: loaded: modesetting
    unloaded: fbdev,vesa dri: iris gpu: i915 resolution: 1: 2560x1440
    2: 1680x1050 3: 1920x1200
# systemd-analyze critical-chain
...
graphical.target @4.983s
└─watchdog.service @4.968s +14ms
  └─multi-user.target @4.966s
    └─smbd.service @4.856s +108ms
      └─nmbd.service @1.578s +3.272s
        └─network-online.target @1.510s
          └─network.target @1.510s
            └─systemd-resolved.service @1.312s +195ms
              └─systemd-tmpfiles-setup.service @1.291s +14ms
                └─local-fs.target @1.285s
                  └─usr-local.mount @1.268s +15ms
                    └─systemd-fsck@dev-disk-by\x2dlabel-pny5p04usrlcl.service @1.217s +39ms
                      └─dev-disk-by\x2dlabel-pny5p04usrlcl.device @1.005s

Raxnic · 12-08-2022, 06:16 PM

Quote:

Originally Posted by mrmazda

The very last line in the log confirms something is wrong. It could be an issue in the kernel that would very likely be fixed by now if you were using a supported distro. Numbers such as [ 6405.572] at the beginning of the log's lines represent seconds since booting. If the pastebinned log was generated upon a fresh boot, its numbers are confirming slowness, more than 20 minutes between boot start and X startup finishing. Do you have any Linux DVDs or USB sticks with bootable Linux you could test to see how long they take to boot to a GUI desktop? Consider an upgrade to 22.04 LTS or 22.10 if yes and times are reasonable when not using 20.10.

What do sudo systemd-analyze critical-chain and sudo systemd-analyze blame report? Please post input/output here

Yes I have some usb sticks i can download a bootable version to and check load times, I will give that a try.

I have version 22.10 I do all the updates as they show up.

Code:

The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @2min 44.405s
└─multi-user.target @2min 44.405s
  └─plymouth-quit-wait.service @2min 4.441s +39.962s
    └─systemd-user-sessions.service @2min 4.353s +86ms
      └─network.target @2min 4.349s
        └─NetworkManager.service @1min 58.807s +5.541s
          └─dbus.service @1min 52.721s +6.079s
            └─basic.target @1min 52.577s
              └─sockets.target @1min 52.577s
                └─snapd.socket @1min 52.576s +541us
                  └─sysinit.target @1min 52.532s
                    └─systemd-resolved.service @1min 51.967s +564ms
                      └─systemd-tmpfiles-setup.service @1min 50.241s +1.718s
                        └─systemd-journal-flush.service @55.517s +54.722s
                          └─systemd-remount-fs.service @54.423s +1.092s
                            └─systemd-journald.socket @53.379s
                              └─system.slice @52.722s
                                └─-.slice @52.722s

Code:

54.722s systemd-journal-flush.service
46.961s dev-sda2.device
39.962s plymouth-quit-wait.service
20.471s blueman-mechanism.service
18.960s dev-loop13.device
18.933s dev-loop11.device
18.776s dev-loop10.device
18.686s dev-loop12.device
18.426s dev-loop8.device
17.885s dev-loop14.device
17.872s dev-loop9.device
17.043s dev-loop15.device
16.776s dev-loop4.device
16.752s dev-loop5.device
16.706s dev-loop7.device
16.612s dev-loop0.device
16.258s dev-loop3.device
15.477s dev-loop2.device
15.340s dev-loop6.device
13.417s dev-loop1.device
13.353s systemd-udevd.service
13.214s snapd.service
11.320s accounts-daemon.service
lines 1-23

How can you see the pastebin I posted?

Thanks.

mrmazda · 12-08-2022, 07:25 PM

Quote:

Originally Posted by Raxnic

I have version 22.10 I do all the updates as they show up.

Your OP listed 20.10. Was it a typo? How recently did you recently upgrade to 22.10, and from what? Was 22.10 a fresh installation?

Quote:

How can you see the pastebin I posted?

Visiting there was how I discovered that

Quote:

the log confirms something is wrong

Some of those systemd-analyze times posted suggest an I/O bottleneck and/or an old and very slow system and/or disk. Please provide input/output from:

Code:

inxi -dMC
du -sx / /var/log/journal  /var/cache/apt/archives
df -h --exclude-type=tmpfs --exclude-type=devtmpfs --exclude-type=cgroup

Prepend sudo and rerun if either of those commands produce permission or command not found errors. You may need to install inxi first. If using SATA for Ubuntu's /, also run hdparm -t /dev/sda. If NVME, then do hdparm -t /dev/nvme0n1 instead.

Raxnic · 12-08-2022, 08:15 PM

Quote:

Originally Posted by mrmazda

Your OP listed 20.10. Was it a typo? How recently did you recently upgrade to 22.10, and from what? Was 22.10 a fresh installation?

Visiting there was how I discovered that

Some of those systemd-analyze times posted suggest an I/O bottleneck and/or an old and very slow system and/or disk. Please provide input/output from:

Code:

inxi -dMC
du -sx / /var/log/journal  /var/cache/apt/archives
df -h --exclude-type=tmpfs --exclude-type=devtmpfs --exclude-type=cgroup

Prepend sudo and rerun if either of those commands produce permission or command not found errors. You may need to install inxi first. If using SATA for Ubuntu's /, also run hdparm -t /dev/sda. If NVME, then do hdparm -t /dev/nvme0n1 instead.

Yes it was a typo. I installed 22.04 (fresh install on a brand new Westen Digital 2TB internal HD) upgraded to 22.10 just after installing 22.04.
Its not an old system, only a few years. 8 gigs of memory, Intel I3, although it does have on chip video.

Code:

inxi -dMC
Machine:
  Type: Desktop System: HP product: HP 280 G1 ST Business PC v: 1.00
    serial: <superuser required>
  Mobo: HP model: 2B5B v: 1.01 serial: <superuser required> UEFI: AMI
    v: A0.07 date: 11/03/2015
CPU:
  Info: dual core model: Intel Core i3-4170 bits: 64 type: MT MCP cache:
    L2: 512 KiB
  Speed (MHz): avg: 2969 min/max: 800/3700 cores: 1: 3692 2: 3692 3: 800
    4: 3695
Drives:
  Local Storage: total: 1.82 TiB used: 465.64 GiB (25.0%)
  ID-1: /dev/sda vendor: Western Digital model: WD20EZAZ-00L9GB0
    size: 1.82 TiB
  Optical-1: /dev/sr0 vendor: hp model: DVDRW DU8A6SH dev-links: cdrom
  Features: speed: 24 multisession: yes audio: yes dvd: yes
    rw: cd-r,cd-rw,dvd-r,dvd-ram

Code:

sudo du -sx / /var/log/journal  /var/cache/apt/archives
488248788	/

Code:

 df -h --exclude-type=tmpfs --exclude-type=devtmpfs --exclude-type=cgroup
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       1.8T  466G  1.3T  27% /
/dev/sda1       511M  5.3M  506M   2% /boot/efi

Thanks.

mrmazda · 12-09-2022, 12:16 AM

Yours is rather much alike what I'm typing from, which I run 24/7:

Code:

# inxi -dMCSz
System:
  Kernel: 5.14.21-150400.24.33-default arch: x86_64 bits: 64
    Console: pty pts/0 Distro: openSUSE Leap 15.4
Machine:
  Type: Desktop Mobo: MSI model: B85-G41 PC Mate(MS-7850) v: 1.0 serial: N/A
    BIOS: American Megatrends v: 2.9 date: 03/30/2015
CPU:
  Info: dual core model: Intel Core i3-4150T bits: 64 type: MT MCP cache:
    L2: 512 KiB
  Speed (MHz): avg: 2695 min/max: 800/3000 cores: 1: 2700 2: 2700 3: 2683
    4: 2700
Drives:
  Local Storage: total: raw: 1.93 TiB usable: 1.03 TiB
    used: 758.03 GiB (72.0%)
  ID-1: /dev/sda vendor: Patriot model: Burst Elite 120GB size: 111.79 GiB
  ID-2: /dev/sdb vendor: Seagate model: ST1000DM003-1CH162 size: 931.51 GiB
  ID-3: /dev/sdc vendor: Seagate model: ST1000NM0011 size: 931.51 GiB
...

The OS is clearly different, but the kernels are similar and the CPU is a close sibling, 35W TDP and 3.0GHz instead of your 65W TDP and 3.7GHz. The Seagates comprise RAID1. Booting is faster only in part because the OS runs from an SSD:

Code:

# systemd-analyze critical-chain
...
graphical.target @5.849s
└─multi-user.target @5.849s
  └─smb.service @5.696s +151ms
    └─nmb.service @2.605s +3.087s
      └─basic.target @2.482s
        └─sockets.target @2.482s
          └─uuidd.socket @2.482s
            └─sysinit.target @2.465s
              └─systemd-timesyncd.service @2.069s +395ms
                └─systemd-tmpfiles-setup.service @1.944s +82ms
                  └─local-fs.target @1.907s
                    └─disks-boot.mount @1.887s +10ms
                      └─systemd-fsck@dev-disk-by\x2dlabel-realboot03p775.service @1.688s +187ms
                        └─dev-disk-by\x2dlabel-realboot03p775.device @584542y 2w 2d 20h 1min 47.955s +3.283s

Most of the rest of the difference in startup time is surely from absence of 40s delay from plymouth-quit-wait.service and 54s delay from systemd-journal-flush.service. I would have thought sjfs in yours would be from an overabundant volume of data being written to /var/log/journal/*/*, but according to your du output, you don't have a persistent journal. I suggest you enable it by creating directory /var/log/journal, then reboot twice, and then run systemd-analyze critical-chain again to see if it impacts time consumed by systemd-journal-flush.service. Right after a boot completes, run sudo dmesg | wc -l and sudo journalctl -b | wc -l to see how much data is getting logged. Mine are 1070 and 4882, though my current uptime is 9 days, accounting for a much bigger number from the journal. Try running sudo dmesg | grep aile | less and sudo journalctl -b | grep aile | less to scan for outright failure messages. If you get a few, copy & paste here. If you get a lot, pastebin each of journal and dmesg in whole.

I don't have Plymouth installed on any OS, so can't relate how much time it should be expected to devour, but I sense 40s must be terribly excessive. It should be negligible.

A PC like yours ought to boot much faster, a little slower than the following due to HDD instead of SSD:

Code:

# inxi -CSMdz
System:
  Kernel: 5.15.0-48-generic arch: x86_64 bits: 64 Console: pty pts/0
    Distro: Ubuntu 22.04.1 LTS (Jammy Jellyfish)
Machine:
  Type: Desktop System: ASUS product: All Series v: N/A serial: N/A
  Mobo: ASUSTeK model: B85M-E v: Rev X.0x serial: <filter>
    UEFI: American Megatrends v: 3602 date: 04/04/2018
CPU:
  Info: dual core model: Intel Pentium G3220 bits: 64 type: MCP cache:
    L2: 512 KiB
  Speed (MHz): avg: 2893 min/max: 800/3000 cores: 1: 2893 2: 2894
Drives:
  Local Storage: total: 238.47 GiB used: 71.23 GiB (29.9%)
  ID-1: /dev/sda vendor: SanDisk model: TEAM T253X2256G size: 238.47 GiB
...
# systemd-analyze critical-chain
...
graphical.target @6.378s
└─multi-user.target @6.378s
  └─smbd.service @6.130s +247ms
    └─nmbd.service @5.905s +223ms
      └─network-online.target @5.902s
        └─systemd-networkd-wait-online.service @3.274s +2.627s
          └─systemd-networkd.service @3.177s +92ms
            └─network-pre.target @3.174s
              └─ufw.service @3.039s +130ms
                └─local-fs.target @3.005s
                  └─pub.mount @2.911s +92ms
                    └─systemd-fsck@dev-disk-by\x2dlabel-tg1p06pub.service @2.472s +423ms
                      └─dev-disk-by\x2dlabel-tg1p06pub.device @2.471s

This only has two total threads, but boots with about the same speed as my i3-4150T, also without lengthy plymouth or systemd-journal-flush.service.

Try running smartctl -t long /dev/sda, wait the announced time for it to finish, then do smartctl -x | pastebinit so we can check if your WD operating is up to spec. A quick HD speed-only test: hdparm -t /dev/sda.

Raxnic · 12-09-2022, 09:50 PM

https://paste.ubuntu.com/p/TCsNYbV3c4/

Quote:

Originally Posted by mrmazda

Yours is rather much alike what I'm typing from, which I run 24/7:Most of the rest of the difference in startup time is surely from absence of 40s delay from plymouth-quit-wait.service and 54s delay from systemd-journal-flush.service. I would have thought sjfs in yours would be from an overabundant volume of data being written to /var/log/journal/*/*, but according to your du output, you don't have a persistent journal. I suggest you enable it by creating directory /var/log/journal, then reboot twice, and then run systemd-analyze critical-chain again to see if it impacts time consumed by systemd-journal-flush.service. Right after a boot completes, run sudo dmesg | wc -l and sudo journalctl -b | wc -l to see how much data is getting logged. Mine are 1070 and 4882, though my current uptime is 9 days, accounting for a much bigger number from the journal. Try running sudo dmesg | grep aile | less and sudo journalctl -b | grep aile | less to scan for outright failure messages. If you get a few, copy & paste here. If you get a lot, pastebin each of journal and dmesg in whole.

I don't have Plymouth installed on any OS, so can't relate how much time it should be expected to devour, but I sense 40s must be terribly excessive. It should be negligible.

A PC like yours ought to boot much faster, a little slower than the following due to HDD instead of SSD:This only has two total threads, but boots with about the same speed as my i3-4150T, also without lengthy plymouth or systemd-journal-flush.service.

Try running smartctl -t long /dev/sda, wait the announced time for it to finish, then do smartctl -x | pastebinit so we can check if your WD operating is up to spec. A quick HD speed-only test: hdparm -t /dev/sda.

The /var/log/journal already exists There are several long alpha-numeric files in it.

Code:

The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @2min 19.773s
└─multi-user.target @2min 19.773s
  └─plymouth-quit-wait.service @1min 40.062s +39.710s
    └─systemd-user-sessions.service @1min 39.813s +246ms
      └─network.target @1min 39.808s
        └─NetworkManager.service @1min 34.699s +5.108s
          └─dbus.service @1min 29.731s +4.963s
            └─basic.target @1min 29.710s
              └─sockets.target @1min 29.710s
                └─snapd.socket @1min 29.709s +949us
                  └─sysinit.target @1min 29.614s
                    └─systemd-resolved.service @1min 28.271s +1.343s
                      └─systemd-tmpfiles-setup.service @1min 26.015s +2.210s
                        └─systemd-journal-flush.service @1min 6.908s +19.105s
                          └─systemd-journald.service @1min 5.306s +1.601s
                            └─systemd-journald.socket @1min 5.233s
                              └─-.mount @1min 4.568s
                                └─-.slice @1min 4.568s

This plymouth thing, I did see it was taking alot of boot time. I looked it up and I guess it comes with Ubuntu because I did not install it and I dont really think I need it. It seems to be some kind of graphical thing while booting.

Code:

 sudo dmesg | wc -l
1021

Code:

sudo journalctl -b | wc -l
4873

Code:

sudo dmesg | grep aile | less
[   88.481671] systemd[1]: File System Check on Root Device was skipped because of a failed condition check (ConditionPathExists=!/run/initramfs/fsck-root).
[   88.570678] systemd[1]: Repartition Root Disk was skipped because all trigger condition checks failed.
[   89.694808] systemd[1]: Platform Persistent Storage Archival was skipped because of a failed condition check (ConditionDirectoryNotEmpty=/sys/fs/pstore).
[  102.175949] spi-nor: probe of spi0.0 failed with error -22

This is journalctl -b | grep aile | less and shows a huge amount of errors / failures
https://paste.ubuntu.com/p/TCsNYbV3c4/

This is sudo dmesg | grep aile | less
https://paste.ubuntu.com/p/kN7tTYk3QZ/

I tried to install smartmontools and cannot.
I got this after running hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 630 MB in 3.00 seconds = 209.85 MB/sec
Thanks

mrmazda · 12-10-2022, 12:35 AM

Plymouth is a howitzer used to quiet a chirping bird; bloatware installed by default unnecessarily on too many distros. It provides a GUI curtain to hide boot process messages. The OS doesn't need it do do its normal work. How much time it ought to consume I can't say, but you ought to be able to reduce your own boot time by up to about 40s by uninstalling it.

On a 3-4 year newer system I get this immediately on boot completion:

Code:

# inxi -CMS
System:
  Host: ab250 Kernel: 5.15.0-47-generic arch: x86_64 bits: 64
    Desktop: Trinity Distro: Ubuntu 22.04.1 LTS (Jammy Jellyfish)
Machine:
  Type: Desktop Mobo: ASUSTeK model: PRIME B250M-C v: Rev X.0x
    serial: 171013077301155 UEFI: American Megatrends v: 1608 date: 10/21/2019
CPU:
  Info: quad core model: Intel Core i5-7500T bits: 64 type: MCP cache:
    L2: 1024 KiB
  Speed (MHz): avg: 800 min/max: 800/3300 cores: 1: 800 2: 800 3: 800
    4: 800
# dmesg | wc -l
970
# journalctl -b | wc -l
1410

Comparing this to your results suggests need to evaluate your journal to see why yours contains so many lines:

Code:

sudo journalctl -b | pastebinit

Simply run sudo journalctl -b to scan through it yourself to look for more clues than the obvious one many times repeated:

Code:

snap.snapd-desktop-integration.snapd-desktop-integration.service: Failed with result 'exit-code'

Likely the following will speed up boot without solving whatever the underlying problem actually is that causes the failure and lengthy delay:

Code:

sudo systemctl disable snap.snapd-desktop-integration.snapd-desktop-integration.service

None of my installations include snap*.

sudo dmesg | grep aile | less and sudo journalctl -b | grep aile | less were for local examination of selected lines out of those logs. man less. To pastebin you replace less with pastebinit.

Quote:

/var/log/journal already exists There are several long alpha-numeric files in it.

/var/log/journal on all of my installations has but one file in it, a subdirectory. That subdirectory contains large files on systems with persistent journal enabled. If the journal subdirectory contains more than one subdirectory, something is wrongly configured. Long alpha-numerically named files are expected in that subdirectory. They comprise the persistent journal. If there are lots and lots of files or lots of files with old dates you can gain some disk space by reconfiguring /etc/systemd/journald.conf to limit the age and/or file count and/or size, etc. Excerpts from mine:

Code:

SystemMaxFiles=10
RuntimeMaxFiles=12

Your hdparm 209.85 MB/sec looks in range for your HDD.

apt install smartmontools worked for me on Jammy.

Raxnic · 12-10-2022, 03:03 PM

Quote:

Originally Posted by mrmazda

Plymouth is a howitzer used to quiet a chirping bird; bloatware installed by default unnecessarily on too many distros. It provides a GUI curtain to hide boot process messages. The OS doesn't need it do do its normal work. How much time it ought to consume I can't say, but you ought to be able to reduce your own boot time by up to about 40s by uninstalling it.

On a 3-4 year newer system I get this immediately on boot completion:

Code:

# inxi -CMS
System:
  Host: ab250 Kernel: 5.15.0-47-generic arch: x86_64 bits: 64
    Desktop: Trinity Distro: Ubuntu 22.04.1 LTS (Jammy Jellyfish)
Machine:
  Type: Desktop Mobo: ASUSTeK model: PRIME B250M-C v: Rev X.0x
    serial: 171013077301155 UEFI: American Megatrends v: 1608 date: 10/21/2019
CPU:
  Info: quad core model: Intel Core i5-7500T bits: 64 type: MCP cache:
    L2: 1024 KiB
  Speed (MHz): avg: 800 min/max: 800/3300 cores: 1: 800 2: 800 3: 800
    4: 800
# dmesg | wc -l
970
# journalctl -b | wc -l
1410

Comparing this to your results suggests need to evaluate your journal to see why yours contains so many lines:

Code:

sudo journalctl -b | pastebinit

Simply run sudo journalctl -b to scan through it yourself to look for more clues than the obvious one many times repeated:

Code:

snap.snapd-desktop-integration.snapd-desktop-integration.service: Failed with result 'exit-code'

Likely the following will speed up boot without solving whatever the underlying problem actually is that causes the failure and lengthy delay:

Code:

sudo systemctl disable snap.snapd-desktop-integration.snapd-desktop-integration.service

None of my installations include snap*.

sudo dmesg | grep aile | less and sudo journalctl -b | grep aile | less were for local examination of selected lines out of those logs. man less. To pastebin you replace less with pastebinit.

/var/log/journal on all of my installations has but one file in it, a subdirectory. That subdirectory contains large files on systems with persistent journal enabled. If the journal subdirectory contains more than one subdirectory, something is wrongly configured. Long alpha-numerically named files are expected in that subdirectory. They comprise the persistent journal. If there are lots and lots of files or lots of files with old dates you can gain some disk space by reconfiguring /etc/systemd/journald.conf to limit the age and/or file count and/or size, etc. Excerpts from mine:

Code:

SystemMaxFiles=10
RuntimeMaxFiles=12

Your hdparm 209.85 MB/sec looks in range for your HDD.

apt install smartmontools worked for me on Jammy.

I stopped Plymouth then unistalled it and there is no change in boot time at all, not only that, now Ive got a two more irq error messages at boot.

I am pretty sure SNAP is a Ubunto only thing and I have read that it is integrated into ubuntu and cannot be removed. I did end u disabling snap for firefox because firefox that came with Ubuntu would not run properly, after doing that I downloaded FF right from the Mozilla website and FF works like it should.

I have come to the conclusion that this is a hardware issue. I am going to open the box and check for jumper settings on the HD and MB and disconnect all USB devices, double check the HD is plugged in correctly and using the correct ribbon cable and reset the BIOS to see if anything changes.

Thanks for your time mrmazda.

Raxnic · 12-11-2022, 11:54 AM

I checked the HD and motherboard and jumpers are correct, I unistalled plymouth and disabled bluman (but it came back

)
I unplugged the keyboard and mouse and rebooted and nothing changed.

These look to be the culprits as to why its taking so long to boot:

Code:

 2.819739] scsi 4:0:0:0: Direct-Access     Generic- SD/MMC/MS PRO    1.00 PQ: 0 ANSI: 4
[    2.820429] sd 4:0:0:0: Attached scsi generic sg2 type 0
[    2.822422] sd 4:0:0:0: [sdb] Media removed, stopped polling
[    2.823140] sd 4:0:0:0: [sdb] Attached SCSI removable disk
[   32.098782] systemd[1]: Inserted module 'autofs4'

I dont have any removable disks attached.

Code:

[   37.431709] systemd[1]: Hostname set to <me>.
[   88.759294] systemd[1]: Queued start job for default target Graphical Interface.

Why would Hostname take so long?

Any ideas as to what else I can try?

Thanks.

mrmazda · 12-20-2022, 03:34 AM

Quote:

Originally Posted by Raxnic

Why would Hostname take so long?

Misconfiguration.

Quote:

Any ideas as to what else I can try?

My memory fails me on this. It's been a long time since this happened to me. If /etc/hostname or /etc/resolv.conf are symlinks, try renaming them and create real files with those names, with real content. Also, ensure your IP is properly placed in your /etc/hosts file.

What does hostnamectl have to report?

Raxnic · 12-25-2022, 02:42 PM

Quote:

Originally Posted by mrmazda

Misconfiguration.

My memory fails me on this. It's been a long time since this happened to me. If /etc/hostname or /etc/resolv.conf are symlinks, try renaming them and create real files with those names, with real content. Also, ensure your IP is properly placed in your /etc/hosts file.

What does hostnamectl have to report?

I ended up formatting the drive and installing a different version of ubuntu, it was not just the hostname that was taking forever it was the bios error messages and other things during boot that were slowing things down to over three minutes just to get to the gui. I installed ubuntu (minimal) on another system and it ran really fast with no problems I decided to do the same, so I installed Xubuntu and it still has the bios erros but down to one and a half minutes to boot. but of course there are other issues now......

Sorry took so long to reply.

Thanks for the help mrmazda