Linux - Hardware This forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux? |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
|
06-25-2020, 05:04 PM
|
#16
|
LQ Newbie
Registered: Nov 2003
Location: Canada
Distribution: Linux Miny 19.3
Posts: 29
Original Poster
Rep:
|
Quote:
Originally Posted by teckk
No kidding. Does it automatically check for updates and install them on boot up? I've been told that windows does that now whether you like it or not. No wonder the default on windows is to hibernate and not turn off.
|
AFAIK, Linux Mint does not update on boot. There is an error reported in the attached file, which I want to track down and verify that it is, or not, the cause of the slow boot. The message should not be relevant I was told. But I am searching the web, and seek more expert input, that the error may have been triggered by verifying the health of three disk drive and a DVD drive. The disk drives are: 120GB SSD for Windows 10 without user data, 1TB Seagate dedicated to Linux with 70GB of Linux data, and the 2B for everything else.
|
|
|
06-25-2020, 05:24 PM
|
#17
|
LQ Newbie
Registered: Nov 2003
Location: Canada
Distribution: Linux Miny 19.3
Posts: 29
Original Poster
Rep:
|
Quote:
Originally Posted by Samsonite2010
I have a 12TB mechanical disk array on my file server - I guess boot time is not an issue as it is on 24/7, but size is not an issue (insert joke here).
When I moved some of my Linux desktops from mechanical to SSD, we are talking 2 mins changing to under 30 seconds. My main desktop went from a minute to 10 seconds power to desktop. I built a living room PC for my sister with an M.2 drive which is power to desktop in under 10 (jealous, wish I did that on mine).
Just giving my anecdotal experience with Linux boot times. And to add that for every single machine that I converted from Windows to Linux, the time was improved massively. We had a Windows 10 machine that took about 10 minutes before it was operational (an expensive laptop) - put Debian on it and it was under a minute on a mechanical drive. Boot times are so variable but at the same time, generally easy to improve.
|
I know, that at the end, if I want better performance it would be with an SSD, and best performance with an M2. Mine is an 8th gen. MB and I saw one unused M2 slot. 120GB M2 would do the trick. Thanks for the heads up.
|
|
|
06-26-2020, 03:10 AM
|
#18
|
LQ Addict
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 23,695
|
Quote:
Originally Posted by ineuw
There is an error reported in the attached file, which I want to track down and verify that it is, or not, the cause of the slow boot. ... But I am searching the web, and seek more expert input, that the error may have been triggered by verifying the health of three disk drive and a DVD drive.
|
That is not the best way to solve it. You need to analyze your own system. We have no access to it and we cannot see the logs and cannot do any test. Waiting for the perfect solution without details is just nonsense.
|
|
|
06-26-2020, 03:22 AM
|
#19
|
LQ Addict
Registered: Dec 2013
Posts: 19,872
|
Quote:
Originally Posted by ineuw
a fast (3.9GHz) desktop
|
How many cores/threads?
Anyhoo, your bootinfo.txt shows that you have a whole bunch of drives with NTFS and vfat partitions, and each drive with its own EFI partition it seems, in there.
A hot mess from my (Linux) point of view, sorry.
Also the 2TB drive in question conatins only Microsoft partitions.
Do you have any difficulties with all your NTFS partitions apart from the boot delay?
|
|
1 members found this post helpful.
|
06-26-2020, 04:32 AM
|
#20
|
LQ Newbie
Registered: Nov 2003
Location: Canada
Distribution: Linux Miny 19.3
Posts: 29
Original Poster
Rep:
|
Quote:
Originally Posted by ondoho
How many cores/threads?
Anyhoo, your bootinfo.txt shows that you have a whole bunch of drives with NTFS and vfat partitions, and each drive with its own EFI partition it seems, in there. A hot mess from my (Linux) point of view, sorry.
Also the 2TB drive in question contains only Microsoft partitions.
Do you have any difficulties with all your NTFS partitions apart from the boot delay?
|
Thanks for your interest and I am responding in reverse order. I was wrong about the Linux drive size. Linux is installed on the 1TB drive, and Windows data is on the 2TB. Nevertheless, the problem came about after installing the 2TB drive.
There are no boot delays or speed problems with Windows 10. It boots fast and with instant access to the NTFS partitions. Keeping in mind that Windows ignores Linux partitions whereas Linux does not ignore Windows partitions.
Here are the CPU specs. Performance nearly matches that of an I3 of the same (8th) generation.
Code:
Topology: Dual Core model: Intel Pentium Gold G5600 bits: 64 type: MT MCP
arch: Kaby Lake rev: B L2 cache: 4096 KiB
flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 31199
Speed: 800 MHz min/max: 800/3900 MHz Core speeds (MHz): 1: 800 2: 800 3: 800 4: 800
You misread the Boot-repair report. There is only one EFI partition on the SSD created by Windows. If you see any others, I don't know anything about them.
1. The SSD is dedicated to Windows 10 and its three masked system partitions.
2. A 2TB drive divided into four partitions, all NTFS.
3. A 1TB drive divided into three EXT4 partitions, for system, data and backup, and a 5GB swap partition.
Since I wrote this post, I don't mount the NTFS paritions, but it still makes no difference.
P.S: After booting there is no lag when accessing anything on the EXT4 and NTFS drives.
Last edited by ineuw; 06-26-2020 at 04:38 AM.
Reason: clarifications
|
|
|
06-26-2020, 09:50 AM
|
#21
|
Senior Member
Registered: Feb 2011
Location: Massachusetts, USA
Distribution: Fedora
Posts: 4,269
|
Old thread, but in case anybody is wondering, the LVM developers are nuts. All of their code: vgs, lvs, lvm will print that scary-sounding error if called by a program with any open file descriptor other than 0, 1, or 2 (like a shell script writing to a log on fd 63). It is not a problem with you or the calling code. It is a paranoia issue with LVM.
fsck will scan the filesystem if the previous shutdown did not save everything and umount the disk. Make sure your power button is set up to run shutdown and wait rather than shut off immediately which will lose data. Also, do not mount an HDD with barrier=0 unless you know what you're doing.
|
|
|
06-26-2020, 03:24 PM
|
#22
|
LQ Newbie
Registered: Nov 2003
Location: Canada
Distribution: Linux Miny 19.3
Posts: 29
Original Poster
Rep:
|
Quote:
Originally Posted by smallpond
Old thread, but in case anybody is wondering, the LVM developers are nuts. All of their code: vgs, lvs, lvm will print that scary-sounding error if called by a program with any open file descriptor other than 0, 1, or 2 (like a shell script writing to a log on fd 63). It is not a problem with you or the calling code. It is a paranoia issue with LVM.
fsck will scan the filesystem if the previous shutdown did not save everything and umount the disk. Make sure your power button is set up to run shutdown and wait rather than shut off immediately which will lose data. Also, do not mount an HDD with barrier=0 unless you know what you're doing.
|
Much thanks for the clarifications and thanks to all for contributing to my understanding. I will check the disk configurations, and buy an M2 for booting Linux.
|
|
|
06-27-2020, 03:39 AM
|
#23
|
LQ Addict
Registered: Dec 2013
Posts: 19,872
|
^ what's M2 and how would buying more hardware solve the problem?
BTW, I'm not convinced that the error from post #1 is relevant at all.
Quote:
Originally Posted by ineuw
Since I wrote this post, I don't mount the NTFS paritions, but it still makes no difference.
|
Well, then, logically, the delay cannot come from mounting the drives, no?
Anyhow, I think we need some hard data on this:
Code:
systemd-analyze blame
In the end I tend to agree that 75s isn't too bad for a 4-threaded consumer CPU and a machine chock full of spinning NTFS hard drives, and you should probably leave well enough alone.
|
|
|
06-27-2020, 09:36 PM
|
#24
|
LQ Newbie
Registered: Nov 2003
Location: Canada
Distribution: Linux Miny 19.3
Posts: 29
Original Poster
Rep:
|
Quote:
Originally Posted by ondoho
What's M2 and how would buying more hardware solve the problem?
BTW, I'm not convinced that the error from post #1 is relevant at all.
Well, then, logically, the delay cannot come from mounting the drives, no?
Anyhow, I think we need some hard data on this: "systemd-analyze blame"
|
ondohono, I noticed the "scratching" of M2. :-)
Also came to believe that these are not issues.
The delay is due to the speed of the drive and because of the 12 partitions:
3 ext4
7 ntfs
1 swap
1 vfat
Originally, I started out with 18 partitions and reduced them to 12.
"systemd-analyze blame sums up to ~84 seconds.
The previous installation there was a dedicated 120GB SSD which booted ~15 seconds.
|
|
|
06-28-2020, 05:01 AM
|
#25
|
LQ Addict
Registered: Dec 2013
Posts: 19,872
|
Quote:
Originally Posted by ineuw
systemd-analyze blame sums up to ~84 seconds.
|
Which is roughly the time you are bemoaning.
Doesn't help us a bit unless you show us the full output.
|
|
|
06-28-2020, 05:50 PM
|
#26
|
LQ Newbie
Registered: Nov 2003
Location: Canada
Distribution: Linux Miny 19.3
Posts: 29
Original Poster
Rep:
|
Quote:
Originally Posted by ondoho
Which is roughly the time you are bemoaning.
Doesn't help us a bit unless you show us the full output.
|
The increase from 15 to 84 seconds boot time qualifies me to bemoan. I enjoyed your choice of the word, but I stop bemoaning. What really surprised me was the speed difference of an electromechanical device versus an SSD and I looked at it as a software defect.
|
|
|
06-28-2020, 11:56 PM
|
#27
|
LQ Addict
Registered: Dec 2013
Posts: 19,872
|
Quote:
Originally Posted by ineuw
The increase from 15 to 84 seconds boot time qualifies me to bemoan. I enjoyed your choice of the word, but I stop bemoaning. What really surprised me was the speed difference of an electromechanical device versus an SSD and I looked at it as a software defect.
|
And you're still not showing us the output of 'systemd-analyze blame'???
Sorry for using fancy words, sometimes I just can't help myself.
|
|
|
06-29-2020, 12:13 AM
|
#28
|
LQ Newbie
Registered: Nov 2003
Location: Canada
Distribution: Linux Miny 19.3
Posts: 29
Original Poster
Rep:
|
A simple misunderstanding. This is the "systemd-analyze blame" as of now. Not the one mentioned above. I am curious what you make of it.
Please keep on using "big" words, I enjoy reading posts with good English.
Code:
33.869s fstrim.service
24.344s apt-daily.service
7.058s NetworkManager-wait-online.service
5.464s networkd-dispatcher.service
4.121s ubuntu-system-adjustments.service
3.901s dev-sdb1.device
3.764s ufw.service
3.401s NetworkManager.service
3.211s networking.service
2.804s ModemManager.service
2.722s rsyslog.service
2.545s udisks2.service
2.272s systemd-random-seed.service
1.977s accounts-daemon.service
1.653s lvm2-monitor.service
1.539s systemd-journal-flush.service
1.531s wpa_supplicant.service
1.154s keyboard-setup.service
959ms polkit.service
936ms systemd-tmpfiles-setup-dev.service
930ms gpu-manager.service
928ms media-wikimedia.mount
869ms media-tools.mount
867ms apparmor.service
845ms grub-common.service
829ms systemd-fsck@dev-disk-by\x2duuid-14D5\x2d3796.service
730ms avahi-daemon.service
716ms systemd-modules-load.service
673ms systemd-udevd.service
656ms systemd-logind.service
654ms thermald.service
611ms dns-clean.service
610ms plymouth-read-write.service
610ms systemd-tmpfiles-setup.service
485ms systemd-sysctl.service
441ms media-adam.mount
393ms lm-sensors.service
391ms lightdm.service
390ms plymouth-quit-wait.service
388ms plymouth-start.service
382ms speech-dispatcher.service
307ms media-tali.mount
293ms alsa-restore.service
241ms colord.service
189ms systemd-remount-fs.service
184ms upower.service
182ms systemd-timesyncd.service
177ms systemd-resolved.service
153ms packagekit.service
128ms setvtrgb.service
125ms systemd-journald.service
114ms media-timeshift.mount
103ms pppd-dns.service
101ms dev-sdb2.swap
92ms systemd-udev-trigger.service
92ms media-linux\x2ddata.mount
78ms kmod-static-nodes.service
62ms blk-availability.service
61ms dev-mqueue.mount
61ms systemd-user-sessions.service
60ms dev-hugepages.mount
59ms sys-kernel-debug.mount
48ms user@1000.service
45ms systemd-update-utmp.service
33ms boot-efi.mount
32ms hddtemp.service
27ms kerneloops.service
14ms ureadahead-stop.service
14ms motd-news.service
7ms systemd-tmpfiles-clean.service
6ms systemd-update-utmp-runlevel.service
3ms console-setup.service
3ms finalrd.service
3ms rtkit-daemon.service
2ms sys-kernel-config.mount
1ms sys-fs-fuse-connections.mount
999us openvpn.service
|
|
|
06-29-2020, 12:28 AM
|
#29
|
LQ Addict
Registered: Dec 2013
Posts: 19,872
|
Quote:
Originally Posted by ineuw
A simple misunderstanding. This is the "systemd-analyze blame" as of now. Not the one mentioned above. I am curious what you make of it.
Code:
33.869s fstrim.service
24.344s apt-daily.service
7.058s NetworkManager-wait-online.service
|
Rather self-explanatory.
I don't know what fstrim does, but you probably need to tell it to leave NTFS partitions alone.
apt-daily has nothing to do with your hard drives, apt is your packet manager.
Waiting for a (wireless) network to become ready can take quite some time and is not necessarily required during boot.
|
|
1 members found this post helpful.
|
06-29-2020, 12:34 AM
|
#30
|
LQ Newbie
Registered: Nov 2003
Location: Canada
Distribution: Linux Miny 19.3
Posts: 29
Original Poster
Rep:
|
Thanks for pointing out the wireless. Just posted the results without looking at them.will disable it tomorrow and check again.
|
|
|
All times are GMT -5. The time now is 08:01 PM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|