Manjaro boot slows down when resizing root partition

Support
1

Doing a fresh install on an SSD with MBR table, using the “Erase disk” option and “ext4”, Manjaro boots in only 11 seconds. It makes no difference whether swap is used or not, and whether it is a partition or a file.

Then I reboot the computer from Live and change the size of / to a smaller value with the help of “gParted” freeing up space behind it. Now the boot time of my installation is 23 seconds. The extra 12 seconds elapses from the disappearance of GRUB until the text is displayed:

/dev/sdc1: clean, XXXXXX/XXXXXXX files, XXXXXXX/XXXXXXXX blocks

Returning the partition to its initial size does not solve the problem. “fsck -p” says it is clean.

The same happens when copying or moving that partition before resizing it.

Translated with DeepL Translate: The world's most accurate translator (free version)

2

Unusual phenomena, I have resized my root partition many times. I would try to restore the boot loader and double-check if the UUID settings in your /etc/fstab are still OK.

3

Checked UUIDs in fstab and reinstalled GRUB, but nothing changes.

This is the journal output for that disk:


[wibol@wibol-ep43tusb3 ~]$ journalctl -b | grep sdc
ene 16 14:33:21 wibol-ep43tusb3 kernel: sd 2:0:0:0: [sdc] 234441648 512-byte logical blocks: (120 GB/112 GiB)
ene 16 14:33:21 wibol-ep43tusb3 kernel: sd 2:0:0:0: [sdc] Write Protect is off
ene 16 14:33:21 wibol-ep43tusb3 kernel: sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00
ene 16 14:33:21 wibol-ep43tusb3 kernel: sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
ene 16 14:33:21 wibol-ep43tusb3 kernel:  sdc: sdc1 sdc2
ene 16 14:33:21 wibol-ep43tusb3 kernel: sd 2:0:0:0: [sdc] Attached SCSI disk
ene 16 14:33:22 wibol-ep43tusb3 kernel: EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
ene 16 14:33:22 wibol-ep43tusb3 kernel: EXT4-fs (sdc1): re-mounted. Opts: (null). Quota mode: none.
ene 16 14:33:22 wibol-ep43tusb3 kernel: Adding 18023772k swap on /dev/sdc2.  Priority:-2 extents:1 across:18023772k SSFS

I have tried changing in fstab “fsck pass” from 1 to 0 and removed “quiet” from GRUB with no results.

4

Reinstalling does not help you need to restore grub.

In addition, please post output of

sudo systemd-analyze critical-chain
5

Sorry. I used these commands after to do manjaro-chroot:

# grub-install --force --target=i386-pc --recheck --boot-directory=/boot /dev/sdc
# grub-mkconfig -o /boot/grub/grub.cfg

This is the output for systemd-analyze:

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 @2.922s
└─multi-user.target @2.922s
  └─ModemManager.service @2.619s +302ms
    └─polkit.service @2.250s +359ms
      └─basic.target @2.216s
        └─sockets.target @2.212s
          └─snapd.socket @2.205s +3ms
            └─sysinit.target @2.143s
              └─ufw.service @2.120s +18ms
                └─systemd-sysctl.service @2.106s +6ms
                  └─systemd-modules-load.service @532ms +1.567s
                    └─systemd-journald.socket @476ms
                      └─system.slice @449ms
                        └─-.slice @449ms

Would it help if I reinstall Manjaro and compare these values before and after resizing? From what I have seen, the delay occurs even before the mkinitpcio.conf HOOKS are processed.

6

I tried leaving an extra MiB at the beginning of the disk (2 in total in front of the / partition) but it did not reduce the boot time.

I’m going to reinstall Manjaro and do the whole process from the beginning.

7

I reinstalled Manjaro by erasing the disk, using ext4 and no swap and rebooted from the SSD. The elapsed time from GRUB to printing the first line (/dev/sdc1: clean, XXXXXXXX/XXXXXXXXXXX files, XXXXXXXXX/XXXXXXXXXXXX blocks) was 6 seconds and 11 seconds to the login screen. I removed “quiet” from GRUB and installed the updates.

The second boot time is 5 seconds to the first line (running early hook (udev)) and 11 to the login. Then I reduced the size of / to 50 GB using gnome-disks this time.

The third boot time is 18 seconds to the first line (running early hook (udev)) and 25 to login.

I am completely lost. Does Manjaro keep any record of the original size of the root partition? What processes take place before the first line appears?

Thanks.

8

I guess the longer boot time has nothing to do with your size change of /.

9

I don’t think it has to do with the size, but with the change itself. It is possible that the resizing programs are using some option that affects my hardware or operating system, which forces it to auto-detect, recalculate or check for something. The partitions are aligned.

10

After 1000 tests the solution was to use GPT partition table instead of MBR, which is the default Calamares partition table for a BIOS PC like mine.

For this I had to use manual partitioning, create a new GPT table, create an 8 MB partition with flag “bios_grub”. Then Calamares flagged / as “boot, esp”.

Now I can resize the Manjaro partition as many times as I want without increasing the OS boot time beyond the initial 11 seconds. I guess the resize tool was making some mistake or inaccuracy when writing to the MBR.

Thanks.

11
12