Cloned PC takes longer to boot

[Bristow 0]

I have a new problem

• I cloned a workstation to an identical one, and it takes 20s longer to start (fstab checked)…
• Also, I switched from 16.04 to 20.04 and had to double the boot time on this 4GB computer with an i3.

Could this be a known problem with Linux partition cloning?

I’d like to point out that I made my initial image on a computer newer than these two…

Thanks !

[george1421]

@bristow-0 Can you get a screen shot of the error so we can see the context of the error.

Is the ubuntu reference taking longer to boot on a target computer or the FOG server. I’m unclear how FOG fits into what you have posted so far.

[Bristow 0]

Thank you @george1421

I don’t have an error, it just takes longer to boot on a cloned PC.

I recapitulate my procedure:

• I took a snapshot of a Lenovo workstation classroom with 8G of Ram and i5.
• I deployed this image on an HP workstation with 4G of ram and an i3
• I captured this image again on Fog
• I deployed this image on a strictly identical PC near (HP with 4G ram and an i3)

The latter PC takes 20s longer to boot… and overall, all HP PCs are very slow to boot compared to my old linux distribution which was based on Ubuntu 16.04.

Thanks

[george1421]

@bristow-0 said in Cloned PC takes longer to boot:

I deployed this image on a strictly identical PC near (HP with 4G ram and an i3)

OK looking at the truth table on this, one thing we don’t know is that if the i3 is just slower all around or if its ubuntu 20.04 that is the cause.

If you take an i3 and load ubuntu 20.04 on it straight from the iso image, how does booting time compare with the fog cloned image? Is fog doing something to the disk structure to cause slow booting or it it just the fact that 20.04 is slowing the process down? I don’t know but that looks like the test I would do trying to sort out what changed.

[Bristow 0]

@george1421 on Mastodon, I was suggested this blog post :
https://tipstricks.itmatrix.eu/solving-the-running-scripts-local-block-loop-while-booting-in-linux/

and as a result, I saved 30 s of direct boot time, it worked perfectly.

Maybe the linux fog client does this job? As it didn’t rename the machines for me (I don’t know why), this could be the cause of the problem?

Thanks.

[george1421]

@bristow-0 I can tell you the fog client doesn’t do this because for linux the fog client is primitive.

You might be able to do this using a FOG Postinstall script. Understand that the post install script runs as root in FOS Linux. So you will need to mount the target disk partition if you want o interact with the target disk files.

Or just make a script that runs just the first time when the computer boots up that finds the uuid of swap volume and then updates the resume file and finally rebuilds the init ram fs.

[Bristow 0]

@george1421 Thank you for the answer.

I don’t have enough experience with FOG scripts, so I do it manually.

I’m still glad I found it and maybe it will be useful for someone later!

I’ll put the procedure here in case the article disappears:

Problem:
Linux booting and taking a long time while looping with the script:
/scripts/local-block

Reason:
Linux boot needs to know the UUID of the Swap file it tries to mount.

Solution:
Run the command:

blkid

and get the UUID of the Swap file.
Run the command:

nano /etc/initramfs-tools/conf.d/resume

This file doesn’t exist. It will then be created.
Add the following line as follows(example of UUID):

RESUME=UUID=4b7ead25-e0d9-4064-bfa3-167ac46ada3f

Save the file
Run the following command:

update-initramfs -u

Reboot.

[george1421]

@bristow-0 So when you run the blkid command on one of these computers, what does the output look like?

[Bristow 0]

@george1421

Like this :

/dev/sda6: UUID="73c90b5f-8486-4ba7-b9d2-a318c57d89a5" TYPE="swap" PARTUUID="8f07c4f0-06"
/dev/sda5: UUID="3b3c3f72-f223-4d79-b6d9-c109a8dce12e" TYPE="ext4" PARTUUID="8f07c4f0-05"
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/sda1: LABEL="Win7" UUID="386EED41073FF16B" TYPE="ntfs" PARTUUID="8f07c4f0-01"
/dev/sda2: UUID="e19aa8e5-902d-49a8-9794-1933dee19faa" TYPE="ext4" PARTUUID="8f07c4f0-02"
/dev/sda3: UUID="0DDFEA530EBC86EF" TYPE="ntfs" PARTUUID="8f07c4f0-03"

[george1421]

@bristow-0 Very good. What is the output of this command
cat /etc/initramfs-tools/conf.d/resume

[Bristow 0]

@george1421

$ cat /etc/initramfs-tools/conf.d/resume 
RESUME=UUID=73c90b5f-8486-4ba7-b9d2-a318c57d89a5

but I created this file. It did not exist when the cloning was completed.

[george1421]

@bristow-0 Ok so what I’m working on is this rough outline of a script.

If you run this command on your target computer it should return the uuid of the swap partition.
blkid | grep swap | awk '{print $2}'

So if we start building a script to automate the process it might start to look like this

!#/bin/bash

uuid=$(blkid | grep swap | awk '{print $2}')

if grep -Fxq "RESUME=UUID" /etc/initramfs-tools/conf.d/resume
then
    # if found replace with new uuid
    sed -i 's/^RESUME=UUID.*$/RESUME=${uuid}/' /etc/initramfs-tools/conf.d/resume
else
    # if not found just append command to config file
echo "RESUME=${uuid}" >>/etc/initramfs-tools/conf.d/resume

update-initramfs -u

This script would need to be executed on first boot of the target computer is what I’m thinking.