Bind mounts do the same job as links. Links are better.!

For discussions about programming, programming questions/advice, and projects that don't really have anything to do with Puppy.
Message
Author
User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#16 Post by sunburnt »

The O.S. on HD or USB, but could do CD-DVD boot too of course.
A CD and DVD are storage devices, but can boot an O.S. into ram well.

Base O.S. is 2 files like Murga`s Puppy with Sq. inside the image.gz file.
The kernel extracts a cpio file to initrdfs, and an image file to a ramdisk.
A ramdisk is simple, initrdfs is more complex and definitely overkill.
Root FS is dirs., links, and Sq. file(s), so a fixed size ramdisk of ~ 40 MB.
AppPkgs. can be loaded/unloaded in ram or not to manage the ram usage.

/bin, /lib, /sbin, and most of /usr are in a Sq. file or files. No union FS.
/dev, /mnt, /proc, /sys, /tmp are in image.gz and extracted to the ramdisk.
/etc, /home, /opt, /root, /var on partition, /usr/etc + /usr/local/etc => /etc.
/usr/share could be on partition, but AppPkg using a union it`s in a Sq. file.

O.S. has simple desktop and utilities, other WMs and desktops in AppPkgs.


# I`m no M$ fan, but they saw value in having a junction link in Windows...
.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#17 Post by amigo »

What do you mean by junction link in Windows? Windows doesn't even have symbolic links. A Windows 'shortcut' is a real file which contains 'directions' to the item short-cutted item.

Wouldn't it be simpler to create you setup so that anything the user wants can simply be installed including dependencies, using dpkg and that file would then all reside on the USB stick or HD? The maximum implementation of modularity is achieved with normal packages. I only create AppDirs where the nature of the application indictates the utility of it.

Under Puppy, most AppDirs wind up acting simply as shortcits to start a program. I mean the special edvantages of using an AppDir are not implemented or used at all. I use an AppDir when I want nice drag-n-drop functionality or a switchable default behaviour -right click to change options. Most Puppy stuff uses a complex right-click or default MIME-type script to offer such options. For instance, under Puppy, when you click on an html file, you might get a pop-up menu which lets you choose between opening the file with a browser or with an editor.

I find it nicer to simply have an AppDir for each -if I want to edit something I drop it on the editor AppDir. If I want to view it with a browser I drop it on the browser AppDir. These AppDirs don't necessarily *contain* the application. Instead, the AppDir provides a versatile, configurable way to access the application. This actually follows the original RISC/ROX concept -where the user is able to focus on *his files* and not the programs he uses to manipulate them. What I mean is this: the user always knows where his files are -right where he saved them. He can find them much easier than first finding an app to manipulate them, opening that app, then using the apps 'Open' feature to (again) browse to where the file is that he wants to open.

Another example. I created an AppDir which consists of just scripting for working with archives. If you drop a file or a directory on it, then it offers option windows for creation of an archive. If you drop an archive(or compressed file) on it, then it offers options for decompressing the archive or file.

Do you see the way the interaction with the user is turned around? It keeps a normal user from having to navigate through the bin dirs for apps. It also avoids navigating through menus -once the AppDir is on the desktop it is always easily available. Some folks like a GUI without any taskbar or menu at all.

Hope you don't think I'm trying to provoke you in a mean way or even convince you of a certain view of things. I'm just trying to tickle your brain as go along...

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#18 Post by sunburnt »

No no, it`s all "food for thought". MU made a number of desktop DnD apps.
And this is an excellent use of the AppDir concept, though a very simple one.
It`s very nice having "things" in dirs. and Sq., can even drop AppDirs on AppDirs!

Puppy doesn`t really need AppDir or RoxApp, SFS files do well in Precise and Slacko.
Puppy has a lot of utilities to deal with SFS files, booting, load/unload, upgrade, etc.

It`s good using dpkg to build AppPkgs, but for installing apps. the target O.S. must have it.
AppPkg doesn`t assume the target O.S. has any installed infrastructure, as none is needed.
To go the "installed" infrastructure route, then I`d put it in an AppPkg ( so it`s not installed ).
So then all the AppPkg apps. rely on an AppPkg dep. to work ( not really what I had in mind ).

2 intentions for AppPkg, app. portability ( for compatible O.S.s ), and for my AppPkg only O.S.
With AppPkg handling all of it`s functioning itself, the O.S. needs few installed utilities ( lean ).

Working from the file point of view is definitely much better than access through menus.
Puppy`s ROX right-click could be improved a lot though. Whatever menu type, sub menus suck.

Some like desktop icons, and some want a clean DT. I like the idea of many slide-out panels.
I posted a concept of labeled colored bars anywhere along the screen sides. hover to slide-out.
On a single left side panel: desktop buttons, drive/partition buttons, task-bar buttons, and tray.
Task-bar and drive/partition buttons are stacked vertically so lots of them fit in a small space.
Another left side panel bar labeled menu is a slide-out apps. menu that can also be DnD on.
Desktop icons get covered up, but the bars and panels are on-top, so drag-hover-select-drop.
Desktop icons are messy, slide-out panels organize items and the desktop`s clean and pristine.


### M$ junction is not a shortcut: http://en.wikipedia.org/wiki/NTFS_junction_point


### P.S.: Can`t seem to get Chrome to work, it should work.
I had no trouble getting it to work the old way with links. :?
Error and line 17 of google-chrome wrapper script:

Code: Select all

/usr/bin/google-chrome: line 17: /dev/null: Permission denied
Failed to open /dev/null

if ! which xdg-settings &> /dev/null; then
It`s looking for installed xdg utilities:
# We include some xdg utilities next to the binary, and we want to prefer them
# over the system versions when we know the system versions are very old. We
# detect whether the system xdg utilities are sufficiently new to be likely to
# work for us by looking for xdg-settings. If we find it, we leave $PATH alone,
# so that the system xdg utilities (including any distro patches) will be used.
I tried running a modified command in rxvt ( it works okay...):

Code: Select all

sh-4.1# if ! which xdg-settings &> /dev/null; then echo GOOD ;fi
GOOD
I checked the union dir. and everything seems to be there.
I don`t see how the union or chroot would make /dev/null inaccessible.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#19 Post by amigo »

The NTFS junction seem to be simple links -actually less-feature than linux symlinks in every way and do not provide a multi-target capability. They do introduce a term -reparse junction which is useful for the discussion, since any such multi-link-target capability will require parsing the optioanl points and deciding according to priorities which file should be linked to -must not forget handling the possibility that none of the possible links are valid/present.

About /dev/null, that is strange. Is chrome running as root or non-privileged user? Is the execution being done by a wrapper script? If so, llok for /dev/null in there to see more of what is going on.

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#20 Post by sunburnt »

If none of the paths in a j-Link have the target dir. or file, it`s the same as any "not found" error.

Yes, the wrapper script errors at line 17 ( shown in post above ).
I thought about if unionfs-fuse was messing with the allowed users.
So I tried running it with the option:

Code: Select all

-o allow_other         allow access to other users
It made no difference.

gparted is always been a real pickle to get working also, "Buss error".
I didn`t think gparted is complex, uses lots of libs. But should be simple.

I`m guessing mPlayer and Handbrake will be lots of fun too.
Had good luck with music players, simpler? Not screwed up intentionally?

# If this is how the complex apps. go, the AppPkg builder becomes a tool.
Making build scripts for apps. is probably pointless, they keep changing.

### So the Linux O.S. is not the Linux problem, the damn apps. are.!!!
.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#21 Post by amigo »

Hmm, you may be needing to mount /proc in the chroot so that needed stuff is avialable -like /proc/partitions, /proc/mounts and others.
chroot, mount /proc, then exec the app...

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#22 Post by sunburnt »

Thanks amigo; I don`t intend to bother you with diagnosing apps.

Here`s the run file:

Code: Select all

chroot $Pkg/$Pkg.u /proc
$@
./setup &

# The error is completely different:
chroot: can't execute '/proc': Permission denied
./run: line 2: google-chrome: command not found
No change when I tried it with: unionfs-fuse -o allow_other

### Update: I put "pwd" and "ls" commands to test it.
I had to use "sleep 30" as "read K" didn`t work inside the chroot.
Here`s the errors:

Code: Select all

#  Mount Union:  chrome-24_i386.u
/

ls: cannot access /usr/bin/google-chrome: No such file or directory

ls: cannot access /opt/google/chrome/google-chrome: No such file or directory

./run: line 9: google-chrome: command not found
But when I look in the union`s paths the files ARE there.!!!

# I`m going to start another forum thread for help with these apps.
.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#23 Post by amigo »

"can't execute '/proc'"
The last errors are because the chroot is failing. This does all relate to the method you are trying. You need to mount proc inside the chroot. The last argument to chroot is the command to run inside the chroot -/bin/sh would be the 'manual' way to enter the chroot. Since you need to run more than one comand, you can cat them together into a variable:
CHROOT_CMD="mount /proc; mount /sys; ..."

$@
./setup &
Is this script receiving some parameters in $@? And, is the setup script really in '/' of the chroot?

Try setting up a chroot manually so you can get in there and see better what is going on and how it works. You shouldn't be needing to use LD_LIBRARY_PATH at all.
Last edited by amigo on Wed 23 Jan 2013, 08:25, edited 1 time in total.

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#24 Post by sunburnt »

Chroot, that`s what I thought, the union seems to be working ( more or less...).

I tried your suggestion on Chrome and Xfe and both jam at the chroot command and I have to unmount it all.
Xfe runs with the original commands, but can`t find /share stuff ( it`s there...) and /.Choices permission error.
Xfe isn`t a complex app., just icons and a config. file in /share.

xMahjongg runs nice and fast, no problems ( I guess not that odd...).
And it`s using the original commands:

Code: Select all

chroot $Pkg/$Pkg.u $@
./setup &
The thing that I noticed that amazed me was, the setup file is outside the chroot, but it still runs.!!!
There`s a lot of wacky stuff going on with this setup, need to get a handle on it for it to be useful.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#25 Post by amigo »

My, you are up early! You posted as I was editing my last post.
Really, try setting one up manually so you can really understand the union and then the chroot. Use a simpler example -xmahjongg should be good -it probably writes to /var/games (scores) and maybe looks for a conf file besides /usr/bin and /usr/lib?

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#26 Post by sunburnt »

It`s 2 am here but I stay up late a bit, I`m about to go to sleep.

The chroot wants an exec., it doesn`t jam if I use: chroot (union) pwd

xMahjongg has no config. or /var files, just game graphics in /share
Xfe runs but can`t find some deps. in /share ( what`s different? )
Chrome can`t even find it`s main exec. script: google-chrome
And it reports:

Code: Select all

/ ( pwd command )
mount: proc already mounted
./run: line 3: google-chrome: command not found
It sounds like your saying a bunch of stuff needs mounting for it to find files in the union?

As I said, the files are there, the union does seem to be working.
Chroot looks to be the bugger upper, it seems to mess with file access.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#27 Post by amigo »

A couple of questions? Where did you get chrome from? Is it packaged in some way as a *.deb?

I think mhddfs is not really the right tool -it expects every layer to be read-write which is not gonna be the case if using squahsfs *images*.
unionfs-fuse is also in the repos so you should be able to use it just as well -it's gonna provide better control.

Can you install chrome normally and verify that it actually works on your system? If so, we can go to next step by creating a normal chroot environment manually.

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#28 Post by Ibidem »

FYI, I'd enter a chroot with something like this (loosely based on my script plus a couple changes)

Code: Select all

#!/bin/sh
cd $1 && shift && \
for d in dev dev/pts proc sys
do
   mkdir $d ; mount --bind /$d ./$d
done
mkdir etc; cp /etc/resolv.conf etc/
chroot ./ $@
dev/pts is mainly for terminals, sys is rarely needed (only for runtime configuration of the kernel), proc is usually not needed. You may want to add dev/shm for shared memory, delete resolv.conf to prevent network access, add etc/hosts or etc/fstab, or $HOME/somedir, and so on.
Usage would be about like so:

Code: Select all

chrootin /opt/chrome  /usr/bin/chromewrapper http://www.murga-linux.com/puppy
where /opt/chrome/usr/bin/chromewrapper is the command executed.
Note the need to add a shell inside the chroot if you want to run scripts!

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#29 Post by sunburnt »

amigo; From Google for Ubuntu: https://www.google.com/intl/en/chrome/browser/

After I posted the 3 AppPkg scripts I changed to unionfs-fuse from Ubuntu Precise.
Both it and mhddfs had the same problem of the files not being found.
The 2 commands I`ve tried:

Code: Select all

#	unionfs-fuse $Pkg/$Pkg.rw=RW:$Pkg/$Pkg.app=RO:/=RO $Pkg/$Pkg.u
	unionfs-fuse -o allow_other $Pkg/$Pkg.rw=RW:$Pkg/$Pkg.app=RO:/=RO $Pkg/$Pkg.u
I`m posting this from Chrome-24 that I originally got working with my "Links & Paths" method.


Ibidem; This is a union setup: a Save layer ( dir.) on a Chrome layer ( Sq. file ) on /.
chroot to / should allow a normal operating system shouldn`t it?
I look at the union and all the files are there: Save, Chrome, and /.
But the run script errors saying it can`t find the Chrome wrapper script.


If it takes a lot of code to make this work, then it`s not much better than my "Links & Paths" method.

My starting criteria was: 1 method that will work for everything ( a Silver Bullet ).

Tiny Core has scm apps., I noticed that they use many different methods for making them.

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#30 Post by Ibidem »

sunburnt wrote: The 2 commands I`ve tried:

Code: Select all

#	unionfs-fuse $Pkg/$Pkg.rw=RW:$Pkg/$Pkg.app=RO:/=RO $Pkg/$Pkg.u
	unionfs-fuse -o allow_other $Pkg/$Pkg.rw=RW:$Pkg/$Pkg.app=RO:/=RO $Pkg/$Pkg.u
I`m posting this from Chrome-24 that I originally got working with my "Links & Paths" method.


Ibidem; This is a union setup: a Save layer ( dir.) on a Chrome layer ( Sq. file ) on /.
chroot to / should allow a normal operating system shouldn`t it?
I look at the union and all the files are there: Save, Chrome, and /.
But the run script errors saying it can`t find the Chrome wrapper script.


If it takes a lot of code to make this work, then it`s not much better than my "Links & Paths" method.
Looking at the command line I think you're mounting the union including / on an app directory, rather than on /.
In other words, after all the union stuff finishes, you need to have a union root with an appdir layer. Instead, you have / as a layer in a union appdir. This will only work if you somehow remount stuff in different locations (I know it's possible...) or chroot in.

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#31 Post by sunburnt »

Ibidem; Correct. My post on the first page shows the 3 files that run it ( It`s old now ).

First is a unique script that exports the pkg. name+ver., runs script 2 passing app. exec. and args.
Second is a generic script, mounts Sq. files and unionfs-fuse, runs script 3 passing app. exec. and args.
Third is a generic tiny ( 31 b ) "hook" script that does chroot and runs the app`s. exec.

There`s a RW config. dir. layer, on a RO app. dir. layer, on a RO / layer, all on a union dir.
Chroot into the union dir. and all 3 layers should be accessible as / . Right?
I look at the union dir. and all of the layers ARE there. Chroot isn`t playing nice.
xMahjongg runs just fine in this setup, but so far nothing else works.

### I`m now thinking of different ways to use the union without chroot.
I thought of 5 unions, Save layers mounted on each: /etc, /var, /opt, /root, /usr/share
Each of them like this: unionfs-fuse /tmp/OS/etc=RW:/tmp/OS/sq.mnt/etc=RO /etc
Links in /etc point to the AppPkg /etc dir. So the config. files are in AppPkg.

Also 1 union like Puppy ( chroot ) with a Save layer of only configs. and links on / .
No App. installs in Save because there`s no need to with AppPkgs.

For Puppy I`ve said before that there should be 2 Save files, for configs. and apps.
.

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#32 Post by greengeek »

sunburnt wrote:I like the idea of many slide-out panels.
I posted a concept of labeled colored bars anywhere along the screen sides. hover to slide-out.
On a single left side panel: desktop buttons, drive/partition buttons, task-bar buttons, and tray.
Task-bar and drive/partition buttons are stacked vertically so lots of them fit in a small space.
Another left side panel bar labeled menu is a slide-out apps. menu that can also be DnD on.
Desktop icons get covered up, but the bars and panels are on-top, so drag-hover-select-drop.
Desktop icons are messy, slide-out panels organize items and the desktop`s clean and pristine.
Excellent idea, especially for netbooks.

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#33 Post by greengeek »

sunburnt wrote:For Puppy I`ve said before that there should be 2 Save files, for configs. and apps.
.
Another excellent idea - config files could contain all personal info (wireless key etc) and be completely separate from other app additions (and hopefully portable to all future puppies...)

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#34 Post by sunburnt »

Thanks greengeek; All "loose file" apps. in one layer, and everything else in the other.

Portable to the future... Never gonna happen, they keep changing everything.
JWM has changed, and the apps. change for no reason at all it seems.
GTK folks redo all kinds of stuff on a regular basis, and so do many others.
Only the base Linux O.S. stuff stays the same, neer as I can tell...

Standards. IF they don`t wanna, it`s okay, then they`re just not compatible.
What if Firefox`s user base fell because they didn`t follow "app. standards".
Last edited by sunburnt on Thu 24 Jan 2013, 07:50, edited 1 time in total.

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#35 Post by jpeps »

Exactly. It's a much better idea to keep backups and config notes somewhere that you can browse before screwing up the new distro. It's way too easy to forget what you've configured.

Post Reply