Well obviously I was wrong in my first post. It's ntp after all. Some 3 mins and 45 seconds to start.
EDIT: This is curious as I know you tried live boot, booting the installed LM, Ubuntu and a few other flavors of Linux. And they all presented an extremely long boot up time. I'm wondering if anything in BIOS settings could be contributing to this. But I've been wrong before (see my first post here ). I'm also no expert on ntp hanging on boot. But now we know what at least.
no-pager-b-p3 results:
-- Logs begin at Mon 2017-02-20 15:28:28 EST, end at Mon 2017-02-20 15:44:01 EST. --
Feb 20 15:28:29 walt-OptiPlex-GX520 kernel: hid-generic 0003:1A2C:0021.0003: usb_submit_urb(ctrl) failed: -1
Feb 20 15:28:52 walt-OptiPlex-GX520 ntpdate[879]: name server cannot be used: Temporary failure in name resolution (-3)
Feb 20 15:28:58 walt-OptiPlex-GX520 NetworkManager[740]: nm_device_get_device_type: assertion 'NM_IS_DEVICE (self)' failed
Feb 20 15:29:29 walt-OptiPlex-GX520 mdmwebkit[1104]: GLib-GObject-CRITICAL: g_signal_add_emission_hook: assertion 'signal_id > 0' failed
Feb 20 15:29:34 walt-OptiPlex-GX520 mdm[1083]: PAM unable to dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object file: No such file or directory
Feb 20 15:29:34 walt-OptiPlex-GX520 mdm[1083]: PAM adding faulty module: pam_kwallet.so
Feb 20 15:29:45 walt-OptiPlex-GX520 mdm[1083]: GLib-CRITICAL: g_key_file_get_string: assertion 'key_file != NULL' failed
Feb 20 15:29:45 walt-OptiPlex-GX520 mdm[1083]: GLib-CRITICAL: g_key_file_free: assertion 'key_file != NULL' failed
Feb 20 15:30:10 walt-OptiPlex-GX520 colord-sane[1503]: io/hpmud/pp.c 627: unable to read device-id ret=-1
Feb 20 15:30:14 walt-OptiPlex-GX520 pulseaudio[1390]: [pulseaudio] bluez5-util.c: GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
--state=failed results:
0 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
plot_svg results: Very lengthy and noted that it would be best opened in a browser, so not included here.
I did this, Menu >Settings >Date and Time > switch off "Network Time". Restarted, waited, then ran blame again. Blame showed 14.307s, however, timed with a watch startup took 3m 25s to get to the desktop. That is the same thing that happened as I reported yesterday (Sun Feb 19, 2017 10:16 am).
Found this on a website to disable ntp: sudo systemctl disable ntp. I ran it, restarted and no change, 3m 15s startup.
Re-enabled with this: sudo systemctl enable ntp and then switched network time back on in the Settings.
Once again, similar blame results:
3min 45.092s ntp.service
14.811s dev-sda1.device
12.788s ModemManager.service
10.216s networking.service
etcetera
Went into the bios, drilled down through all entries. Didn't know what I was looking for but I found nothing changed from the factory default settings.
I had problems with my Dell desktop before, taking a long time to boot and also after I logged in, it would take longer for my proper theme to display.
It ended up being a poorly seated board, a quick re-seat solved my issue. This was with Mint 17 so I didn't run systemd-analyze on it.
Also I think that systemd-analyze could be re-named systemd-find scape-goat as it can be misleading.
you could also check your UUID's of both partitions and compare with whats in /etc/fstab:
mintNme wrote:Update: Diagnostics results, no problems with hardware or memory.
odtech: I removed the "splash" as per your instructions. 1st screen message is about scanning for Btrfs filesystem; 2nd message has OS name, computer name, something about tty1, then computer name login:_ ; 3rd message is the same as the 2nd.
YouTube Slow Startup Video: https://youtu.be/dybYCTWgq0g
GRUB: 1st message is at 37s, 2nd at 1m 19s, 3rd at 1m 31s.
Startup from power on to desktop 3 minutes 15 seconds.
I will use it as is, unless there is a quick, easy fix.
That wasn't quite what i was expecting, it seems you have to remove "quiet" too from grub.
Remove it using the same steps as i posted earlier leaving the quote marks only with no space in between.
Now it will show you the wall of text and you can see at what point it gets stuck the longest.
greerd: The UUIDs match. Perhaps you are right about a "poorly seated board" but I'm not at the point where I want to open this old box and start messing with boards that I know nothing about. I suspect that I could do more harm than good.
odtech: I removed the quite splash. As a result, the 1st very lengthy GRUB list scrolled by very quickly with very few pauses, too quickly to read. Then it went on to the 2nd message Login_. Using a watch, GRUB appeared around 15s after I pressed the power button. The 1st message (list) ran until 1m 12s so that list ran for about 55 sec with very few pauses, then it went on to the 2nd message, Login_, from there it took about 2m 8s to get to the Desktop. Total time was 3m 20s.
The current blame result is very similar to what it has been:
3min 45.051s ntp.service
14.526s networking.service
14.345s dev-sda1.device
12.795s accounts-daemon.service
12.447s loadcpufreq.service
10.729s grub-common.service
10.267s ModemManager.service
etc.
It appears to me that GRUB starts very near to that "14.526s networking.service" entry because that is similar to my watch time of 15s for the GRUB list to begin. So, under the guise of that 3m 45s ntp.service GRUB is running during that time with who knows what else. As I now see it the ntp.service is a misnomer, that is based on my disabling and re-enabling it on 2 occasions during this ordeal without any noticeable improvement.
There are 2 lines shown in RED in the Terminal text. Perhaps that means something!
The RED line (2nd from bottom) is related to .swap. It has the same UUID number as the 1st entry for .device.
At greerd's suggestion I had checked the UUIDs:
sda
├─sda1 ext4 f126a980-6454-4be5-8070-b0afc65e325d / <----This number DOES NOT show up in the "critical-chain" results.
├─sda2
└─sda5 swap a63bc174-68be-47e5-9f59-b769bfc5ac11 [SWAP] <...This number is shown as ".device", and also ".swap", in the "critical-chain" results.
mintNme wrote:greerd: The UUIDs match. Perhaps you are right about a "poorly seated board" but I'm not at the point where I want to open this old box and start messing with boards that I know nothing about. I suspect that I could do more harm than good.
If I understand this correctly, the live boot also takes a long time? I think a re-seating is the next order of business, you don't have to pull the cards right out, just wiggle & push. (break the rust!) All cards, memory sticks, connectors that plug into the mother board should be wiggled & pushed.
greerd, the RED uuid line in the critical-chain results, with device and swap having the same uuids is of concern at this time. I will seriously consider your advice and I will most probably do as you suggest. However, I had thought that when I ran the Dell Diagnostics and Memory tests a fault would have shown up at that time.
FYI, to all: When using the Terminal I have been using commands that create a txt file to the desktop rather than showing any text in the Terminal window. For instance: I used "systemd-analyze critical-chain > ~/Desktop/critical-chain.txt". As a result, I did not see the RED lines that show when running just "systemd-analyze critical-chain" which shows the text in the Terminal. Each time, in the text documents, I saw symbols in the lines that are in RED on the Terminal but I failed to recognize what those symbols meant. Examples: [0;1;31mdev-disk-by\x2duuid-a63bc174\x2d68be\x2d47e5\x2d9f59\x2db769bfc5ac11.swap @18.899s +520ms[0m and [0;1;31mModemManager.service @22.732s +12.324s[0m. I had no way of knowing that those symbols meant RED text.
viewtopic.php?t=226892 Have you done anything with the swap partition lately? Look at Greywolf's post (second to last). I had one installer sneakily format it for me in multiboot situation and it increased boot time.
MintyO, I looked at the link that you provided. I am not multiple booting, find no evidence of any "multiboot situation" and I have made no changes to swap. I have a separate swap partition, no swap files that I know of and, as noted before, the UUIDs were checked/compared and appear to be valid.
My todo list now consists of finding out why the critical-chain results have those RED entries and what those RED items mean. Later today I will probably open the box and wiggle some contents. In the meantime, maybe someone will know how to fix for the RED terminal entries. Especially where when first starting up the device and swap show the same UUIDs.
Okay, I thought I mentioned just in case. Sorry, I'm not really of help in these kinds of troubleshooting. Just to add one thing about those red entries, I have 2 red entries too and my boot time is normal.
mintNme wrote:MintyO, I looked at the link that you provided. I am not multiple booting, find no evidence of any "multiboot situation" and I have made no changes to swap. I have a separate swap partition, no swap files that I know of and, as noted before, the UUIDs were checked/compared and appear to be valid.
My todo list now consists of finding out why the critical-chain results have those RED entries and what those RED items mean. Later today I will probably open the box and wiggle some contents. In the meantime, maybe someone will know how to fix for the RED terminal entries. Especially where when first starting up the device and swap show the same UUIDs.
Seems like you're on the right track. But stepping back a bit I'm still wondering WHY a live boot takes so long as well. The swap UUID's shouldn't be a problem at that stage I would think. Maybe Greegd's suggestion to check/reseat your hardware (do all the cables you can as well) would help. And that link to Xenopeek's post on swap from Mintyo might help as well.
Just because it passed diagnostics doesn't mean something isn't mucking up intermittently. Look at it this way. Two days ago you were going to live with it. Now you have something interesting to do for hours on end, i.e. debugging.
I have the same issue now.
I had an HP pavilion desktop, MB died on me and I could not recover the windows 10 setup.
it was OEM install upgraded in place. somehow it was not connected to my ms account on update so
now it says I have to buy new license. I figured this would be the best opportunity to move this machine to Mint.
so the hardware is
(I do not remember right now 100%) but I believe it is a GIGAByTE M5A78L I used it for my HTPC with Mint 17/Kodi
8GB ram
an AMD Phenom 2 quad core CPU
OS is installed on 120GB laptop drive
I also have a 1TB drive where the old windows 10 was/is setup.
as of now the old setup is not accessible. Mint says the drive is locked and cannot be mounted.
I suspect it is the way win10 works as it does not shutdown but go to sleep hence leaving the disk in locked state.
next weekend I will try to reformat the disk for linux properly. (this is the PC my father In-law uses, so I grabbed all data from the windows on an external drive and am letting him look over the backup before wiping the windows 10 setup to hell) I only have about two more week before mandatory activation kicks in and locks me out of setup so I set myself a limit of one week for all)
it is possible that my problem is that Mint tries to mount the old drive on boot and hangs on time out as it can not access the drive.
if I reformat the old drive and it solves the problem great, if not i will be back here looking for solution.
PS>> can someone tell me if/how it is possible to move the mint install I have to SSD.
the laptop drive I used is a bit oldish and maybe slow to add to the pain. if I get a new SSD , can I copy the whole setup onto it? I really do not wish to reinstall and reconfigure the system.
I wiggled some wires/connections, unplugged and replugged others, removed and re-installed memory, replaced the battery, and blew out some dust. Had to go to the bios to reset the date/time so I checked each setting again. After it booted up, slowly, I waited a while then shutdown, waited some more then started up. Timed with watch, 3m15s to desktop. Waited 10m, ran blame and critical-chain.
I dunno at this point. We need someone smarter than you and I. Take a look at this (it's the SAME link that grumpy_geek posted when you started this thread. But this will take you to the last post there. viewtopic.php?f=46&t=224604&start=20#p1281517
Do the lsblk -f command. You're going to comparing these UUIDs against the contents of the file /etc/fstab. See if the UUIDs match. Meanwhile I'll look for some more posts on a massively long ntp hang on boot or whatever else might make sense.
At this point I suspect hardware since ALL version of Linux you tried do the same thing, even on a live boot. But then again, your diagnostics and memory test all passed, right? Of course that doesn't mean there isn't some problem that diagnostics don't pick up.
EDIT: Fwiw.. if you have another network cable try switching that. If it works I'll shoot myself.
gtsfedr, the UUIDs have already been compared as per greerd's suggestion (Mon Feb 20, 2017 6:47 pm). They are correct. Network cable? I'm not on a network.
I visited a friend who has a Dell GX280SD. I ran 2 live dvds, 18.1 cinnamon and 18.1 mate. From power on to desktop, cinnamon 3m26s then we listened to the disk spinning for another 1m12s. For mate 4m17s to desktop then disk spinning for another 2m2s. Based on all that I have done I have a hard time believing that there are folks getting to the desktop in the times that have been posted. I will be allowed to take a hard drive over and install LM on the GX280SD. I'm going to use the mate version for that installation.
vl1969 wrote:
I also have a 1TB drive where the old windows 10 was/is setup.
as of now the old setup is not accessible. Mint says the drive is locked and cannot be mounted.
I suspect it is the way win10 works as it does not shutdown but go to sleep hence leaving the disk in locked state.
You can change the shutdown behaviour in the Windows 10 system settings to "real" shutdown (please google that, as I'm to keep brain
free of that Win10 stuff as much as possible).
Try that first before killing a running system.
Yoga 910 16GB/2TB running Mint 20.3 Cinnamon 64Bit
__________________________
…trust me - I’m the sunscreen.
mintNme wrote:gtsfer, the UUIDs have already been compared as per greerd's suggestion (Mon Feb 20, 2017 6:47 pm). They are correct. Network cable? I'm not on a network.
Saw that before groping at straws I guess. Yes you are on a network btw. You are connected to the internet right? It's with a cable from the looks of your card (i.e. it's not wifi). That's "on a network" so to speak. But never mind that anyway. https://www.amazon.com/Broadcom-BCM5751 ... B005NX1DAK (Link is just for reference)
mintNme wrote:I visited a friend who has a Dell GX280SD. I ran 2 live dvds, 18.1 cinnamon and 18.1 mate. From power on to desktop, cinnamon 3m26s then we listened to the disk spinning for another 1m12s. For mate 4m17s to desktop then disk spinning for another 2m2s. Based on all that I have done I have a hard time believing that there are folks getting to the desktop in the times that have been posted. I will be allowed to take a hard drive over and install LM on the GX280SD. I'm going to use the mate version for that installation.
OK, EXACTLY how are you making your DVDs or flash sticks? This CAN'T be right that it takes so long to boot LM on two different computers now. And with both Mate and Cinnamon. Maybe we've been barking up the wrong tree all along. Did you verify the checksum of the download?
You tried Cinnamon, Mate, Ubuntu on your machine. And they all did the same thing? Plus your friend's machine now too? I'm an idiot, I should have checked this out long ago.
). I'm also no expert on ntp hanging on boot. But now we know what at least.
