0

I have slow boot. From systemd-analyze blame, i can see that dev.sda1(which holds root file system) is taking a lot of time(around 9 seconds) Now,I have 4 ext4 partitions in my system.

From dmesg :

1. EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)--> Here root file system is mounted in read only mode for fsck
2. EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro --> Here root file system is remounted in read-write mode
3. EXT4-fs (sda7): mounted filesystem with ordered data mode. Opts: (null) --> Here sda7 is mounted on /home
4. EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null) --> Here sd5 is mounted on /mnt/data

My /etc/fstab look like this:

#                
# / was on /dev/sda1 during installation
UUID=e27bebbb-f8e8-4bd7-9849-2421323efc3a /               ext4    errors=remount-ro 0       1
# /home was on /dev/sda7 during installation
UUID=0622bb8c-dd7d-4035-8c92-b0f729a60035 /home           ext4    defaults        0       2
# swap was on /dev/sda6 during installation
UUID=dc788cde-d82a-4bdc-a5b1-8def34546012 none            swap    sw              0       0
# /dev/sda5 was mounted on /mnt/data post installation
UUID=144ba46c-e53d-4e0f-9da2-5a3d31bb617a /mnt/data           ext4    defaults        0       2

My question is why remounting root file system in read write mode takes so much time(around 9 sec).

1 Answer 1

0

A remount can take a long time due to existing processes having an open file they were writing to before you remounted as read only. It is best to close those processes before you remount as read only or create a ramdisk or some other location that they can map to, to allow them to work even over remounts.

Another possibility is your UUID changed. Verify you have the right UUID in your fstab. You can see what your UUIDs are by executing this command: sudo blkid

Hope this helps.

5
  • As per my understanding, at boot time, first time the root file system is mounted in read-only mode so that it can be fscked. Later when it is remounted, then it is mounted in read-write mode. As first time root file system was mounted in read only mode negates chances of some existing process trying to write to an open file in root file system which negates the chances of remounting being delayed due to some open file.
    – RaviK
    Nov 20, 2018 at 5:35
  • Also i checked UUID in fstab. It is same as the UUID configured for root file system in /boot/grub/grub.cfg.
    – RaviK
    Nov 20, 2018 at 16:47
  • Code it be since it is in Read Only initially a process starts up, say networking and tries to bind, but since the FileSystem is RO it fails with a timeout. I would check what is taking time at boot to see. Try systemd-analyze blame for example to see. Nov 21, 2018 at 17:23
  • systemd-analayze blame output: 10.484s systemd-journal-flush.service 9.669s dev-sda1.device 8.385s keyboard-setup.service 6.817s systemd-tmpfiles-setup-dev.service 6.510s systemd-sysctl.service 2.943s systemd-fsck@dev-disk-by\x2duuid-0622bb8c\x2ddd7d\x2d4035\x2d8c92\x2db0f729a60035.service 2.785s thermald.service 2.601s NetworkManager.service 2.410s ModemManager.service 2.253s udisks2.service 2.157s accounts-daemon.service 1.938s systemd-random-seed.service
    – RaviK
    Nov 22, 2018 at 6:08
  • Cool! So it looks like you may have a lot of logs and this is slowing things down. You can age out the old logs and get faster boot time with systemd-journal-flush.service. You could remove all but the last 5 days of logs with this command once you're booted up: sudo journalctl --vacuum-time=5d . For a detailed explanation check here: remove old logs Nov 25, 2018 at 21:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .