Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Thu 21 Nov 2019, 09:30
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
BionicDog (updated: 2018-06-04)
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 54 of 57 [844 Posts]   Goto page: Previous 1, 2, 3, ..., 52, 53, 54, 55, 56, 57 Next
Author Message
wiak

Joined: 11 Dec 2007
Posts: 1830
Location: not Bulgaria

PostPosted: Mon 15 Apr 2019, 21:44    Post subject:  

fredx181 wrote:
already mounted ro, mount --bind -o ro makes no difference then IMO.
But I'll study some more on it in the next days.

Fred


Sorry Fred, only got my android phone here just now. I wrote wrong lines above... Yes 01-filesystem.squashfs read only mounted to tmp1... I was meaning the changes stuff in tmpa ought to be mounted readonly. I.e. ignore tmp1 it is fine, but tmpa should be mounted read-only prior to the remaster (this is rubbish, see EDIT2 below - my memory was deserting me till I got back on actual computer... Smile )

EDIT2:
Quote:
makes it already mounted ro, because the source /mnt/live/memory/images/01-filesystem.squashfs is already mounted ro, mount --bind -o ro makes no difference then IMO.


Yes, you are correct. I got mixed up and what I wrote in last post was junk.

Back on XenialDog64 now and see my memory let me down and I've been writing rubbish since tmpa is not the changes info (its the aufs merge), rather $BRANCH contains the changes info. tmp1 is indeed readonly after existing mount line so should stay as it already is and $BRANCH needs to be writable so cleanup function works. I'm thinking further about this cos I'm more clued up on overlayfs just now than aufs... but seems maybe best to leave all as stands for now anyway! That's the trouble with using an android phone and making bold statements when not near my actual computer Wink

I hate to add more since my last thinking was so astray, but I guess if ever there was a problem with something writing directly to $BRANCH (the changes info) then that could in fact be bind mounted readonly to some other empty mount point and then an extra writable layer added in the mount aufs line such that cleanup function could still work okay (on aufs merged tmpa directory). Anyway - I need a whisky.

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
fredx181


Joined: 11 Dec 2013
Posts: 4165
Location: holland

PostPosted: Tue 16 Apr 2019, 15:03    Post subject:  

No problem wiak !
Code:
Anyway - I need a whisky

Me too after trying to investigate this difficult stuff (but it's very interesting though) Wink

The most ideal would be to use mount bind '/' , something like this (which (newer) quick-remastergui has included, btw:
Code:
# create directories:
mkdir tmpa
for i in $(find / -maxdepth 1 -mindepth 1 -type d 2> /dev/null); do
mkdir tmpa${i} 2> /dev/null
done
# mount bind selection of dirs from / to tmpa
for i in $(find / -maxdepth 1 -mindepth 1 -type d -not -name tmp  -not -name mnt -not -name media -not -name sys -not -name run -not -name dev -not -name live -not -name proc 2> /dev/null); do
mount --bind $i tmpa${i}
done

But then, if possible (I think it should, but don't know how), if you do for example:
Code:
touch /root/newfile

that 'newfile' doesn't appear in tmpa/root, in other words that the mountpoint tmpa is binded, but sort of "fixated" by not showing any changes that are made in '/'
Mount read-only by using "mount --bind -o ro $i tmpa${i}" doesn't make a difference.
Maybe you have some thoughts (I'm almost sure you do Laughing ) ?

Fred

_________________
Dog Linux website
Tinylinux blog by wiak
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1830
Location: not Bulgaria

PostPosted: Tue 16 Apr 2019, 17:48    Post subject:  

fredx181 wrote:

Mount read-only by using "mount --bind -o ro $i tmpa${i}" doesn't make a difference.
Maybe you have some thoughts (I'm almost sure you do Laughing ) ?

Fred


Oh yeah, I see from 'man mount' page:

Quote:
Note that the filesystem mount options will remain the same as those on the original mount point, and cannot be changed by passing the -o option along with --bind/--rbind. The mount options can be changed by a separate remount command, for example:

mount --bind olddir newdir
mount -o remount,ro newdir


wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
fredx181


Joined: 11 Dec 2013
Posts: 4165
Location: holland

PostPosted: Tue 16 Apr 2019, 18:07    Post subject:  

Hi wiak,

Quote:
mount --bind olddir newdir
mount -o remount,ro newdir


Yes, then newdir is mounted read-only (cannot make changes there), but what I'm looking for is that when some file is added to - or changed in olddir, that this change doesn't appear in newdir.
Maybe this cannot be accomplished with mount bind itself, could be that it's possible with aufs or overlayfs, didn't find out yet.

Fred

_________________
Dog Linux website
Tinylinux blog by wiak
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1830
Location: not Bulgaria

PostPosted: Tue 16 Apr 2019, 18:30    Post subject:  

fredx181 wrote:
Hi wiak,

Quote:
mount --bind olddir newdir
mount -o remount,ro newdir


Yes, then newdir is mounted read-only (cannot make changes there), but what I'm looking for is that when some file is added to - or changed in olddir, that this change doesn't appear in newdir.
Maybe this cannot be accomplished with mount bind itself, could be that it's possible with aufs or overlayfs, didn't find out yet.

Fred


I understand what you mean; I'll think about it too. EDIT: I've explored that slightly in the past with overlayfs - but I can't remember whether direct changes to a layer were reflected up to the merge or not in my various trys. I understand that you don't want the 'reflection'.

Also see a different issue concerning aufs not being able to nest other aufs layers (whereas overlayfs can) I bring up here:

http://murga-linux.com/puppy/viewtopic.php?p=1025496#1025496

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1830
Location: not Bulgaria

PostPosted: Tue 16 Apr 2019, 18:43    Post subject:  

@Fred: Following my EDITed above post.

I understand you don't want the reflection up to merged layer when something written direcly to an underlying layer. Doubt its possible with bind alone (but that's just off the top of my head); with aufs maybe the =ro option for the relevant layer prevents further reflection after direct to layer writes? Not sure about that (still to test) or about when overlayfs used instead yet.

EDIT: For overlayfs such change apparently may or may not be reflected - according to kernel overlayfs documentation the result is 'undefined':

Quote:
Changes to the underlying filesystems while part of a mounted overlay
filesystem are not allowed. If the underlying filesystem is changed,
the behavior of the overlay is undefined, though it will not result in
a crash or deadlock.


EDIT: no I think that for aufs the =ro layer option is only from the point of view of the merge result layer in that it tells aufs whether writes to merge layer can be written directly to relevant lower layer or whether a copy-up of file to writable upper layer is necessary (but again I haven't yet checked this). Basically I presently don't see how to achieve what you want... please let me know if you find solution! Smile

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1830
Location: not Bulgaria

PostPosted: Tue 16 Apr 2019, 19:20    Post subject:  

@Fred: for aufs, it might be something to do with:

Code:
udba=none | reval | inotify

Specifies the level of UDBA (User's Direct Branch Access) test. (cf. User's Direct Branch Access and Inotify Limitation).


so maybe udba=none stops the reflection up (I'm just guessing but will try that).

wiak

EDIT: Nah... I tried:

Code:
cd /mnt/live/tmp
mkdir lower upper overlay
mount -t aufs -o br=/mnt/live/tmp/lower=ro:/mnt/live/tmp/upper=rw -o udba=none none /mnt/live/tmp/overlay


but 'touch lower/filea' still resulted in filea being reflected up and seen in overlay merge.

Also checked:

https://www.thegeekstuff.com/2013/05/linux-aufs/

which talks about meaning of udba options.
====

EDIT: So I can't find a way to make a bind copy that doesn't reflect what is changed in olddir. So neither with bind, aufs,or overlayfs have I found a way to keep say a 'changes' directory read-only whilst a remaster is being performed - I thought a bind,ro would do it, but like you say, it doesn't.

EDIT2: I imagine you could simply do a chroot with the newfoldet inside that protected from changes to outside oldfolder. Or some container technology - for example, pflask that rufwoof mentioned on my recent overlayfs how to thread.

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
PeteAir


Joined: 01 May 2009
Posts: 43
Location: Texas

PostPosted: Tue 11 Jun 2019, 20:59    Post subject: A few small problems with Bionicdog  

This is Bionicdog64.

1.When I go to opt/docs/pictures and right click a .jpg to open with mtpaint I get error cannot open file. When I open mtpaint from the menu and use open file from the bar then files open.

2. Geany will not load from the menu, in terminal I get geany: error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory
What is the fix?

Thanks Pete
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3631

PostPosted: Tue 11 Jun 2019, 22:27    Post subject:  

Check the /usr/share/applications file for mtpaint.desktop. Not using bionicdog myself but recall that the default mtpaint.desktop used to have something like a %U when it should be a %F as the Exec launch parameter - which caused a problem such as you're experiencing.

Exec=mtpaint %F

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 2161

PostPosted: Tue 11 Jun 2019, 22:50    Post subject:  

rufwoof wrote:
Check the /usr/share/applications file for mtpaint.desktop. Not using bionicdog myself but recall that the default mtpaint.desktop used to have something like a %U when it should be a %F as the Exec launch parameter - which caused a problem such as you're experiencing.

Exec=mtpaint %F


As a side note pcmanfm understands URLs pointing to files but in my opinion, rox is better in many ways.

_________________
Find me on minds and on pearltrees.
Back to top
View user's profile Send private message Visit poster's website 
fredx181


Joined: 11 Dec 2013
Posts: 4165
Location: holland

PostPosted: Wed 12 Jun 2019, 03:04    Post subject: Re: A few small problems with Bionicdog  

PeteAir wrote:
This is Bionicdog64.

1.When I go to opt/docs/pictures and right click a .jpg to open with mtpaint I get error cannot open file. When I open mtpaint from the menu and use open file from the bar then files open.

2. Geany will not load from the menu, in terminal I get geany: error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory
What is the fix?

Thanks Pete


Hi Pete, for mtpaint 'open with', the fix that rufwoof suggested works, but the error from geany I cannot reproduce, works fine for me on latest BionicDog64 (BionicDog64_2018-06-04-firmware_all.iso)
You use the same BionicDog64 version ?

Fred

_________________
Dog Linux website
Tinylinux blog by wiak
Back to top
View user's profile Send private message 
PeteAir


Joined: 01 May 2009
Posts: 43
Location: Texas

PostPosted: Wed 12 Jun 2019, 06:12    Post subject:  

Thanks rufwoof, that fixed mtpaint,
Yes fredx181, that is the same one {BionicDog64_2018-06-04-firmware_all.iso} with pcmanfm+lxpanel, I have searched and have not found anyone else with this geany problem. The only ref. I found to libpcre.so.1 was run as spot for chrom.

Thanks pete
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1830
Location: not Bulgaria

PostPosted: Wed 12 Jun 2019, 07:45    Post subject:  

PeteAir wrote:
1 was run as spot for chrom.


"spot"... suggests use of BionicPup, not BionicDog? But other description sounds like BionicDog... Maybe I didn't understand the comment about "spot" though.

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
PeteAir


Joined: 01 May 2009
Posts: 43
Location: Texas

PostPosted: Wed 12 Jun 2019, 09:17    Post subject: A few small problems with Bionicdog (SOLVED)  

Fixed it! Dog was missing the symbolic link from libpcre.so.1 to
libpcre.so.3 located in /lib/x86_64-linux-gnu folder. Once there geany works fine. They way I found this was to look in bionicpup that I have installed on this same laptop.

Thanks pete
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1830
Location: not Bulgaria

PostPosted: Thu 13 Jun 2019, 02:42    Post subject: Re: A few small problems with Bionicdog (SOLVED)  

PeteAir wrote:
Fixed it! Dog was missing the symbolic link from libpcre.so.1 to
libpcre.so.3 located in /lib/x86_64-linux-gnu folder. Once there geany works fine. They way I found this was to look in bionicpup that I have installed on this same laptop.

Thanks pete


That's a bit odd pete. I just did a fresh install of BionicDog64 and geany started fine from the Menu. I also checked with ldd and result was:

Code:
libpcre.so.1 => /lib/x86_64-linux-gnu/libpcre.so.1 (0x00007fdd34a5f000)


So symlink is there in the iso and yes, it is actually a symlink to /lib/x86_64-linux-gnu/libpcre.so.3 (which itself is a symlink to /lib/x86_64-linux-gnu/libpcre.so.3.13.3). The provided geany version is 1.28. I guess you must have accidentally deleted the original symlink somehow.

Anyway, thanks for bringing BionicDog64 thread back up. I've been meaning to upgrade to it from my old XenialDog64 install and now have finally done it. XenialDog was fine but BionicDog comes with iuplua, which I wanted by default (despite it no longer being newest version of iuplua).

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 54 of 57 [844 Posts]   Goto page: Previous 1, 2, 3, ..., 52, 53, 54, 55, 56, 57 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1848s ][ Queries: 12 (0.0718s) ][ GZIP on ]