Page 1 of 1
Troubleshooting a delay in booting Porteus due to unmounting changes
Posted: 04 May 2023, 02:20
by 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
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?
Troubleshooting a delay in booting Porteus due to unmounting changes
Posted: 04 May 2023, 04:24
by Ed_P
Just a guess but see if adding the cheatcode reboot=cold helps.
Troubleshooting a delay in booting Porteus due to unmounting changes
Posted: 05 May 2023, 01:17
by 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.
Troubleshooting a delay in booting Porteus due to unmounting changes
Posted: 05 May 2023, 01:17
by mattl
Thanks Ed_P!
Troubleshooting a delay in booting Porteus due to unmounting changes
Posted: 05 May 2023, 22:39
by 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?
Troubleshooting a delay in booting Porteus due to unmounting changes
Posted: 06 May 2023, 00:30
by Ed_P
mattl wrote: ↑05 May 2023, 22:39
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.
Troubleshooting a delay in booting Porteus due to unmounting changes
Posted: 24 May 2023, 03:07
by 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.
Troubleshooting a delay in booting Porteus due to unmounting changes
Posted: 24 Dec 2023, 19:56
by 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.