Speed up Boot

Linux Support
1

Hi All
I’m currently running Mint 18.2 Sonya Mate on a separate 40GB hdd and I’m trying to speed up the boot process.

At first it booted to the desktop at around 2m 30secs but after removing some startup items (and enabling auto login etc), I’ve got it down to 1m 25secs. Using the systemd-analyze critical-chain utility, I see that it takes 25secs to begin booting from the hdd (dev sdb5-device). Is there a way to get this time decreased safely?

Further info below -

The time after the unit is active or started is printed after the “@” character.
The time the unit takes to start is printed after the “+” character.

graphical.target @36.210s
??multi-user.target @36.210s
??getty.target @36.205s
[email protected] @36.204s
??rc-local.service @35.659s +19ms
??network-online.target @35.623s
??network.target @35.620s
??NetworkManager.service @32.168s +3.450s
??dbus.service @31.788s
??basic.target @31.771s
??paths.target @31.771s
??cups.path @31.771s
??sysinit.target @31.729s
??systemd-update-utmp.service @31.397s +329ms
??systemd-tmpfiles-setup.service @31.295s +47ms
??local-fs.target @31.291s
??run-cgmanager-fs.mount @32.185s
??local-fs-pre.target @9.147s
??systemd-remount-fs.service @9.086s +58ms
??system.slice @4.141s

$ systemd-analyze blame
24.325s dev-sdb5.device
6.771s ufw.service
3.929s preload.service
3.450s NetworkManager.service
2.797s keyboard-setup.service
2.604s thermald.service
2.367s systemd-tmpfiles-setup-dev.service
2.083s iio-sensor-proxy.service
1.749s systemd-udevd.service
1.610s dev-hugepages.mount
1.583s systemd-journald.service
1.575s systemd-modules-load.service
1.530s dev-mqueue.mount
1.529s sys-kernel-debug.mount
1.507s upower.service
1.389s udisks2.service
1.229s networking.service
1.226s grub-common.service
1.222s systemd-fsck@dev-disk-by\x2duuid-e5fdbb08\x2d9250\x2d489a\x2d9e
1.117s loadcpufreq.service
1.005s irqbalance.service
904ms rsyslog.service
888ms console-setup.service

Plot.svg shows the kernel loads in @ 7secs and systemd in @ a further 5secs so the delay seems to be in finding the boot files.

Any tips/info would be great!

TIA Rich

2

Hi - I’m still struggling with improving the boot times of Mint 18.2. Blame gives this (just the main culprits)

22.102s dev-sdb5.device
19.344s ufw.service
18.402s systemd-tmpfiles-setup-dev.service
16.550s systemd-sysctl.service
12.252s apt-daily-upgrade.service
6.818s udisks2.service
6.645s preload.service
4.235s NetworkManager.service
2.862s iio-sensor-proxy.service
2.752s keyboard-setup.service
2.453s systemd-modules-load.service
2.318s thermald.service
2.154s upower.service
2.012s grub-common.service
1.788s loadcpufreq.service
1.760s systemd-journald.service
1.668s colord.service
1.484s systemd-fsck@dev-disk-by\x2duuid-e5fdbb08\x2d9250\x2d489a\x2d9e9a\x2dd83de51b2f45.service
1.466s networking.service
1.241s irqbalance.service
1.187s sys-kernel-debug.mount
1.185s dev-mqueue.mount
1.070s binfmt-support.service
1.070s dev-hugepages.mount
1.063s console-setup.service
1.019s polkitd.service

Further investigations have indicated possible errors in fstab and I wonder if these can be corrected?

/etc/fstab: static file system information.

Use ‘blkid’ to print the universally unique identifier for a

device; this may be used with UUID= as a more robust way to name devices

that works even if disks are added and removed. See fstab(5).

/ was on /dev/sda5 during installation

UUID=b5f3259f-385a-4768-b6de-a27a60a03468 / ext4 errors=remount-ro 0 1

/boot was on /dev/sda1 during installation

#UUID=e5fdbb08-9250-489a-9e9a-d83de51b2f45 /boot ext4 defaults 0 2

swap was on /dev/sda6 during installation

UUID=7878d4b2-294f-4d21-974c-7929419f617a none swap sw 0 0

Move /tmp to RAM

tmpfs /tmp tmpfs defaults,noexec,nosuid 0 0
UUID=e5fdbb08-9250-489a-9e9a-d83de51b2f45 /boot ext4 defaults 0 2

Whereas lsblk -f shows -

NAME FSTYPE LABEL UUID MOUNTPOINT
sdb
??sdb5 ext4 b5f3259f-385a-4768-b6de-a27a60a03468 /
??sdb1 ext4 e5fdbb08-9250-489a-9e9a-d83de51b2f45 /boot
??sdb6 swap 7878d4b2-294f-4d21-974c-7929419f617a [SWAP]
sr0
sda
??sda2
??sda5 ext4 fd7a3f3e-5d95-48cb-ab1b-0a7415cfd185
??sda1 ext4 bd41cb59-1633-4957-8b92-e85530ad0662
??sda6 swap eed0839a-eded-443d-91b6-f1c239008fe0

And blkid shows -

/dev/sda1: UUID=“bd41cb59-1633-4957-8b92-e85530ad0662” TYPE=“ext4” PARTUUID=“0001ba51-01”
/dev/sda5: UUID=“fd7a3f3e-5d95-48cb-ab1b-0a7415cfd185” TYPE=“ext4” PARTUUID=“0001ba51-05”
/dev/sda6: UUID=“eed0839a-eded-443d-91b6-f1c239008fe0” TYPE=“swap” PARTUUID=“0001ba51-06”
/dev/sdb1: UUID=“e5fdbb08-9250-489a-9e9a-d83de51b2f45” TYPE=“ext4” PARTUUID=“7ad54111-01”
/dev/sdb5: UUID=“b5f3259f-385a-4768-b6de-a27a60a03468” TYPE=“ext4” PTTYPE=“dos” PARTUUID=“7ad54111-05”
/dev/sdb6: UUID=“7878d4b2-294f-4d21-974c-7929419f617a” TYPE=“swap” PARTUUID=“7ad54111-06”

The UUID’s shown in fstab are listed on the wrong drive as M18 is installed on sdb, not sda.

I reckon this has happened due to the way I installed M18. Because of previous Grub issues with installing distro’s on separate HDD’s, on Mark’s advice, I disconnected sda (M17) before installing M18 on sdb. I now realise that, as the only HDD ‘seen’ by the system, this drive now automatically becomes ‘sda’ and the fstab file would be generated to reflect that.

On booting to M18, the system must first be looking for the boot files for M18 on sda and they aren’t there - hence the long delay. Is there a way to re-generate the fstab file to show the correct locations, now that both HDD’s are connected? Btw, both distro’s run fine, it’s just that M18 takes an age to boot - more than twice as long as M17.

Thanks for your time.

Rich

3

The sdXX designations in your fstab are there for historical reasons. Drives are mounted using the UUID’s which do not change (unless you replace the drives).
You need to look elsewhere for the holdup.

22.102s dev-sdb5.device
That line indicates a way too long waite for that partition. Have you run fsck on it?

You could try running (boot to Mint 17 or live CD):

sudo e2fsck -C0 -p -f -v /dev/sdb5

See if that throws anything up.

Also while at it test HDD speed to:

sudo hdparm -tT /dev/sdb

and compare to sda

sudo hdparm -tT /dev/sda

You might have a very slow HDD to blame.

4

Hi SeZo - thanks for the reply.

sudo e2fsck -C0 -p -f -v /dev/sdb5 returns -

461757 inodes used (21.27%, out of 2170880)
594 non-contiguous files (0.1%)
435 non-contiguous directories (0.1%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 404389/83
3344862 blocks used (38.57%, out of 8671744)
0 bad blocks
1 large file

  342488 regular files
   59172 directories
      56 character device files
      25 block device files
       0 fifos
      29 links
   60006 symbolic links (57195 fast symbolic links)
       1 socket

  461777 files

sudo hdparm -tT /dev/sdb returns -

/dev/sdb:
Timing cached reads: 1704 MB in 2.00 seconds = 851.98 MB/sec
Timing buffered disk reads: 110 MB in 3.00 seconds = 36.64 MB/sec

sudo hdparm -tT /dev/sda returns -

/dev/sda:
Timing cached reads: 1628 MB in 2.00 seconds = 813.43 MB/sec
Timing buffered disk reads: 184 MB in 3.02 seconds = 60.83 MB/sec

I can’t see any particular issues there but I’m not experienced in analysing this kind of data! Any ideas your end?

5

Can you post the output from:

sudo fdisk -l
6

Hi Mark - as requested

~ $ sudo fdisk -l
[sudo] password for richard:
Disk /dev/sda: 149.1 GiB, 160041885696 bytes, 312581808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0001ba51

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 980991 978944 478M 83 Linux
/dev/sda2 983038 312580095 311597058 148.6G 5 Extended
/dev/sda5 983040 152638097 151655058 72.3G 83 Linux
/dev/sda6 304693248 312580095 7886848 3.8G 82 Linux swap / Solaris

Disk /dev/sdb: 37.3 GiB, 40020664320 bytes, 78165360 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x7ad54111

Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 976895 974848 476M 83 Linux
/dev/sdb2 978942 78163967 77185026 36.8G 5 Extended
/dev/sdb5 * 978944 70352895 69373952 33.1G 83 Linux
/dev/sdb6 70354944 78163967 7809024 3.7G 82 Linux swap / Solaris

7

In Mint 18 can you run:

dmesg > ~/Desktop/dmesg.txt

you’ll then find a file on your desktop called “dmesg.txt” … can you host that file online somewhere and provide a link to it.

[EDIT]

Here’s a free file hosting service
http://www.tinyupload.com/

8

As requested -

http://s000.tinyupload.com/?file_id=94794851481583555645

9

Hmm, I’m a bit baffled by some of the contents of that :-\

It seems sdb5 (/) gets mounted about 5 seconds into the boot

[    5.286754] EXT4-fs (sdb5): mounted filesystem with ordered data mode. Opts: (null)

It then gets remounted at around 30 seconds into the boot

[   30.793631] EXT4-fs (sdb5): re-mounted. Opts: errors=remount-ro

this remount is normal, but it seems very slow (on my system there’s only 1 second between them).

the sdb1 (/boot) gets mounted at 35 seconds into the boot

[   35.757600] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)

then the ata ports that were originally configured 1.5 seconds into the boot

[    1.497499] ata1.00: configured for UDMA/100
[    1.503086] ata1.01: configured for UDMA/100

get configured again at 77 seconds in

[   77.760095] ata1.00: configured for UDMA/100
[   77.785320] ata1.01: configured for UDMA/100
[   77.785327] ata1: EH complete

so as I don’t seem to be able to find out what “EH complete” means, I’m going to have to assume you have a hard drive that’s just very slow to initialise.

Are the hard drives both PATA/IDE drives ?

if so, how are they configured ? … separate ribbon cables, or both on the same ribbon cable with the CD/DVD on a separate ribbon ?

10

SCSI Disks - both ATA - same ribbon - sda on end connector - sdb on centre connector - DVD ATAPI on separate (SATA?) cable via adaptor

From memory, I ended up with this config as there were problems with the disks being ‘seen’ when connected differently (master/slave etc). I needed an adaptor for the DVD as there is only 1 IDE connector on this motherboard. All 3 devices are IDE connected.

I could try changing the connections around if you think this would help?

‘EH’ - error handler, possibly?

Hope this helps

Rich

11

I don’t know if it’ll help, but I guess it can’t hurt to try.

As you installed Mint 18 whilst it was the only drive in the PC it should have it’s own GRUB stage 1 in its master boot record … how quickly does the PC boot if you disconnect the Mint 17 drive and the DVD and set the jumper on the Mint18 drive to master.
(so it’s the only drive attached)

Is it still slow ?

12

Ok, I’ll give that a try but it might be a day or 3 before I get back to you.

Regarding the set-up as per the fdisk -l data -

Before installation of M18, I set up sdb partitions exactly the same as sda was with M17, following your instructions. (I’d had issues with the boot files not being found - possibly due to the motherboard specs or file sizes?) Anyway, I let the installer do its job and all seemed to go exactly the same as with M17. But - the boot files are in a different place in M18? sdb5 in M18 yet sda1 in M17… Could that be a factor? And does it matter? I would expect the installer to put the boot files on the 1st partition also.

13

NO, as SeZo suggested the lines such as

# / was on /dev/sda5 during installation

in fstab are not acted upon, they’re only there for informational purposes.

The bit that’s acted upon is the UUID, and this won’t change when you move the drive to another port.

As for where the “boot files” go…

There are a few stages to a bootloader (in this case GRUB)

Stage 1 (on a non UEFI system such as yours) goes on the drives Master Boot Record (MBR), not in any particular partition … this then just points at where to find stage 2 which can be anywhere.
(the ONLY part of the boot sequence that has to be in a particular location on a non EFI system the first part of the bootloader MUST be on the master boot record (this is the only place a BIOS knows to look for it) the rest of the bootloader can be in ANY partition.

Clear as mud ? …

Okay sure by default WINDOWS would put the second stage of its bootloader on the first partition, but then it’s Windows so doesn’t expect (or want) any other OS on there. GRUB is smarter and will adjust to suit the setup or go where you tell it to.

Effectively, the first detected disk (currently sda) will have it’s master boot record read by the BIOS, that will point it to stage 2 which is the Mint 17 GRUB configuration files that will hold entries for how to boot both Mint 17 and Mint18 (and these are determined by the partitions UUID’s)

If you remove sda, then the first master boot record found would then be the one on the drive currently sdb … because of the way you installed (with the other drive removed) this will point at the UUID of the Mint18 root partition so should still boot.

Hope that made sense, but even if it didn’t just ignore the references to “sda” and “sdb” in your fstab, they’re for information only and are even commented out … only lines that DO NOT start with an “#” are acted upon :wink:
Any line that starts with an # is a “comment” so is ignored by the shell.

14

Hi Mark and thanks for the explanation - very clear.

Things are now getting a bit weird…

To test sdb boot speed I did this -

Disconnected all cables
Changed sdb jumper from ‘slave’ to ‘master’
Reconnected cables to sdb
Restarted and system hung at the options screen - press Del, Esc, Tab etc. Pressing any key did nothing.
Swapped connectors on data ribbon (tried both centre and end). No different, same as above.
Connected cables to DVD and got a little further. Past the options screen but now hanging on ‘no device found’
Changed sdb jumper back to ‘slave’
Reconnected sda cables and booted.
Back to Grub screen listing both distro’s as before (and they both boot successfully) but, and this is the weird bit, the Grub list has now reversed it’s order… ???

After I’d originally got M18 on to sdb, I wasn’t sure which distro was the right one to use to update Grub, so I used M18 (as the last one installed) and everything went ok. Grub listed M18 first, then M17 - which is what I’d expected. Now, after trying out the above, M17 is listed first, then M18 but at no time have I updated Grub! Very odd!

I wonder if the problem with running sdb independently of sda may be due to the way I set things up and I possibly missed a step? Basically, I just popped the drive in, set the jumper and cables and the used GParted to partition the drive before installing M18. Or perhaps is just a peculiarity of this motherboard?

Anyway, nothing lost - both distro’s boot ok (he says, fingers crossed!) but M18 is still a bit on the slow side in firing up. Once up though, it runs fine. The reason for all this rigmarole is I wanted to fully test M18 64bit independently of M17 without the danger of screwing up. It seems fine so far so I’ll do a clean install of M18 on the larger Hdd and use the smaller one for data storage - but that’s for another time!

Thanks again for your help.

Rich

15

You’re probably now using grub from the M17 drive … in other words, the first boot device has changed in the BIOS.

16

Yes, you’re correct! I checked in the BIOS and indeed, M17 on sda is now 1st drive listed but how it did so is still a mystery as it wouldn’t boot into anything beyond the options screen until I re-connected all the bits… Computers, eh? ;D

Not to worry, all ok for the moment!!

Rich