Troubleshooting a delay in booting Porteus due to unmounting changes

[mattl]

I have encountered an intermittent delay during boot, adding up to 40 seconds to the usual boot time, which occurs when booting with changes in a saved.dat container in read only mode. Using a custom linuxrc file, I was able to trace the problem to the following line

Code: Select all

umount /memory/changes;

within the following section of linuxrc:

Code: Select all

		echo $i"filesystem is posix compatible"; CHNDEV=/mnt/$DEV
		rmdir /memory/changes/mnt/* 2>/dev/null
		rm -rf /memory/changes/var/lock/* /var/run/laptop-mode-tools/* /var/spool/cron/cron.??????
		for x in `find /memory/changes/var/run -name "*pid" 2>/dev/null`; do rm $x; done
		if [ $CHNEXIT = EXIT -o "`egrep -o " changes-ro( |\$)" /proc/cmdline`" ]; then
		    CHNEXIT=$CHNDEV/$LPTH; echo $CHNEXIT >/tmp/changes-exit
		    param changes-ro && echo $i"[1;36m""changes will not be saved for this session""[0m" || echo $i"[1;36m""changes will be saved only during reboot/shutdown""[0m"
		    for x in `find /memory/changes -name ".wh.*" | grep -v '.wh..wh..opq' | tr ' ' '@' `; do x=`echo $x | tr '@' ' ' `; cp -a --parents "$x" /var; done
		    umount /memory/changes; mount -nt tmpfs -o size=$RAMSIZE tmpfs /memory/changes
		    # need to fix busybox bug on 'cp -a' as it does not preserve perms on dirs:
		    mv /var/memory/changes/* /memory/changes 2>/dev/null; CHANGES=memory
		    chown -R guest /memory/changes/home/guest 2>/dev/null
		fi

I boot from a USB drive and the problem seems to occur only on some computers and even on those computers, it is intermittent.

Does anyone have any idea why it would take a long time to unmount the /memory/changes during the boot script?

[Ed_P]

Just a guess but see if adding the cheatcode reboot=cold helps.

[mattl]

This delay occurred after the following lines were displayed:

filesystem is posix compatible
changes will not be saved for this session


The reboot=cold cheatcode seems to help, reducing the delay to 0-2 seconds. It is an intermittent problem but I will post if it occurs again.

[mattl]

Thanks Ed_P!

[mattl]

The problem still occurs. It is intermittent.

I modified the linuxrc to include an echo statement to dmesg before and after the umount. Here is the output from dmesg during a boot that had delay of 27.5 sec:

Code: Select all

[    2.133888] sd 4:0:0:0: [sdb] 61440000 512-byte logical blocks: (31.5 GB/29.3 GiB)
[    2.134524] sd 4:0:0:0: [sdb] Write Protect is off
[    2.134533] sd 4:0:0:0: [sdb] Mode Sense: 23 00 00 00
[    2.135152] sd 4:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn\'t support DPO or FUA
[    2.138884]  sdb: sdb1 sdb2
[    2.141202] sd 4:0:0:0: [sdb] Attached SCSI removable disk
[    2.334087] urandom_read: 1 callbacks suppressed
[    2.334094] random: blkid: uninitialized urandom read (6 bytes read)
[    2.476686] random: blkid: uninitialized urandom read (6 bytes read)
[    2.483405] FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[    2.502410] loop0: detected capacity change from 0 to 150984
[    2.935144] random: blkid: uninitialized urandom read (6 bytes read)
[    2.936654] loop1: detected capacity change from 0 to 1048576
[    2.945405] exFAT-fs (loop1): invalid boot record signature
[    2.945407] exFAT-fs (loop1): failed to read boot sector
[    2.945408] exFAT-fs (loop1): failed to recognize exfat type
[    2.947983] XFS (loop1): Mounting V5 Filesystem
[    2.988752] XFS (loop1): Ending clean mount
[    2.992626] xfs filesystem being mounted at /memory/changes supports timestamps until 2038 (0x7fffffff)
[    3.334436] Start umount /memory/changes; <----------------------------------------------------------------- delay start
[    6.344311] random: crng init done
[    7.223680] XFS (loop1): Unmounting Filesystem
[   30.871133] Done.  <----------------------------------------------------------------- delay over
[   30.915361] loop0: detected capacity change from 0 to 150984
[   30.933197] loop1: detected capacity change from 0 to 259528
[   31.020654] loop2: detected capacity change from 0 to 213632

Could it perhaps have something to do with Windows hibernation? If I boot Porteus after running Windows, it tends to occur. If I boot Porteus immediately after shutting down Porteus, the delay does not occur. But why would that affect an unmount operation?

[Ed_P]

Could it perhaps have something to do with Windows hibernation?

Definitely! Especially on plugin computers. If I plug my notebook in before closing it then unplug it before reopening it I end up with the notebook rebooting rather than restarting Windows. If also experienced cases where my save.dat file is classified as non-writable yet Windows has no problem writing to the harddrive the save.dat is on. To solve that problem I run a chkdsk command in Windows on the drive then reboot Porteus and the save.dat file is writable.

Added in 2 minutes 33 seconds:
Dell Inspiron 14 notebook and Windows 11. save.dat on a ntfs drive, not the c: drive. Harddrive is an SSD drive.

[mattl]

The problem still occurs in linuxrc. I think there is a pending file operation so the umount waits for that, causing the delay.

I tried adding a "sync" command, to flush file buffers, before the umount, but then it hangs at the sync command.

Then I tried adding a sync after each file copy as follows:

Code: Select all

				if [ $CHNEXIT = EXIT -o "`egrep -o " changes-ro( |\$)" /proc/cmdline`" ]; then
					CHNEXIT=$CHNDEV/$LPTH; echo $CHNEXIT >/tmp/changes-exit
					param changes-ro && echo $i"[1;36m""changes will not be saved for this session""[0m" || echo $i"[1;36m""changes will be saved only during reboot/shutdown""[0m"
					for x in `find /memory/changes -name ".wh.*" | grep -v '.wh..wh..opq' | tr ' ' '@' `; do 
						x=`echo $x | tr '@' ' ' `; 
						cp -a --parents "$x" /var; 
						sync; <------ ADDED LINE
					done
					umount /memory/changes; 

However, now it hangs on the sync after the first file in the loop is copied. The rest of the files copy and sync quickly and the umount occurs quickly.

I also tried adding the "-l" flag to the umount to force a lazy unmount and that did not seem to work.

I am kind of fishing here. Is there some flag I can add to the mount command to prevent this delay? I will probably look in the preceding code in linuxrc to find if there is a file operation there that could be causing it.

[mattl]

I found a solution (workaround?) for this delay on boot during unmount while setting up the saved.dat container. I am going to save changes into a module, using "sudo /opt/porteus-scripts/save-changes saved.xzm", instead of using the saved.dat container. This solves the problem by avoiding it.

I never found the reason for delay of about 40 seconds. I assume it was a corrupted saved.dat container, but I did not prove this by create a new container and copying the files over.