blender3d

If you are looking for a specific 64-bit package and you can't find it in any of the 64-bit repos, please post a request for it here
User avatar
ncmprhnsbl
DEV Team
DEV Team
Posts: 3679
Joined: 20 Mar 2012, 03:42
Distribution: v5.0-64bit
Location: australia
Contact:

blender3d

Post#16 by ncmprhnsbl » 31 Oct 2022, 23:53

the most likely culprit is in the save1.dat .. the quick way to test this is boot with the changes cheatcode (either 'alway fresh' or hit TAB at the boot screen remove the changes=* )
if this is the case it shouldn't be too hard to fix..
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44

coa
Black ninja
Black ninja
Posts: 33
Joined: 13 Oct 2022, 16:41
Distribution: porteus 5.0 cinnamon
Contact:

blender3d

Post#17 by coa » 01 Nov 2022, 03:57

hi i tried booting fresh and blender works then.. but i dont know why?

User avatar
ncmprhnsbl
DEV Team
DEV Team
Posts: 3679
Joined: 20 Mar 2012, 03:42
Distribution: v5.0-64bit
Location: australia
Contact:

blender3d

Post#18 by ncmprhnsbl » 01 Nov 2022, 12:06

coa wrote:
01 Nov 2022, 03:57
hi i tried booting fresh and blender works then.. but i dont know why?
:) , from this distance i can only guess..
usually, when this sort of thing happens, it's to do with files that exist in modules, being deleted in the live system, causing a file called a 'whiteout' to be created and stored in changes (the changes file or folder)..
so that, even though the files still exist in the module, when the changes file or folder is loaded (which is always after or 'on top' of modules) , the whiteout 'whites out' that file ..
you can get this happening in the live system without even using changes (because the live system records changes, whether or not they are saved) eg. activate a module, delete some file belonging to it, deactivate it and reactivate it, and that file will still be missing.. (until a reboot)
what to do?
the quick and dirty fix is to copy the files back from the module (or to be more exact from the module mounted in memory) which should 'unwhiteout' them
in this case: (as root in a terminal, using changes with blender activated)

Code: Select all

cp /mnt/live/memory/images/blender-3.4.0-x86_64-en-US.xzm/usr/share/applications/blender.desktop /usr/share/applications/
cp /mnt/live/memory/images/blender-3.4.0-x86_64-en-US.xzm/usr/bin/blender /usr/bin/
presuming that's all that's missing...
why this fix is dirty, is that those files will now be present in changes, whether the module is activated or not ..
but.. i guess, if you now deactivate the blender module, and then delete these files, because they don't correspond to files in a module, they shouldn't create a new whiteout.. maybe?

disclaimer: i never use changes beyond basic testing and someone who does may have a better way to clean out whiteouts.. (if this is actually the problem here)
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44

coa
Black ninja
Black ninja
Posts: 33
Joined: 13 Oct 2022, 16:41
Distribution: porteus 5.0 cinnamon
Contact:

blender3d

Post#19 by coa » 01 Nov 2022, 14:57

thanks for trying to help
i dont know if you understand you but i tried the cp command as you suggestied but no luck

i got this notice to i do not know what it means
cp: not writing through dangling symlink '/usr/bin/blender'
Last edited by coa on 01 Nov 2022, 15:59, edited 2 times in total.

User avatar
gnintilgyes
Black ninja
Black ninja
Posts: 74
Joined: 14 Sep 2022, 17:52
Distribution: Porteus v5 MATE/Cinnamon

blender3d

Post#20 by gnintilgyes » 01 Nov 2022, 15:38

I don't know that much about the innards of the system, but maybe copy the entire XZM contents into "rootcopy" and restart?

Otherwise there should have been more "cp" commands than were shown. If everything is copied directly into "/usr/bin" or whatever and it still doesn't work, then, well...
ncmprhnsbl wrote:
01 Nov 2022, 12:06
usually, when this sort of thing happens, it's to do with files that exist in modules, being deleted in the live system, causing a file called a 'whiteout' to be created and stored in changes (the changes file or folder)..
so that, even though the files still exist in the module, when the changes file or folder is loaded (which is always after or 'on top' of modules)
I learned something else valuable today about Porteus. This should serve as a valuable lesson for somebody to understand to know what he/she is doing.

User avatar
Rava
Contributor
Contributor
Posts: 4414
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.0 x86_64 + 4.0 i586
Location: Forests of Germany

blender3d

Post#21 by Rava » 02 Nov 2022, 04:48

ncmprhnsbl wrote:
01 Nov 2022, 12:06
the whiteout 'whites out' that file ..
you can get this happening in the live system without even using changes (because the live system records changes, whether or not they are saved) eg. activate a module, delete some file belonging to it, deactivate it and reactivate it, and that file will still be missing.. (until a reboot)
Good to know, this happened to me more than once and since I never use changes= myself, I thought it must be some kind of mechanism how Porteus handles its modules and what is done when files in there got deleted in the live system - as you cannot delete files in the squashfs itself since these are all read-only.
Now I better know the background to all that (I suspected it must be something similar to what ncmprhnsbl described…) but it's better knowing these things than just suspecting something in a more or less vague way.

Anyhow, where is this whiteout thingy defined?
Is it part of 001-core.xzm ?
Cheers!
Yours Rava

coa
Black ninja
Black ninja
Posts: 33
Joined: 13 Oct 2022, 16:41
Distribution: porteus 5.0 cinnamon
Contact:

blender3d

Post#22 by coa » 02 Nov 2022, 05:14

thanks for all help! i got it to work by your suggestion ncmprhnsbl
i could not understand first what i should do.
learned alot about porteus in the progress
Last edited by coa on 02 Nov 2022, 05:43, edited 1 time in total.

User avatar
Ed_P
Contributor
Contributor
Posts: 7323
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 4.0 & 5.0 ISOs
Location: Western NY, USA

blender3d

Post#23 by Ed_P » 02 Nov 2022, 05:27

This is how I handle whiteout files.

Code: Select all

#!/bin/sh 
# https://forum.porteus.org/viewtopic.php?f=81&t=3501&p=25151#p25162  <- USM problem 
# https://forum.porteus.org/viewtopic.php?f=81&t=3501&p=25151#p25178
# https://forum.porteus.org/viewtopic.php?f=81&t=5698#p43823

#  mloop requires changes= cheatcodes not be used (Always Fresh mode)
#  nor modsavedat/porteussave.dat.xzm!!

#set -x;

SAVEDAT=50save.dat    # porteussave.dat

# http://forum.porteus.org/viewtopic.php?f=53&t=3801&start=30#p28472
BOOT=`grep -A1 "Porteus data found in:" /var/log/porteus-livedbg|tail -n1|sed 's^//^/^g'`
DRV=${BOOT:5:4}
if [ "$DRV" == "nvme" ]; then
   DRV=${BOOT:5:9}
fi 
VERSION=$(cat /etc/porteus-version)
SYSTM=porteus${VERSION:9:3}

if [ "${BOOT:0:12}" == "/mnt/isoloop" ]; then
   ISOBOOT=`grep -A1 "//porteus" /var/log/porteus-livedbg`
   SYSTM="${ISOBOOT:11:10}"
   DRV=${ISOBOOT:5:4}
   if [ "$DRV" == "nvme" ]; then
      SYSTM="${ISOBOOT:16:10}"
      DRV=${ISOBOOT:5:9}
   fi
fi 

BOOTDEV=/mnt/$DRV
FOLDER=$SYSTM     
GUEST="$BOOTDEV/$FOLDER/Guest"
MODULES="$BOOTDEV/$FOLDER/Modules"

if [ `whoami` != "root" ]; then
   echo -e "Enter root's password\033[1;31m"
   su -c "sh $0 $1 $2"; exit
fi
echo -e "\033[0m"; echo -en "\033]0;Remove .wh files\a" 

if [ "$1" == "" ]; then
   if [ -a /mnt/live/memory/images/changes ]; then
      SPACEDATDIR=/mnt/live/memory/images/changes 
   else
      echo mloop $BOOTDEV/$FOLDER/changes/$SAVEDAT
      mloop $BOOTDEV/$FOLDER/changes/$SAVEDAT
      SPACEDATDIR=/mnt/loop
   fi
else
   echo mloop $1
   mloop $1
   SPACEDATDIR=/mnt/loop
fi

if [ ! -d ${SPACEDATDIR}/home ]; then 
   echo " Error!! "
   dmesg | tail > t
   UUIDck=$(grep -c "duplicate UUID" t) 
   if [ ! "$UUIDck" == "0" ]; then
      echo
      echo " * This is NOT Always Fresh mode. * "
      echo
   else 
      echo
      echo "dmesg | tail "
      dmesg | tail  
   fi
   rm t
   uloop
   exit
fi


echo find ${SPACEDATDIR} -name .wh.*
find ${SPACEDATDIR} -name .wh.*
echo
echo -en "Enter 1 to delete, 2 to exit.\n"
select yn in "Yes" "No"; do
   case $yn in
        Yes ) echo "find ${SPACEDATDIR}/home -name .wh.* -delete"
              find ${SPACEDATDIR}/home -name ".wh.*" -delete
              find ${SPACEDATDIR}/usr  -name ".wh.*" -delete
              find ${SPACEDATDIR}/var  -name ".wh.*" -delete
              echo
              echo find ${SPACEDATDIR} -name .wh.*
              find ${SPACEDATDIR} -name .wh.*
              break;;
        No )  break;; 
   esac
done

echo "Press Enter to exit"
read
if [ -a /mnt/live/memory/images/changes ]; then
   exit
else
   uloop 
fi
#exit
Ed

User avatar
Rava
Contributor
Contributor
Posts: 4414
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.0 x86_64 + 4.0 i586
Location: Forests of Germany

blender3d

Post#24 by Rava » 02 Nov 2022, 06:27

Thanks for the script, Ed_P, but…
Ed_P wrote:
02 Nov 2022, 05:27
VERSION=$(cat /etc/porteus-version)
SYSTM=porteus${VERSION:9:3}
SYSTM would report a wrong version number if we get a similar version like we did with Porteus 3.2.2

Look for yourself. Setting up a Port version in " /etc/porteus-version-TEST"

Code: Select all

root@porteus:/# echo Porteus-v5.2.2 > /etc/porteus-version-TEST
root@porteus:/# cat /etc/porteus-version-TEST
Porteus-v5.2.2
and then test how your code would process that:

Code: Select all

guest@porteus:~$ VERSION=$(cat /etc/porteus-version-TEST)
guest@porteus:~$ SYSTM=porteus${VERSION:9:3}
guest@porteus:~$ echo $SYSTM
porteus5.2
When you use SYSTM=porteus${VERSION:9} instead it would work for all kinds of sub-versions (e.g. 5.2.2) as well as main versions (e.g. 5.0).

Look for yourself. SYSTM=porteus${VERSION:9} handles both "5.0" and "5.2.2" correct:

Code: Select all

guest@porteus:~$ head /etc/porteus-version /etc/porteus-version-TEST 
==> /etc/porteus-version <==
Porteus-v5.0

==> /etc/porteus-version-TEST <==
Porteus-v5.2.2
guest@porteus:~$ VERSION=$(cat /etc/porteus-version-TEST)
guest@porteus:~$ SYSTM=porteus${VERSION:9}
guest@porteus:~$ echo $SYSTM
porteus5.2.2
guest@porteus:~$ VERSION=$(cat /etc/porteus-version)
guest@porteus:~$ SYSTM=porteus${VERSION:9}
guest@porteus:~$ echo $SYSTM
porteus5.0
HTH.
Cheers!
Yours Rava

User avatar
Ed_P
Contributor
Contributor
Posts: 7323
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 4.0 & 5.0 ISOs
Location: Western NY, USA

blender3d

Post#25 by Ed_P » 02 Nov 2022, 15:42

Rava wrote:
02 Nov 2022, 06:27
When you use SYSTM=porteus${VERSION:9} instead it would work for all kinds of sub-versions (e.g. 5.2.2) as well as main versions (e.g. 5.0).
Thank you Rava. Not sure when I added the ":3". But it does work for all of my porteus folders.

Code: Select all

guest@porteus:/mnt/nvme0n1p7$ ls -doh porteus*
drwxrwxrwx 1 guest 4.0K Jan 10  2018 porteus3.0/
drwxrwxrwx 1 guest 8.0K Jan 25  2020 porteus3.2/
drwxrwxrwx 1 guest 8.0K Mar 25  2022 porteus4.0/
drwxrwxrwx 1 guest 4.0K Oct 17 00:29 porteus5.0/
drwxrwxrwx 1 guest  20K Feb  7  2022 porteusold5.0/
guest@porteus:/mnt/nvme0n1p7$ 
Ed

User avatar
gnintilgyes
Black ninja
Black ninja
Posts: 74
Joined: 14 Sep 2022, 17:52
Distribution: Porteus v5 MATE/Cinnamon

blender3d

Post#26 by gnintilgyes » 02 Nov 2022, 18:04

Ed_P wrote:
02 Nov 2022, 05:27
This is how I handle whiteout files.
Thank you for this script. But "SAVEDAT" should be changed to the actual name of my "savefile"?

I'm sorry, I'm asking because I'm not sure about this.

But if I have a dedicated "ext4" partition for the "/porteus/changes" then it's just looking for the *.wh files and deleting them? Or which ones to delete? Anyway I'd rather have something like this script taking care of it.

User avatar
Ed_P
Contributor
Contributor
Posts: 7323
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 4.0 & 5.0 ISOs
Location: Western NY, USA

blender3d

Post#27 by Ed_P » 02 Nov 2022, 22:56

gnintilgyes wrote:
02 Nov 2022, 18:04
"SAVEDAT" should be changed to the actual name of my "savefile"?
Yes. :happy62:
gnintilgyes wrote:
02 Nov 2022, 18:04
I'm sorry, I'm asking because I'm not sure about this.
No reason to be sorry, asking is a safe way to learn. I asked a lot when I started here 10 yrs ago. I was new to Linux not just Porteus.

The script works for me which is why I posted it. And it does have a yes/no option before deleting the files so you can see how many files are involved before choosing to delete them or to skip doing it.

If your changes are on an ext4 drive I don't know what your file is called. I've never used an ext4 drive and to the best of my knowledge the save.dat file is only used on FAT/NTFS drives.
Ed

Post Reply