Puppy Linux Discussion Forum

I have noticed this problem for a few months, but I only realised today what is happening because I had to learn about aufs and mount -t squashfs -o loop ...etc

since compiling 6+ kernels, I couldn't load an sfs after boot. So today I looked at load_sfs.sh and changed one function then everything worked again.

find_free_loop() {
	export FREELOOP=$(losetup -f | cut -f2 -d'p')
	#local in_use 
	#in_use=$(losetup -a | sed 's/:.*//; s|^.*/||' | tr '\n' '+')
	
	#FREELOOP=$RESERVED
	#while [ $FREELOOP -le $MAXLOOP ]; do
		#case "$in_use" in
			#*"loop${FREELOOP}+"*) 
				#FREELOOP=$((FREELOOP+1)); 
				#continue ;;
		#esac
		#break
	#done
}

It's not getting the free loop device correctly, my simple code gets it.

Errr ... that works, but there is a reason why the complicated code exists.
We don't want to hog the loop devices less than 10.
That's why we test form 10, going upwards.

What is the failure, anyway?
Can you tell me what you see when you run "losetup -a" under kernel 6.x?

oh! .... i just did a pristine boot with peebee's 6.3 and no problem!

previously System SFS load reported unsuccessful using loop16 (that's when i changed the code and it used loop2) .... so i checked permissions for loop16, and was not the same as loop15, so my /dev/loop16 was corrupted! False alarm.....my apologies for not investigating fully in the first place!

No worries, glad to see it sorts itself out.